设计应用生命周期流程图，先要明确这张图给谁看、要回答什么问题，再按“阶段—活动—角色—交付物—评审门”五层结构展开，最后用泳道和状态标记把跨角色交接与异常回流画清楚。本文给出可直接执行的设计步骤、角色与交付物对应表、一段可参照的流程图片段和成图后的核对清单。流程图落地后需要承载阶段状态与评审记录时，可以借助 ONES 的工作项与文档管理来承接。
要点总览（TL;DR）
- 先写一页设计说明，明确流程图的主用途（阶段准入、角色交接或审计依据）、读者清单和覆盖边界，再开始画图。
- 按阶段、活动、角色、交付物、评审门五层展开，依次完成划分主干阶段、列活动与负责人、定义评审门、补回流路径、成图并统一图例五步。
- 用角色—阶段—交付物对应表固化交接关系，每个评审门写明准入证据、评审人和不通过处理方式，证据要可核对。
- 跨角色交接多时用泳道图作主图，关注单个工作项状态时用状态图补充；打回、返工、紧急发布三类回流用虚线画出并标注触发条件。
- 成图后按阶段完整性、评审门可执行、交接有输入输出、异常路径覆盖、图例命名统一、版本维护规则六项核对，不通过就回到对应步骤修正。
先定图的用途与边界：这张流程图要回答什么
流程图最常见的失败原因是画完没人用。动笔前先写一段设计说明，回答三个问题：这张图服务于哪类判断、读者是谁、覆盖到哪里为止。说明写清楚，后面的阶段粒度和标注详略才有依据。
三类典型用途，决定图的详略
- 阶段准入判断：读者在评审会上对照图确认“能不能进入下一阶段”。这类用途要求评审门、准入证据写得具体，活动描述可以粗一些。
- 角色交接说明：读者关心“我做完交给谁、交什么”。这类用途要求泳道清晰、每个交接点标注输入和输出物。
- 审计与评审依据：读者需要证明过程受控。这类用途要求交付物名称、责任人、记录留存位置可追溯，图例和版本规则要统一。
一张图可以同时服务三类用途，但要有主次。建议在说明里写明主用途，其余作为附带价值，避免为了兼顾所有读者把图填得过密。
覆盖边界：从需求提出到退役下线
本图覆盖单个应用从需求提出、设计开发、测试验证、发布上线、运行维护到退役下线的主干过程，以及阶段之间的评审与回流。以下内容不纳入本图：产品商业阶段与市场生命周期管理、单个缺陷或单个需求的处理流程、具体工具的功能对比。边界写进说明，可以避免评审时反复争论“这个要不要画”。
读者对象与各自关心的判断点
| 读者 | 关心的判断点 | 图中需要突出 |
|---|---|---|
| 研发 | 本阶段要完成哪些活动、达到什么条件才能提交评审 | 活动清单、评审门准入条件 |
| 测试 | 何时介入、测试通过的标准是什么、缺陷如何回流 | 测试阶段入口、回流路径 |
| 运维 | 发布前拿到什么、上线后承接什么 | 发布交接物、运维阶段活动 |
| 质量 | 每个评审门查什么证据、谁签字 | 评审门、证据类型、责任人 |
| 管理层 | 阶段状态、卡点在哪、责任归属 | 阶段划分、状态标记 |
完成标志：形成一页设计说明，包含用途（主用途与附带用途）、读者清单、覆盖边界与不覆盖事项，经流程相关角色确认后作为绘图依据。
核心答案与操作步骤：五层结构画出生命周期主干
五层结构指阶段、活动、角色、交付物、评审门。阶段是时间轴主干，活动是阶段内的动作，角色决定泳道，交付物是活动的产出，评审门是阶段之间的关卡。按下面五步依次完成，每步都有明确的输入、动作、输出和完成标志。
第一步：划分主干阶段
输入是设计说明中的覆盖边界。动作是把生命周期切成需求、设计、开发、测试、发布、运维、退役七个主干阶段。阶段粒度按“评审门能卡住”来取舍：一个阶段内如果存在两种明显不同的完成标准，就拆开；如果两个阶段总是同时评审、同一批人负责，可以合并。例如小团队可以把设计与开发合并为“设计开发”，但测试与发布建议分开，因为两者的准入证据不同。
输出是阶段清单，每个阶段一句话说明起止。完成标志：每个阶段都能回答“进入条件是什么、完成标志是什么”。
第二步：列出关键活动与负责人
输入是阶段清单。动作是逐阶段列出三到八项关键活动，每项活动标注一个负责人角色。活动写到可执行的程度，例如“编写接口设计说明”比“完成设计”更可用。负责人写角色而非姓名，便于图长期复用。
输出是“阶段—活动—负责人”清单。完成标志：每项活动都有唯一负责人，不存在无人负责的活动。
第三步：定义评审门与准入证据
输入是活动清单。动作是在阶段之间设置评审门，为每个门写明三件事：准入证据（需要提交哪些交付物）、评审人（谁有权放行）、不通过时的处理（打回上一阶段还是带条件放行）。证据要可核对，例如“测试报告含用例执行率与遗留缺陷清单”，而不是“测试完成”。
输出是评审门清单。完成标志：每个门都有证据类型、评审人和不通过处理方式。
第四步：补充异常回流路径
输入是主干流程与评审门。动作是画出三类回流：评审未通过打回上一阶段、测试或评审发现缺陷返工到开发、线上紧急问题触发紧急发布通道。每条回流路径标注触发条件和回流目标阶段，紧急通道还要写明事后补哪些记录。
输出是回流路径清单。完成标志：每条回流都有触发条件、目标阶段和记录要求。
第五步：选择表达方式并统一图例
输入是前四步的全部清单。动作是选择图形表达：跨角色交接多、需要看清“谁交给谁”时用泳道图，横向为阶段、纵向为角色；关注单个工作项状态流转时用状态图。两种图可以并存，泳道图作主图，状态图作补充。图例统一规定形状含义，例如矩形表示活动、菱形表示评审门、粗箭头表示主干、虚线箭头表示回流。
输出是成图与图例说明。完成标志：图中每个符号都能在图例中找到对应，任意两个角色之间的交接都能沿箭头读出输入和输出。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 一、划分阶段 | 设计说明与覆盖边界 | 切分七个主干阶段，说明起止 | 阶段清单 | 每阶段有进入条件与完成标志 |
| 二、列活动与负责人 | 阶段清单 | 逐阶段列关键活动，标注负责角色 | 阶段—活动—负责人清单 | 每项活动有唯一负责人 |
| 三、定义评审门 | 活动清单 | 设门，写证据、评审人、不通过处理 | 评审门清单 | 每门证据可核对 |
| 四、补回流路径 | 主干与评审门 | 画打回、返工、紧急发布三类回流 | 回流路径清单 | 每条回流有触发条件与记录要求 |
| 五、成图与图例 | 前四步清单 | 选泳道图或状态图，统一图例 | 成图与图例 | 符号与图例一一对应，交接可读 |
角色与交付物：谁在哪个阶段交付什么
流程图能否支撑跨角色交接，取决于角色与交付物是否固化成表。下表按阶段列出主要角色、关键动作、交接对象和评审门所需证据，可作为绘图时的填写底稿。角色名称按团队实际设置调整，职责划分保持一一对应。
| 阶段 | 主要角色 | 关键动作 | 交接对象 | 交付物与评审证据 |
|---|---|---|---|---|
| 需求 | 产品/需求负责人 | 收集需求、编写需求说明、组织需求评审 | 开发、测试 | 需求说明、优先级清单、需求评审记录 |
| 设计 | 开发（架构/设计人员） | 方案设计、接口与数据设计、设计评审 | 开发、测试、运维 | 设计说明、接口文档、设计评审结论 |
| 开发 | 开发 | 编码、自测、提交代码与构建 | 测试 | 代码与构建产物、自测记录、提测说明 |
| 测试 | 测试 | 编写用例、执行测试、提交缺陷、出具报告 | 开发、发布审批人 | 测试用例、缺陷清单、测试报告 |
| 发布 | 发布审批人、运维 | 发布评审、部署、验证、回滚预案确认 | 运维、质量 | 发布申请、回滚预案、发布验证记录 |
| 运维 | 运维 | 监控告警、事件处理、变更管理 | 开发、质量 | 监控记录、事件单、变更记录 |
| 退役 | 产品/需求负责人、运维 | 退役评估、数据归档、下线通知与执行 | 运维、质量 | 退役评估结论、归档记录、下线确认单 |
质量角色贯穿各评审门，负责核对证据完整性并记录评审结论；发布审批人对发布门放行负责。表中每个交付物都应能在评审门清单中找到对应的证据条目，反之亦然，两边对不上说明有一处遗漏。
这张表也是流程图落地后的管理对象。以 ONES ALM 研发管理方案为例，其围绕需求、基线、版本和变更建立统一管理对象，支撑需求变更影响分析、过程状态追踪和交付结果回溯；测试用例、缺陷、版本和发布过程可以关联到需求链路中，出现问题时便于定位影响范围。流程图中的阶段状态与评审记录因此有承载位置，标准流程、评审节点和交付物模板也可以沉淀为可复用资产，把规范转成项目中的执行流程。具体模块的开通与配置以实际部署为准。
示例：一条需求从提出到退役的流程图片段
以下为演示场景，用于说明标注方式，不代表真实项目。场景：某应用新增一项数据导出功能，从需求提出走到上线运维，后续随应用整体退役。
主干与标注方式
横向按阶段排开，纵向设产品、开发、测试、运维、质量五条泳道。需求阶段，产品泳道放“编写需求说明”矩形，箭头指向质量泳道的评审门菱形“需求评审”，菱形旁标注证据“需求说明＋评审记录”。设计阶段，开发泳道放“方案设计”与“设计评审”，评审通过后箭头进入开发泳道的“编码与自测”。测试阶段，测试泳道放“用例编写”“执行测试”“出具报告”，缺陷以虚线箭头回流到开发泳道的“修复”。发布阶段，运维泳道放“部署与验证”，质量泳道放发布门菱形，证据标注“测试报告＋回滚预案”。运维阶段，运维泳道放“监控与事件处理”。退役阶段，产品与运维泳道共同放“退役评估”与“下线执行”，质量泳道设退役门。
异常回流的画法
- 评审未通过：从评审门菱形引虚线箭头回到上一阶段的活动，箭头上标注“打回＋原因类别”，例如“需求评审未通过：范围不清”。
- 上线回滚：从发布阶段的“部署与验证”引虚线箭头回到发布门前，标注“回滚”，并在运维泳道补一个“回滚记录”交付物。
- 紧急发布：从运维阶段的“事件处理”引一条旁路箭头直达发布阶段，标注“紧急通道＋事后补评审记录”，避免紧急路径脱离流程管理。
可迁移的规律
这个片段的画法可以迁移到其他应用类型：主干阶段不变，活动按应用特点增减；评审门的证据类型随交付物调整，但“证据可核对、评审人有名、不通过有去向”三条保持不变；回流路径始终用虚线并与主干区分。应用规模较小时可以合并泳道，但合并后要确认每个交接点仍有明确的输入和输出。
完成检查：流程图是否可用的核对项
成图后按下面清单逐项核对，任一项不通过就回到对应步骤修正，修正后重新核对受影响的相邻项。
| 核对项 | 通过标准 | 不通过时的修正动作 |
|---|---|---|
| 阶段完整且无重叠 | 七个主干阶段齐全，相邻阶段起止衔接，无同一活动落在两个阶段 | 回到第一步，按评审门重新切分或合并阶段 |
| 评审门可执行 | 每个门有准入证据、评审人、不通过处理方式 | 回到第三步，补齐缺失的门要素 |
| 角色交接有输入输出 | 每条跨泳道箭头都能读出交付物名称 | 回到第二步与角色交付物表，补交付物或调整泳道 |
| 异常路径覆盖 | 打回、返工、紧急发布三类回流均已画出并有触发条件 | 回到第四步补充回流路径 |
| 图例与命名统一 | 符号含义唯一，活动与交付物命名全文一致 | 统一图例，按命名规则批量修订 |
| 版本维护规则明确 | 注明版本号、修订记录和责任人，变更时同步更新 | 在图角落加版本信息栏，指定维护人 |
核对通过后，把流程图与设计说明、角色交付物表放在一起发布，并在首次使用时收集读者反馈：评审会上是否真的对照图做准入判断、交接时是否按图确认交付物。若图被搁置不用，优先检查用途与读者是否定错，而不是继续增加细节。流程图承载的阶段状态和评审记录需要在日常工作中持续更新时，可以依托 ONES 的工作项状态与文档记录保持图与执行一致。
常见问题
小团队人手少，七个主干阶段可以合并吗？
可以合并，但合并的依据是评审门的准入证据是否相同，而不是人数多少。设计与开发如果由同一批人负责、共用一次评审，可以合并为“设计开发”；测试与发布建议分开，因为测试看的是用例执行与缺陷情况，发布看的是回滚预案与部署验证，两者的证据类型不同。合并后要重新确认每个交接点仍有明确的输入和输出，避免合并把责任边界一起抹掉。
流程图里的评审门设多少道比较合适？
评审门的数量由阶段之间的完成标准差异决定，没有统一数量。判断方法是看相邻两个阶段的准入证据是否明显不同：证据不同就设门，证据相同可以合并。门设得过多会让流程变慢，设得过少则阶段之间缺少把关。每个门至少写清三件事——准入证据、评审人、不通过时的处理方式，缺一项这道门就难以在评审会上实际使用。
紧急发布通道要不要画进流程图？
建议画进去，用旁路箭头从运维阶段的事件处理直达发布阶段，并标注“紧急通道＋事后补评审记录”。紧急发布如果不出现在图上，实际执行时就会脱离流程管理，事后也难以追溯。画出紧急通道的同时，要写明事后补哪些记录、由谁补、在什么时限内补，让这条路径仍然受控。
流程图发布后没人对照使用，应该怎么调整？
先检查用途和读者是否定错，再考虑增加细节。常见情况是图按“审计依据”的详略画成，但实际读者是研发和测试，他们需要的是活动清单和交接物，而不是证据留存位置。可以回到设计说明，重新确认主用途，删减与主用途无关的标注，把评审会上真正要对照的判断点放到显眼位置。图被搁置时继续加细节通常只会让问题更严重。
流程图落地后，阶段状态和评审记录怎么保持与图一致？
需要把图中的阶段、评审门和交付物对应到日常使用的管理对象上，让状态更新发生在工作过程中，而不是事后补图。以 ONES ALM 研发管理方案为例，其围绕需求、基线、版本和变更建立统一管理对象，支撑过程状态追踪和交付结果回溯，测试用例、缺陷、版本与发布过程可以关联到需求链路中；标准流程、评审节点和交付物模板也可以沉淀为可复用资产。这样流程图与执行记录有共同的承载位置，图变更时同步调整配置即可。具体模块的开通与配置以实际部署为准。
