编写研发流程手册，核心思路是先定读者与覆盖范围，再搭出章节骨架，把每个活动写成含输入、动作、输出、负责人和完成标志的条目，最后用真实项目走查后发布。手册面向组织共用的流程约定，单个工作项的状态操作另归具体操作说明。手册中的流程活动与交付物通常需要在研发管理工具中承载，ONES可作为这类承载平台之一。
要点总览（TL;DR）
- 动笔前先定三件事：手册给谁看、覆盖从需求到发布的哪些阶段、由谁牵头编写，并把范围外内容注明归属。
- 章节骨架按“总览—阶段—活动—角色—模板索引—附录”组织，阶段章只写到准入准出，具体动作留给活动条目。
- 每个活动条目统一写清输入、动作、输出、负责人、完成标志五要素，完成标志要可观察，例如评审结论已记录、交付物已归档。
- 初稿先经流程负责人和一线执行者评审，再选一到两个真实项目试运行，记录卡点后修订发布。
- 发布时同步建立变更入口、复审周期和版本修订记录，废弃条目保留历史并标注替代条目。
先定手册的读者、范围与编写分工
动笔前先把三件事定下来：手册给谁看、覆盖哪些流程、由谁牵头编写。这三项决定了后续章节的详略和取舍，也决定了手册发布后是否有人真正使用。
读者分层
不同读者对手册的诉求差异明显，编写时可按层列出各自需要的信息，避免内容平均用力。
| 读者 | 需要从手册获得的信息 | 对应章节侧重 |
|---|---|---|
| 新员工 | 流程全景、自己在各阶段要做什么、去哪里找模板 | 总览章、活动条目、模板索引 |
| 项目经理 | 阶段准入准出、交接点、评审要求 | 阶段章、角色与交接章 |
| 职能负责人 | 本职能职责边界、资源投入时点、审批节点 | 角色与职责章、评审章 |
| 评审角色 | 评审对象、评审依据、通过标准 | 活动条目中的完成标志、评审章 |
范围划定
明确手册覆盖从需求到发布的哪些阶段，例如需求分析、方案设计、开发、测试、发布上线。范围之外的内容要写清归属，例如单个工作项的状态流转操作、代码规范、环境运维手册，分别由对应的操作说明或专项制度承载。范围边界写进启动说明，可以避免编写过程中不断被拉入过细内容。
编写分工与版本责任
建议设置三类角色：流程负责人对流程内容的正确性负责，通常由各阶段对应的职能负责人担任；文档主编负责结构统一、文字规范和进度推进；评审人由一线执行者和下游角色组成，在初稿完成后介入。同时指定手册的维护责任人和变更入口，明确版本号规则与生效方式，这部分内容在启动说明中就要落定。
启动说明的产出物包括：读者清单、范围边界说明、编写分工表（含各角色介入时点）、版本与维护约定。
手册骨架：章节结构与每章要写的内容
骨架决定手册是否好用。推荐按“总览—阶段—活动—角色—模板—附录”的顺序组织，每章承担一个明确回答任务，读者可按下表直接搭出目录。
| 章节 | 回答的问题 | 主要内容 |
|---|---|---|
| 总览章 | 整体流程是什么样 | 流程全景图、阶段划分、适用项目类型与裁剪原则 |
| 阶段章 | 每个阶段要做到什么程度 | 阶段目标、准入条件、准出条件、关键活动清单 |
| 活动条目 | 每件事具体怎么做 | 输入、动作、输出、负责人、完成标志五要素 |
| 角色与职责章 | 谁负责什么、如何交接 | 角色定义、职责边界、交接关系与确认方式 |
| 模板与表单索引 | 配套文档在哪里 | 各活动对应的模板、表单、记录清单及存放位置 |
| 附录 | 术语与变更如何查 | 术语表、变更记录、相关制度引用 |
总览章要说明手册适用于哪类项目，例如新产品研发与维护类需求是否走同一套流程、哪些阶段可以裁剪，裁剪需要谁批准。阶段章只写到阶段层级的目标和准入准出，具体动作留给活动条目，避免两处重复描述同一件事。模板索引按活动编号对应，方便执行时直接取用。
把每个活动写成可执行的条目
手册最常见的失效原因是条目空泛，读者看完仍不知道要做什么、做到什么程度算完成。解决办法是统一采用五要素写法，每个活动条目都包含输入、动作、输出、负责人和完成标志。
五要素的写法要求
- 输入：写清活动开始前必须具备的材料或前置状态，例如已评审通过的需求文档、上一阶段的准出记录。
- 动作：用动词开头，写清操作对象和判断条件，例如“依据需求文档拆分开发任务，对无法在一个迭代内完成的需求提出拆分建议”。
- 输出：列出活动产生的交付物及其形态，例如任务清单、设计说明、测试用例集。
- 负责人：写角色而非人名，一人多角色时注明以哪个角色执行。
- 完成标志：必须可观察，例如“设计说明通过架构评审并记录评审结论”“测试用例覆盖需求清单中的全部条目并归档”。
避免口号式表述
“加强沟通”“确保质量”“及时同步”这类表述无法执行也无法检查，应替换为具体动作和可验证结果。例如把“及时同步进度”改为“每周五更新任务状态，延期任务在周会中说明原因与调整方案”。
活动条目填写示例
以下为演示情景，用于说明条目结构，不代表任何具体企业的流程规定。
| 要素 | 填写内容 |
|---|---|
| 活动名称 | 需求评审 |
| 输入 | 需求文档初稿、需求来源记录 |
| 动作 | 组织产品、开发、测试角色评审需求文档，逐条确认需求描述是否完整、验收标准是否明确，对存在歧义的条目记录修改意见 |
| 输出 | 评审意见记录、修订后的需求文档 |
| 负责人 | 产品负责人 |
| 完成标志 | 评审意见全部关闭或明确处理结论，修订版需求文档归档并标记评审通过 |
角色、职责与交接怎么落到手册里
活动条目写清“做什么”，角色章节写清“谁来做、做完交给谁”。两部分配合，跨角色协作才有明确的责任人和交付物。
角色定义与一人多角色
角色章先给出角色清单和定义，说明每个角色的职责边界和不承担的事项。小团队中一人兼任多个角色是常态，手册应约定处理方式，例如在活动条目中标注“本活动由兼任测试职责的开发人员执行时，评审人不得为同一人”，保证关键评审的独立性。
负责人、参与人与评审人的标注
每个活动条目除负责人外，建议标注参与人和评审人。负责人对输出负责，参与人提供输入或协同执行，评审人对完成标志进行确认。三类角色在同一张表中列出，读者一眼能看出自己在该活动中的位置。
交接点的写法
交接点清单按“交出方—接收方—交付物—确认方式”四列组织。确认方式要具体，例如“接收方在任务系统中确认接收并注明遗留问题”，避免只写“双方确认”。职责出现冲突或空缺时，手册应约定由流程负责人裁定，并记录裁定结果，作为后续修订的依据。
评审、试运行与发布
初稿完成后不能直接发布，需要经过内部评审和真实项目试运行，确认条目可执行后再生效。
内部评审的关注点
流程负责人重点看流程逻辑是否完整、阶段衔接是否顺畅、与其他制度是否冲突；一线执行者重点看条目是否可操作、完成标志是否可判断、模板是否够用。两类意见分开记录，避免评审会变成文字润色。
试运行与卡点记录
选一到两个真实项目，按手册条目走一遍关键阶段，记录执行中遇到的卡点：哪些条目无法判断是否完成、哪些交接没有对应交付物、哪些角色在实际项目中不存在。试运行问题清单按条目编号整理，作为修订依据。
修订与发布
修订遵循一条原则：只改影响执行的条目，文字性调整合并处理并保留变更记录。发布时明确生效日期、培训或宣贯方式、旧版本的处理方式（归档或标注失效），并通知全部读者。
手册的维护与变更机制
手册发布后若无人维护，很快会与团队实际做法脱节。维护机制要在发布时同步建立。
- 变更入口：指定统一的变更提交方式，任何读者都可提出修改建议，由文档主编汇总、流程负责人审批。
- 定期复审：约定固定复审周期，例如每半年一次；出现组织调整、流程工具更换、重大流程问题时触发临时复审。
- 版本与修订记录：版本号随条目变更递增，修订记录写清变更条目编号、变更内容、审批人和生效日期。
- 废弃条目处理：废弃条目保留在修订记录中并标注失效日期与替代条目，不直接删除，便于追溯历史做法。
手册中的活动条目、交付物和评审记录如果分散在文档与任务工具中，维护成本会明显上升。以ONES为例，流程文档可在文档模块中统一存放并保留版本，活动对应的任务、评审记录和交付物可在工作项中关联，使手册条目与实际执行记录保持对应，便于复审时核对。
完成检查：手册可以发布了吗
发布前逐项核对以下清单，全部满足再进入发布流程。
| 检查项 | 通过标准 |
|---|---|
| 范围与读者 | 启动说明中的读者清单和范围边界已写入手册，范围外内容已注明归属 |
| 章节完整 | 总览、阶段、活动、角色、模板索引、附录六部分齐全，目录与正文一致 |
| 活动条目五要素 | 抽查各阶段活动条目，输入、动作、输出、负责人、完成标志均具备，完成标志可观察 |
| 角色与交接 | 每个活动有明确负责人，交接点清单中无空缺角色，一人多角色情形已有约定 |
| 试运行 | 至少一个真实项目按手册走查，问题清单中的卡点已处理或明确保留原因 |
| 维护责任 | 维护责任人、变更入口、复审周期、版本规则已写入附录并公布 |
清单核对完成后，按既定生效日期发布并组织宣贯，手册进入执行与维护阶段。
常见问题
手册覆盖的流程和单个工作项的操作说明怎么划清界限？
手册写组织共用的流程约定，包括阶段划分、准入准出、活动五要素、角色职责和交接方式。单个工作项的状态流转、字段填写这类操作，放到对应工具的操作说明或专项制度中，手册只在范围边界处注明归属，不展开步骤。这样手册的篇幅可控，读者也不会在两份文档里看到重复且可能不一致的描述。
小团队一人兼任多个角色，手册里的评审独立性怎么保证？
角色章先列出角色清单和职责边界，再约定兼任时的处理方式。常见做法是在活动条目中注明：当执行人与评审人为同一人时，该活动的评审需由另一名具备相应职责的人员完成，或由流程负责人代为确认。约定要写到具体活动上，例如需求评审、设计评审，避免只写一句原则性要求而无法执行。
试运行要走到什么程度才算验证充分？
选一到两个真实项目，按手册条目走完关键阶段即可，重点记录三类卡点：条目无法判断是否完成、交接点没有对应交付物、手册中列出的角色在实际项目中不存在。问题清单按条目编号整理，能当场修订的修订，需要讨论的明确保留原因和后续处理时点。试运行的目标是验证可执行性，不追求覆盖全部项目类型。
手册发布后，团队实际做法和文档不一致怎么办？
先判断差异来源：如果是条目本身不可执行，走变更流程修订条目；如果是团队未按手册执行，由流程负责人在复审或项目复盘时提出，明确是调整做法还是调整手册。变更入口保持统一，任何读者都可提交建议，由文档主编汇总、流程负责人审批，修订记录写清变更条目编号、内容和生效日期，便于追溯。
手册中的活动条目和交付物要不要放进研发管理工具？
条目数量多、交付物需要长期追溯时，放进工具承载会明显降低维护成本。以ONES为例，流程文档可在文档模块中统一存放并保留版本，活动对应的任务、评审记录和交付物可在工作项中关联，复审时能直接核对条目与实际执行记录是否一致。条目较少、团队规模小的场景，先用文档加共享目录也能运转，后续再逐步迁移。
