研发流程手册示例要能直接照着填：先界定手册覆盖的组织共用流程范围，再按阶段写清输入、角色、活动、交付物、评审与退出条件，最后附上变更维护规则。下面给出一份结构完整、字段齐全的填写样例，覆盖从需求到发布的主干流程。示例中的项目背景、角色名称与数值均为演示情景，读者可替换为自身流程后使用。
要点总览（TL;DR）
- 这份示例给出一份组织共用研发流程手册的完整填写样例，覆盖从需求到发布的主干流程，共六章：总则、角色职责、阶段说明、评审与质量门禁、变更与例外管理、附录。
- 阶段说明按输入、主责角色、关键活动、交付物、退出条件五项统一填写，退出条件写成可当场核对的证据，例如评审结论、测试报告结论、发布清单确认记录。
- 角色按活动而非部门划分，交付物清单只写到文档层级、具体结构交给模板索引，避免手册与模板重复维护。
- 改成自用手册时先定流程边界再写阶段，保留裁剪与例外通道，并按团队规模、交付节奏和合规要求调整评审点密度。
- 示例中的项目背景、角色名称与数值均为演示情景，读者应替换为自身流程后使用。
这份示例要示范到什么程度
这份示例示范的是一份“组织共用研发流程手册”的成品形态，覆盖从需求提出到版本发布的主干流程。它回答的问题是：一份手册应该分成哪几章、每章写什么、每个阶段填哪些字段、字段填到什么颗粒度才算可用。读者拿到示例后，可以对照自己团队的流程逐章替换内容，而不必从空白页开始设计结构。
需要先说明三点使用前提。第一，示例中的项目背景、角色名称、评审周期、缺陷收敛标准等均为演示情景，用于展示填写方式，不代表任何真实客户案例或实测效果。第二，示例聚焦组织层面的共用流程，即多个项目都会走的主干路径；单个工作项的状态如何流转、看板如何配置，属于工具操作层面，不在本示例展开。第三，示例不介绍 IPD、ALM 等现成体系框架的完整内容，只在需要时借用其“阶段—评审点—交付物”的组织思路，帮助读者理解手册的层级关系。
换句话说，手册管的是“大家共同遵守的流程约定”，工具管的是“每个工作项按约定流转”。两者分工明确：手册定义阶段、角色、交付物和退出条件，工具承载状态、记录和归档。示例只写前者，落地时再由后者承接。
完整示例：一份研发流程手册的填写样例
以下样例假设一个中等规模软件研发团队，采用两周一迭代、按月发布版本的节奏，产品、研发、测试、运维四类角色参与。手册共六章，目录结构与各章职责如下。
| 章节 | 章节名称 | 本章职责 |
|---|---|---|
| 第一章 | 总则与适用范围 | 说明手册目的、覆盖的流程范围、适用项目类型、术语定义 |
| 第二章 | 角色与职责 | 按活动定义角色，写明每个角色在各阶段承担的动作与产出 |
| 第三章 | 流程阶段说明 | 逐阶段写输入、角色、活动、交付物、评审点、退出条件 |
| 第四章 | 评审与质量门禁 | 规定各评审点的组织方式、检查项、结论类型与记录要求 |
| 第五章 | 变更与例外管理 | 规定流程变更的发起、审批、生效，以及例外申请的条件与通道 |
| 第六章 | 附录 | 交付物清单、模板索引、术语表、修订记录 |
第三章是手册的主体。下面按需求、设计、开发、测试、发布五个阶段，给出各字段的填写样例。
| 阶段 | 输入 | 主责角色 | 关键活动 | 交付物 | 退出条件 |
|---|---|---|---|---|---|
| 需求 | 业务方需求说明、上一版本遗留问题清单 | 产品负责人 | 需求收集、优先级排序、需求评审 | 需求清单、需求评审记录 | 需求评审结论为“通过”，每条需求有验收口径和优先级 |
| 设计 | 已通过评审的需求清单 | 技术负责人 | 方案设计、接口设计、设计评审 | 设计说明、接口文档、设计评审记录 | 设计评审记录中无未关闭的高优先级问题，接口文档已同步测试角色 |
| 开发 | 设计说明、接口文档、开发排期 | 开发负责人 | 编码、自测、代码评审、提测 | 代码提交记录、自测报告、提测单 | 提测单已提交且自测报告覆盖主要功能路径，代码评审意见已关闭 |
| 测试 | 提测单、需求验收口径、测试计划 | 测试负责人 | 用例设计、功能测试、回归测试、缺陷跟踪 | 测试报告、缺陷清单、回归结论 | 测试报告结论为“可发布”，遗留缺陷均有处理结论 |
| 发布 | 测试报告、发布计划、回滚方案 | 运维负责人 | 发布准备、上线执行、发布验证、发布复盘 | 发布清单、发布记录、复盘纪要 | 发布清单逐项确认完成，发布验证通过，复盘纪要已归档 |
第四章评审条款的示例写法是：“需求评审由产品负责人组织，参与角色包括技术负责人、测试负责人；评审检查项包括需求描述是否完整、验收口径是否可判定、优先级是否明确；评审结论分为通过、有条件通过、退回三种，有条件通过须在需求清单中记录待办项与责任人，待办项关闭后方可进入设计阶段。”这段写法的特点是：组织者、参与者、检查项、结论类型、后续动作都在一条条款内说清。
第五章变更条款的示例写法是：“流程变更由流程负责人发起，说明变更内容、影响范围与生效时间，经研发负责人与质量负责人确认后生效，并在附录修订记录中登记。例外申请适用于单次项目因外部约束无法执行某条款的情形，由项目负责人提交，写明例外条款、原因、替代措施与期限，经流程负责人批准后执行，例外到期自动失效。”变更管长期规则，例外管单次偏离，两条通道分开写，避免用例外绕开变更。
逐项解释：每个字段为什么这样填
阶段退出条件写成可判定的证据，是整份手册最值得花力气的地方。“测试完成”无法判断是否完成，“测试报告结论为可发布且遗留缺陷均有处理结论”则可以当场核对。退出条件的本质是给阶段交接一个客观依据：上一阶段的人能证明自己交付了什么，下一阶段的人能据此决定是否接手。填写时可以用一个简单检验：把退出条件交给不熟悉该项目的人，他能否仅凭文档判断阶段是否结束。如果不能，说明条件还停留在主观描述。
角色按活动划分而非按部门划分，原因是部门架构会调整，活动职责相对稳定。示例中写“技术负责人组织设计评审”，而不是写“研发部负责设计评审”，前者明确了谁发起、谁负责，后者只说明归属。当一个活动涉及多个角色时，手册应写清主责与参与：主责角色对交付物负责，参与角色提供输入或给出评审意见。这样在人员变动或跨团队协作时，职责不会因为部门边界模糊而落空。
交付物清单要避免与文档模板重复。手册的职责是列出“这个阶段必须产出什么、由谁产出、存放在哪里”，模板的职责是规定“这份文档内部长什么样”。示例中交付物只写到“设计说明”“测试报告”这一层，具体章节结构放在附录的模板索引中指向对应模板。如果手册把模板内容全文抄进来，模板一改手册就要跟着改，维护成本会迅速上升。
变更与例外条款的写法要点在于区分两类情形并给出不同路径。流程变更影响所有项目，需要较正式的确认与登记；例外只影响单次项目，需要说明原因、替代措施和期限。两类条款都要写明“谁批准、记录在哪、何时失效”，否则执行时容易出现口头同意、事后无据的情况。示例中把例外设为到期自动失效，是为了防止临时偏离变成事实上的新规则。
从示例到自用手册：可迁移的写法规律
把这份示例改成自己团队可用的版本，可以按以下规律操作。
- 先定流程边界，再写阶段。在总则中写清手册覆盖哪些项目类型、从哪个节点开始、到哪个节点结束、哪些流程不在范围内。边界清楚，后面的阶段才不会无限扩张。
- 用统一字段描述每个阶段。每个阶段都按输入、主责角色、关键活动、交付物、退出条件五项填写，读者可以横向对比阶段之间的衔接关系，新增阶段时也有固定格式可循。
- 把评审点写成检查项而非口号。每个评审点列出可逐条核对的检查项和明确的结论类型，评审记录中能看出哪些项通过、哪些项待办。
- 保留裁剪与例外通道。为小项目或特殊情形留出裁剪规则，说明哪些阶段可以合并、哪些评审可以简化，以及由谁批准。没有裁剪通道的手册，执行者往往选择绕开。
- 给手册本身安排维护节奏。在附录中保留修订记录，约定定期回顾的周期和触发回顾的情形，例如组织调整、发布节奏变化或连续出现同类例外。
这五条规律与团队规模无关，区别只在取值。小团队可以把设计与开发评审合并为一次，把发布复盘简化为发布记录；规模较大的团队则需要更细的角色划分和更密的评审点。规律不变，参数随团队调整。
适用边界：哪些情况需要调整示例
示例默认的是中等规模、两周一迭代、按月发布的软件研发团队。团队规模明显更小、交付节奏更快时，可以减少评审层级，把多个阶段的退出条件合并为一次检查；合规要求较高的场景，则需要增加评审记录、审批留痕和交付物归档的要求，退出条件相应写得更严格。调整的方向是增减评审点与证据要求，而不是改变字段结构。
以下场景需要在示例基础上补充章节：硬件研发需要增加样机验证、物料齐套、试产等阶段及其退出条件；外包协作需要增加供应商准入、交付验收、知识产权归属等条款；多产品线并行时，需要在总则中说明共用流程与产品线特有流程的关系，避免同一活动出现两套冲突规定。这些补充章节的写法仍可沿用示例的字段结构。
手册落地后，流程状态与评审记录需要有承载的地方。以 ONES 为例，可以把手册中的阶段对应为项目中的阶段划分，把评审检查项对应为评审工作项或检查清单，把交付物关联到对应工作项或文档上，使“阶段是否结束、评审结论是什么、交付物在哪里”在系统中可查。这样手册规定的退出条件就有了可核对的记录来源，复盘时也能回溯每个阶段的评审过程。具体配置方式需结合团队实际流程与所用工具版本确定。
最后提醒一点：示例的价值在于结构和字段，不在于具体数值。评审周期、缺陷收敛标准、发布窗口这些取值，应结合团队历史数据和交付要求自行设定，并在手册修订记录中说明调整依据。
常见问题
手册里的退出条件写多细才合适？
退出条件的颗粒度以“不熟悉该项目的人能否仅凭文档判断阶段是否结束”为标准。写成“测试完成”无法核对，写成“测试报告结论为可发布，且遗留缺陷均有处理结论”就能当场验证。如果条件需要依赖口头确认或主观判断，说明还需要补充可留存的证据，例如评审记录、提测单或发布清单。
小团队可以直接照搬这份示例吗？
可以沿用结构和字段，取值需要调整。小团队通常可以把设计与开发评审合并为一次，把发布复盘简化为发布记录，减少评审层级；但输入、角色、活动、交付物、退出条件这五项字段建议保留，便于阶段之间横向对比。调整后应在手册修订记录中写明合并了哪些评审点、由谁批准。
流程变更和例外申请为什么要分成两条通道？
两者影响范围不同。流程变更影响所有项目，需要说明变更内容、影响范围与生效时间，并经相关负责人确认后登记；例外只影响单次项目，需要写明原因、替代措施与期限，到期自动失效。分开写可以避免执行者用临时例外绕开正式变更，也能让复盘时看清哪些偏离是偶发、哪些已经具备变更条件。
手册写好后，评审记录和交付物放在哪里管理？
手册本身只定义阶段、角色、交付物和退出条件，具体记录需要有承载的地方。常见做法是把阶段对应到项目中的阶段划分，把评审检查项对应为评审工作项或检查清单，把交付物关联到对应工作项或文档上，使阶段是否结束、评审结论是什么、交付物在哪里都能查到。以 ONES 为例，可以借助项目与文档协同能力承载这些记录，具体配置方式需结合团队实际流程与所用工具版本确定。
硬件研发或外包协作场景要补充哪些章节？
硬件研发通常需要增加样机验证、物料齐套、试产等阶段及其退出条件；外包协作需要增加供应商准入、交付验收、知识产权归属等条款；多产品线并行时，需要在总则中说明共用流程与产品线特有流程的关系，避免同一活动出现两套冲突规定。补充章节仍可沿用示例的字段结构，先写输入与主责角色，再写活动、交付物和可判定的退出条件。
