研发流程建模的起点是圈定范围：先列出要建模的流程清单，为每条流程写明触发事件、起点、终点和最终交付物；再把流程拆成阶段、活动、角色、输入输出和判定条件，形成可评审的模型；最后选一条流程试点，用实际工作项和评审记录校验模型能否执行，再逐步推广。建模的核心产物是一份能落到角色和交付物上的流程模型，流程图只是它的表达形式之一。
要点总览（TL;DR）
- 研发流程建模从圈定范围开始：按业务链路列出待建模流程清单，为每条流程写明触发事件、起点、终点和最终交付物，再排优先级。
- 拆解分两层：先按交付物形态变化或关键决策点划分阶段，再按“一个角色在一次交接内可完成”的标准拆活动，并标注执行角色、评审角色和交接输出。
- 每个活动补齐输入物、输出物、进入与退出条件、完成证据和异常返工路径，判定条件要写成可观察的检查项。
- 建模工作由流程负责人牵头，领域专家提供业务事实，质量或过程角色把关可检查性，发布后明确维护人和变更触发条件。
- 模型建好后先选一条流程和一个团队试点，用实际工作项与评审记录核对一致性，修订形成版本后再分批推广。
先定建模范围和流程边界
研发流程建模常见的失败方式，是一开始就画一张覆盖全研发链路的流程图。图越画越大，角色和交付物却说不清楚，评审时无人能判断对错。更稳妥的做法是先定范围，把“这次要建哪些流程、每条流程管到哪里”写成文字，再进入拆解。
第一步是按业务链路列出待建模流程清单。可以从需求进入研发到版本发布的链路出发，逐段识别流程，例如需求评审、技术方案设计、开发与自测、代码评审、测试验证、发布上线。清单不必一次列全，但要覆盖当前最需要标准化的环节。列完后排优先级，判断依据可以包括：该流程当前问题是否集中、涉及角色是否多、交付物是否直接影响下游、是否已有可参照的做法。
第二步是为每条流程写明边界。边界说明至少包含四项：触发事件（什么情况下流程启动）、起点（第一个动作或第一份输入）、终点（流程结束的标志）、最终交付物（流程对下游或对客户交付什么）。例如“需求评审”流程的触发事件可以是需求提出方提交评审申请，起点是评审材料准备完成，终点是评审结论形成并通知相关方，最终交付物是带结论和待办项的需求评审记录。
第三步是明确本次建模不覆盖的范围。单个工作项的状态流转操作、个人任务安排、工具按钮怎么点，通常不属于组织共用流程的建模对象。把这些排除在外，可以避免模型被操作细节淹没，也便于后续把流程模型与工具配置分开维护。
| 流程名称 | 触发事件 | 起点 | 终点 | 最终交付物 | 优先级 |
|---|---|---|---|---|---|
| 需求评审 | 需求提出方提交评审申请 | 评审材料准备完成 | 评审结论形成并通知相关方 | 需求评审记录（含结论与待办） | 高 |
| 技术方案设计 | 需求评审通过并进入设计 | 设计任务分派到负责人 | 方案评审通过 | 技术方案文档及评审意见 | 高 |
| 开发与自测 | 方案评审通过 | 开发任务拆解完成 | 自测通过并提交代码评审 | 可评审的代码变更与自测记录 | 中 |
| 测试验证 | 代码评审通过并提测 | 测试环境与用例就绪 | 测试报告出具 | 测试报告与缺陷清单 | 高 |
这张表就是范围界定的交付物。它让后续拆解有明确对象，也让评审者能先判断“流程选得对不对”，再判断“流程拆得细不细”。
把流程拆成阶段、活动与角色
范围确定后，进入流程建模的核心拆解。拆解分两层：先分阶段，再分活动，同时把角色和交接点标出来。阶段回答“流程大致经过几个大的形态变化”，活动回答“每个阶段里谁在什么条件下做什么”。
阶段划分可以依据交付物形态变化或关键决策点。交付物从“评审记录”变成“技术方案”，再变成“代码变更”，再变成“测试报告”，这些形态变化天然形成阶段边界。关键决策点同样可以作为阶段分界，例如“方案是否通过评审”“是否允许提测”“是否允许发布”。阶段数量不宜过多，一条中等复杂度的研发流程通常控制在四到七个阶段，便于沟通和检查。
活动颗粒度用一个标准判断：一个角色在一次交接内可以完成。如果一项工作需要在多个角色之间来回传递，或者需要等待另一个角色的输出才能继续，就应拆成两个活动。颗粒度过细会让模型维护成本上升，颗粒度过粗则无法定位责任和证据。可以用“活动完成后能否交出一份可检查的产物”作为辅助判断。
角色与职责要区分执行角色和评审角色。执行角色对活动产出负责，评审角色对活动是否满足退出条件给出结论。同一个岗位在不同活动中可能承担不同角色，建模时应按活动标注，而不是按部门笼统标注。交接点需要写清输入、输出和接收方：上游活动交出什么、下游活动接收什么、接收方以什么方式确认收到并可用。
| 阶段 | 活动 | 执行角色 | 评审角色 | 交接输出 | 接收方 |
|---|---|---|---|---|---|
| 需求确认 | 准备评审材料 | 需求提出方 | — | 需求说明与验收要点 | 评审组织者 |
| 需求确认 | 组织需求评审 | 评审组织者 | 产品、研发、测试代表 | 评审结论与待办清单 | 需求提出方、研发负责人 |
| 方案设计 | 编写技术方案 | 方案负责人 | — | 技术方案文档 | 评审人 |
| 方案设计 | 方案评审 | 方案负责人 | 架构或技术负责人 | 评审意见与通过结论 | 开发负责人 |
| 开发交付 | 开发与自测 | 开发人员 | — | 代码变更与自测记录 | 代码评审人 |
| 开发交付 | 代码评审 | 代码评审人 | 模块负责人 | 评审意见与合入结论 | 测试负责人 |
这张阶段-活动-角色分解表是流程模型的骨架。它把“谁在哪个阶段交出什么、交给谁”固定下来，后续字段定义都挂在这张表上。
定义活动字段：输入、输出、判定条件与证据
只有阶段和活动名称，模型仍然不可执行。每个活动需要补齐字段，让执行者知道什么时候可以开始、做到什么程度算完成、完成后留下什么可检查的记录。字段定义建议统一口径，避免不同活动各写一套。
输入物与输出物是基础字段。输入物写清活动开始前必须具备的材料或前置结论，输出物写清活动结束后产生的文档、记录或工作项状态。输入输出应尽量指向具体对象，例如“需求评审记录”“技术方案文档”“测试报告”，而不是“相关资料”这类无法核对的表述。
进入条件与退出条件构成判定条件。进入条件回答“满足什么才能开始”，退出条件回答“满足什么才算完成”。判定条件要可观察，例如“评审意见全部关闭”“自测用例执行完毕且无阻塞缺陷”“测试报告经测试负责人确认”。无法观察的条件，如“质量达到要求”，应转化为具体检查项。
完成证据是模型可检查的关键。常见形式包括评审记录、文档版本、测试报告、缺陷清单、变更记录。建模时为每个活动指定证据形式，并说明证据保存在哪里、由谁确认。证据形式不必复杂，但要能回答“如果事后检查，拿什么证明这个活动确实做过且达到退出条件”。
异常与返工路径同样需要记录。评审未通过、测试发现阻塞缺陷、方案需要重大调整，这些情况在模型中应有明确走向：回到哪个活动、由谁决定、需要补充什么证据、返工后如何重新进入评审。把返工路径写进模型，可以避免实际执行时靠口头协调。
| 字段 | 填写要求 | 示例 |
|---|---|---|
| 输入物 | 活动开始前必须具备的具体对象 | 需求说明、验收要点、历史评审意见 |
| 输出物 | 活动结束后产生的具体对象 | 需求评审记录、待办清单 |
| 进入条件 | 可观察的开始前提 | 评审材料已提交且评审人已确认参会 |
| 退出条件 | 可观察的完成标准 | 评审结论已记录，待办项均已指定负责人和期限 |
| 完成证据 | 可事后检查的记录形式 | 评审记录文档、结论通知 |
| 异常路径 | 未满足退出条件时的走向 | 评审未通过则退回材料准备，补充后重新评审 |
角色分工与交付物责任
流程建模本身也是一项有角色分工的工作。把建模角色和流程执行角色分开看，可以避免“谁执行谁随便写”导致模型缺乏一致性。通常需要三类角色参与。
流程负责人牵头建模。其职责包括确定建模范围、组织拆解、汇总字段定义、推动评审和发布。流程负责人对模型整体一致性负责，交付物是流程清单、边界说明和流程模型文档。领域专家提供业务事实，包括实际做法、常见异常、角色设置和交付物形态。领域专家不需要写完整模型，但要对本领域活动的输入输出和判定条件给出确认。质量或过程角色把关可检查性，重点看判定条件是否可观察、证据形式是否可留存、返工路径是否闭合。
建模工作本身也需要评审。评审方式可以是集中评审会，也可以是逐条流程的书面评审。评审对象是流程模型文档，评审结论应记录为通过、有条件通过或退回修改，并保留修改意见和关闭情况。评审通过后形成发布版本，版本号与生效范围一并记录。
流程发布后需要明确维护责任。维护责任包括：谁接收流程执行中的问题反馈、谁判断是否需要修订、修订后由谁评审和发布。变更触发条件可以包括组织角色调整、交付物形式变化、试点或执行中发现模型与实际做法不一致、下游流程发生变更。维护机制不必复杂，但应写清触发条件和责任人，避免模型发布后长期无人更新。
| 建模角色 | 主要职责 | 交付物 |
|---|---|---|
| 流程负责人 | 牵头范围界定、组织拆解、汇总模型、推动评审与发布 | 流程清单、边界说明、流程模型文档、发布版本 |
| 领域专家 | 提供实际做法、异常情况和角色设置，确认本领域字段 | 领域活动说明、输入输出确认意见 |
| 质量或过程角色 | 检查判定条件可观察性、证据可留存性和返工路径闭合性 | 评审意见、可检查性检查记录 |
| 流程维护人 | 接收反馈、判断修订需求、组织变更评审 | 变更记录、修订版本 |
示例：一条需求到发布流程的建模片段
下面用“需求评审到开发交付”的一段流程示范字段怎么填。示例只覆盖片段，目的是让读者看到模型如何从阶段落到活动字段，不代替完整流程。
阶段一为需求确认。活动“组织需求评审”的执行角色是评审组织者，评审角色包括产品、研发、测试代表。输入物为需求说明、验收要点和评审议程；输出物为评审结论与待办清单。进入条件是评审材料已提交且评审人已确认参会；退出条件是评审结论已记录、待办项均已指定负责人和期限。完成证据为评审记录文档和结论通知。异常路径：若评审未通过，退回“准备评审材料”活动，由需求提出方补充材料后重新组织评审，返工记录附在原评审记录之后。
阶段二为方案设计。活动“方案评审”的执行角色是方案负责人，评审角色是架构或技术负责人。输入物为技术方案文档和需求评审结论；输出物为评审意见与通过结论。进入条件是技术方案文档已提交且覆盖需求评审中的待办项；退出条件是评审意见全部关闭或明确转为后续任务。完成证据为方案文档版本和评审意见记录。异常路径：若方案需要重大调整，退回“编写技术方案”，调整后重新评审，并在评审记录中标注调整原因。
阶段三为开发交付。活动“代码评审”的执行角色是代码评审人，评审角色是模块负责人。输入物为代码变更和自测记录；输出物为评审意见与合入结论。进入条件是自测用例执行完毕且无阻塞缺陷；退出条件是评审意见关闭并完成合入。完成证据为代码评审记录和合入记录。异常路径：若评审发现阻塞问题，退回开发人员修改并重新自测，再进入代码评审。
这个片段展示了三个要点：每个活动都有明确的输入输出；判定条件写成可观察的检查项；返工路径指向具体活动而不是笼统写“重新处理”。读者可以按同样结构补充测试验证和发布阶段，形成完整模型。
试点运行与模型校验
模型建好后，先不要全量推广。选取一条流程和一个团队试点，用实际运行结果校验模型是否可执行。试点流程宜选择问题集中、角色配合度较高、交付物相对清晰的流程；试点团队宜覆盖该流程的主要执行角色，规模不必大，但要能跑完至少一个完整周期。
试点期间，用实际工作项和评审记录核对模型与实际做法是否一致。核对重点包括：活动是否按模型顺序发生、角色是否按模型承担职责、输入物是否在活动开始前到位、退出条件是否被实际检查、证据是否留存、返工是否按模型路径走。发现不一致时，先判断是模型写错了，还是执行偏离了模型。模型写错就修订模型；执行偏离则记录原因，判断是否需要补充说明或调整角色设置。
试点结束后形成校验记录，列出发现的问题、修订内容和修订后的版本。模型修订应保留版本记录，说明改了什么、为什么改、影响哪些活动。修订后的模型再经过一次评审，确认可执行后再逐步推广到其他团队或相关流程。
在协作平台中承载流程运行时，可以把阶段、活动、角色和状态落到工作项与文档上，让工作项流转对应活动推进，让评审记录和变更记录随工作项留存。这样试点校验时可以直接调取实际记录，而不必依赖事后回忆。ONES 这类研发管理平台可以承载工作项、文档和评审记录的管理动作，具体配置方式应结合组织现有流程和工具环境确定。工具承载的是流程运行记录，模型本身仍需由流程负责人维护和评审。
建模完成检查清单
发布推广前，用下面这份清单逐项核对。清单的作用是判断模型是否达到可执行、可检查、可维护的状态，而不是追求文档篇幅。
| 检查项 | 核对内容 | 通过标准 |
|---|---|---|
| 流程边界 | 每条流程是否有触发事件、起点、终点和最终交付物 | 四项齐全，且与流程清单一致 |
| 阶段划分 | 阶段是否依据交付物形态变化或关键决策点划分 | 阶段数量适中，边界可解释 |
| 活动拆解 | 活动是否满足“一个角色在一次交接内可完成” | 无跨角色来回传递的粗活动 |
| 角色职责 | 执行角色与评审角色是否按活动标注 | 每个活动都有明确执行者和评审者 |
| 输入输出 | 每个活动是否写清输入物和输出物 | 指向具体对象，可核对 |
| 判定条件 | 进入条件与退出条件是否可观察 | 无“质量达标”等无法检查的表述 |
| 完成证据 | 每个活动是否指定证据形式和保存方式 | 事后可调取、可确认 |
| 异常路径 | 返工和异常是否有明确走向 | 指向具体活动，有决定人和补充证据要求 |
| 维护责任 | 是否明确维护人、变更触发条件和评审方式 | 发布后有责任人和更新机制 |
| 试点校验 | 是否完成试点并留有校验记录 | 有修订版本和评审结论 |
清单全部通过后，流程模型可以进入发布推广。推广时建议按优先级分批进行，每批发布后保留反馈渠道，把执行中发现的问题纳入下一轮修订。这样流程模型才能随着组织实际做法持续更新，而不是停留在一次性的文档里。
常见问题
流程建模时，阶段和活动拆到什么程度算合适？
阶段按交付物形态变化或关键决策点划分，一条中等复杂度的研发流程通常控制在四到七个阶段。活动用一个标准判断：一个角色在一次交接内可以完成。需要多个角色来回传递，或要等待另一个角色输出才能继续的工作，应拆成两个活动。
如果活动完成后交不出一份可检查的产物，说明拆得偏粗；如果活动细到需要单独维护大量字段却无人核对，说明拆得过细。可以先用一条流程试拆，再根据试点反馈调整颗粒度。
流程模型里的判定条件怎么写才可检查？
把无法观察的表述转化为具体检查项。例如“质量达到要求”可以改为“评审意见全部关闭”“自测用例执行完毕且无阻塞缺陷”“测试报告经测试负责人确认”。
进入条件和退出条件都要指向可核对的对象或结论，并为每个活动指定证据形式，如评审记录、文档版本、测试报告、缺陷清单。事后检查时能调取这些记录，判定条件才算真正落地。
试点发现模型与实际做法不一致，应该改模型还是改执行？
先判断不一致的来源。如果是模型写错了，例如活动顺序与实际交付逻辑不符、角色设置遗漏，就修订模型并保留版本记录。如果是执行偏离了模型，则记录偏离原因，判断是说明不清、角色未落实，还是模型本身不具备可执行性。
两种情况都可能需要调整，关键是保留校验记录：列出发现的问题、修订内容、修订后的版本以及影响的活动，修订后再经过一次评审确认。
流程发布后由谁维护，什么时候需要修订？
发布时应明确流程维护人，负责接收执行中的问题反馈、判断是否需要修订、组织变更评审和发布。变更触发条件可以包括组织角色调整、交付物形式变化、试点或执行中发现模型与实际做法不一致、下游流程发生变更。
维护机制不必复杂，但要写清触发条件和责任人。每批推广后保留反馈渠道，把执行中发现的问题纳入下一轮修订，模型才能随组织实际做法持续更新。
流程模型和协作工具里的工作项配置是什么关系？
流程模型描述组织共用的阶段、活动、角色、输入输出和判定条件，是评审和发布的依据；工具里的工作项状态和流转是模型的一种运行承载方式。建模时先把模型定清楚，再考虑在协作平台中把阶段、活动、角色和状态落到工作项与文档上，让评审记录和变更记录随工作项留存。
两者分开维护的好处是：流程调整时先改模型并评审，工具配置随之更新，避免把操作细节混进流程定义。具体配置方式应结合组织现有流程和工具环境确定。
