业产研协同流程图的设计，先要确定打通的业务链路，从业务机会或客户诉求出发，经产品决策、研发交付，到上线反馈回流；再按“阶段—角色—输入—动作—输出—交接条件”六列建模，把每个交接点写成可判断的状态与交付物，最后用一条真实业务线索走查，确认没有断点和责任真空。流程图的价值在于让业务、产品、研发对同一份工作链路达成一致，重点落在交接规则和异常路径上。流程图定稿后，可以放到ONES这类平台中承载工作项状态与交接记录，让图上的规则在日常协作中持续生效。
要点总览（TL;DR）
- 先划定链路范围：以业务机会、客户诉求或年度规划为起点，以上线反馈回流为终点，明确业务、产品、研发三类核心角色及必要支撑角色。
- 用六列建模：阶段、负责角色、输入、动作、输出、交接条件，其中交接条件必须写成第三方可独立判断的状态，如评审通过、验收通过。
- 绘制顺序按主干、分支、异常三步推进：主干覆盖业务提出到上线反馈，分支处理需求变更、优先级调整、方案驳回、验收不通过，异常标注信息不全、依赖阻塞与上线问题回流。
- 配套角色与交付物分工表，每个阶段写清主责角色、参与角色、交付物形态和交接确认方式，确认人写岗位而非姓名。
- 定稿前用一条真实业务线索走查，确认每个阶段有负责人和输出物、每个交接点可判断、分支有归处、异常有出口。
先定链路范围：流程图从哪一步画到哪一步
动笔之前先回答一个问题：这张图要解决哪一段协作的混乱。业产研协同最常见的断点出现在部门交接处——业务把诉求交给产品后失去进展，产品把方案交给研发后无法确认排期，研发上线后业务不知道结果。流程图应覆盖这段完整链路，起点选业务机会、客户诉求或年度规划中实际触发工作的那一项，终点定在上线反馈回流到业务或产品为止。
范围说明需要写清四件事，建议作为流程图的第一页附注：
- 起点：哪类事件触发流程，例如客户提出定制诉求、业务发现市场机会、年度规划确定方向。起点要具体到可识别的事件，避免写成“业务有需求时”。
- 终点：以什么状态视为一轮协同结束，例如上线完成且反馈已回流、验收结论已归档。
- 参与角色：业务、产品、研发三类核心角色，加上必要的支撑角色，如测试、运维、法务或采购。支撑角色只在链路确实经过其职责时列入。
- 不纳入本图的事项：需求受理的排队规则、需求池的日常管理、团队目标与绩效决策等相邻主题，另行处理，避免流程图变成一张什么都画的大图。
范围说明的完成标志是：三方负责人对“从哪开始、到哪结束、谁在图上”没有异议。这一步花半天对齐，能省掉后面反复改图的时间。
六列建模：把每个阶段写成可交接的字段
流程图画不清楚，多数时候是字段缺失：只写了“产品评估”，没写评估的输入是什么、输出交给谁、什么条件下算评估完成。六列建模把每个阶段拆成固定字段，填满即成型。
| 列 | 填写要求 | 常见错误 |
|---|---|---|
| 阶段 | 用动宾短语命名，如“评估需求价值”“制定版本计划” | 用部门名代替阶段名 |
| 负责角色 | 写具体岗位，一名主责人，可附参与角色 | 写“产品团队”导致无人认领 |
| 输入 | 进入该阶段必须具备的材料或状态 | 输入写成“相关背景”这类无法核对的描述 |
| 动作 | 该角色实际执行的工作，可观察 | 动作写成“沟通协调” |
| 输出 | 产出的交付物形态：文档、评审记录、版本计划、验收结论等 | 输出只写“完成评估”，没有载体 |
| 交接条件 | 可判断的状态，如评审通过、方案确认、验收通过 | 写成“双方达成一致”这类无法判定的表述 |
交接条件是六列中最关键的一列。判断标准很简单：换一个没参与的人来看，能否仅凭这句话判断该阶段是否结束。例如“方案评审通过，评审记录中无未关闭的反对意见”可以判断；“方案基本确定”无法判断。输出物形态也要落到具体载体，文档、评审记录、版本计划、验收结论各自对应不同的留存方式，后续追溯时才知道去哪里找。
六列字段表填完后，它本身就是流程图的绘制底稿：每个阶段对应一个框，交接条件对应框之间的连线标注，输出物对应框旁挂的交付物清单。
画图顺序：从主链路到分支与异常
绘制按三步推进，先保证主干能走通，再补分支，最后标异常。顺序颠倒会让图越画越乱。
第一步，画主干。按“业务提出—产品评估—研发排期—交付验收—上线反馈”五个环节串成一条线。每个环节在图上标注输入、动作、输出与完成标志，例如“研发排期”的完成标志是版本计划确认且资源已分配。主干阶段数控制在五到七个，过多说明粒度太细，过少说明交接点被合并隐藏。
第二步，补分支。主干之外，实际工作中高频出现的路径要单独画出：
- 需求变更：已进入研发的需求发生范围调整，回到产品评估还是就地变更，需要明确判断条件和审批人。
- 优先级调整：业务侧出现更高优先级诉求时，被插队需求的排期如何处理。
- 方案驳回：产品方案在评审中未通过，退回补充材料还是重新评估价值。
- 验收不通过：交付物未达到验收标准，退回研发修复的路径与时限。
每条分支要写清触发条件、处理动作和回到主干的哪个节点，避免分支画出去没有归处。
第三步，标异常。异常路径与业务分支的区别在于它由意外情况触发：信息不全导致无法进入下一阶段、跨团队依赖造成阻塞、上线后出现需要回流处理的问题。异常路径在图上用不同线型标注，并写明谁负责推动解除、超时如何升级。异常处理不需要画得很细，但必须存在，否则流程图在真实场景中第一次遇到阻塞就会失效。
角色与交付物分工表
流程图只有框没有责任人，执行时就会互相等待。分工表按阶段列出主责角色、参与角色和交付物，与流程图配套使用。
| 阶段 | 主责角色 | 参与角色 | 交付物 | 交接确认方式 |
|---|---|---|---|---|
| 提出诉求 | 业务 | 客户成功、售前 | 诉求说明，含场景描述与验收标准 | 产品确认收到并理解诉求 |
| 评估价值与方案 | 产品 | 业务、研发 | 方案文档、优先级判断 | 方案评审通过 |
| 可行性评估与排期 | 研发 | 产品、测试 | 技术方案、版本计划 | 排期确认并同步产品 |
| 开发与自测 | 研发 | 测试 | 可交付版本、自测记录 | 提测通过 |
| 验收 | 产品 | 业务、测试 | 验收结论 | 验收通过或退回修复 |
| 上线与反馈 | 研发 | 业务、产品 | 上线记录、反馈汇总 | 反馈回流至业务或产品 |
业务角色的职责集中在两端：前端提出诉求时提供真实场景与可检验的验收标准，后端上线后反馈实际使用情况。产品角色承担价值判断与方案输出，是链路中交接次数最多的角色，需要保证每次交接都有书面记录。研发角色负责可行性判断、排期承诺与交付质量，排期一旦确认即构成对产品的交接承诺。
交接点的确认人与确认方式要单独写明。确认方式建议采用可留痕的形式，例如评审记录、版本计划中的确认标记、验收结论文档，口头确认在出现争议时无法追溯。确认人写岗位而非姓名，人员变动时流程图仍然有效。
示例：一条客户定制诉求走完整个流程
以下为演示情景，用于说明六列字段如何填写，不代表任何真实客户案例。
某业务人员收到客户定制诉求：希望在报表中增加按区域维度的汇总导出。业务填写诉求说明，写明使用场景、涉及客户数量与验收标准（导出文件包含区域字段且汇总数据与页面一致），提交给产品。这是“提出诉求”阶段的输出，交接条件是产品确认收到并理解诉求。
产品评估后认为该诉求与产品路线图中的报表优化方向一致，输出方案文档并组织评审，业务与研发参加。评审中研发提出当前数据结构的区域字段不完整，方案被驳回，退回产品补充数据来源说明。这是第一次分支处理：方案驳回的触发条件是评审存在未关闭的技术异议，处理动作是产品补充材料后重新评审，回到“评估价值与方案”节点。补充完成后第二次评审通过，进入研发排期。
研发评估可行性后给出排期，纳入下个版本计划，产品确认排期。开发完成后提测，测试通过后交产品验收。产品按验收标准核对时发现汇总数据与页面存在一处口径差异，验收不通过，退回研发修复。这是第二次分支处理：验收不通过的触发条件是验收结论中存在未达标项，处理动作是研发修复后重新提交验收，时限按版本节奏约定。修复后二次验收通过，上线。
上线后业务向客户确认使用情况，将反馈汇总回流给产品，本轮流程结束。整个过程中，诉求说明、两次评审记录、版本计划、两次验收结论和反馈汇总均作为交接记录留存，任何一方对某个节点的状态有疑问时，都能从记录中找到依据。这类记录如果放在ONES中，业务需求池、产品需求池与工单可以承接诉求与状态流转，评审记录和验收结论可随工作项留存，需求、任务、测试、缺陷之间的关联也能在同一个链路里追溯。
完成检查：流程图是否可用的判断标准
流程图定稿前，用以下清单逐项核对。任何一项不通过，都说明图还停留在示意阶段，无法指导实际协作。
- 阶段完整性：从起点到终点每个阶段都有明确负责人和输出物，不存在只有框没有责任人的环节。
- 交接可判断：每个交接点的完成条件都能被第三方独立判断，没有“基本完成”“大致一致”这类表述。
- 交付物有载体：每个输出都对应具体形态，文档、评审记录、版本计划、验收结论各有存放位置。
- 分支有归处：需求变更、优先级调整、方案驳回、验收不通过等分支都写明了触发条件、处理动作和回归节点。
- 异常有出口：信息不全、依赖阻塞、上线问题回流等异常路径有推动人和升级方式。
- 走查无断点：选一条近期真实业务线索，从起点模拟走到终点，确认每一步都能在图上找到对应阶段和交接条件。
走查是最有效的验收方式。走查时让业务、产品、研发各出一人，按各自视角指出“这一步我实际拿不到输入”或“这个条件我无法判断”的位置，这些位置就是需要修订的地方。走查通过后，流程图可以作为三方协作的共同基准发布，并在每次出现新的分支或异常类型时更新版本。
常见问题
流程图画到多细才合适，阶段数量怎么控制？
主干阶段建议控制在五到七个，覆盖业务提出、产品评估、研发排期、交付验收、上线反馈这条主线。阶段过多说明粒度太细，图会变成操作手册；阶段过少说明交接点被合并隐藏，部门之间的责任边界反而看不清。判断标准是：每个阶段对应一次明确的责任转移，如果两个相邻阶段由同一角色连续完成且中间没有交付物交接，可以合并。
业务、产品、研发三方对交接条件理解不一致怎么办？
交接条件的分歧通常来自表述模糊，而非立场不同。处理方式是逐条改写为可判断的状态，例如把“方案基本确定”改成“方案评审通过，评审记录中无未关闭的反对意见”。改写后让三方各出一人做一次走查，按各自视角指出无法判断的位置，这些位置就是需要修订的地方。走查通过后，流程图作为共同基准发布，后续出现新的分支类型时更新版本，避免口头约定替代图上规则。
需求变更和优先级调整在图上怎么处理，是否需要单独审批？
需求变更和优先级调整是两类不同分支，建议分开画。需求变更的触发条件是已进入研发的需求发生范围调整，需要明确是回到产品评估还是就地变更，并指定审批人；优先级调整的触发条件是业务侧出现更高优先级诉求，需要写明被插队需求的排期如何处理。两条分支都要标注触发条件、处理动作和回到主干的哪个节点。是否单独审批取决于变更影响的范围，影响版本计划或验收标准的变更建议留痕审批，仅涉及描述补充的变更可由产品主责人确认。
流程图定稿后放在哪里，怎么保证日常协作中持续生效？
流程图本身是共识文件，真正让规则生效的是每个交接点的状态与记录有承载位置。常见做法是把阶段对应到工作项状态，把交接条件对应到状态流转的准入规则，把评审记录、版本计划、验收结论随工作项留存。ONES 提供统一的业务需求池、产品需求池与工单系统，可承接需求提出到交付的状态流转，需求、任务、测试、缺陷之间可以关联追溯，评审与验收记录随工作项保存。流程图发布后建议指定一名维护人，在出现新分支或异常类型时更新版本并同步三方。
团队规模较小、角色由一人兼任时，流程图还需要画吗？
需要，但可以简化。角色兼任时，流程图的价值从划分部门责任转为明确阶段交付物和判断条件，避免同一个人在不同阶段之间跳过必要的确认。做法是保留六列结构中的输入、输出和交接条件，负责角色可以合并填写，但每个阶段的输出物形态仍要写清，例如方案文档、版本计划、验收结论。走查时重点检查是否存在自己确认自己、缺少独立判断的环节，这类环节在团队扩张后最容易成为断点。
