设计研发流程图，先梳理组织共用的研发阶段、关键决策点和交付物，再确定泳道与角色分工，用统一符号画出主流程，最后通过评审、试点和版本维护让流程图真正被使用。流程图的价值在于让不同角色对同一套研发活动、输入输出和交接条件形成一致理解，因此设计顺序应是先定流程边界与阶段，再定角色与泳道，再定活动与交付物，最后定符号规范与评审机制。
要点总览（TL;DR）
- 研发流程图的设计顺序是：先定流程边界与阶段，再定角色泳道，再定活动与交付物，最后定符号规范与评审机制。
- 流程边界要写明覆盖阶段、起止点、适用团队和不纳入内容，把组织共用主流程与单项目操作分开。
- 阶段划分要同时定义阶段目标、关键决策点和进入/退出条件，只画活动不画判断会让流程图退化成任务清单。
- 泳道按角色或职能划分，跨泳道连线处标注交付物和完成条件，并配套角色—活动—交付物对照表。
- 定稿后经跨角色评审、小范围试点和版本维护，按检查清单逐项核对后再正式启用。
先定流程边界：画哪一段研发流程
动笔之前先回答一个问题：这张图画给谁看、覆盖哪一段。研发流程图通常服务于组织层面的流程共识，覆盖从需求立项到版本发布这一段主流程，参与对象包括产品、研发、测试、发布等角色。如果一开始就把某个项目的具体操作、某个工作项的状态流转画进去，图会迅速膨胀，读者反而看不清主干。
边界说明建议写成一段可核对的文字，包含四项内容：覆盖的阶段范围、流程起点与终点、适用的团队或产品线、明确不纳入的内容。例如起点定为“需求通过立项评审”，终点定为“版本发布并完成发布评审”，不纳入的内容写明“单个缺陷的修复流转、日常站会等团队内部操作”。这样后续讨论阶段和角色时，大家有共同的参照范围。
区分组织共用流程与单项目操作的关键，是看这条活动是否所有项目都要经过、是否有统一的输入输出和责任人。凡是因项目而异、由团队自行决定的做法，适合放到子流程或团队级说明中，主图只保留共性部分。完成标志是：边界说明经过流程负责人确认，且能回答“哪些内容画、哪些内容不画”。
拆解研发阶段与关键决策点
边界确定后，把范围内的研发过程拆成若干阶段，形成流程图的主干。阶段划分的依据是交付物的形态变化和管理关注点的转移，常见做法是需求、设计、开发、测试、发布几个阶段，具体数量和名称按组织实际调整。每个阶段要写清三件事：阶段目标、主要活动、阶段结束时产出的交付物。
阶段之间要设置关键决策点，也就是评审关口。决策点回答“这一步能不能进入下一阶段”，例如需求评审决定需求是否进入设计，设计评审决定方案是否进入开发，发布评审决定版本是否可对外发布。只画活动不画判断，流程图就退化成任务清单，无法体现控制逻辑。
进入与退出条件要和决策点绑定。进入条件说明启动该阶段需要哪些前置输入，退出条件说明满足什么标准才算完成。下表可作为阶段划分表的填写结构：
| 阶段名称 | 阶段目标 | 关键决策点 | 进入条件 | 退出条件 |
|---|---|---|---|---|
| 需求 | 明确要做什 么、为什么做 | 需求评审 | 立项通过，需求来源明确 | 需求文档评审通过并基线化 |
| 设计 | 确定技术方案与实现路径 | 设计评审 | 需求基线已确认 | 设计文档评审通过，接口与依赖明确 |
| 开发 | 完成功能实现与自测 | 开发完成检查 | 设计评审通过，任务已拆分 | 代码合入，自测通过，提测单提交 |
| 测试 | 验证功能与质量达标 | 测试准出评审 | 提测通过，测试环境就绪 | 测试报告完成，遗留问题有处理结论 |
| 发布 | 完成上线与交付 | 发布评审 | 测试准出通过 | 发布完成，发布记录归档 |
这张表是流程图的骨架，画图时每个阶段对应一组活动，每个决策点对应一个判断符号。完成标志是：阶段之间没有断点，每个决策点都有明确的判断标准和责任人。
确定角色泳道与职责分工
泳道解决“谁来做”的问题。划分泳道时按角色或职能设置，例如产品、研发、测试、运维、项目管理，同一角色在不同阶段的活动放在同一条泳道内。泳道数量控制在能看清交接的范围内，角色过多时可以合并相近职能，把细分职责放到角色说明中。
跨泳道的连线表示交接，交接处必须标注交付物和完成条件。比如研发泳道向测试泳道交接时，连线上标注“提测单+自测报告”，条件写“自测用例全部通过”。这样流程图不仅说明顺序，还能回答每个交接点需要什么、由谁确认。
角色与交付物的对应关系建议单独整理成对照表，与流程图配套使用。表格按角色列出其负责的活动、产出的交付物和参与的评审，便于新成员快速定位自己的职责。填写时注意一个交付物只设一个主要责任人，避免出现“共同负责”导致无人推进。
| 角色 | 主要活动 | 交付物 | 参与的评审 |
|---|---|---|---|
| 产品 | 需求收集与定义、需求优先级排序 | 需求文档、需求基线 | 需求评审、发布评审 |
| 研发 | 方案设计、编码实现、自测 | 设计文档、代码、自测报告 | 设计评审、开发完成检查 |
| 测试 | 测试设计、执行、缺陷跟踪 | 测试用例、测试报告 | 测试准出评审 |
| 运维 | 环境准备、发布执行 | 发布方案、发布记录 | 发布评审 |
| 项目管理 | 计划跟踪、风险协调、流程维护 | 项目计划、评审记录 | 各阶段评审组织 |
完成标志是：图中每条活动都能对应到具体泳道，每个跨泳道交接都有交付物标注，对照表与图内容一致。
统一符号与画法规范
符号规范的作用是让不同人画的图可以互相读懂。常用约定包括：圆角矩形表示开始与结束，矩形表示活动，菱形表示判断，平行四边形表示输入输出，文档符号表示交付物，箭头表示流向。组织内部不必追求符号大全，选定一套并写进规范即可，关键是全员一致。
命名规则同样需要统一。活动名称用“动词+对象”的结构，如“编写需求文档”“执行回归测试”，避免“需求阶段”这类无法判断动作的写法。判断节点写成可回答的问题，如“评审是否通过”，两条出线分别标注“是”和“否”。交付物名称与组织实际使用的文档名保持一致，便于查找。
版式上采用分层绘制：主流程只放阶段、关键活动和决策点，细节活动拆成子流程单独成图，主图用子流程符号引用。这样主图保持一页可读，子流程按需展开。完成标志是形成一份书面规范，包含符号表、命名规则和主流程与子流程的拆分约定，并在绘图工具中配置好对应模板。
评审、试点与版本维护
流程图初稿完成后，组织跨角色评审。参与角色应覆盖图中每条泳道的代表，评审要点包括：阶段和决策点是否与实际做法一致，交接处的交付物是否齐全，退出条件是否可判断，是否存在无人负责的活动。评审记录按“问题—提出人—处理结论—修改位置”的格式留存，便于追溯。
评审通过后先小范围试点，选一到两个项目按流程图执行，观察实际执行中哪些环节卡住、哪些交付物缺失、哪些判断标准有歧义。试点周期覆盖一个完整版本迭代即可，收集反馈后集中修订一次，再扩大适用范围。
版本维护要建立触发规则：组织调整、评审关口变化、交付物模板变更、试点中发现系统性偏差时，都应触发流程图更新。每次更新记录版本号、变更内容和生效日期，旧版本归档保留。流程图落地时，可以把阶段、评审关口和交付物对应到研发管理平台的工作项与文档中，让流程活动有承载位置、交接记录可查。ONES 支持项目管理、知识库、测试管理等模块组合，可用于承载流程活动与协作记录，具体模块范围需结合组织实际确认。
示例：一条需求到发布的研发主流程
以下示例演示前述方法的组合应用，组织可按自身情况调整阶段名称和评审设置。
阶段与决策点：主流程设需求、设计、开发、测试、发布五个阶段，阶段之间依次设需求评审、设计评审、开发完成检查、测试准出评审、发布评审五个决策点。每个决策点标注判断问题，如“需求评审是否通过”，未通过时回流到上一活动修订。
泳道与角色：图中设产品、研发、测试、运维、项目管理五条泳道。需求阶段的活动主要落在产品泳道，设计、开发阶段落在研发泳道，测试阶段落在测试泳道，发布阶段由运维执行、项目管理跟踪。项目管理泳道贯穿各阶段，承载计划跟踪和评审组织。
交付物与交接标注：产品泳道向研发泳道交接时标注“需求基线+评审记录”，研发向测试交接时标注“提测单+自测报告”，测试向发布交接时标注“测试报告+准出结论”。每条交接连线旁写明完成条件，例如“测试报告已评审，遗留问题均有处理结论”。这样一张图同时呈现了顺序、责任和交接标准，新成员可以据此判断自己所在环节的输入和输出。
完成检查：流程图是否可用
发布前逐项核对以下清单，全部通过再正式启用：
- 流程边界说明已确认，覆盖阶段、起止点、适用团队和不纳入内容均已写明。
- 阶段划分完整，每个阶段有目标、活动和交付物，阶段之间无断点。
- 每个决策点有明确的判断问题、判断标准和责任人，未通过时的回流路径已画出。
- 每条活动都能对应到具体泳道，跨泳道交接均标注交付物和完成条件。
- 角色与交付物对照表与图内容一致，每个交付物有唯一主要责任人。
- 符号、命名和版式符合组织规范，主流程与子流程已分层。
- 已完成跨角色评审，评审记录留存，试点反馈已处理。
- 版本号、变更记录和更新触发规则已建立，旧版本已归档。
清单通过意味着流程图具备了发布条件。投入使用后仍需按变更触发规则定期回顾，让流程图与研发实际保持一致。
常见问题
研发流程图应该先画活动还是先定阶段？
建议先定阶段，再往阶段里填活动。阶段划分决定了流程图的主干结构和决策点位置，活动是在阶段内部展开的细节。如果先画活动，容易陷入具体操作，画到一半发现阶段边界不清，返工成本更高。实际操作中可以先写一份阶段划分表，确认阶段目标、关键决策点和进入/退出条件，再逐段补充活动。
组织共用流程和单项目操作怎么区分，哪些不该画进主图？
判断标准是这条活动是否所有项目都要经过、是否有统一的输入输出和责任人。所有项目都经过、有统一交付物和确认人的活动放进主图；因项目而异、由团队自行决定的做法放到子流程或团队级说明中。单个工作项的状态流转、日常站会等团队内部操作通常不画进组织共用主流程，否则主图会迅速膨胀，读者看不清主干。
流程图评审应该找哪些人参加，评审什么？
评审参与角色应覆盖图中每条泳道的代表，包括产品、研发、测试、运维和项目管理等。评审要点包括：阶段和决策点是否与实际做法一致，交接处的交付物是否齐全，退出条件是否可判断，是否存在无人负责的活动。评审记录按“问题—提出人—处理结论—修改位置”的格式留存，便于后续追溯和修订。
流程图试点多久合适，试点后要改什么？
试点周期覆盖一个完整版本迭代即可，选一到两个项目按流程图执行。试点中重点观察三类问题：哪些环节实际执行时卡住、哪些交付物缺失或无人产出、哪些判断标准存在歧义。收集反馈后集中修订一次，再扩大适用范围。如果试点中发现系统性偏差，应同步检查阶段划分和决策点设置是否合理。
流程图落地后怎么和研发管理平台结合？
可以把阶段、评审关口和交付物对应到研发管理平台的工作项与文档中，让流程活动有承载位置、交接记录可查。ONES 支持项目管理、知识库、测试管理等模块组合，可用于承载流程活动与协作记录，具体模块范围需结合组织实际确认。工具只是承载方式，流程图本身的内容正确性和评审机制仍是前提。
