设计业产研协同流程图，关键是把业务、产品、研发三方之间的交接点画清楚，让每个交接点都有负责人、交付物和完成标志。本文按“定链路—五步绘制—角色分工—示例—完成检查”的顺序展开，范围限定在业产研工作链路本身，需求管理和团队目标对齐只作为边界说明，不展开。
要点总览（TL;DR）
- 先圈定链路范围：以业务目标输入为起点、价值反馈为终点，识别目标转需求、需求转方案、方案转开发、开发转验收、上线转反馈五个关键交接点。
- 按五步绘制：列角色与职责边界、梳理阶段四要素、用泳道和交接箭头组织图形、标注评审变更与异常分支、补充价值反馈回路并定稿。
- 每个交接点都要落到具体角色和交付物上，评审与变更节点单独指定决策角色，避免图好看但无人认领。
- 完成检查看六项：交接点负责人、交付物与验收口径、状态覆盖、异常分支、反馈回路、与实际做法一致。
- 流程图试用一两个迭代后复查，把新增分支和实际使用的交付物补进图里再定稿发布。
先定链路：流程图要覆盖哪几段协同
动笔之前先圈定范围。业产研协同流程图通常以业务目标输入为起点，以价值反馈为终点，中间经过业务、产品、研发三段。范围定得越具体，图越容易落地；把相邻主题全部塞进一张图，往往导致节点过多、无人认领。
链路划分可以按三个问题推进：业务段回答“为什么做、做到什么程度算成功”；产品段回答“做成什么、先做哪部分”；研发段回答“怎么实现、何时可交付”。三段之间的交界处就是关键交接点，通常出现在目标转需求、需求转方案、方案转开发、交付转验收、上线转反馈这几个位置。
需要明确的是，具体需求如何分级、如何排优先级属于需求管理的范畴；团队目标如何设定、决策机制如何运转属于目标对齐的范畴。本文只处理这些内容在流程图上作为“输入”或“约束”出现的位置，不展开其内部方法。
完成这一步的产物是一份链路范围清单，至少写清三列：起止点（从什么事件开始、到什么事件结束）、三段交接点（列出名称和触发条件）、不在图内的相邻主题（写明归属，避免后续争议）。
核心答案与操作步骤：五步画出协同流程图
五步法的核心逻辑是先把人和事列全，再组织图形，最后补分支和回路。每一步都有明确的输入、动作、输出和完成标志，做完一步再进入下一步，避免边画边改。
第一步：列出参与角色与职责边界
输入是链路范围清单。动作是把三段中出现的角色逐一列出，并写明每个角色“负责什么、不负责什么”。输出是一张角色清单。完成标志是：每个角色都能说出一句职责边界，且不存在两个角色对同一件事都声称负责或都不负责的情况。
第二步：按阶段梳理输入、动作、产出、状态
输入是角色清单。动作是沿链路逐段填写四要素：这一段收到什么输入、谁做什么动作、产出什么交付物、交付物处于什么状态（如待评审、已确认、开发中、待验收）。输出是一张阶段要素表。完成标志是每个阶段四要素齐全，且状态名称前后一致。
第三步：用泳道和交接箭头组织图形
输入是阶段要素表。动作是按角色划分泳道，把动作放入对应泳道，用箭头表示交接，箭头两端标注交付物名称。输出是流程图初稿。完成标志是：任意一条箭头都能回答“谁交给谁、交的是什么”。
第四步：标注评审、变更、异常分支
输入是流程图初稿。动作是在需要确认的节点加评审标记，写明评审人和通过标准；在可能返工的位置加变更分支，写明变更由谁提出、谁决策；对延期、需求撤回、验收不通过等情况补充异常路径。输出是带分支的流程图。完成标志是每条分支都有终点，不出现断头箭头。
第五步：补充价值反馈回路并定稿
输入是带分支的流程图。动作是从上线或交付节点引出反馈回路，标明反馈由谁收集、以什么形式回到业务段或产品段、触发什么后续动作。输出是定稿流程图及配套说明。完成标志是反馈回路闭合，且图与团队实际做法一致。
角色及交付物：每个交接点由谁负责
流程图上的节点要落到具体角色和交付物上，否则容易出现“图好看、事没人管”。下表给出常见交接点的分工参考，实际使用时按团队岗位名称调整。
| 交接点 | 交出方 | 接收方 | 交付物 | 验收口径 |
|---|---|---|---|---|
| 目标转需求 | 业务 | 产品 | 业务目标说明与成功指标 | 指标可量化、范围可界定 |
| 需求转方案 | 产品 | 研发 | 需求说明与方案草案 | 关键场景、边界条件已确认 |
| 方案转开发 | 研发 | 研发 | 技术方案与排期 | 评审通过、依赖已识别 |
| 开发转验收 | 研发 | 产品、业务 | 可验收版本与说明 | 验收清单逐项通过 |
| 上线转反馈 | 业务 | 产品 | 使用数据与问题清单 | 反馈有来源、有归集口径 |
评审与变更节点需要单独指定决策角色。常见做法是：方案评审由产品负责人和研发负责人共同确认，范围变更由业务负责人决策、产品负责人评估影响。决策角色写进图里，比写在会议纪要里更容易被遵守。
当流程图需要承载状态流转时，可以用ONES的工作项状态和评审流转来对应图中的节点：需求、任务、缺陷各自有状态，评审结论和变更记录留在工作项上，交接时以状态变化作为完成标志。这样图上的箭头和系统里的流转能对得上，减少“图上一套、实际一套”的偏差。
示例：一条需求从业务目标到价值反馈的流程图
以下为演示情景，用于说明图形组织方式，不代表任何具体团队的真实案例。
背景：某业务线希望提升新用户首次使用完成率，链路从业务目标提出开始，到上线后数据反馈结束。泳道划分为业务、产品、研发三条，另设一条“评审与决策”辅助泳道。
节点排布如下：业务泳道依次为“提出目标与指标”“确认验收结果”“收集使用反馈”；产品泳道依次为“拆解需求”“输出方案”“组织验收”“分析反馈并决定是否迭代”；研发泳道依次为“方案评审”“开发与自测”“提交验收版本”“上线发布”。
交接箭头标注方式：业务到产品的箭头写“目标说明与成功指标”；产品到研发的箭头写“需求说明与方案草案”；研发到产品的箭头写“可验收版本”；产品到业务的箭头写“验收结论”。评审点用菱形标在“方案评审”和“组织验收”两处，旁边注明评审人和通过标准。变更分支从“方案评审”引出，指向“拆解需求”，注明变更提出人和决策人。反馈回路从“收集使用反馈”回到“拆解需求”，标注反馈形式和归集周期。
这张图的价值在于：任何一个人沿着箭头走一遍，都能知道自己在上游等什么、向下游交什么。迁移到自己场景时，保持泳道划分和箭头标注规则不变，替换节点名称即可。
完成检查：流程图是否可用的判断标准
图画完后，用下面这份清单逐项核对。全部通过，说明图可以进入试用；有未通过项，回到对应步骤修补。
| 检查项 | 判断标准 | 不通过时的处理 |
|---|---|---|
| 交接点负责人 | 每条箭头两端都有明确角色，无“相关方”这类模糊表述 | 回到第一步补角色边界 |
| 交付物与验收口径 | 每个交接点都有交付物名称和可核对的验收标准 | 回到第二步补四要素 |
| 状态覆盖 | 主要交付物都有状态标识，状态名称前后一致 | 统一状态命名后重画 |
| 异常分支 | 延期、撤回、验收不通过等情形有路径和终点 | 回到第四步补分支 |
| 反馈回路 | 反馈有收集人、有回到链路的入口、有触发动作 | 回到第五步补回路 |
| 与实际做法一致 | 随机抽三个近期事项，能按图走通 | 修正图或调整做法，二者取其一 |
最后一项最容易被忽略。流程图是协同约定的载体，图与实际做法不一致时，要么改图，要么改做法，保留两套标准只会让交接点重新变得模糊。建议在试用一两个迭代后复查一次，把新增的分支和实际使用的交付物补进图里，再定稿发布。
常见问题
流程图要不要把需求优先级排序、目标设定这些内容也画进去？
建议不画进去。需求如何分级、如何排优先级属于需求管理的内部方法，团队目标如何设定、决策机制如何运转属于目标对齐的范畴。流程图只处理这些内容作为“输入”或“约束”出现的位置，例如业务段的目标说明作为产品段的输入、需求优先级结论作为方案排期的约束。把这些内部方法展开成节点，会让图迅速膨胀，交接点反而被淹没。
如果团队确实需要在一张图里看到这些内容，可以单独画一张关联图，用入口节点指向协同流程图，保持主图聚焦在业务、产品、研发三段的交接上。
小团队角色少，一个人同时承担业务和产品职责，泳道怎么划分？
泳道按职责划分，不按人头划分。一个人承担多个职责时，可以在不同泳道里出现同一个名字，或者把泳道名称写成“业务/产品”合并泳道。关键是每个交接点的交出方和接收方仍然明确，不能因为人少就省略交接动作。
合并泳道后要额外检查一点：原来由两个人交接时自然产生的确认动作，现在是否还有明确的完成标志。例如目标转需求这个交接点，即使同一个人完成，也应留下目标说明和成功指标作为交付物，供后续验收对照。
评审点和变更分支画到什么颗粒度合适？
以“能回答谁评审、评审什么、不通过怎么办”为标准。评审点标出评审人和通过标准即可，不必把评审会议议程画进图里；变更分支标出变更由谁提出、谁决策、回到哪个节点即可，不必展开变更影响分析的细节。
颗粒度过细会让图变成操作手册，过粗则分支没有终点。一个实用的判断方法是：随机挑一个近期发生过的变更，看能否沿着图上的分支走通。走不通说明分支缺失，走得太绕说明颗粒度需要收敛。
流程图定稿后，怎么保证团队按图执行？
先让图与团队实际做法对齐，再谈执行。定稿前随机抽三个近期事项按图走一遍，走不通的地方要么改图、要么改做法，保留两套标准会让交接点重新变得模糊。
执行阶段可以把图上的状态和交接标志对应到团队日常使用的工作项上，让状态变化成为交接完成的信号。ONES 的工作项状态和评审流转可以承载这类节点，需求、任务、缺陷各自有状态，评审结论和变更记录留在工作项上，图上的箭头和系统里的流转能对得上。建议试用一两个迭代后复查一次，把实际新增的分支补进图里再正式发布。
业务方不习惯看流程图，怎么让流程图真正被用起来？
把图翻译成业务方关心的语言。业务方通常更关注“我提出目标后什么时候能得到什么”“验收不通过会怎样”，可以在图旁配一份简版说明，按业务视角列出三个问题的答案：我需要提供什么、我在哪个节点参与确认、反馈多久回到我这里。
另外，把交接点的交付物做成固定模板，例如目标说明模板、验收清单模板，业务方按模板填写即可，降低看图门槛。流程图作为协同约定的载体，配套模板和简版说明往往比图本身更容易被日常使用。
