业务产品研发分工示例的价值，在于把“谁在什么阶段、对哪个工作项、交付什么、由谁确认”写成可对照的表格。本文给出一份虚构但自洽的示例：以一次“订单改价”需求从业务提出到研发上线为主线，逐项填出业务、产品、研发三方在提出、澄清、方案、开发、验收各环节的职责、输入输出与交接确认人。分工表落地时，可以用ONES的工作项流转与文档记录承载交接留痕，具体配置按团队实际流程调整。
要点总览（TL;DR）
- 这份示例把“订单改价”需求从提出到上线拆成七个阶段，每个阶段写明角色、动作、输入、输出和确认人，可直接对照改写。
- 三方职责边界是：业务对要什么和值不值得做负责，产品对做成什么样和范围到哪里负责，研发对怎么做和做得对不对负责。
- 可迁移的核心是按阶段切分职责，每个交接点都有输出物和确认人；角色可以合并，职责不能空缺。
- 分工表落到工具里，可让每个阶段对应一个工作项状态，交接以状态变更和文档记录留痕，具体配置按团队流程设置。
- 示例为虚构演示，不覆盖需求优先级排序与团队目标决策，套用时需按团队规模、行业和流程调整。
这份分工示例要解决什么问题
业产研分工最常见的争议，往往集中在“这件事该谁做”和“做到什么程度算交接完成”这两个问题上。分工示例的用途，是把抽象的职责描述落到具体阶段、具体工作项和具体交付物上，让三方在需求开始前就对边界有共同预期。它适合两类场景：一是新组建的业产研团队需要一份起步模板；二是已有团队在复盘协作摩擦时，需要一份可对照的参照物。
本文示例的假设前提是一条完整链路：一个需求从业务侧提出，经产品澄清与方案设计，由研发开发测试，最终由业务验收上线。示例只覆盖这一条主链路，不涉及多需求并行排期、跨团队资源协调等更复杂的场景。
读者可以带着三个问题对照本文：需求由谁提出、以什么形式提出；方案由谁拍板、业务在什么节点确认；上线结果由谁验收、验收不通过时回到哪个环节。这三个问题分别对应“谁提、谁定、谁验”，也是分工表最容易出现空缺的位置。
完整示例：订单改价需求的分工表
以下为虚构演示情景，用于说明填写方法，不代表任何真实客户案例或实测效果。情景设定：某电商团队（虚构）的业务运营提出“订单支持改价”需求，产品经理负责澄清与方案，研发团队负责开发与测试，三方共同完成上线验收。团队规模、行业背景与组织架构均为示例假设，读者替换时需按自身情况调整。
| 阶段 | 角色 | 动作 | 输入 | 输出 | 确认人 |
|---|---|---|---|---|---|
| 需求提出 | 业务运营 | 描述改价场景、受影响订单类型、期望效果 | 客户反馈记录、运营痛点说明 | 业务需求单（含场景描述与期望） | 业务负责人 |
| 需求澄清 | 产品经理 | 与业务确认范围、边界与优先级，拆解为可执行需求 | 业务需求单 | 需求说明文档（含范围、不做项、验收要点） | 业务负责人 |
| 方案设计 | 产品经理主导，研发参与 | 输出交互与规则方案，研发评估技术可行性与工作量 | 需求说明文档 | 方案文档、技术评估结论 | 产品负责人、研发负责人 |
| 开发实现 | 研发工程师 | 按方案开发、自测，提交测试 | 方案文档、技术评估结论 | 可测试版本、开发说明 | 研发负责人 |
| 测试验证 | 研发测试 | 按验收要点执行测试，记录缺陷并跟踪修复 | 可测试版本、验收要点 | 测试报告、缺陷清单 | 研发负责人 |
| 业务验收 | 业务运营 | 按验收要点在预发环境验证实际场景 | 测试报告、验收要点 | 验收结论（通过/不通过及原因） | 业务负责人 |
| 上线发布 | 研发工程师 | 执行发布，同步上线说明 | 验收通过结论 | 上线记录、变更说明 | 研发负责人 |
三方职责边界可以概括为：业务对“要什么、值不值得做”负责，产品对“做成什么样、范围到哪里”负责，研发对“怎么做、做得对不对”负责。测试验证阶段由研发侧判断质量是否达标，业务验收阶段由业务侧判断场景是否满足，两个判断标准不同，不能互相替代。
交接点的确认方式建议统一为“输出物加确认人”：每次交接都留下可查阅的文档或工作项记录，确认人在对应记录上给出明确结论。留痕位置可以是需求单、方案文档或工作项状态变更记录，关键是让下一次交接能追溯到上一次确认的内容。
逐项解释：每一格为什么这样填
需求澄清放在产品主导、业务确认，是因为业务最清楚场景，产品最擅长把场景转成可执行的范围描述。如果由业务直接写需求说明，容易出现范围模糊、验收要点缺失；如果由产品单方面定范围而不经业务确认，又容易在验收时出现“这不是我要的”分歧。让产品主笔、业务确认，兼顾了专业分工与责任归属。
研发在方案阶段介入，而不是等到开发才出现，目的是尽早暴露技术约束。方案文档如果只由产品完成，可能包含实现成本极高的规则；研发此时给出可行性评估和工作量判断，能让方案在定稿前完成一轮收敛。这一格的产出是技术评估结论，而不是代码，介入时机早于开发但晚于需求澄清。
验收环节的两个判断标准需要分开写：测试验证看的是功能是否符合验收要点、缺陷是否收敛，判断人是研发负责人；业务验收看的是真实业务场景是否被满足，判断人是业务负责人。两者都通过才算完成，任何一方不通过都回到对应环节，测试不通过回到开发，业务验收不通过回到需求澄清或方案设计，具体回到哪一步取决于不通过的原因。
确认人一栏的作用是避免职责悬空。没有确认人，输出物就只是“提交了”，而不是“被接受了”。确认人应当是能对结果负责的角色，而不是流程上的签字人。示例中每个阶段都指定了确认人，实际使用时如果某个阶段确实无人可确认，说明该阶段的职责划分还需要重新讨论。
需要说明哪些格子是示例假设：阶段数量、角色名称、确认人层级都按虚构团队设定。例如小团队可能由产品经理兼任测试验收协调，大团队可能拆分出独立的业务分析角色。这些调整不改变“每格有输出、每段有确认”的结构，只改变具体填法。
可迁移规律：换到别的团队怎么改
这份示例最值得迁移的是按阶段切分职责的思路，而不是按部门罗列职责。按部门写分工，容易写成“业务负责提需求、产品负责设计、研发负责开发”这类无法执行的描述；按阶段切分，每个阶段都有明确的动作、输入、输出和确认人，职责自然落到具体的人和工作项上。
改写时可以遵循四条规则：
- 每个交接点必须有明确输出物和确认人，输出物要能被下一次交接直接使用。
- 角色可以合并，职责不能空缺。小团队中产品兼业务分析、研发兼测试都可行，但每个阶段的动作和确认仍要有人承担。
- 阶段划分按团队实际流程调整，例如增加“灰度发布”或“数据回收”阶段，删减不存在的环节。
- 分工表要与工作项状态对应，每个阶段对应一个可观察的状态，交接即状态变更。
分工表落到工具里，关键是让状态流转和交接记录可追溯。ONES 提供业务、产品经理与研发团队三大视角，通过统一的需求池、工单与任务看板同步状态与信息，需求—任务—测试—缺陷形成闭环，业务团队可以跟踪需求和缺陷处理进度。示例中的“业务需求单—需求说明—方案文档—测试报告—验收结论”这条链路，可以在需求池与工单中对应为工作项及其关联文档，每次交接以状态变更和文档版本留下记录，确认人的结论也随记录保存。具体字段、状态流与权限配置需按团队流程在系统中设置。
适用边界：这份示例不覆盖什么
本文示例针对业产研工作链路中的职责划分与交接，不展开具体需求优先级排序方法。示例中“业务负责人确认优先级”只是一格职责描述，排序用什么模型、需求池如何管理，属于相邻主题，需要另行设计。
通用团队目标设定与决策机制同样不在本文范围。分工表回答的是“一件事怎么流转”，不回答“团队今年做什么、资源怎么分配”。这两类问题需要目标管理与决策流程来支撑，分工表只能承接已经确定的目标和需求。
团队规模、行业与组织架构不同时，示例需要调整：角色数量和名称按实际岗位替换，阶段划分按实际流程增删，确认人层级按授权关系设定。调整后应重新检查三个自查问题——谁提、谁定、谁验——是否每个都有明确答案。
最后需要强调，本文全部情景为虚构演示，用于说明填写方法，不代表任何真实客户案例，也不包含实测数据或量化成效。读者套用时，应以自己团队的实际流程和角色为准，把示例当作结构参照，而不是标准答案。
常见问题
小团队角色少，产品经理同时兼业务分析和验收协调，分工表还能用吗？
可以用，调整方式是合并角色、保留职责。示例中“需求澄清”由产品主笔、业务确认，“业务验收”由业务负责人判断场景是否满足；如果产品经理兼任业务分析，澄清阶段仍要保留业务侧确认这一动作，验收阶段也要明确由谁代表业务给出结论。判断标准是每个阶段的动作、输出物和确认人都有人承担，而不是每个角色都由不同的人担任。
业务验收不通过时，应该退回开发还是退回需求澄清？
取决于不通过的原因。功能与验收要点不符、存在缺陷，退回开发修复；真实业务场景未被满足、验收要点本身写错了，退回需求澄清或方案设计。示例把测试验证和业务验收设为两个独立判断，测试看功能是否符合验收要点，业务看场景是否被满足，两者不通过时的回退路径不同。实际操作中建议在验收结论里写明原因类别，避免每次靠口头判断。
分工表里的确认人，和流程审批人是一回事吗？
不是。确认人是对该阶段输出物能否被接受负责的角色，需要实际查看内容并给出结论；审批人更多是流程上的授权节点。示例中每个阶段指定确认人，目的是避免输出物“提交了但没人接受”。如果某个阶段找不到能对结果负责的确认人，说明该阶段的职责划分还需要重新讨论，而不是随便指定一个人签字。
分工表怎么和现有的项目管理工具对应起来？
基本做法是让每个阶段对应一个可观察的工作项状态，交接即状态变更，输出物作为工作项的关联文档或附件保存。以示例中的链路为例，业务需求单、需求说明、方案文档、测试报告、验收结论可以分别对应需求池与工单中的工作项及其关联文档，确认人的结论随记录保存。ONES 提供业务、产品经理与研发团队三大视角，通过统一的需求池、工单与任务看板同步状态与信息，需求—任务—测试—缺陷形成闭环；具体字段、状态流与权限配置需按团队流程在系统中设置。
团队有灰度发布和数据回收环节，分工表怎么加？
按同样结构增加阶段即可：写明该阶段的角色、动作、输入、输出和确认人。例如灰度发布阶段由研发执行发布、业务确认灰度范围，数据回收阶段由业务或数据分析角色输出效果结论。新增阶段后要检查前后交接是否衔接，灰度发布的输入应来自业务验收通过结论，数据回收的输出应能回流到下一轮需求提出。阶段数量按团队实际流程增删，结构规则不变。
