业产研协同流程图的价值，在于把业务、产品、研发三方在同一工作链路上的输入、动作、产出和交接点画清楚，减少靠口头传递造成的理解偏差。下面给出一份可直接套用的完整示例：以“业务提出机会—产品定义方案—研发交付上线”为主线，标出每个环节的责任角色、关键字段、评审节点和异常回流路径，并逐项解释这样画的原因。示例为演示情景，非真实客户案例；流程图落地后需要承载工作项状态与交接时，可考虑用ONES这类平台承接需求池、任务看板与测试缺陷闭环。
要点总览（TL;DR）
- 这份业产研协同流程图示例以“业务提出机会—产品定义方案—研发交付上线”为主线，包含三条泳道、八个环节，每个环节标注责任角色、输入、产出物和完成标准。
- 关键交接点集中在立项评审和测试验收：前者是业务与产品的正式移交，后者是研发交付前的质量关口；三条回流路径分别回到机会提出、方案定义和排期开发。
- 可迁移的核心规律是：先定交接点再补环节，每个环节必须有可核对的产出物和可判断的完成标准，回流路径要写触发条件而非只画箭头。
- 该示例适合中大型跨部门协作、有明确交付节奏的团队；单人团队或纯外包交付可压缩为机会提出、方案确认、验收交付三个节点。
- 流程图落地后需要承载工作项状态与交接时，可用ONES统一需求池、任务看板与测试缺陷闭环作为承接方向。
这份流程图要解决什么问题
这张图的目标很具体：让三方在同一个页面上看到“谁在什么时候把什么东西交给谁”。业务侧关心机会是否被受理、进展到哪一步；产品侧关心方案是否被评审、研发是否理解；研发侧关心输入是否完整、验收标准是否明确。流程图把这些交接点固定下来，形成可对照、可追溯的协作约定。
覆盖范围限定在从业务机会识别到研发上线交付的主链路，包括立项评审、方案定义、技术评估、排期开发、测试验收、上线交付和复盘。需求优先级排序、团队目标对齐与决策机制不在本图展开，它们属于另外的管理动作，混进流程图会让主链路失焦。
| 范围界定 | 内容 |
|---|---|
| 在范围内 | 业务机会提出、立项评审、方案定义、技术评估、排期开发、测试验收、上线交付、复盘；三方泳道与交接点；评审节点与异常回流路径 |
| 不在范围内 | 具体需求优先级排序与需求池管理规则；团队目标对齐与决策机制；工具选型、价格与版本对比 |
完整示例：一张业产研协同流程图
以下为演示情景：某团队计划上线一项面向存量客户的自助服务能力。图中三条泳道分别对应业务、产品、研发，主链路共八个环节，每个环节标注责任角色、输入、产出物和完成标准。文字化泳道图按“环节—泳道—产出—交接对象”排列，便于直接转成绘图工具中的泳道结构。
| 环节 | 责任泳道与角色 | 主要输入 | 产出物 | 交接对象与完成标准 |
|---|---|---|---|---|
| 1. 机会提出 | 业务泳道：业务负责人 | 客户反馈、市场信号、业务数据 | 机会说明单（背景、目标客户、预期价值、初步约束） | 提交至产品负责人；完成标准为机会说明单字段齐全 |
| 2. 立项评审 | 业务与产品共同：业务负责人主持，产品负责人参与 | 机会说明单、初步可行性判断 | 立项结论（通过/退回/暂缓）与立项纪要 | 通过则移交产品泳道；退回则回流至机会提出 |
| 3. 方案定义 | 产品泳道：产品经理 | 立项纪要、业务目标、用户场景 | 产品方案（范围、流程、验收口径、依赖说明） | 提交技术评估；完成标准为方案覆盖立项目标且验收口径可测 |
| 4. 技术评估 | 研发泳道：技术负责人 | 产品方案、现有架构与资源约束 | 技术评估意见（可行性、工作量区间、风险点、替代方案） | 反馈产品经理；方案需澄清则回流至方案定义 |
| 5. 排期开发 | 研发泳道：研发负责人与开发人员 | 确认后的方案、技术评估意见 | 排期计划、开发任务、提测版本 | 提测移交测试；完成标准为任务拆分到人、提测说明完整 |
| 6. 测试验收 | 研发泳道：测试人员；产品泳道：产品经理参与验收 | 提测版本、验收口径、测试用例 | 测试报告、缺陷清单、验收结论 | 通过则移交上线；缺陷则回流至排期开发 |
| 7. 上线交付 | 研发泳道：发布负责人；业务泳道：业务负责人确认 | 验收结论、上线检查单 | 上线记录、交付说明、业务可用确认 | 移交复盘；完成标准为上线检查单逐项确认 |
| 8. 复盘 | 三方共同：业务、产品、研发各出一名代表 | 上线记录、过程问题、业务反馈 | 复盘纪要（问题、原因、改进项与责任人） | 改进项进入下一轮机会或流程优化 |
评审节点集中在两处：立项评审是业务与产品的正式交接点，测试验收是研发交付前的质量关口。回流路径有三条：立项未通过回到机会提出；技术评估发现方案不可行回到方案定义；测试发现缺陷回到排期开发。三条回流都标注触发条件，避免只画正向箭头。
逐项解释：每个环节为什么这样画
流程图的可信度来自每个环节的设计理由能被说清楚。下面按环节解释关键选择，并给出每个环节应携带的关键字段与回流条件。
| 环节 | 设计理由 | 关键字段 | 回流条件与去向 |
|---|---|---|---|
| 立项评审 | 业务与产品的职责在此切换：业务确认“值不值得做”，产品确认“能不能接”。把评审设为交接点，使机会说明单成为双方共同认可的输入，避免产品在信息不全时直接进入方案设计 | 负责人、机会说明单、评审结论、评审日期 | 结论为退回或暂缓时，回流至机会提出补充信息 |
| 方案定义 | 方案是研发评估的对象。先有范围、流程和验收口径，技术评估才有比较基准，否则评估容易变成对模糊想法的口头讨论 | 产品经理、方案版本、验收口径、依赖说明 | 技术评估提出方案澄清时，回流至本环节修订 |
| 技术评估 | 放在方案定义之后、排期之前，是因为它需要方案作为输入，同时它的结论直接影响排期。评估输出工作量区间和风险点，为排期提供依据 | 技术负责人、可行性结论、工作量区间、风险清单 | 判定不可行或成本超出预期时，回流至方案定义调整范围 |
| 排期开发 | 排期是把评估结论转成可执行任务的动作。任务拆分到人、提测说明完整，才能保证测试环节拿到可验证的版本 | 研发负责人、排期计划、任务清单、提测说明 | 开发中发现方案缺口时，回流至方案定义确认 |
| 测试验收 | 测试与上线分离，是因为测试回答“是否符合验收口径”，上线回答“是否具备发布条件”。合并两者会让质量判断被发布节奏挤压 | 测试负责人、测试报告、缺陷清单、验收结论 | 存在未关闭缺陷时，回流至排期开发修复 |
| 上线交付 | 上线需要业务侧确认可用，交付说明让业务知道如何使用和反馈。上线检查单把发布前的确认动作固定下来 | 发布负责人、上线检查单、交付说明、业务确认 | 上线后发现阻断性问题时，回流至排期开发并触发复盘 |
| 复盘 | 复盘把过程问题和业务反馈转成改进项，让流程图本身可以迭代，而不是画完就固定 | 三方代表、复盘纪要、改进项与责任人 | 改进项进入下一轮机会提出或流程修订 |
每个环节都应携带四类关键字段：负责人、输入、产出、完成标准。负责人写角色而非姓名，便于人员变动时图仍然有效；输入写上游交付物名称，保证交接可核对；产出写具体文档或记录；完成标准写可判断的条件，例如“验收口径可测”“检查单逐项确认”。回流路径要写触发条件，例如“技术评估判定不可行”“存在未关闭缺陷”，只画箭头不写条件，回流就会变成无法执行的装饰。
当流程图从纸面进入日常协作，交接点的状态需要被持续记录。ONES 提供业务、产品经理与研发团队三大视角，通过统一的需求池、工单与任务看板同步状态与信息，并构建需求—任务—测试—缺陷的全流程闭环，可作为承载上述环节与回流路径的方向之一。
可迁移规律：换团队也能照着改
这张示例图可以直接借用结构，但环节粒度和角色名称需要按团队实际情况调整。以下四条规律帮助你把示例改成自己的版本。
- 先定交接点再补环节。先列出三方之间必须正式移交的节点，例如立项结论、方案确认、提测版本、验收结论，再在交接点之间补充动作环节。这样画出的图不会因为环节堆叠而失去主线。
- 每个环节必须有明确产出物和完成标准。产出物是下游可核对的输入，完成标准是可判断的条件。缺少这两项，环节就退化成“大家讨论一下”，交接无法验证。
- 回流路径要写触发条件而非只画箭头。每条回流标注“什么情况下回、回到哪个环节、由谁决定”。回流条件越具体，执行时越少扯皮。
- 按团队规模与业务节奏调整环节粒度。团队规模较小、交付节奏快时，可把方案定义与技术评估合并为一次联合评审；跨部门多、依赖复杂时，可把测试验收拆成功能验收与业务验收两段。调整的是粒度，交接点和产出物的要求保持不变。
调整时建议保留一张“环节—角色—产出—完成标准”的清单作为流程图附件。图负责看全局，清单负责查细节，两者配合才能让流程图在日常工作中被真正使用。
适用边界与常见误用
这份示例适合中大型跨部门协作、有明确交付节奏的团队，尤其是业务、产品、研发分属不同汇报线、交接容易失真的场景。单人团队或纯外包交付场景中，角色高度重叠、交接点很少，照搬八个环节会增加不必要的记录负担，可以只保留机会提出、方案确认、验收交付三个节点。
| 常见误用 | 表现 | 调整方式 |
|---|---|---|
| 把流程图当审批流 | 每个环节都设审批人，图变成签批链条，协作讨论被审批替代 | 只保留关键评审节点，其余环节以产出物和完成标准约束 |
| 环节过多导致无人维护 | 图越画越细，实际执行时没人对照，逐渐失效 | 控制主链路环节数量，细节放入附件清单，指定维护责任人 |
| 只画正向不画回流 | 图上只有顺利路径，遇到方案调整或缺陷修复时无据可依 | 为每个评审和质量关口补充回流条件、去向和决定人 |
流程图是协作约定的可视化表达，需要随团队节奏定期复核。当交接点频繁出现同一类问题时，优先修订对应环节的产出物和完成标准，再考虑增加环节。把图、清单和维护责任放在一起管理，这张业产研协同流程图才能从示例变成团队可长期使用的协作依据。
常见问题
流程图里的环节数量应该画多少个才合适？
环节数量取决于交接点的多少，而不是固定值。可以先列出三方之间必须正式移交的节点，例如立项结论、方案确认、提测版本、验收结论，再在交接点之间补充动作环节。中大型跨部门团队通常保留六到十个主链路环节；团队规模小、角色重叠多时，把方案定义与技术评估合并、把测试验收与上线交付合并，也能保持主线清晰。判断标准是：每个环节都能说清谁负责、产出什么、下游拿什么核对。
业务方不参与复盘，流程图还能跑通吗？
复盘环节的价值在于把过程问题和业务反馈转成改进项，业务方缺席会让改进项偏向研发内部视角，上线后的实际使用问题难以进入下一轮机会提出。如果业务方时间难以协调，可以改为异步方式：由产品经理整理上线记录和业务反馈，业务方在约定时间内补充意见，复盘纪要仍由三方确认。关键是把业务反馈的入口保留下来，形式可以灵活。
回流路径画了但执行时没人遵守，怎么处理？
先检查回流路径是否写清了三个要素：触发条件、回到哪个环节、由谁决定。只画箭头不写条件的回流，执行时容易变成口头协商。其次，把回流条件与对应环节的完成标准绑定，例如“存在未关闭缺陷”对应测试验收不通过，这样回流就有可判断的依据。如果同一类回流频繁发生，说明上游环节的产出物或完成标准需要修订，优先改上游，而不是增加更多回流箭头。
这张流程图和审批流有什么区别？
流程图描述的是工作如何从业务机会流转到研发交付，重点是交接点、产出物和完成标准；审批流描述的是谁有权签字放行。把每个环节都设成审批节点，会让协作讨论被签批替代，图也会变得冗长。实践中只保留关键评审节点，例如立项评审和测试验收，其余环节用产出物和完成标准约束即可。两者可以并存，但不宜混在同一张图里表达。
流程图落地到工具里，需要重点配置哪些内容？
优先配置三类内容：一是工作项类型与状态，对应流程图中的环节和回流条件；二是交接点的必填字段，例如负责人、输入、产出、完成标准；三是评审与验收记录，保证结论可追溯。ONES 提供业务、产品经理与研发团队三大视角，通过统一的需求池、工单与任务看板同步状态与信息，并构建需求—任务—测试—缺陷的全流程闭环，可作为承载上述环节与回流路径的方向之一。具体字段配置需结合团队实际流程设计。
