研发流程手册把组织共用的研发流程写清楚，让不同项目按同一口径执行。本文提供一份可直接复制填写的空白模板，覆盖流程总览、角色职责、活动与交付物、裁剪规则和变更记录五个部分，并逐字段说明填写口径、划分必填与选填、给出一份完整填写示例，最后说明手册发布后的调整与维护方法。
要点总览（TL;DR）
- 模板由封面与适用范围、流程总览、角色职责、活动与交付物、裁剪规则、变更记录六张表组成，用流程编号和活动编号把各部分串起来。
- 流程编号、活动编号、执行角色、输出、裁剪条件与审批人、变更记录为必填；流程目标、输入、评审方式、关键决策权可按项目类型选填，留空统一填“不适用”并注明原因。
- 填写顺序建议先定流程清单，再补角色职责，然后拆活动与交付物，最后写裁剪规则；示例中需求评审流程的五部分行可直接对照仿写。
- 手册发布后按局部修订升次版本号、结构调整升主版本号管理，生效日期不早于批准日期，旧版本归档并通知，建议每半年或每年复核一次。
可复制空白模板
下面这份模板按五个部分组织，表头固定、内容留空。复制到文档工具后，把方括号占位符替换为实际内容即可。五部分之间通过流程编号和活动编号关联，填写时先定流程清单，再补角色、活动和裁剪规则。
第一部分：封面与适用范围
| 栏目 | 填写内容 |
|---|---|
| 手册名称 | [组织/部门名称] 研发流程手册 |
| 手册编号 | [如 RDM-001] |
| 当前版本 | [如 V1.0] |
| 生效日期 | [YYYY-MM-DD] |
| 适用范围 | [适用的产品线、项目类型、组织范围] |
| 编制人 / 批准人 | [姓名 / 姓名] |
| 相关文件 | [引用的质量体系文件、模板清单] |
第二部分：流程总览表
| 流程编号 | 流程名称 | 适用项目类型 | 流程负责人 | 流程目标 |
|---|---|---|---|---|
| [P-01] | [流程名称] | [类型代码] | [角色/姓名] | [一句话目标] |
| [P-02] | [流程名称] | [类型代码] | [角色/姓名] | [一句话目标] |
第三部分：角色职责表
| 角色 | 所属部门 | 主要职责 | 关键决策权 |
|---|---|---|---|
| [角色名称] | [部门] | [承担的流程活动] | [可批准/否决的事项] |
| [角色名称] | [部门] | [承担的流程活动] | [可批准/否决的事项] |
第四部分：活动与交付物表
| 活动编号 | 所属流程 | 活动名称 | 执行角色 | 输入 | 输出 | 评审方式 |
|---|---|---|---|---|---|---|
| [P-01-A01] | [P-01] | [活动名称] | [角色] | [输入物] | [输出物] | [评审方式及评审角色] |
| [P-01-A02] | [P-01] | [活动名称] | [角色] | [输入物] | [输出物] | [评审方式及评审角色] |
第五部分：流程裁剪规则表
| 裁剪项 | 允许裁剪的条件 | 审批人 |
|---|---|---|
| [可裁剪的活动或交付物编号] | [满足什么条件可省略或简化] | [角色] |
| [可裁剪的活动或交付物编号] | [满足什么条件可省略或简化] | [角色] |
第六部分：变更记录表
| 版本 | 日期 | 变更内容 | 提出人 | 批准人 |
|---|---|---|---|---|
| [V1.0] | [YYYY-MM-DD] | [首次发布或具体变更说明] | [姓名] | [姓名] |
字段说明：每个栏位填什么
同一份手册往往由多人分头填写，字段口径不统一会让后续比对和审计失效。下表逐字段说明含义与填写要求，填写前先通读一遍，能减少返工。
| 字段名 | 含义 | 填写口径 | 示例值 |
|---|---|---|---|
| 流程编号 | 流程的唯一标识 | 采用“P-两位序号”，序号按流程在生命周期中的先后排列，发布后不复用 | P-03 |
| 活动编号 | 活动在流程内的唯一标识 | 采用“流程编号-A两位序号”，活动调整时保留原编号，新增活动顺延 | P-03-A02 |
| 适用项目类型 | 流程适用的项目分类 | 先定义类型代码（如新品研发、定制交付、维护升级），表中填代码，代码含义在封面适用范围中说明 | 新品研发 |
| 输入 | 活动开始前必须具备的材料或状态 | 写具体交付物名称或明确的状态条件，避免写“相关资料”这类模糊表述 | 已批准的需求说明书 |
| 输出 | 活动完成后产生的交付物 | 写可验收的交付物名称，与下游活动的输入保持一致 | 设计评审记录 |
| 评审方式 | 输出物的确认形式 | 写明评审形式与评审角色，如“同行评审，由系统架构师签署” | 会议评审，技术负责人批准 |
| 裁剪条件 | 允许省略或简化流程项的前提 | 写成可判断的条件句，包含判断依据和判断人 | 合同金额低于阈值且无定制开发时，可省略方案评审 |
| 版本号 | 手册的修订标识 | 首次发布为 V1.0；局部修订升次版本号，结构调整升主版本号 | V1.1 |
| 生效日期 | 该版本开始执行的日期 | 统一写 YYYY-MM-DD，生效日期不早于批准日期 | 2025-03-01 |
编码规则需要在手册开头单独说明一次，后续所有表格引用编号时不再重复解释。输入与输出的区分看方向：输入是本活动消费的上游成果，输出是本活动交给下游的成果；同一份文档在一个活动中是输出，在下一个活动中就是输入。
必填与选填：哪些字段不能空
模板字段并非全部同等重要。必填字段缺失会让流程无法执行或无法追溯，选填字段则按项目类型和流程复杂度决定是否填写。下表给出划分建议。
| 字段 | 填写要求 | 理由或适用情形 |
|---|---|---|
| 流程编号、流程名称、流程负责人 | 必填 | 缺少任一项，流程无法被引用和问责 |
| 活动编号、所属流程、执行角色、输出 | 必填 | 构成活动的最小可执行信息 |
| 角色、主要职责 | 必填 | 职责表是裁剪审批和评审签字的依据 |
| 裁剪项、裁剪条件、审批人 | 必填 | 裁剪规则不完整会导致执行口径失控 |
| 版本、日期、变更内容、批准人 | 必填 | 变更记录是版本追溯的唯一凭据 |
| 流程目标 | 选填 | 流程较多时建议填写，便于新成员理解设计意图 |
| 输入 | 按项目类型选填 | 启动类活动可无输入；其余活动建议填写 |
| 评审方式 | 按项目类型选填 | 涉及质量门禁的活动必填，日常协作类活动可留空 |
| 关键决策权 | 选填 | 角色承担审批职责时填写，纯执行角色可留空 |
| 相关文件 | 选填 | 有外部体系文件引用时填写 |
按项目类型差异化处理时，建议在手册中单列一张说明：例如新品研发类项目要求“评审方式”必填，维护升级类项目允许留空。留空字段统一填“不适用”并注明原因，由流程负责人在评审时确认；直接空白不视为有效留空。裁剪规则涉及的字段一旦留空，须经表内注明的审批人批准。
填写示例：一份完整的研发流程手册片段
以下片段以“需求评审流程”为例，演示五部分如何互相引用。示例中的组织名称和阈值均为演示设定，实际填写时替换为组织自身的口径。
流程总览行
| 流程编号 | 流程名称 | 适用项目类型 | 流程负责人 | 流程目标 |
|---|---|---|---|---|
| P-02 | 需求评审 | 新品研发、定制交付 | 产品经理 | 在开发启动前确认需求范围与优先级 |
角色职责行
| 角色 | 所属部门 | 主要职责 | 关键决策权 |
|---|---|---|---|
| 产品经理 | 产品部 | 组织需求评审，维护需求清单 | 决定需求是否进入开发排期 |
活动与交付物行
| 活动编号 | 所属流程 | 活动名称 | 执行角色 | 输入 | 输出 | 评审方式 |
|---|---|---|---|---|---|---|
| P-02-A01 | P-02 | 需求收集与整理 | 产品经理 | 客户反馈、市场调研记录 | 需求清单初稿 | 不适用（内部整理） |
| P-02-A02 | P-02 | 需求评审会 | 产品经理 | 需求清单初稿 | 评审纪要、确认版需求清单 | 会议评审，技术负责人与测试负责人签署 |
| P-02-A03 | P-02 | 需求基线确认 | 项目经理 | 确认版需求清单 | 需求基线记录 | 项目经理批准后归档 |
裁剪规则行
| 裁剪项 | 允许裁剪的条件 | 审批人 |
|---|---|---|
| P-02-A02 需求评审会 | 需求变更仅涉及文案调整且不影响功能范围时，可改为书面确认 | 产品经理 |
变更记录行
| 版本 | 日期 | 变更内容 | 提出人 | 批准人 |
|---|---|---|---|---|
| V1.1 | 2025-03-01 | 新增 P-02-A03 需求基线确认活动，调整裁剪条件表述 | 产品经理 | 研发总监 |
示例中活动编号、裁剪项和变更内容相互对应：新增活动在变更记录中可查，裁剪规则指向具体活动编号，评审方式写明了签署角色。按这个方式填写，手册就能作为执行和审计的共同依据。
手册定稿后，流程、活动和交付物需要在日常协作中承载，否则文档与执行会脱节。ONES 支持将流程中的活动配置为工作项类型，用自定义字段记录执行角色、输入输出和评审状态，评审记录与变更说明沉淀在文档中，使手册条目与实际工作项保持对应。具体配置方式以组织实际使用的平台能力为准。
调整与维护方法
研发流程手册发布后需要持续维护，否则会逐渐与实际执行脱节。维护的核心是明确什么情况触发变更、由谁批准、旧版本如何处置。
变更触发条件与提出渠道
以下情形建议触发手册修订：组织架构或角色职责调整、项目类型新增或合并、流程活动增删、裁剪条件失效、评审中发现执行口径不一致。任何成员均可通过固定渠道（如流程负责人邮箱或协作平台的需求入口）提出变更申请，申请中写明涉及的流程编号、变更内容和理由。
版本号递增与生效日期规则
- 局部修订（措辞调整、裁剪条件细化）升次版本号，如 V1.0 到 V1.1。
- 结构调整（新增流程、合并活动、变更角色设置）升主版本号，如 V1.1 到 V2.0。
- 生效日期不早于批准日期，涉及培训的变更可预留过渡期，并在变更记录中注明。
评审与批准流程
变更申请由流程负责人初审，涉及跨部门职责调整的提交研发负责人批准。批准后更新手册正文和变更记录表，两处内容须一致。评审意见和批准结论一并归档，便于后续追溯。
旧版本归档与通知方式
旧版本移入归档目录并标注“已废止”，保留只读权限。新版本发布后通过固定渠道通知全体相关人员，通知中说明变更要点和生效日期；涉及执行方式变化的，安排一次简短说明会。
定期复核周期建议
建议每半年或每年复核一次手册，核对流程与实际执行是否一致、裁剪规则是否仍适用。复核结论记入变更记录，即使无修改也记录复核日期和复核人，形成完整的维护轨迹。
常见问题
手册里的流程编号和活动编号，后续调整时能不能重新排？
不建议重排。流程编号发布后不复用，活动编号在活动调整时保留原编号，新增活动顺延序号。重排会让裁剪规则、变更记录和历史文档中的引用全部失效，追溯时难以对应。确需合并或废弃编号时，在变更记录中写明原编号与新编号的对应关系。
项目类型较多时，适用项目类型一栏怎么填才不会混乱？
先在封面适用范围中定义类型代码及其含义，表格中只填代码。类型数量较多时，可在手册中增加一张类型说明表，列出代码、定义、典型特征和对应流程范围。这样流程总览表保持简洁，新增类型时只需更新说明表，不必逐行改流程。
裁剪规则写了条件，执行时仍出现各项目自行简化的情况，怎么处理？
常见原因是裁剪条件写得不够可判断，或者审批人没有落实到具体角色。建议把条件写成包含判断依据和判断人的条件句，例如“合同金额低于阈值且无定制开发时，可省略方案评审，由产品经理审批”。同时在变更记录中登记每次裁剪的实际使用情况，复核时据此判断规则是否需要调整。
手册和项目管理平台里的流程配置不一致，以哪个为准？
以手册为准，平台配置是手册的执行载体。发现不一致时，先确认是手册需要修订还是平台配置需要调整，再走变更流程。ONES 支持将流程中的活动配置为工作项类型，用自定义字段记录执行角色、输入输出和评审状态，评审记录与变更说明沉淀在文档中，便于让手册条目与实际工作项保持对应；具体配置方式以组织实际使用的平台能力为准。
定期复核时没有发现需要修改的内容，还要记录吗？
要记录。即使无修改，也在变更记录中登记复核日期、复核人和复核结论，形成完整的维护轨迹。这样能证明手册处于受控状态，也便于下次复核时了解上次核对的范围和判断依据。
