业产研分工示例的核心，是把“谁在什么节点、基于什么输入、产出什么、交给谁”写成一张可填写的分工表。下面以一次促销活动需求为演示情景，给出一张已填写的分工表，并逐项解释字段填写理由、迁移到其他业务场景的调整方法，以及这张表适用的边界。示例为演示情景，非真实客户案例。
要点总览（TL;DR）
- 业产研分工示例的核心是一张可填写的分工表，字段包括阶段、负责人、协作方、输入、产出、交接对象与确认方式。
- 示例以一次促销活动需求为演示情景，覆盖目标对齐、需求转译、方案评审、研发交付、验收与价值反馈五个阶段。
- 每个阶段只设一个负责人，输入与产出成对出现，交接对象与确认方式写清，交接才有可检查的依据。
- 迁移到其他场景时保留五个字段的骨架，按场景增加或替换节点，按团队规模调整节点颗粒度。
- 示例为演示情景，不替代组织对职责的正式授权，具体需求处理与通用目标决策分别归其他主题。
示例目标：分工表要解决哪三个衔接问题
业产研协作中的返工，多数发生在角色交接处，而非某个角色自身的工作质量。分工表的价值在于把三个容易含糊的衔接点提前写清楚，让每个节点在开始前就知道自己接什么、交什么。
第一个问题是目标由谁定义。业务侧提出活动目标时，需要明确目标的口径、统计范围和验收标准，避免产品拿到一个无法判断完成与否的目标。第二个问题是需求由谁转译。业务语言中的“提升成交”“拉动新客”需要产品转成可执行的需求描述，包括范围、优先级和方案取舍。第三个问题是交付由谁确认。研发交付后，由谁对照最初的验收口径确认结果，需要在分工表中指定，避免上线即结束、无人回看目标。
本示例设定一次促销活动需求，涉及业务、产品、研发三类角色。判断这张分工表是否可用，可以看四条标准：每个节点有唯一负责人；每个节点有明确输入；每个节点有可检查的产出；每个产出有明确的交接对象和确认方式。四条同时满足，交接才有据可依；缺一条，该节点就容易在推进中被反复追问。
完整示例：一次促销活动需求的业产研分工表
示例背景：业务侧希望在活动期提升某品类的成交，提出活动目标与验收口径；产品负责把目标转成需求与方案；研发按方案拆解交付并回传进度。以下分工表覆盖从目标提出到验收反馈的全链路，为演示情景，不涉及真实客户身份与量化效果。
| 阶段 | 负责人 | 协作方 | 输入 | 产出 | 交接对象 | 确认方式 |
|---|---|---|---|---|---|---|
| 目标对齐 | 业务负责人 | 产品负责人 | 活动背景、品类范围、目标口径与统计周期 | 活动目标说明，含验收口径与不做什么 | 产品负责人 | 目标沟通会口头确认，目标说明留档 |
| 需求转译 | 产品负责人 | 业务负责人、研发负责人 | 活动目标说明、现有系统与活动能力现状 | 需求说明与初步方案，含范围、优先级、待定项 | 研发负责人 | 需求评审会逐条过范围与待定项 |
| 方案评审 | 研发负责人 | 产品负责人、业务负责人 | 需求说明与初步方案 | 技术方案与排期，标注依赖与风险 | 产品负责人 | 方案评审会确认排期与风险应对 |
| 研发交付 | 研发负责人 | 产品负责人 | 技术方案与排期 | 可验收的交付物、进度与风险同步记录 | 产品负责人 | 按里程碑同步进度，风险变化即时告知 |
| 验收与价值反馈 | 产品负责人 | 业务负责人、研发负责人 | 交付物、活动目标说明中的验收口径 | 验收结论与目标达成情况反馈 | 业务负责人 | 验收会对照口径逐项确认，结论留档 |
这张表的关键在于每个阶段的产出都能被下一阶段直接使用：目标说明是需求转译的输入，需求说明是方案评审的输入，技术方案是研发交付的依据，交付物与验收口径共同支撑验收结论。活动结束后，验收结论回到业务负责人，形成一次完整闭环。
逐项解释：每个字段为什么这样填
分工表的字段不多，但每个字段都对应一类常见失误。理解填写理由，比记住表格样式更有用。
负责人唯一
每个阶段只设一个负责人，目的是让拍板的人清晰可找。同一节点出现两个负责人，遇到范围取舍时容易互相等待，或在事后各执一词。协作方可以多人，但负责人的职责是汇总意见并给出结论。常见填错方式是把“业务负责人”和“产品负责人”并列写进同一格，看似重视协同，实际让决策悬空。
输入与产出成对出现
输入写清“开始这个阶段需要拿到什么”，产出写清“这个阶段结束时交出什么”，两者成对，交接才有可检查的物件。只写产出不写输入，容易出现负责人在信息不全时开工，返工后难以界定责任；只写输入不写产出，阶段结束没有可确认的成果，进度只能靠口头判断。填写时尽量用具体物件描述，例如“含验收口径的目标说明”，比“活动目标”更容易检查。
交接对象与确认方式
交接对象回答“交给谁”，确认方式回答“怎么算交接完成”。评审会和验收会是两类典型确认节点：评审会确认范围与方案，验收会确认结果与目标口径。确认方式写成“开会讨论”过于笼统，写成“评审会逐条过范围与待定项，结论留档”才能形成共同确认。常见填错方式是把确认方式留空，默认对方收到即确认，后续出现分歧时缺少依据。
目标转译与进度回传
业务目标转成产品可执行的需求描述，通常要完成三件事：把目标口径转成可判断的功能范围，把范围拆成有优先级的条目，把暂不确定的部分列为待定项并约定确认时间。研发回传进度与风险时，除了完成比例，还应说明影响排期的依赖和风险变化，让产品和业务能提前调整预期。这两类动作写进分工表的产出栏，交接时就有具体内容可核对。
可迁移规律：换一个业务场景怎么改这张表
这张表可以迁移到渠道合作、内部系统改造等场景，方法是保留骨架、替换内容、调整颗粒度。
保留骨架：阶段、负责人、输入、产出、交接对象五个字段不变，确认方式随场景调整。骨架稳定，团队每次填写都有共同语言，跨项目对比也更容易。
按场景替换内容：促销活动场景的核心节点是目标对齐、需求转译、方案评审、研发交付、验收反馈；渠道合作场景可能需要增加“合作方对接”节点，明确对外沟通由谁负责；内部系统改造场景可能需要增加“现状梳理”节点，把现有流程与数据情况作为需求转译的输入。替换时保持每个节点仍有唯一负责人和成对的输入产出。
按团队规模调整颗粒度：小团队可以把需求转译与方案评审合并为一个节点，由产品与研发共同完成；大团队可以把方案评审拆成技术方案评审与排期确认两个节点，分别由不同角色确认。颗粒度调整的原则是：节点合并后仍能说清谁拍板，节点拆分后每个节点仍有独立产出。
把分工表与工作项、文档状态关联，让交接有记录可查。分工表中的每个产出，可以对应一个工作项或一份文档；交接动作体现为工作项状态变更或文档评审通过。这样，分工表不再只是会前填写的表格，而成为推进过程中的检查依据。在ONES中，工作项可以承载各阶段任务与负责人，文档可以承载目标说明、需求说明和验收结论，状态变化记录交接是否完成，评审与验收结论随文档留存，便于活动结束后回看每个节点的实际交接情况。
适用边界：分工表示例不能替代什么
这张分工表是演示情景下的填写示例，用于说明角色、节点与交接的写法，不代表任何真实客户的做法与效果。读者参照时，需要结合自身组织的职责划分与授权范围调整负责人和确认方式，不能直接照搬。
分工表聚焦业产研工作链路上的角色与交接，具体需求的处理流程归需求管理主题，通用的目标设定与决策机制归团队目标对齐主题，本文不展开。涉及工具的具体能力、版本与集成方式时，需要另行查证，本文不对这类时效信息作出判断。
分工表能减少交接处的含糊，但无法替代组织对职责的正式授权，也无法保证目标本身合理。把它当作沟通与检查的工具，配合实际的评审和验收动作使用，才能发挥示例中展示的作用。
常见问题
分工表里的负责人和协作方怎么区分，协作方多了会不会影响推进？
负责人是该阶段拍板并交出产出的角色，协作方是提供输入、参与评审或配合执行的角色。协作方可以多人，但结论由负责人汇总给出。协作方增多时，建议在确认方式中写明意见收集的截止时间和最终确认人，避免评审会上意见分散、无人收口。
小团队人手少，五个阶段都要设负责人吗？
阶段可以合并，负责人不能空缺。小团队常把需求转译与方案评审合并为一个节点，由产品负责人主导、研发负责人共同确认；研发交付与验收也可以由同一人跟进，但验收时仍需对照最初的目标口径逐项确认。合并的原则是每个节点仍能说清谁拍板、交出什么、交给谁。
业务目标本身定得不清楚，产品在需求转译阶段该怎么处理？
需求转译阶段可以把不清楚的部分列为待定项，并约定确认时间与确认人，而不是自行补全目标口径。分工表中“需求说明与初步方案”的产出栏可以包含待定项清单，交接给研发前由业务负责人逐项确认。目标口径的最终解释权留在业务侧，产品负责把它转成可判断的功能范围。
分工表填完之后，怎么保证执行中真的按表交接？
把每个阶段的产出对应到具体的工作项或文档，交接动作体现为状态变更或评审通过，分工表就从会前表格变成推进中的检查依据。在ONES中，工作项承载各阶段任务与负责人，文档承载目标说明、需求说明与验收结论，状态变化记录交接是否完成，评审与验收结论随文档留存，活动结束后可以回看每个节点的实际交接情况。
渠道合作或内部系统改造场景，这张表最需要改哪里？
骨架保留，节点按场景增补。渠道合作场景通常要增加合作方对接节点，明确对外沟通与承诺由谁负责；内部系统改造场景通常要增加现状梳理节点，把现有流程与数据情况作为需求转译的输入。增补节点时，同样为每个节点写清唯一负责人、输入、产出和交接对象。
