Scrum把产品决策、流程引导和交付执行分给三类角色：Product Owner决定“做什么、先做什么”，Scrum Master保证Scrum框架被正确运行，开发团队负责在每个Sprint内把待办项做成可交付增量。三者共同商定Sprint目标，但决策权、流程权和执行权分属不同角色。本文按职责定义、边界划分、Sprint配合、相邻概念辨析和情景示例逐层说明，帮助团队判断一件事该由谁拍板、谁引导、谁执行。
要点总览（TL;DR）
- Product Owner负责产品待办列表的内容、顺序和价值最大化，决定“做什么、先做什么”，是产品决策的最终责任人。
- Scrum Master负责Scrum框架被正确理解和执行，组织事件、推动障碍清除、引导流程改进，不替团队做产品决策或分配任务。
- 开发团队负责每个Sprint内如何把选中的待办项做成可用增量，自主拆分任务、估算工作量、安排每日协作。
- 三者共同商定Sprint目标，决策权、流程权、执行权分离；范围调整由Product Owner保留取舍权，但需与团队协商评估影响。
- Scrum Master不等于项目经理，Product Owner聚焦待办列表价值与顺序，开发团队包含设计、开发、测试等跨职能成员。
一句话说清三类角色的分工
Scrum只有三种角色，但每种角色对结果的责任类型不同。可以用一句话分别定义：Product Owner对产品待办列表（Product Backlog）的内容、顺序和价值最大化负责；Scrum Master对Scrum框架被团队和相关方正确理解与执行负责；开发团队对每个Sprint内如何把选中的待办项做成满足“完成定义”的可用增量负责。
这三句话背后是三种权力的分离。Product Owner握有产品决策权，能决定一个需求进不进待办列表、排在什么位置；Scrum Master握有流程权，能推动事件按时召开、规则被遵守、障碍被暴露和处理，但不替任何人做内容决策；开发团队握有执行权，自主决定任务怎么拆、谁来做、工作量如何估算。Sprint目标是三方共同商定的结果，Product Owner在其中保留范围取舍的最终判断。
需要强调的是，三种角色是职责划分，不是职级划分。一个组织里可能有人同时承担Product Owner和别的岗位工作，但只要他在这件事上行使的是产品决策权，就应当按Product Owner的职责要求来判断。角色清晰的价值在于：当出现分歧时，团队能迅速定位“这件事归谁决定”，减少反复拉扯。
职责边界：哪些事归谁决定
把职责落到具体事项上，边界才真正可用。下表按常见管理事项列出主要责任角色和判断依据，便于团队逐项核对。
| 事项 | 主要责任角色 | 判断依据 |
|---|---|---|
| 产品待办列表包含哪些条目 | Product Owner | 对产品价值负责，决定做什么 |
| 待办条目的优先级与排序 | Product Owner | 决定先做什么，排序即资源投向 |
| 待办条目的验收标准是否清晰 | Product Owner主导，开发团队参与澄清 | 双方对“做完的标准”达成一致 |
| Scrum事件是否按规则召开 | Scrum Master | 对框架执行负责，组织并引导 |
| 团队障碍的识别、暴露与推动清除 | Scrum Master | 服务团队，协调资源而非指挥任务 |
| 流程偏差的纠正与Scrum规则的解释 | Scrum Master | 流程权的归属 |
| 待办项拆成哪些任务 | 开发团队 | 自组织安排工作，执行权归属 |
| 工作量估算与任务认领 | 开发团队 | 由实际执行者判断可行性 |
| 每日协作方式与进度同步 | 开发团队 | 团队内部协调，Scrum Master仅引导 |
| Sprint目标的确定 | 三方共同商定 | Product Owner提供价值方向，团队评估可行性 |
| Sprint范围内是否调整 | Product Owner保留取舍权，需与团队协商 | 范围变更影响承诺，须共同评估 |
这张表最重要的两条否定性边界是：Scrum Master不代替Product Owner做产品决策，也不代替开发团队分配任务。Scrum Master看到某个需求价值存疑，可以提出问题和事实，但排序仍由Product Owner决定；看到任务分配不均，可以引导团队在每日站会中讨论，但不能直接指派谁做什么。越界的“帮忙”会削弱角色本身的清晰度，让团队重新回到等人安排的状态。
另一条容易被忽略的边界是验收标准。Product Owner对待办项的价值和“什么算完成”负责，但验收标准需要开发团队参与澄清，否则容易出现“产品方以为做完了、开发方以为还没做”的错位。边界清晰不等于各管一段、互不沟通，而是每件事有明确的最终责任人。
三类角色如何在一个Sprint里配合
静态的职责表要放到Sprint的时间线上才有意义。一个Sprint通常经历计划、执行、评审、回顾四个阶段，三角色在每个阶段的动作和交接对象各不相同。
Sprint计划：价值输入与可行性评估
Product Owner在计划会上说明候选待办项的业务价值、优先级和验收标准，回答团队关于需求的疑问。开发团队据此评估工作量和技术可行性，判断本Sprint能承接多少，并形成Sprint目标。这个环节的产出是一份团队认可、范围明确的Sprint待办列表。交接关系是：Product Owner提供“做什么、为什么”，开发团队给出“能做多少、怎么做”。
执行期间：自组织推进与障碍处理
开发团队按自己拆分和认领的任务推进，通过每日站会同步进度、暴露风险，自主调整任务安排。Scrum Master在这个阶段的动作是观察流程是否被遵守、记录并推动清除团队无法自行解决的障碍，必要时协调团队外部资源。Product Owner则保持待办列表的梳理，为下一个Sprint做准备，并随时可被团队咨询需求细节。这里的交接是：团队把障碍交给Scrum Master，Scrum Master把处理结果反馈给团队。
Sprint评审：增量展示与价值判断
开发团队向Product Owner和相关方展示本Sprint完成的增量，说明哪些待办项已达到完成定义。Product Owner对照业务价值判断增量是否符合预期，并据此调整产品待办列表的顺序和内容。评审的产出是对“下一步做什么”的更新判断，而不是对团队的打分。
回顾：协作方式的改进
Scrum Master引导团队回顾本Sprint的协作过程，讨论哪些做法有效、哪些需要改进，并形成可跟踪的改进项。开发团队和Product Owner共同参与，改进项进入后续工作跟踪。回顾的产出是具体的改进行动，而非泛泛的总结。
四个阶段串起来看，三角色的配合本质是“价值输入—执行反馈—价值校验—流程改进”的循环。每个环节都有明确的输入、产出和交接对象，职责边界在流动中保持稳定。
容易混淆的相邻概念与常见误解
Scrum角色常被套进传统岗位的框架里理解，由此产生混淆。区分相邻概念，有助于团队正确设置角色。
Scrum Master与项目经理
项目经理通常对交付结果负责，掌握进度、资源和范围的决定权，通过计划和指挥推动项目。Scrum Master服务团队和流程，帮助团队理解并执行Scrum，推动障碍清除，但对交付结果没有指挥权，也不替团队做任务安排。两者的关键差别在于：项目经理的权力指向结果控制，Scrum Master的权力指向流程保障。
Product Owner与产品经理
产品经理的职责范围通常更宽，可能涵盖市场调研、商业模式、跨部门协调等。Product Owner聚焦产品待办列表的价值与顺序，是团队需求来源的最终决策者。在不少组织中这两个角色由同一人承担，但Scrum语境下强调的是其对“做什么、先做什么”的决策责任，而非全部产品职能。
开发团队不等于只写代码的人
Scrum中的开发团队指所有参与把待办项变成增量的人，设计、开发、测试、数据分析等跨职能成员都可以包含在内。团队整体对增量负责，而不是各管一段、只对技术负责。
常见误解纠正
- 误解一：Scrum Master是团队领导。纠正：Scrum Master是服务型角色，通过引导和障碍清除帮助团队，不通过指令管理团队。
- 误解二：Product Owner可以随意变更Sprint范围。纠正：Sprint目标一旦确定，范围调整需要与开发团队协商并评估影响，Product Owner保留取舍权但不应单方面推翻承诺。
- 误解三：开发团队只对技术负责。纠正：开发团队对每个Sprint交付可用增量负责，包括质量、完成定义和Sprint目标的达成。
一个具体例子：需求变更时谁做什么
以下为演示性情景，用于说明职责边界如何落地，不代表任何真实客户案例。
假设Sprint进行到一半，业务方提出一个紧急需求，希望立即插入当前Sprint。三类角色按边界分别行动：
- Product Owner评估这个需求的价值和紧迫性，判断它是否值得进入产品待办列表、应排在什么位置。如果认为确实紧急，Product Owner需要与开发团队沟通，说明为什么它比当前Sprint目标更优先，并承担范围取舍的判断责任。
- Scrum Master提示Sprint范围的相关规则，说明中途插入需求对Sprint目标和承诺的影响，组织Product Owner、开发团队和业务方沟通，让信息充分对齐。Scrum Master不替Product Owner决定这个需求该不该做，也不替开发团队决定要不要接。
- 开发团队评估插入新需求对当前工作的影响，给出可行方案：是替换某个待办项、缩小原范围，还是排到下一个Sprint。团队基于实际工作量做出判断，并对调整后的Sprint目标负责。
三方在各自边界内完成动作后，形成一个共同决定：新需求进入待办列表并排序，当前Sprint是否调整由Product Owner与团队协商确定。这个例子的价值在于展示：需求变更不是某一个人的事，但每个环节都有明确的决策人和执行人，边界让协作有章可循，而不是互相等待或越权拍板。
把角色职责落到协作工具中的管理动作
职责边界说清楚之后，还需要在日常协作中持续被执行。待办排序、障碍跟踪、任务流转、评审与回顾结论这些管理动作，如果散落在聊天记录和表格里，边界很容易模糊。把它们放到协作工具中，可以让每个角色的动作留下可追溯的记录。
Product Owner的决策动作对应产品待办列表的维护：在需求池中记录条目、标注优先级、把选中的需求规划到对应迭代。ONES敏捷研发管理解决方案支持产品负责人根据需求优先级，将产品待办列表中的需求规划至对应迭代，并在迭代计划会议上与团队共同评审需求，这与Product Owner的价值排序职责相对应。
开发团队的执行动作对应任务拆分与状态流转：在就当前迭代需求与验收标准达成一致后，设计、研发、测试人员可用子任务拆分需求，并在迭代过程中通过敏捷看板管理任务状态，在每日站会中对齐进度和风险。这些动作承载的是开发团队的自组织执行权。
Scrum Master的引导职责对应障碍与流程改进项的跟踪：团队在站会和回顾中暴露的问题、形成的改进建议，可以作为工作项持续跟踪，避免停留在口头。迭代完成后，团队可通过燃尽图、工时日志等数据复盘进度、质量和成本偏差，讨论改进建议，让回顾结论形成可追溯记录。
需要说明的是，工具承载的是管理动作的记录与流转，角色边界仍由团队约定和Scrum规则决定。ONES为研发团队中的不同角色提供需求管理、任务管理、缺陷管理、迭代管理等场景支持，但具体到某个团队如何分配权限、如何设置流程，仍需结合自身情况配置。把角色职责映射到工具中的字段、状态和视图，目的是让“谁决定、谁执行、谁引导”在每一次协作中都能被看见和核对。
常见问题
Scrum Master和项目经理可以由同一个人担任吗？
可以由同一人担任，但需要区分两种职责在具体事项上的行使方式。项目经理通常对交付结果负责，掌握进度、资源和范围的决定权；Scrum Master服务团队和流程，推动障碍清除、引导事件，对交付结果没有指挥权。
如果同一人兼任，建议在团队内明确：涉及流程规则、事件组织和障碍协调时按Scrum Master的方式工作，通过引导和协商推动；涉及交付承诺和任务安排时，交由开发团队自主决定。否则容易让团队重新回到等人安排任务的状态，削弱自组织。
Product Owner不在时，开发团队能否自行调整Sprint范围？
Sprint目标一旦确定，范围调整需要与Product Owner协商并评估影响。Product Owner保留范围取舍权，但不应单方面推翻团队承诺；开发团队也不宜在Product Owner缺席时自行决定砍掉或替换待办项。
可行的做法是：团队先评估变更对当前工作的影响并形成方案，由Product Owner在恢复参与后确认取舍。若组织内Product Owner经常无法及时响应，应提前约定代理决策人或授权边界，把例外情况写进团队工作约定，避免每次变更都陷入停滞。
开发团队里包含测试和设计人员，任务该由谁分配？
Scrum中的开发团队指所有参与把待办项变成增量的人，设计、开发、测试、数据分析等跨职能成员都可以包含在内。任务拆分和认领由团队自主完成，Scrum Master不直接指派谁做什么。
实际操作中，团队可以在Sprint计划或每日站会上共同确认任务拆分，由成员根据自身能力和当前负载认领。遇到任务分配不均，Scrum Master可以引导团队在站会中讨论并调整，但决定权留在团队内部。团队整体对增量负责，包括质量和完成定义的达成。
Scrum Master发现某个需求价值存疑，应该怎么处理？
Scrum Master可以提出问题和事实，例如指出该需求与Sprint目标的关系、可能带来的范围影响，但排序和取舍仍由Product Owner决定。越界替Product Owner做产品决策，会削弱角色边界的清晰度。
更合适的做法是把信息带到合适的场合：在待办列表梳理或Sprint计划中提出疑问，组织Product Owner与开发团队充分沟通，让决策建立在完整信息之上。如果问题涉及流程规则，例如中途插入需求是否影响Sprint目标，Scrum Master可以说明规则和影响，由Product Owner与团队协商后决定。
团队规模较小、一人身兼多角时，职责边界还有意义吗？
有意义，但落地方式可以简化。角色边界的作用是让每件事有明确的最终责任人，避免出现分歧时无人拍板或互相等待。小团队中同一人可能既做Product Owner又参与开发，此时关键是区分“此刻行使的是哪种权力”。
建议在团队工作约定中写明：涉及待办列表内容和排序时按Product Owner的职责判断，涉及任务拆分和估算时按开发团队的方式自主决定，涉及流程规则和障碍协调时按Scrum Master的方式引导。角色可以兼任，但每类决策的责任归属仍需清晰，否则容易在需求变更、范围取舍等场景中反复拉扯。
