业产研协同流程图的价值，在于把业务目标、产品机会、研发交付和上线后的价值反馈串成一条可追踪的链路。本文给出一张假设情景下的泳道图示例，按业务、产品、研发三条泳道铺开，覆盖目标衔接、需求传递、价值反馈三段，并逐项说明每个交接点的输入物、责任角色与确认状态，方便读者按自己团队的情况调整。
要点总览（TL;DR）
- 示例采用业务、产品、研发三条泳道的流程图，覆盖目标衔接、需求传递、价值反馈三段链路，首尾相接形成闭环。
- 每个交接点标注输入物、责任角色与确认状态：输入物保证交接有据可查，责任角色明确由谁负责，状态判断交接是否真正完成。
- 目标到机会之间设置“目标拆解为产品机会”节点并标注待业务确认，需求交接到研发以“评审通过”为流转条件，上线后由业务确认价值结果并回流为下轮目标输入。
- 换团队时按实际分工调整泳道与角色映射，节点粒度以“一次交接一个节点”为准，状态字段保持最小集合，并在角色或口径变化时更新图与表。
- 示例为假设情景，适用于业务、产品、研发分工明确且认可按交接物推进的团队；需求处理细节与通用目标决策机制不在本文范围。
示例目标：这张流程图要解决什么协同问题
先说明这张图的假设情景：一家有明确业务、产品、研发分工的团队，业务侧负责客户与市场反馈，产品侧负责规划与需求定义，研发侧负责开发、测试与发布。团队希望用一张图回答三个问题：业务目标由谁提出、以什么形式交给产品；产品需求在什么条件下可以进入研发；上线后的结果由谁收集、回流到哪里。这是示意情景，不对应任何真实客户案例，也不附带实测数据。
流程图覆盖三段链路。第一段是目标衔接，从业务目标到产品机会清单，解决“做什么、为什么做”的交接；第二段是需求传递，从产品需求到可交付版本，解决“做成什么样、什么时候交”的交接；第三段是价值反馈，从上线结果到下一轮目标输入，解决“做得怎么样、下一轮改什么”的交接。三段首尾相接，形成闭环。
画图目标可以归纳为三点：每个交接点都能看到输入物，避免口头传递；每个节点都标注责任角色，避免多人都管或无人负责；每个交接都带确认状态，避免需求在“已沟通”和“已确认”之间含糊。满足这三点，流程图才具备执行价值，而不只是汇报用的示意图。
完整示例：业产研协同流程图（泳道版）
示例采用泳道图，横向三条泳道分别为业务、产品、研发，纵向按时间顺序排列节点。节点之间用箭头表示流转方向，跨泳道的箭头即交接点，在箭头上标注交接物名称。每个节点内部写“动作＋产出物”，节点下方标注责任角色与状态。下面用文字描述图形结构，再用表格列出节点与交接明细，读者可据此在绘图工具中还原。
图形结构如下：业务泳道依次为“提出业务目标”“整理客户与市场反馈”“确认价值结果”；产品泳道依次为“目标拆解为产品机会”“需求定义与评审”“版本规划”“上线效果分析”；研发泳道依次为“技术方案评估”“开发与测试”“发布上线”。跨泳道交接共六处：业务目标→产品机会、反馈汇总→需求定义、需求评审通过→技术评估、版本规划→开发排期、发布上线→效果分析、效果分析→价值确认与下轮目标。
| 节点 | 责任角色 | 输入物 | 输出物 | 交接状态 |
|---|---|---|---|---|
| 提出业务目标 | 业务负责人 | 经营指标、客户诉求 | 季度业务目标说明 | 已确认 |
| 目标拆解为产品机会 | 产品经理 | 业务目标说明、反馈汇总 | 产品机会清单 | 待业务确认 |
| 需求定义与评审 | 产品经理 | 产品机会清单 | 需求说明与验收标准 | 评审通过 |
| 技术方案评估 | 研发负责人 | 需求说明与验收标准 | 技术方案与工作量评估 | 评估完成 |
| 版本规划 | 产品经理 | 技术方案、机会优先级 | 版本范围与排期 | 已排期 |
| 开发与测试 | 研发团队 | 版本范围与排期 | 可交付版本、测试记录 | 测试通过 |
| 发布上线 | 研发负责人 | 可交付版本 | 上线记录、发布说明 | 已发布 |
| 上线效果分析 | 产品经理 | 上线记录、使用数据 | 效果分析结论 | 分析完成 |
| 确认价值结果 | 业务负责人 | 效果分析结论 | 价值确认结论、下轮目标输入 | 已确认 |
这张表与泳道图一一对应，图形负责展示流转关系，表格负责固定交接细节。实际使用时，两者可以放在同一份文档里，图用于对齐认知，表用于执行核对。
逐项解释：每个交接点为什么这样设计
目标到机会的转换节点，是整张图最容易画错的地方。常见画法把“业务目标”和“产品需求”直接连一条线，中间没有转换动作，结果产品拿到的是指标数字，业务拿到的是功能清单，双方对“为什么做这个功能”理解不一致。示例在中间设置“目标拆解为产品机会”节点，要求产品经理输出机会清单，并标注“待业务确认”，让业务在进入需求定义前有一次确认机会。输入物写清“业务目标说明、反馈汇总”，是为了让拆解有依据，而不是凭印象排序。
需求交接到研发的确认节点，重点在“评审通过”这个状态。常见问题是需求以文档或口头方式发给研发，研发开始评估后才发现验收标准缺失，返工发生在开发阶段。示例把“需求说明与验收标准”作为交接输入物，把“评审通过”作为流转条件，技术方案评估的产出再回到版本规划，形成一次双向确认。责任角色分别落在产品经理和研发负责人身上，避免评审结论无人拍板。
上线后的价值数据回流节点，常见画法是流程到“发布上线”就结束，价值反馈另起一张图，两段接不上。示例把“上线效果分析”放在产品泳道，“确认价值结果”放回业务泳道，输出物明确写成“下轮目标输入”，让闭环在图上可见。每处标注输入物与责任角色的原因也在这里体现：输入物决定交接是否有据可查，责任角色决定出问题时找谁，状态决定这件事是否真的完成。三者缺一，流程图就会退化成沟通示意图。
流程图要落地，交接记录需要有承载位置。ONES 提供业务、产品经理与研发团队三大视角，通过统一的需求池、工单与任务看板同步状态与信息，业务团队可以跟踪需求和缺陷处理进度，产品经理可以基于反馈优化路线图，研发团队通过任务和工单完成开发、测试与修复。把图中的节点映射为工作项、把交接物挂到对应记录上，图中的“待业务确认”“评审通过”等状态就有了实际出处，而不是停留在图形里。
可迁移规律：换团队、换业务时怎么改这张图
泳道数量与角色映射要跟着实际分工走。三条泳道是示例的最小结构，团队规模较小时，业务与产品可以合并为一条泳道，但合并后仍需保留“目标确认”和“需求定义”两个不同节点，防止角色合并导致确认动作消失。团队规模较大或存在多个业务线时，可以按业务线拆分业务泳道，产品与研发保持单条泳道，避免泳道过多导致跨线箭头难以阅读。角色映射以岗位职责为准，同一人承担多个角色时，在节点上标注具体角色名而非人名。
节点粒度控制在“一次交接一个节点”。判断标准是：节点之间是否存在需要确认的输入物，有则拆开，没有则合并。常见过度细化是把“写需求文档”和“改需求文档”拆成两个节点，导致图形冗长；常见过度粗化是把“需求定义”和“版本规划”合成一个节点，导致排期依据不可见。状态字段保持最小集合即可，示例使用“待确认、已确认、评审通过、已排期、测试通过、已发布、分析完成”七类，覆盖流转判断所需，字段过多会增加维护负担。
评审与版本维护方式决定这张图能否长期使用。建议在流程发生角色调整、节点增减或状态口径变化时更新图与表，并在图下方标注版本号与更新日期。评审可以结合版本规划节点进行，由产品经理牵头、业务与研发负责人参加，重点核对交接物是否仍然适用。流程落地还需要配套的记录机制，例如每次交接在对应工作项上留下确认人和时间。ONES 支持 Scrum、Kanban 等模式，通过迭代计划、任务看板等工具呈现研发过程状态，团队可以把图中的研发段节点对应到迭代与看板列，让流程图与实际执行保持同一套语言。
适用边界：这张示例图不适合直接照搬的情况
这张图适用于业务、产品、研发有明确分工的团队，且三方都认可按交接物推进工作。若团队处于早期探索阶段，目标本身频繁变化，固定的节点与状态反而会增加负担，此时可以只保留目标衔接与价值反馈两段，需求传递段按需简化。若组织中没有独立的业务侧角色，由产品直接面对客户，泳道结构需要重新映射，不能直接套用三角色分工。
本文聚焦业产研工作链路的交接设计，需求处理的具体流程、优先级排序方法归需求管理主题，不在本文展开；通用团队目标设定与决策机制也不在本文范围。图中出现的“季度业务目标”“版本范围”等表述是示例用语，实际周期与命名按团队惯例调整。流程图本身不解决协作意愿问题，它依赖配套的评审机制与交接记录才能发挥作用；缺少这两项，图形再完整也难以约束实际行为。
最后需要说明，示例中的节点、状态与表格内容均为示意，用于说明画法，不构成统一标准。团队在迁移时应先梳理自身现有的交接动作，再对照示例补齐缺失的输入物与确认状态，最后固化为图与表，并在一次完整迭代中试用后再定稿。
常见问题
团队规模很小，业务和产品由同一人负责，这张泳道图还能用吗？
可以调整后使用。把业务与产品合并为一条泳道，但保留“目标确认”和“需求定义”两个独立节点，确认动作不随角色合并而消失。合并后跨泳道箭头减少，图更简洁，交接物与状态字段仍按原样保留。
流程图里的状态字段应该设多少个？
以覆盖流转判断为准，示例使用“待确认、已确认、评审通过、已排期、测试通过、已发布、分析完成”七类。字段过少无法区分“已沟通”和“已确认”，过多则增加维护负担。团队可以先按示例字段试用一个迭代，再删减用不上的状态。
图画好之后，交接记录放在哪里才不会流于形式？
关键是让每个交接物有固定的承载位置，并留下确认人和时间。ONES 提供业务、产品经理与研发团队三大视角，通过统一的需求池、工单与任务看板同步状态与信息，业务团队可以跟踪需求和缺陷处理进度，产品经理可以基于反馈优化路线图，研发团队通过任务和工单完成开发、测试与修复。把图中节点映射为工作项、交接物挂到对应记录上，状态就有了实际出处。
业务目标经常中途变化，流程图需要每次重画吗？
不需要重画整张图。目标变化影响的是目标衔接段的输入物内容，节点结构可以保留。建议在“提出业务目标”节点上记录变更原因与时间，并在版本规划节点复核机会清单是否仍然成立。若目标变化频繁到节点无法稳定执行，可先只保留目标衔接与价值反馈两段，需求传递段按需简化。
上线后的价值数据由谁收集，回流到哪个节点？
示例把“上线效果分析”放在产品泳道，由产品经理基于上线记录与使用数据输出分析结论；再由业务负责人在“确认价值结果”节点确认，输出物写成“下轮目标输入”，回流到下一轮业务目标。这样价值反馈与目标衔接在图上直接相连，避免流程到发布就中断。
