研发流程建模，是把组织共用的研发活动、角色、输入输出、判断条件和状态流转写成一份可执行、可评审、可维护的流程模型。它要解决的是跨角色交接时“谁在什么时候做什么、做到什么程度算完成”的问题。本文按定范围、六步建模、角色分工、完整示例、完成检查的顺序展开，覆盖组织共用流程，不涉及单个工作项的状态操作。
要点总览（TL;DR）
- 先按共用程度和跨角色交接频次筛选流程，把多团队共用、交接点多的流程列为高优先级，单团队内部活动暂不建模。
- 建模按六步推进：定起止条件、梳理活动与交接点、定义输入输出与完成标志、定义状态与分支例外、评审定稿、真实项目试跑修订。
- 流程负责人对模型整体负责并维护版本，领域专家提供活动细节，执行角色确认可操作性，评审者把关一致性与例外覆盖。
- 模型可用的判断标准是活动输入输出齐全、角色责任明确、分支例外有覆盖、版本变更完整、试跑结果支撑定稿。
- 模型定稿后可在协作工具中承载活动、状态与交接，工具承载的是已定稿的模型，建模判断仍由各角色完成。
先定边界：哪些研发流程值得建模
建模的第一步是筛选对象。组织里的流程很多，但并非每条都需要写成正式模型。判断标准可以落在两个维度上：这条流程被多少个团队共用，以及它包含多少次跨角色交接。共用程度高、交接频次高的流程，最值得投入建模成本；只在一个小组内部流转、靠口头约定就能协调的活动，可以先不建模。
具体筛选时，可以按以下顺序过一遍现有流程：
- 列出当前实际在跑的研发流程，标注每条流程涉及的团队和角色数量。
- 标出跨角色交接点，统计一条流程从开始到结束要经过几次责任转移。
- 把“多团队共用且交接点超过三个”的流程列为高优先级，“单团队使用或交接点少”的列为低优先级或暂不建模。
- 对高优先级流程补充一句边界说明：从什么事件触发开始，到什么结果交付结束，中间不包含哪些相邻流程。
需要区分三类容易混淆的对象。第一类是单个工作项的状态配置，比如把某个任务从“进行中”改为“已完成”，这属于工具层面的操作，不构成流程建模。第二类是 IPD、ALM 等现成体系框架，它们提供的是整体框架和术语体系，本文不展开其介绍与选型；建模是在组织自身流程层面把活动写清楚。第三类是部门内部的习惯做法，如果没有跨角色交接，也不必上升为正式模型。
这一步的交付物是待建模流程清单，每条流程包含名称、涉及角色、交接点数量、优先级和边界说明。清单经过流程负责人确认后，才进入下一步。
建模六步：从活动梳理到模型定稿
范围确定后，按六个步骤推进。每一步都有明确的输入、动作、输出和完成标志，完成标志未达成时不进入下一步，避免模型带着模糊点往下走。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 1. 确定触发与结束条件 | 待建模流程清单中的边界说明 | 写清流程由什么事件启动、在什么结果出现时结束，明确不处理的相邻场景 | 触发条件与结束条件说明 | 流程负责人确认起止点无歧义 |
| 2. 梳理活动顺序与交接点 | 起止条件、现有做法记录 | 按实际发生顺序列出活动，标出每次责任转移的位置和交接内容 | 活动清单与交接点标注 | 每个交接点都能指出交出方、接收方和交接物 |
| 3. 定义输入、输出与完成标志 | 活动清单 | 为每个活动写明进入前需要什么、产出什么、达到什么状态算完成 | 活动定义表 | 每个活动三项齐全，无“视情况而定”的模糊表述 |
| 4. 定义状态、分支与例外路径 | 活动定义表 | 设定流程状态、判断分支条件，以及退回、终止、并行等例外路径 | 状态与分支规则 | 每条分支都有判断条件和去向，例外路径有处理角色 |
| 5. 组织评审并定稿 | 完整模型草稿 | 由领域专家、执行角色和评审者逐项核对一致性与可操作性，记录意见并修订 | 评审记录与定稿版本 | 评审意见全部关闭或有明确处理结论 |
| 6. 试跑与修订 | 定稿版本 | 选一个真实项目按模型执行，记录卡点、遗漏和多余环节 | 试跑记录与修订版模型 | 试跑中暴露的问题已修订，模型可再次执行 |
第三步是建模质量的分水岭。完成标志要写成可观察的结果，例如“需求说明通过评审并记录评审结论”，而不是“需求基本清楚”。第四步要特别处理例外：评审不通过退回哪一步、需求变更后回到哪个状态、并行活动之间如何同步，这些路径不写清楚，模型在实际执行中就会被绕开。
第六步的试跑不宜省略。选一条近期真实发生的流程走一遍，比在会议室里推演更能发现问题。试跑记录应包含每个活动的实际耗时、卡点位置和参与者的疑问，这些是修订的直接依据。
角色与交付物：谁建模、谁评审、谁维护
建模不是一个人写完就结束的工作。四类角色在过程中承担不同职责，各自有对应的交付物，职责悬空是模型后期失效的常见原因。
| 角色 | 主要职责 | 各阶段交付物 |
|---|---|---|
| 流程负责人 | 对模型整体负责，决定范围与优先级，主持评审，维护版本 | 待建模流程清单、评审结论、定稿版本、变更记录 |
| 领域专家 | 提供活动细节、判断条件和例外情况的实际做法 | 活动定义表初稿、分支与例外路径说明 |
| 执行角色 | 确认模型在实际工作中可操作，参与试跑并反馈卡点 | 可操作性意见、试跑记录 |
| 评审者 | 把关活动完整性、角色一致性、例外覆盖和表述清晰度 | 评审意见清单 |
流程负责人通常由对该流程结果负责的管理者担任，其核心交付物是版本与变更记录，而不是流程图本身。领域专家来自流程涉及的主要专业岗位，负责把“实际怎么做”讲清楚。执行角色是日常按模型工作的人，他们的确认决定模型能否落地。评审者可以包括质量、项目管理等岗位，重点检查一致性和例外覆盖。
模型定稿后，维护责任归流程负责人。任何变更都应走同一条路径：提出变更原因、评估影响范围、更新模型、记录版本说明、通知执行角色。变更记录至少包含变更日期、变更内容、影响的活动和批准人，这样后续追溯时能说清模型为什么是现在这个样子。
示例：一条需求到上线的流程模型怎么落地
下面用一条“需求到上线”的流程演示模型写法。示例为演示情景，用于说明字段与状态的填写方式，不代表特定组织的实际流程。
活动与角色。流程从需求提出触发，到版本上线结束，包含六个活动：需求提出（提出方）、需求评审（产品负责人主持，研发与测试参与）、方案设计（研发负责人）、开发实现（开发工程师）、测试验证（测试工程师）、上线发布（发布负责人）。交接点出现在需求评审通过后交给方案设计、开发完成后交给测试、测试通过后交给发布三个位置。
关键活动的输入输出与完成标志。以需求评审为例：输入是需求说明和背景材料，输出是评审结论与优先级，完成标志是评审记录中写明通过、退回或搁置，并指定后续责任人。以测试验证为例：输入是开发完成的版本和测试用例，输出是测试报告，完成标志是报告记录通过项、未通过项及处理结论。
状态与分支写法。需求状态可设为“待评审、评审中、已通过、已退回、开发中、测试中、待上线、已上线”。分支规则写明：评审不通过退回“待评审”并注明原因；测试发现阻断问题时回到“开发中”；上线前发现严重缺陷则暂停发布并回到“测试中”。例外路径包括需求在开发中变更，此时回到“评审中”重新确认范围。
评审与试跑中的修订。演示中，评审者指出“测试通过”缺少判定口径，修订后补充为“阻断问题为零且遗留问题有明确处理计划”。试跑时执行角色反馈方案设计与开发实现之间的交接物不明确，修订后在活动定义中增加“设计说明与接口约定”作为交接物。这两处修订都记入版本变更说明。
模型定稿后，需要在协作工具中承载活动、状态和交接，让执行角色按同一份定义推进工作。ONES 可用于承载这类流程中的工作项状态、角色分工与交接记录，具体能力以官方资料为准。工具承载的是已经定稿的模型，建模本身的判断仍由上述角色完成。
完成检查：模型可用的判断标准
模型是否达到可用状态，可以按下面这份清单逐项核对。全部通过再宣布定稿，未通过的项目回到对应步骤修订。
- 活动完整性：每个活动都有明确的输入、输出和完成标志，完成标志可观察、可记录。
- 角色责任：每个活动都有对应责任人，交接点写清交出方、接收方和交接物，没有“相关部门”这类模糊主体。
- 分支与例外：每条判断分支都有条件和去向，退回、终止、变更、并行等例外路径均有处理角色和后续状态。
- 状态定义：状态名称与活动对应，状态之间的流转规则与分支规则一致，不存在无法到达或无法退出的状态。
- 版本与变更：模型有版本号，变更记录包含日期、内容、影响范围和批准人。
- 试跑支撑：至少一个真实项目按模型执行过，试跑记录中的问题已修订或有明确处理结论。
- 评审闭环：评审意见全部关闭，未采纳的意见有书面理由。
这份清单同时可以作为后续复审的基线。流程运行一段时间后，若出现频繁绕行、状态长期停留或交接反复退回，说明模型需要修订，此时按变更路径更新版本，而不是在执行中各自变通。
常见问题
流程建模时，遇到多个部门对同一活动的做法不一致，应该怎么处理？
先把差异记录下来，而不是在建模会上直接投票选一种。做法是让每个部门说明自己这样做的原因和适用条件，判断差异来自业务场景不同还是历史习惯。如果来自场景不同，就在模型里写成两条分支，各自写明判断条件；如果只是习惯不同，由流程负责人结合评审意见确定统一做法，并在变更记录中说明取舍理由。差异处理完再定稿，避免模型写完后执行时各按各的习惯走。
流程模型定稿后，业务或组织调整导致流程变化，怎么更新才不至于混乱？
按变更路径处理：提出变更原因、评估影响范围、更新模型、记录版本说明、通知执行角色。评估影响范围时重点看这次变化涉及哪些活动、哪些交接点和哪些状态，受影响的执行角色要参与确认。版本说明至少写清变更日期、变更内容、影响的活动和批准人。如果变化较大，可以先在小范围试跑再全面推行，试跑记录作为新版本的支撑材料。
试跑时执行角色反映模型太细、操作负担重，应该简化还是保留？
先区分是模型本身冗余，还是执行角色不熟悉。判断方法是看试跑记录：如果某个活动的输入输出在实际工作中从未被使用，或者某个状态从未停留过，说明这一环节可以合并或删除；如果只是填写和确认动作多，但每个环节都有实际交接价值，就保留模型，改为在工具中减少重复录入。简化针对的是没有实际作用的环节，不针对有交接意义的控制点。
流程负责人由谁担任比较合适，能不能由项目管理办公室统一代管？
流程负责人通常由对该流程结果负责的管理者担任，这样范围取舍和版本维护才有决策依据。项目管理办公室可以承担建模方法支持、评审组织和版本归档，适合在多个流程并行建模时统一节奏。如果由项目管理办公室代管全部流程负责人职责，需要明确每个流程仍有对应的业务决策人，否则遇到范围争议和例外处理时容易悬空。组织规模较小时，一人兼多个流程负责人也可行，但每个流程的决策责任要写清楚。
模型里的状态和分支写到什么颗粒度才算够用？
以执行角色能据此判断下一步做什么为准。状态名称与活动对应，状态之间的流转规则与分支规则一致，每条分支都有判断条件和去向，退回、终止、变更、并行等例外路径都有处理角色。颗粒度不必细到每个操作按钮，但要让执行角色在遇到评审不通过、测试阻断、需求变更时知道回到哪个状态、由谁处理。写完可以用一条真实发生过的例外情况对照检查，看模型是否能给出明确去向。
