研发流程设计的核心任务，是把团队实际做事的方式整理成一套可执行、可检查、可维护的规则：先划定流程覆盖的阶段与角色，再把每个阶段写成含输入、活动、输出和完成标志的条目，接着明确谁在什么节点交什么，最后用项目走查验证并按反馈修订。本文按这四步展开，并给出上线前的检查项与维护规则，适合正在从零搭建或重建组织共用研发流程的团队参考。
要点总览（TL;DR）
- 先划定流程边界：以需求正式受理为起点、版本发布并完成交付确认为终点，再按需求、设计、开发、测试、发布划分阶段，并写明裁剪规则。
- 每个阶段按输入、活动、输出、完成标志四要素写成条目，完成标志要可核验，评审与审批按风险配置。
- 用角色责任表把关键活动对应到责任人、评审人和知会人，并汇总关键交付物清单与模板要求。
- 流程设计后先选一个项目走查，把与流程规则相关的卡点回写到流程说明，再判断是否具备推行条件。
- 上线前核对文件一致性、角色落实到人、走查调整项处理状态，并指定维护责任人与版本更新触发条件。
研发流程先定边界：覆盖哪些阶段与角色
流程设计的第一步是确定范围。范围不清，流程要么写得过宽，把采购、运维、市场等无关环节都卷进来，导致没人愿意执行；要么写得过窄，只覆盖编码环节，需求变更和发布仍然靠口头协调。边界的确定方法很直接：找出一个需求从被提出到交付给用户的完整链路，把这条链路上必须由研发团队承担责任的环节纳入流程，其余环节只保留接口说明。
流程起点与终点的界定方法
起点通常定在“需求被正式受理”这一刻，即需求有了明确提出方、目标和初步验收标准，进入研发团队的待办范围。终点定在“版本发布完成并完成交付确认”，即交付物到达使用方、相关记录归档。起点之前的需求收集与优先级排序、终点之后的运营数据反馈，可以在流程说明中用一段接口描述交代，不必展开成流程阶段。这样界定后，流程有明确的触发条件和结束条件，每个参与者都能判断自己手上的事情是否在流程内。
常见阶段划分与裁剪原则
中小型研发团队常用的阶段划分为需求、设计、开发、测试、发布五个阶段。阶段划分的依据是工作性质的转换点：从“确定做什么”转到“确定怎么做”，再转到“把它做出来”，然后转到“验证它做对了”，最后转到“交给使用方”。阶段数量不必强求统一，关键是每个阶段有独立的产出和判断标准。
裁剪原则需要提前写进流程说明，常见做法包括：
- 按变更影响范围裁剪：只改文案、配置的变更可合并设计与开发阶段，但仍需保留测试验证和发布记录。
- 按项目类型裁剪：探索性预研项目可简化评审节点，但需明确预研结论的评审人和归档要求。
- 裁剪必须留痕：由谁批准裁剪、裁剪掉哪些节点、替代的控制手段是什么，都要记录在项目信息中，避免裁剪变成随意跳过。
参与角色清单与职责边界
角色清单按“对结果负责”而非按职级罗列。典型角色包括需求提出方、产品负责人、技术负责人、开发人员、测试人员、发布负责人，规模较小的团队可以一人兼多个角色，但每个角色在流程中的职责要写清楚。职责边界重点处理容易扯皮的地方，例如需求变更由谁评估影响、缺陷修复的优先级由谁决定、发布窗口由谁批准。这些判断点写明白，流程执行中的争议会明显减少。
需要区分三个层次的概念：本文讨论的是组织共用的研发流程，规定阶段、角色和交付物；单个工作项的状态流转（如待处理、进行中、已完成）是工具层面的操作配置，属于流程的承载方式；IPD、ALM 等现成体系框架提供的是完整的体系参考，本文不展开。团队可以先有自己的流程说明，再决定用哪种框架或工具承载。
本节交付物是一份流程范围说明，包含阶段清单、角色清单和裁剪规则三部分，作为后续条目编写的基础。
每个阶段写清输入、活动、输出与完成标志
流程文件空泛，通常是因为只写了“做什么”，没写“凭什么算做完”。把每个阶段拆成输入、活动、输出、完成标志四个要素，流程条目就具备了可执行和可检查的属性。四要素的写法可以统一成一个句式：本阶段以什么为输入，由谁开展哪些活动，产出什么交付物，满足什么条件才算完成。
阶段条目的四要素写法
输入指进入本阶段必须具备的材料和前提，例如设计阶段的输入是已评审通过的需求说明和验收标准。活动指本阶段要完成的工作，用动词开头、指向具体产物，例如“编写接口设计文档”“完成核心流程的用例设计”。输出指本阶段结束时必须存在的交付物，要写到可指认的程度，例如“一份包含接口定义和异常处理说明的设计文档”。完成标志是判断阶段结束的准则，应尽量写成可核验的条件，例如“设计文档通过技术负责人评审，评审意见已闭环”。
完成标志（出口准则）的设定方法
完成标志要避免两类写法：一类是“完成开发”这种无法核验的表述，另一类是“所有问题都解决”这种永远无法满足的绝对条件。可操作的设定方法是把标志分成三类：交付物存在性（文档已提交并归档）、评审结论（评审通过且意见闭环）、质量门槛（如关键用例全部通过、遗留缺陷有明确处理计划）。每类写一到两条即可，过多会让流程变得沉重。
评审与审批节点的设置原则
评审节点解决“谁来判断做得对不对”，审批节点解决“谁有权决定是否继续投入”。设置原则是按风险配置：需求阶段评审关注目标与验收标准是否清晰，设计阶段评审关注方案是否覆盖关键场景和风险，发布前审批关注发布范围、回滚方案和通知安排。低风险变更可以减少评审层级，但不能取消记录。评审与审批要区分开，评审给专业意见，审批给放行决定，两者由不同角色承担时要在流程中写明。
流程条目的颗粒度控制
颗粒度以“一个责任人能独立完成并交付”为宜。条目过细会变成操作手册，维护成本高；条目过粗会退化成口号。一个实用的判断标准是：如果一条活动需要两个以上角色分别完成不同工作，就应拆成两条；如果两条活动的输出是同一份交付物、责任人也相同，可以合并。阶段流程条目表建议用表格呈现，列固定为阶段、输入、活动、输出、完成标志、责任人，便于逐行检查。
角色分工与交付物：谁在什么节点交什么
流程条目写完后，需要把责任落到具体角色和具体交付物上，否则流程执行时会出现“都以为别人在做”的情况。角色责任表的作用是把每条关键活动与一个主责角色对应起来，并标明该活动的产出物。
角色与活动的责任分配方法
常用的分配方法是区分三种责任：责任人（R）负责完成活动并交付产物，评审人（A）负责对产物给出通过或不通过的结论，知会人（I）需要了解结果但不参与决策。分配时遵循一条规则：每条关键活动有且只有一个责任人，评审人可以多人但要有明确的结论责任人。角色责任表按“活动—责任人—评审人—知会人—交付物”五列组织，逐条填写，填不出来的条目说明流程设计还有缺口。
关键交付物清单及模板要求
交付物清单从阶段条目表的输出列汇总而来，再补充模板要求。常见的关键交付物包括需求说明（含目标、范围、验收标准）、设计文档（含方案、接口、风险）、测试用例与测试报告、发布说明（含变更内容、回滚方案、通知范围）。模板要求写清必填字段和最低内容标准，例如需求说明必须包含验收标准，测试报告必须列出未通过项及处理结论。模板不必追求完整，能支撑评审判断即可。
交付物状态与流转记录方式
交付物需要能被查到当前状态和流转过程：谁提交、谁评审、结论是什么、修改了几轮。记录方式可以是文档版本加评审记录，也可以借助协作工具承载。以 ONES 为例，需求、任务、缺陷等工作项可以按流程阶段配置状态，设计文档、测试报告等交付物可在工作项下关联并保留版本与评审记录，使“谁在什么节点交了什么、评审结论如何”在系统中可追溯。工具承载的是记录与流转，流程条目本身仍需团队先定义清楚。
用一个项目走通流程：示例演示
流程设计完成后，不要直接全员推行，先选一个真实项目或模拟项目完整走一遍，检验条目是否可操作。以下示例为演示情景，用于说明走查方法，不对应具体组织。
示例项目的阶段推进过程
假设某团队要为一个内部系统增加“批量导出”功能。需求阶段：需求提出方提交需求说明，产品负责人补充验收标准（导出格式、数据范围、权限限制），需求评审通过后进入设计。设计阶段：技术负责人输出设计文档，说明导出任务的异步处理方式和失败重试策略，评审意见要求补充大数据量场景的说明，修改后通过。开发阶段：开发人员按设计实现，同步编写单元测试，完成后提交代码并更新任务状态。测试阶段：测试人员依据验收标准设计用例，执行后发现两处格式问题，缺陷修复后回归通过。发布阶段：发布负责人整理发布说明，包含变更内容、回滚方式和通知范围，审批通过后在约定窗口发布。
各节点输入输出与责任人的对应
| 阶段 | 输入 | 输出 | 完成标志 | 责任人 |
|---|---|---|---|---|
| 需求 | 需求提出方的业务说明 | 需求说明（含验收标准） | 需求评审通过，验收标准明确 | 产品负责人 |
| 设计 | 已通过的需求说明 | 设计文档 | 技术评审通过，意见闭环 | 技术负责人 |
| 开发 | 设计文档 | 可测试的代码与自测记录 | 自测通过，代码已合入 | 开发人员 |
| 测试 | 验收标准与测试用例 | 测试报告 | 关键用例通过，遗留缺陷有处理计划 | 测试人员 |
| 发布 | 测试报告与发布说明 | 发布记录 | 发布审批通过，交付确认完成 | 发布负责人 |
流程中暴露的卡点与调整
走查中常见的卡点有三类。第一类是完成标志不可核验，例如“设计评审通过”没有说明意见闭环的标准，导致评审反复。调整方式是把标志改为“评审意见全部有处理结论”。第二类是角色缺位，例如小团队没有独立测试人员，测试活动无人主责。调整方式是明确由开发交叉测试并指定一人对测试报告负责，同时保留记录。第三类是交付物模板过重，例如需求说明要求填写十余个字段，实际只用到一半。调整方式是删减非必填字段，保留验收标准等关键项。每次调整都要记录在走查记录中，注明调整原因和影响范围。
示例对通用流程的迁移规律
单个项目的走查结论不能直接等同于通用流程，需要区分两类内容：与项目特性相关的部分（如该项目的异步处理设计）留在项目记录中；与流程规则相关的部分（如完成标志的写法、角色缺位的处理方式）回写到流程说明中。迁移时重点看三个信号：同一卡点在多个节点重复出现，说明流程条目本身有问题；某个角色在多个阶段都缺位，说明角色清单需要补充；某类交付物反复被评审打回，说明模板或评审标准需要修订。
流程落地检查：上线前要确认的几件事
走查通过后，流程具备推行条件，但正式上线前仍需逐项核对，避免带着明显缺口进入全员执行阶段。
流程文件完整性与一致性检查
检查流程说明是否覆盖了范围说明中的全部阶段，每个阶段是否都有四要素条目，角色责任表与阶段条目表中的责任人是否一致，交付物清单是否与各阶段输出列对得上。常见问题是流程说明更新后，角色责任表没有同步修改，导致两处对同一活动的主责人写法不同。检查时以阶段条目表为基准，逐项比对其他文件。
角色与交付物是否落实到人
流程中的角色要对应到具体人员或岗位，不能停留在“由相关负责人评审”这类表述。检查方式是列出全部角色，确认每个角色都有明确承担者，并确认关键交付物的模板已就位、存放位置已确定。对于一人兼多角色的情况，要检查是否存在自己评审自己产出的环节，如有，需补充交叉评审安排。
试点反馈的处理与流程修订
走查记录中的调整项要逐条确认处理状态：已修订的，检查修订内容是否进入流程文件；暂不修订的，记录原因和后续观察计划。试点项目参与者的反馈按“流程规则问题”和“项目执行问题”分类，前者进入流程修订，后者留在项目复盘。修订完成后，流程版本号更新，并在流程说明中记录本次修订的主要变化。
流程维护与版本更新机制
流程需要指定维护责任人和更新触发条件。常见触发条件包括：组织角色调整、工具或交付方式变化、连续多个项目在同一节点出现卡点、外部合规要求变化。更新机制写明谁提出修订、谁审批、修订后如何通知全员、旧版本如何归档。建议每季度做一次轻量回顾，检查流程条目是否仍与实际做法一致，避免流程文件逐渐与实际脱节。
上线检查清单可归纳为：流程文件完整且相互一致；每个角色有明确承担者；关键交付物模板与存放位置就位；走查调整项已处理并记录；维护责任人与更新触发条件已明确。五项全部确认后，流程可以进入正式推行，并在后续项目中持续收集反馈、按版本迭代。
常见问题
团队规模很小，一人兼多个角色，流程还能按角色责任表执行吗？
可以执行，但需要处理两个前提。一是角色可以合并，职责不能合并：同一个人兼任产品负责人和测试负责人时，需求评审和测试报告仍要分别留下记录，避免同一环节既当产出方又当结论方。二是补充交叉评审安排，凡是自己产出、自己评审的环节，指定另一位同事给出评审结论，哪怕只是简短确认。角色责任表按岗位填写，再附一张人员对应表，人员变动时只改对应表，流程文件保持稳定。
流程走查只做了一个项目，结论能直接推广到全团队吗？
不能直接等同。走查的价值在于暴露流程条目本身的问题，而不是证明流程适用于所有项目。推广前先区分两类结论：与该项目特性相关的部分留在项目记录中；与流程规则相关的部分，例如完成标志的写法、角色缺位的处理方式，回写到流程说明。判断是否推广可以看三个信号：同一卡点在多个节点重复出现、某个角色在多个阶段缺位、某类交付物反复被评审打回。出现这些信号说明流程需要修订，修订后再选一个不同类型的项目走查一次更稳妥。
流程上线后，怎么判断它是否还在被真正执行？
可以看几个可观察的痕迹：关键交付物是否按阶段产出并留有评审结论，完成标志是否被实际用来判断阶段结束，裁剪是否都有批准记录。如果发现评审记录长期空白、交付物集中在上线前补交、裁剪没有留痕，说明流程正在被绕过。此时先确认是流程条目过重还是角色缺位，再决定简化条目或补充责任人，不建议直接增加检查频次。每季度做一次轻量回顾，比对流程条目与实际做法，是维持执行度的常用方式。
流程说明、角色责任表和交付物清单，应该先写哪一份？
建议按依赖顺序推进：先写流程范围说明，确定阶段清单、角色清单和裁剪规则；再写阶段条目表，把每个阶段拆成输入、活动、输出、完成标志；然后从条目表的输出列汇总交付物清单，从活动列整理角色责任表。这样后一份文件都能从前一份找到依据，减少相互矛盾。三份文件完成后做一次交叉比对，重点检查同一活动在不同文件中的责任人写法是否一致。
流程修订后，旧版本的项目还要按新流程补做吗？
一般不需要追溯补做。流程修订通常适用于修订生效后新启动的项目，已在执行中的项目可以按原流程完成，或在下一个阶段切换时采用新要求，具体口径写进修订说明。需要补做的只有一类情况：修订涉及合规或安全相关的强制节点，且旧流程存在明确缺口。修订说明中写清生效时间、适用范围和过渡安排，旧版本归档保留，便于后续追溯当时的执行依据。
