研发流程图模板以“阶段—活动—角色—输入—输出—决策点—交接方式”为主干字段，用一张阶段表和一张活动明细表即可覆盖组织共用的研发流程。本文提供可直接复制填写的两张空白表、逐字段填写口径、必填与选填对照，以及一条需求从提出到上线的完整示例，适用于跨部门共用的研发主流程，不涉及单个工作项的状态流转细节。
要点总览（TL;DR）
- 模板由两张表组成：阶段表定义流程骨架，活动明细表定义每个阶段内谁做什么、交付什么，两表通过阶段编号关联。
- 阶段表必填阶段编号、名称、目标、责任角色、入口与出口条件；活动明细表必填活动编号、所属阶段、活动名称、执行角色、输入与输出。
- 决策点改变流程走向，交接方式只解决输出物如何传递与确认，两类字段分开填写，避免混写。
- 文中提供一条需求从提出到上线的完整填写示例，可对照空白表逐字段核对。
- 流程调整时先改阶段表，再同步活动明细表，记录版本并通知使用方，按固定周期或组织变化触发复核。
可复制空白模板：阶段表与活动明细表
先复制下面两张空白表到文档或表格工具中，再按第二节的字段口径逐项填写。阶段表定义流程的骨架，活动明细表定义每个阶段内谁在什么条件下做什么、交付什么。两张表通过“阶段编号”关联，填写时保持编号一致。
表一：阶段表（空白）
| 阶段编号 | 阶段名称 | 阶段目标 | 责任角色 | 入口条件 | 出口条件 | 关键评审 |
|---|---|---|---|---|---|---|
表二：活动明细表（空白）
| 活动编号 | 所属阶段 | 活动名称 | 执行角色 | 输入 | 输出 | 决策点 | 交接方式 | 时限要求 |
|---|---|---|---|---|---|---|---|---|
行数按实际阶段和活动数量增减。建议阶段控制在4至7个，单个阶段下的活动控制在3至8条，超过这个范围通常说明阶段划分过粗或活动拆得过细，可以回头调整结构。
字段说明：每个字段填什么、怎么判断填对了
字段口径统一，不同团队填出来的流程图才能互相对照。下面按表逐一说明，判断标准写成可核验的描述，便于填写人自查和评审人核对。
阶段表字段口径
| 字段 | 填写内容 | 填对的判断标准 |
|---|---|---|
| 阶段编号 | 按流程先后顺序编号，如S1、S2、S3 | 编号连续、不重复，与活动明细表“所属阶段”引用一致 |
| 阶段名称 | 用动宾或名词短语概括该阶段，如“需求确认”“开发实现” | 名称能独立看懂，不与其他阶段含义重叠 |
| 阶段目标 | 该阶段结束时要达成的结果，一到两句 | 目标可判断是否达成，避免“提升质量”这类无法核验的表述 |
| 责任角色 | 对该阶段整体结果负责的岗位或角色 | 写角色而非具体人名，一个阶段只写一个主责角色 |
| 入口条件 | 进入该阶段前必须已具备的状态或交付物 | 能对应上一阶段的出口条件，形成衔接 |
| 出口条件 | 该阶段可以结束、进入下一阶段时必须满足的状态或交付物 | 可检查、可判定，通常对应具体输出物或评审结论 |
| 关键评审 | 该阶段内必须进行的评审名称及结论形式 | 写明评审对象和通过标准，如“需求评审，结论为通过或退回” |
活动明细表字段口径
| 字段 | 填写内容 | 填对的判断标准 |
|---|---|---|
| 活动编号 | 按“阶段编号-序号”编号，如S2-01 | 编号唯一，前缀与所属阶段一致 |
| 所属阶段 | 填写阶段表中的阶段编号 | 能在阶段表中找到对应行 |
| 活动名称 | 一个可执行的动作，如“编写接口文档” | 以动词开头，一条活动只做一件事 |
| 执行角色 | 实际执行该活动的角色 | 与责任角色区分：执行角色做事，责任角色对阶段结果负责 |
| 输入 | 开展该活动所需的材料、信息或前置结论 | 输入能在上游活动的输出中找到，或标注为外部输入 |
| 输出 | 该活动产生的交付物或结论 | 输出有明确名称和形态，如文档、评审记录、测试报告 |
| 决策点 | 该活动中需要做出判断并可能改变流程走向的节点 | 写明判断问题和不同走向，如“评审是否通过：通过进入S3，退回S2” |
| 交接方式 | 输出物如何传递给下游角色 | 写明传递载体和确认动作，如“提交至项目文档库，由下游角色确认接收” |
| 时限要求 | 该活动的完成时限或节奏要求 | 用可执行的口径，如“收到输入后2个工作日内” |
两组容易混淆的字段
入口条件与出口条件的区别在于方向：入口条件回答“凭什么可以开始”，出口条件回答“做到什么程度可以结束”。同一对相邻阶段中，上一阶段的出口条件应当与下一阶段的入口条件对应，若两者对不上，说明阶段之间的衔接存在缺口。
决策点与交接方式的区别在于作用：决策点改变流程走向，产生通过、退回、终止等分支；交接方式只解决输出物从谁传到谁、以什么形式确认，不改变流程路径。一条活动可以没有决策点，但只要有跨角色传递，就应填写交接方式。
必填与选填：哪些字段不能空
模板允许部分字段暂缺，但主干字段留空会让流程图失去可执行性。下表给出必填与选填的划分及理由，团队可以在此基础上收紧，不建议放宽必填范围。
| 表 | 字段 | 要求 | 理由或适用情形 |
|---|---|---|---|
| 阶段表 | 阶段编号、阶段名称、阶段目标、责任角色 | 必填 | 缺少任一项，阶段无法被识别、追责和验收 |
| 阶段表 | 入口条件、出口条件 | 必填 | 阶段衔接的依据，留空会导致上下游职责不清 |
| 阶段表 | 关键评审 | 条件必填 | 该阶段设有评审时必须填写；无评审的阶段填“无”，不留空 |
| 活动明细表 | 活动编号、所属阶段、活动名称、执行角色 | 必填 | 活动的基本身份信息，缺失则无法定位和分派 |
| 活动明细表 | 输入、输出 | 必填 | 流程图的连接线本质上是输入输出关系，留空则图不成立 |
| 活动明细表 | 决策点 | 条件必填 | 存在分支判断时必填；无分支的活动填“无” |
| 活动明细表 | 交接方式 | 条件必填 | 跨角色传递输出物时必填；同一角色内部完成的活动可暂缺 |
| 活动明细表 | 时限要求 | 选填 | 首次梳理流程时可暂缺，流程稳定后补齐；对外承诺类活动建议直接填写 |
允许暂缺的字段主要是时限要求和部分交接方式。补齐时点建议放在流程首次试运行结束后的复盘会上，此时各环节的实际耗时和传递方式已经清楚，填写比凭经验预估更准确。条件必填字段用“无”显式标注，比留空更利于后续核对，因为留空无法区分“没有”和“忘了填”。
填写示例：一条需求从提出到上线的完整流程
以下示例为演示情景，用于说明字段如何联动，不代表任何特定组织的实际流程。示例范围为一条产品需求从提出到上线的主流程，涉及产品、研发、测试和发布四个角色。
示例背景与范围
某团队需要把需求到上线的主流程固化为组织共用流程，供各项目组参照。流程起点是需求提出，终点是上线完成并归档，不包含线上故障处理和后续运营活动。阶段划分为需求确认、方案设计、开发实现、测试验收、发布上线五个阶段。
阶段表填写示例
| 阶段编号 | 阶段名称 | 阶段目标 | 责任角色 | 入口条件 | 出口条件 | 关键评审 |
|---|---|---|---|---|---|---|
| S1 | 需求确认 | 明确需求范围、价值和验收标准 | 产品负责人 | 需求提出人提交需求说明 | 需求评审通过，形成确认版需求文档 | 需求评审，结论为通过或退回 |
| S2 | 方案设计 | 确定技术方案和工作量评估 | 技术负责人 | 确认版需求文档 | 技术方案评审通过，工作量评估完成 | 技术方案评审，结论为通过或修改后通过 |
| S3 | 开发实现 | 按方案完成开发并自测通过 | 开发负责人 | 技术方案与排期确认 | 代码合并完成，自测记录齐全 | 代码评审，结论为通过或退回修改 |
| S4 | 测试验收 | 验证功能符合验收标准 | 测试负责人 | 提测版本与自测记录 | 测试报告通过，遗留问题已定级处理 | 验收评审，结论为通过或打回 |
| S5 | 发布上线 | 完成发布并确认线上可用 | 发布负责人 | 测试通过结论与发布计划 | 上线完成，发布记录归档 | 发布评审，结论为按计划发布或延期 |
活动明细表填写示例
| 活动编号 | 所属阶段 | 活动名称 | 执行角色 | 输入 | 输出 | 决策点 | 交接方式 | 时限要求 |
|---|---|---|---|---|---|---|---|---|
| S1-01 | S1 | 整理需求说明 | 需求提出人 | 业务问题描述 | 需求说明初稿 | 无 | 提交至需求文档库，产品负责人确认接收 | 提出后2个工作日内 |
| S1-02 | S1 | 组织需求评审 | 产品负责人 | 需求说明初稿 | 评审记录与确认版需求文档 | 评审是否通过：通过进入S2，退回S1-01 | 评审结论同步至需求文档库 | 收到初稿后3个工作日内 |
| S2-01 | S2 | 编写技术方案 | 技术负责人 | 确认版需求文档 | 技术方案文档 | 无 | 方案文档提交至项目空间，开发与测试角色查阅 | 需求确认后3个工作日内 |
| S2-02 | S2 | 技术方案评审与估时 | 技术负责人 | 技术方案文档 | 评审结论与工作量评估 | 方案是否通过：通过进入S3，修改后重审 | 评审结论记录在方案文档中 | 方案提交后2个工作日内 |
| S3-01 | S3 | 开发与自测 | 开发工程师 | 技术方案与排期 | 可提测版本与自测记录 | 无 | 提测单提交至测试角色，附自测记录 | 按排期执行 |
| S3-02 | S3 | 代码评审 | 开发负责人 | 代码变更 | 评审意见与合并记录 | 评审是否通过：通过进入S4，退回修改 | 评审意见记录在代码评审单中 | 提测前完成 |
| S4-01 | S4 | 执行测试 | 测试工程师 | 提测版本与验收标准 | 测试报告 | 是否达到验收标准：达到进入S5，未达到打回S3 | 测试报告提交至项目空间，开发负责人确认 | 提测后按测试计划执行 |
| S5-01 | S5 | 执行发布 | 发布负责人 | 测试通过结论与发布计划 | 发布记录 | 发布是否按计划执行：是则完成，否则延期并记录原因 | 发布记录归档，通知相关角色 | 按发布计划执行 |
示例中决策点与交接方式的写法
决策点写成“判断问题＋不同走向”，例如“评审是否通过：通过进入S2，退回S1-01”，读者据此能画出分支箭头。交接方式写成“传递载体＋确认动作”，例如“提测单提交至测试角色，附自测记录”，读者据此知道输出物在哪里、由谁确认接收。两类字段分开填写，避免把“退回”这类分支写进交接方式，也避免把“提交至文档库”这类传递动作写进决策点。
流程落到协作工具中时，阶段可以对应工作项的状态或分组，活动对应具体工作项，输入输出对应文档与附件，交接方式对应指派与确认动作。以ONES为例，需求、任务、测试与发布可以放在同一项目空间内流转，阶段出口条件和评审结论以文档或工作项字段留存，便于按流程图逐项核对。工具承载的是流程的执行记录，流程图模板本身仍以本文两张表为准。
调整与维护方法：流程变化后怎么改模板
流程图模板需要随组织流程演进同步更新，否则会出现模板与实际做法两张皮。维护的核心规则是：先改阶段表，再改活动明细表，最后记录版本并通知使用方。
新增或合并阶段时的字段调整规则
- 新增阶段时，分配新的阶段编号并保持顺序连续，同时明确其入口条件与相邻阶段的出口条件对应关系，避免出现无人负责的衔接空档。
- 合并阶段时，保留合并后阶段的编号，将原阶段编号在版本记录中标注为已合并，活动明细表中相关活动的“所属阶段”同步改为新编号。
- 阶段目标随阶段调整重写，确保一个阶段只有一个主责角色和一个可判定的目标。
活动明细与阶段表的同步修改要求
任何阶段层面的改动都必须检查活动明细表：阶段编号变化时，所属阶段字段全部更新；阶段出口条件变化时，对应活动的输出和决策点需要复核是否仍然匹配；新增阶段时，至少补充一条能产生该阶段出口条件的活动。修改完成后，用“活动输出能否支撑阶段出口条件”做一次反向核对，这是发现遗漏最直接的方法。
版本记录与变更评审方式
模板每次修改都记录版本号、修改日期、修改人、修改内容和影响范围。影响范围写清楚涉及哪些阶段和活动，便于使用方判断是否需要调整自己的项目流程。涉及阶段增减、评审节点变化或责任角色调整的修改，提交流程负责人和相关角色代表评审后生效；仅修正文字表述的修改可由模板维护人直接更新并记录。
定期复核的触发条件
- 固定周期复核：建议每半年或每年复核一次，核对模板与实际执行是否一致。
- 组织调整触发：团队结构、角色职责或汇报关系变化后，复核责任角色与执行角色字段。
- 流程事故触发：出现因交接不清、评审缺失导致的问题后，复核相关阶段的出口条件、决策点和交接方式。
- 工具或交付形态变化触发：发布方式、文档载体或协作工具调整后，复核交接方式与输出形态的描述。
复核结论分为维持、修订和废止三种，均记入版本记录。模板维护人建议由流程管理或项目管理角色固定承担，避免多人各自修改造成版本分叉。
常见问题
阶段数量控制在多少比较合适？活动拆到多细才够用？
建议阶段控制在4至7个，单个阶段下的活动控制在3至8条。超过这个范围通常说明阶段划分过粗或活动拆得过细，可以回头调整结构。判断标准是：每个阶段有独立且可判定的出口条件，每条活动以动词开头、只做一件事。如果一条活动需要多个角色分别完成不同动作，应拆成多条；如果两条活动总是由同一角色连续完成且中间没有交接，可以合并。
团队第一次填写时，时限要求全部空着可以吗？
可以。时限要求属于选填字段，首次梳理流程时可暂缺，流程稳定后补齐。补齐时点建议放在流程首次试运行结束后的复盘会上，此时各环节的实际耗时已经清楚，填写比凭经验预估更准确。对外承诺类的活动建议直接填写时限，避免流程图中缺少对客户或上下游的交付节奏说明。
条件必填字段填“无”和留空有什么区别？
填“无”表示该阶段或活动确实没有这项内容，例如该活动不存在分支判断；留空则无法区分“没有”和“忘了填”。评审人核对时，填“无”的字段可以直接确认，留空的字段需要逐条追问。因此关键评审、决策点、交接方式这类条件必填字段，没有内容时也建议显式写“无”。
流程图模板和协作工具里的工作项状态是什么关系？
流程图模板描述组织共用的研发主流程，回答阶段如何划分、谁负责、输入输出是什么；协作工具里的工作项状态是流程在具体项目中的执行载体。两者可以对应，例如阶段对应工作项的状态或分组，活动对应具体工作项，交接方式对应指派与确认动作。模板本身仍以两张表为准，工具承载的是执行记录，便于按流程图逐项核对。
模板修改后，已经在用旧版流程的项目组需要同步改吗？
取决于修改的影响范围。版本记录中应写明涉及哪些阶段和活动：仅修正文字表述的修改，项目组无需调整；涉及阶段增减、评审节点变化或责任角色调整的修改，应通知使用方评估是否需要同步调整项目流程。建议在版本记录中增加一列“是否需项目组同步”，让使用方一眼判断。
