研发流程手册的核心是一张可填写的流程清单表：以流程域为行，以角色、输入、活动、输出、审批节点、状态流转和度量指标为列，逐行记录组织共用的研发流程。本文提供可直接复制的空白主表、逐字段填写口径、必填与选填划分、一条完整填写示例，以及手册落地后的调整维护方法。手册中的流程行与状态流转最终要在协作工具中承载，ONES 可作为这类流程与工作项管理的落地载体之一。
要点总览（TL;DR）
- 研发流程手册模板的主交付物是一张流程清单表：以流程域为归类，逐行填写流程编号、触发条件、输入物、关键活动、输出物与责任角色。
- 必填字段共九项，覆盖流程识别、启动条件、主体活动与结果责任；审批节点、状态流转、度量指标和关联制度按流程成熟度选填。
- 填写时输入物与输出物写可交付物，责任角色写岗位，审批节点与状态流转分开描述，度量指标写可统计的指标名与单位。
- 手册发布后指定维护责任人和各流程域负责人，按新增、合并、废止、字段修订四类处理变更，并用版本号与变更记录表留痕。
- 手册描述组织共用的流程规则，具体工作项的状态操作属于执行层面，两者分工明确、不必逐条回写。
可复制空白模板：研发流程手册主表
先给表结构。下面这张主表是整本手册的骨架，每一行代表一条组织共用的研发流程，复制到文档或表格工具后按行填写即可。表格保持空白，字段含义在下一节统一说明。
| 流程编号 | 流程域 | 流程名称 | 适用团队 | 触发条件 | 输入物 | 关键活动 | 输出物 | 责任角色 | 审批/评审节点 | 状态流转 | 度量指标 | 关联制度 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
主表之外，配两张小表帮助读者把角色和状态写清楚。角色职责表用于统一岗位口径，避免同一角色在不同流程行里叫法不一致；状态流转表用于描述一条流程从开始到结束经过哪些状态。
| 角色名称 | 所属部门/岗位 | 在流程中的职责 | 对应审批/评审权限 |
|---|---|---|---|
| 状态名称 | 进入条件 | 责任角色 | 离开条件/下一状态 |
|---|---|---|---|
字段说明：每一列填什么、怎么填
同一张表要被不同团队共用，字段口径必须一致。下表逐列给出定义、填写粒度和常见错误，填写时按此对齐。
| 字段名 | 含义 | 填写口径 | 常见错误 |
|---|---|---|---|
| 流程编号 | 流程的唯一标识 | 采用“流程域缩写-序号”，如 REQ-01，编号一经使用不重复 | 编号随意变更，导致引用失效 |
| 流程域 | 流程所属的管理领域 | 按研发阶段或管理对象划分，如需求管理、设计开发、测试验证、发布上线、变更管理 | 流程域过细，一行一个域，失去归类作用 |
| 流程名称 | 该流程的具体名称 | 用“对象+动作”命名，如“需求评审”“版本发布”，一个名称只对应一条流程 | 名称写成部门名或项目名 |
| 适用团队 | 该流程约束的团队范围 | 写团队类型或组织单元，如“全部研发团队”“客户端团队” | 写具体人名或临时项目组 |
| 触发条件 | 流程启动的前置事件 | 写可判断的事件，如“需求进入待评审状态”“缺陷等级为严重” | 写成“需要时”“视情况” |
| 输入物 | 流程开始前必须具备的交付物 | 写可交付物名称，如“需求说明书”“接口设计文档” | 写成动作，如“完成需求分析” |
| 关键活动 | 流程中的主要工作步骤 | 按顺序列 3–6 项活动，每项以动词开头 | 把活动写成岗位职责 |
| 输出物 | 流程结束时产出的交付物 | 写可交付物名称，如“评审结论记录”“发布清单” | 写成“完成评审”这类动作 |
| 责任角色 | 对流程结果负责的岗位 | 写岗位名称，如“产品经理”“测试负责人” | 写具体人名，人员变动后失效 |
| 审批/评审节点 | 流程中需要决策或确认的环节 | 写节点名称与决策角色，如“技术评审：架构师” | 与状态流转混写 |
| 状态流转 | 流程对象经历的状态序列 | 按顺序写状态名，如“草稿→待评审→评审中→已通过” | 把审批动作当成状态 |
| 度量指标 | 衡量流程运行效果的可观测结果 | 写指标名与统计口径，如“需求评审周期（天）”“评审一次通过率” | 写“提升效率”这类空泛描述 |
| 关联制度 | 与该流程相关的制度或规范 | 写制度名称或编号，便于追溯 | 留空且无说明 |
几个容易混淆的口径需要单独说明。流程域与流程名称是归类与个体的关系：流程域回答“这条流程属于哪类管理活动”，流程名称回答“具体是哪条流程”，划分时先定域再定名称，避免同一活动在两个域下重复出现。输入物与输出物一律写可交付物，判断标准是“能否被评审、归档或交接”，写成动作会让流程无法核验。责任角色写岗位，是因为手册服务组织共用流程，人员会变动而岗位相对稳定。
审批/评审节点与状态流转的区别在于：审批节点是流程中的决策环节，回答“谁在哪个点做判断”；状态流转描述流程对象在生命周期中经过的状态序列，回答“对象当前处于什么阶段”。两者可以对应，但不能互相替代，例如“评审中”是状态，“技术评审”是节点。度量指标要能被统计，写清指标名、单位和统计周期，避免“流程顺畅”这类无法观测的表述。
必填与选填：最小可用手册怎么定
手册可以先小后全。建议把决定流程能否被理解和执行的信息设为必填，把用于精细化管理的字段设为选填，先让团队把主干流程写出来，再逐步补全。
| 字段 | 必填/选填 | 理由或适用场景 |
|---|---|---|
| 流程编号 | 必填 | 唯一标识，支撑引用与变更追溯 |
| 流程域 | 必填 | 决定手册的归类结构 |
| 流程名称 | 必填 | 流程的基本识别信息 |
| 适用团队 | 必填 | 明确约束范围，避免误用 |
| 触发条件 | 必填 | 决定流程何时启动 |
| 输入物 | 必填 | 流程启动的前置条件 |
| 关键活动 | 必填 | 流程的主体内容 |
| 输出物 | 必填 | 流程完成的判断依据 |
| 责任角色 | 必填 | 明确谁对结果负责 |
| 审批/评审节点 | 选填 | 流程涉及决策或质量门禁时填写 |
| 状态流转 | 选填 | 流程对象需要跟踪阶段时填写 |
| 度量指标 | 选填 | 流程进入稳定运行、需要评估效果时填写 |
| 关联制度 | 选填 | 存在配套制度或规范时填写 |
按团队情况分层填写更实际。规模较小、流程尚在起步的团队，先填必填字段即可形成最小可用版本：每条流程能说清何时触发、需要什么输入、做哪些活动、产出什么、谁负责，就足以支撑日常协作。流程运行一段时间、出现评审争议或交付波动后，再补审批节点与度量指标。流程成熟度较高的团队，可把状态流转和关联制度一并填全，让手册同时承担流程规范和审计依据的作用。
只填必填字段时，手册的最小可用版本包含九列：流程编号、流程域、流程名称、适用团队、触发条件、输入物、关键活动、输出物、责任角色。这个版本能回答“这条流程是什么、什么时候用、谁来做、做完交付什么”，适合作为第一版发布，后续按需增补。
填写示例：一条完整研发流程怎么填
下面以“需求评审到发布”中的需求评审流程为例，演示一条流程行如何填写。示例为演示情景，用于说明字段对应关系，不代表任何真实客户案例。
| 字段 | 填写内容 |
|---|---|
| 流程编号 | REQ-01 |
| 流程域 | 需求管理 |
| 流程名称 | 需求评审 |
| 适用团队 | 全部研发团队 |
| 触发条件 | 需求说明书提交并进入待评审状态 |
| 输入物 | 需求说明书、原型说明 |
| 关键活动 | 提交评审材料、组织评审会、记录评审意见、修订需求、确认评审结论 |
| 输出物 | 评审结论记录、修订后的需求说明书 |
| 责任角色 | 产品经理 |
| 审批/评审节点 | 需求评审：产品经理、技术负责人、测试负责人 |
| 状态流转 | 草稿→待评审→评审中→已通过/已驳回 |
| 度量指标 | 需求评审周期（天）、评审一次通过率 |
| 关联制度 | 需求管理规范 |
逐字段对照上一节的口径：流程编号采用“域缩写-序号”，与流程域“需求管理”对应；流程名称用“对象+动作”，写成“需求评审”而非“产品经理评审需求”；触发条件写成可判断的状态事件，而不是“有需求时”。输入物和输出物都落在可交付物上，输入是评审前必须具备的材料，输出是评审后可以归档和交接的记录与文档。
审批节点与状态流转在示例中分别体现：审批节点写清“需求评审”这个决策环节及参与角色，状态流转写清需求对象从草稿到已通过或已驳回的完整序列。两者配合使用，读者既能知道在哪个点由谁决策，也能知道对象当前处于哪个阶段。度量指标选取了周期和通过率两个可统计结果，并标注单位，便于后续按周期汇总。
调整与维护：手册怎么改、谁来改
手册发布后需要有人负责维护，否则会逐渐与团队实际做法脱节。建议指定一名流程负责人（通常由研发管理或项目管理岗位承担）作为手册维护责任人，各流程域再指定域负责人，负责本域流程行的准确性。
变更触发条件可以包括：组织或团队结构调整、流程实际执行方式发生变化、评审节点增减、度量指标连续偏离预期、关联制度修订。出现上述情况时，由域负责人提出变更，维护责任人审核后更新手册并记录版本。
| 变更类型 | 处理方式 | 记录要求 |
|---|---|---|
| 新增流程行 | 分配新编号，填写必填字段，按需补充选填字段 | 记录新增原因与生效日期 |
| 合并流程行 | 保留主流程编号，被合并编号标注“已合并至××”，不再单独维护 | 记录合并前后编号对应关系 |
| 废止流程行 | 标注“已废止”及废止日期，保留历史记录供追溯 | 记录废止原因与替代流程 |
| 字段内容修订 | 直接更新对应字段，涉及审批节点或状态流转的修订需经评审 | 记录修订内容与评审人 |
版本号建议采用“主版本.次版本”格式：流程域结构、必填字段或审批规则发生实质变化时升主版本，个别流程行内容修订时升次版本。每条变更在变更记录表中登记，至少包含变更日期、变更类型、涉及流程编号、变更内容、提出人、审核人和生效日期。
| 变更日期 | 变更类型 | 涉及流程编号 | 变更内容 | 提出人 | 审核人 | 生效日期 |
|---|---|---|---|---|---|---|
定期评审建议按季度或半年进行一次，检查点包括：流程行是否仍与团队实际执行一致、审批节点是否仍有必要、度量指标是否可统计、废止流程是否已清理、变更记录是否完整。评审结论形成简要记录，作为下一版本修订的依据。
需要区分手册与具体工作项状态操作的边界：手册描述组织共用的流程规则，回答“这类流程应该怎么走”；具体工作项的状态操作属于执行层面，回答“这个需求当前怎么流转”。手册中的状态流转为工作项状态设计提供依据，执行中的状态变更不必逐条回写手册。手册中的流程行、审批节点和状态流转需要在协作工具中承载时，ONES 的工作项与流程管理能力可以作为落地载体，让手册规则与实际执行保持对应。
常见问题
团队规模很小，也需要填满整张研发流程手册表吗？
不需要。规模较小、流程尚在起步的团队先填九项必填字段即可形成最小可用版本：流程编号、流程域、流程名称、适用团队、触发条件、输入物、关键活动、输出物、责任角色。这个版本能回答流程是什么、何时启动、谁负责、交付什么。等流程运行一段时间、出现评审争议或交付波动后，再补审批节点、状态流转和度量指标。
同一条流程在不同团队做法不一样，手册里应该写几行？
先判断差异是否属于规则层面的不同。如果只是执行细节不同，用一行流程加“适用团队”字段区分范围即可；如果触发条件、审批节点或输出物本身不同，就拆成两条流程行，各自分配编号，并在关联制度里注明依据。拆分后要检查流程域归类是否仍然清晰，避免同一活动在两个域下重复出现。
手册里的状态流转和协作工具中的工作项状态需要完全一致吗？
手册中的状态流转为工作项状态设计提供依据，描述的是这类流程对象应当经过的阶段序列；工具中的工作项状态是执行层面的具体配置，可以按团队需要细化。两者保持主干一致即可，执行中的每次状态变更不必回写手册。当流程规则调整时，再同步检查工具配置是否需要跟着改。
流程废止后，手册里直接删掉那一行可以吗？
建议保留历史记录。做法是标注“已废止”及废止日期，写明废止原因和替代流程，编号不再分配给新流程。这样既能让查阅者知道该流程已停用，也能在追溯历史决策时有据可查。定期评审时再统一清理长期废止且无人引用的条目。
手册多久评审一次比较合适？
可以按季度或半年安排一次定期评审，检查流程行是否仍与团队实际执行一致、审批节点是否仍有必要、度量指标是否可统计、废止流程是否已清理、变更记录是否完整。除定期评审外，组织调整、流程执行方式变化、评审节点增减、指标连续偏离预期、关联制度修订，都可以触发临时修订。
