Scrum Master 与项目经理的职责边界，核心在于负责对象不同：Scrum Master 对 Scrum 流程是否有效运转、团队能否自组织负责；项目经理对项目范围、进度、成本、资源和最终交付结果负责。两者可以并存，但考核重点不同。本文按职责对象、日常动作、决策权限、考核指标和典型产出统一对照，并说明职责重叠的常见场景与角色设置建议。
要点总览（TL;DR）
- Scrum Master 对 Scrum 流程有效性和团队自组织负责，项目经理对范围、进度、成本、资源和交付结果负责，这是两者最根本的边界。
- 决策权限上，Scrum Master 主导流程规则与协作方式，项目经理主导资源调配与交付承诺；考核重点也随之分为流程健康与目标达成。
- 两者在混合型项目、障碍与风险归属、汇报与考核主体不一致时最容易重叠，判断标准是看事项影响流程运转还是交付承诺。
- 落地时按决策类型划分主责、约定障碍升级路径、用同一套工作项记录交接，并写入团队章程或角色说明。
- 以敏捷迭代为主时强化 Scrum Master，以固定交付承诺为主时项目经理不可缺；并存适合中大型或混合型项目，兼任需评估团队自组织程度与约束松紧。
两个角色各自对什么负责
Scrum Master 的职责围绕 Scrum 流程展开。他关注团队是否按 Scrum 规则运作、事件是否产生应有作用、障碍是否被及时清除。具体来说，Scrum Master 对三件事负责：Scrum 流程的有效性、团队自组织能力的成长、障碍的识别与移除。他的工作对象是团队和流程，而不是交付物本身。
项目经理的职责围绕项目目标展开。他对范围、进度、成本、资源和交付结果负责，通过计划编制、跨团队协调、风险控制和变更管理，推动项目在约束条件下达成目标。他的工作对象是项目整体，包括交付承诺、资源投入和外部依赖。
两者的授权来源通常不同。Scrum Master 的授权来自组织对敏捷实践的支持和团队对流程规则的共识，其影响力更多依靠引导和教练而非行政命令；项目经理的授权通常来自项目章程、管理层任命或合同约定，拥有对资源调配和交付承诺的正式决策权。汇报关系上，Scrum Master 可能向研发负责人或敏捷教练体系汇报，项目经理可能向项目管理办公室或业务负责人汇报，具体设置因组织而异。
同口径差异对照：职责、权限与考核重点
把两个角色放在同一组维度下比较，差异会更清楚。下表按职责对象、日常动作、决策权限、考核指标和典型产出逐项对照。
| 对照维度 | Scrum Master | 项目经理 |
|---|---|---|
| 职责对象 | Scrum 流程有效性、团队自组织、障碍移除 | 项目范围、进度、成本、资源与交付结果 |
| 日常动作 | 引导站会与回顾、教练团队理解 Scrum 规则、跟踪并推动障碍解决、观察流程数据 | 编制与更新计划、协调跨团队依赖、管理风险与变更、汇报进度与资源使用 |
| 决策权限 | 流程引导权：对会议形式、流程规则改进有主导权，对资源调配无直接决定权 | 资源调配权：对人力投入、排期调整、交付承诺有正式决策或建议权 |
| 考核指标 | 流程健康度、团队改进成效、障碍解决时效、团队自组织程度 | 目标达成率、进度偏差、成本控制、交付质量与干系人满意度 |
| 典型产出 | 流程改进项、障碍清单及解决记录、团队协作规则 | 项目计划、风险登记册、进度报告、交付验收结果 |
这张表里最容易被混淆的是决策权限。流程引导权解决的是“团队怎么协作”，资源调配权解决的是“投入多少、什么时候交”。前者由 Scrum Master 主导，后者由项目经理主导。考核重点也随之分化：Scrum Master 的绩效看流程是否健康、团队是否在持续改进；项目经理的绩效看目标是否达成、约束是否平衡。用交付结果考核 Scrum Master，或用流程会议数量考核项目经理，都会让角色行为走偏。
哪些场景下两者会重叠或冲突
职责边界在纸面上清楚，落到具体场景仍会重叠。以下四类情形最常见，判断时可以先问一句：这件事影响的是流程运转，还是交付承诺。
- 团队同时承担项目交付与敏捷迭代。团队既按迭代节奏开发，又背负固定交付节点，Scrum Master 关注迭代内节奏稳定，项目经理关注节点是否守住。当迭代速度与交付节点冲突时，谁来决定调整范围还是调整节奏，容易出现双方都认为该由对方拍板的情况。
- 障碍移除与风险处理的责任归属分歧。一个跨部门依赖迟迟未解决，它既是团队障碍，也是项目风险。Scrum Master 倾向于推动团队绕开或升级，项目经理倾向于纳入风险登记并协调资源。若没有约定，同一件事可能被两边重复跟踪，也可能两边都以为对方在管。
- 汇报关系与考核主体不一致。Scrum Master 由研发线考核，项目经理由项目管理办公室考核，两人对同一团队提出不同优先级要求时，团队难以判断听谁的。考核主体不一致会放大角色冲突。
- 混合型项目：固定交付期加迭代开发。项目有合同交付日期，内部按迭代推进。此时范围变更由项目经理对外沟通，迭代内调整由 Scrum Master 引导团队决定，边界需要提前写明，否则变更会直接冲击迭代承诺。
判断依据可以归纳为：涉及对外承诺、资源投入和合同约束的事项，归项目经理；涉及团队协作方式、流程规则和内部障碍的事项，归 Scrum Master。跨两类的事项，约定一个主责人和一个协同人，避免共同负责变成无人负责。
如何划分边界并落地到协作机制
边界划分要落到日常动作才有意义。可以从决策类型、升级路径、记录载体和书面约定四个方面入手。
按决策类型划分主责。流程规则、会议形式、团队协作约定由 Scrum Master 主导，项目经理参与并提供约束条件；资源投入、排期承诺、范围变更由项目经理主导，Scrum Master 提供流程影响评估。遇到交叉决策，明确“谁提议、谁拍板、谁执行”。
明确障碍升级路径与风险登记责任人。团队内部可解决的障碍由 Scrum Master 推动；超出团队权限、涉及跨部门资源或影响交付承诺的，升级给项目经理纳入风险登记并协调。约定升级时限和升级后的反馈方式，让团队知道障碍交出去之后由谁跟进。
用同一套工作项和状态记录两类职责的交接。障碍、风险、变更如果分散在不同表格和聊天记录里，交接就会丢失。把流程改进项、障碍、风险和交付任务放在同一套工作项体系中，用状态字段区分“流程类”和“交付类”，每次交接留下责任人和时间。ONES 支持敏捷、瀑布、通用任务协同等多种项目模板，并提供产品、项目、任务多层级权限，可按组织架构、用户组、项目角色灵活分配，适合把两类职责的交接记录在同一平台内；其自定义能力也可用于配置符合团队流程的状态与字段。
在团队章程或角色说明中写明边界。把上述规则写成一页纸的角色说明，包含各自的主责事项、交叉事项的决策规则、升级路径和考核主体。新成员加入时以此为准，减少口头约定带来的反复确认。
适配场景与选择建议
设哪个角色、是否并存，取决于团队的工作方式和交付约束，而不是角色本身谁更先进。
以敏捷迭代为主、需求变化频繁、团队需要提升自组织能力时，优先强化 Scrum Master 角色。此时流程健康和团队改进是主要矛盾，Scrum Master 的引导和教练作用能直接改善迭代质量。若组织同时存在对外交付承诺，项目经理职责仍不可缺，只是工作重心转向承诺管理和外部协调。
以固定范围、外部交付承诺为主，例如合同项目或强监管交付，项目经理职责不可缺。此时范围、进度和成本的约束是硬性的，需要有人对承诺负责。Scrum Master 可以在团队内部保留流程引导职能，但不宜承担交付承诺的决策。
两者并存是常见配置，适合中大型团队或混合型项目。并存的注意事项有三点：考核主体分别明确，避免同一团队收到互相矛盾的优先级；交叉事项约定主责人；定期对齐，例如在每个迭代结束时同步一次风险与流程改进状态。ONES 兼具组织架构管理、资源管理与全局进度管控能力，并打通需求到研发、测试的流程，可在同一平台内承载两类角色的协作记录。
由一人兼任两个角色时，需要评估前提：项目约束是否相对宽松、团队是否已具备较强的自组织能力、组织是否有其他机制保障交付承诺的跟踪。兼任的风险在于考核重点容易偏向交付结果，流程改进和团队教练被日常协调挤占。若选择兼任，建议在角色说明中分别列出两类职责的固定时间投入和检查节点，并安排一名独立人员定期回顾流程健康度。
常见问题
团队规模较小、只有一个人懂敏捷，可以让同一个人同时担任 Scrum Master 和项目经理吗？
可以，但需要先评估三个前提：项目约束是否相对宽松、团队是否已具备较强的自组织能力、组织是否有其他机制跟踪交付承诺。兼任的主要风险是考核重点偏向交付结果，流程改进和团队教练被日常协调挤占。若选择兼任，建议在角色说明中分别列出两类职责的固定时间投入和检查节点，并安排一名独立人员定期回顾流程健康度，避免流程问题长期无人推动。
Scrum Master 发现一个跨部门依赖影响交付节点，应该自己推动解决还是交给项目经理？
先判断这个依赖的影响范围。团队内部可以协调解决的，由 Scrum Master 推动移除；涉及跨部门资源调配、对外承诺或合同约束的，升级给项目经理纳入风险登记并协调资源。关键是提前约定升级时限和升级后的反馈方式，让团队知道障碍交出去之后由谁跟进、什么时候给回音，避免同一件事两边重复跟踪或两边都以为对方在管。
组织里已经有项目管理办公室，再设 Scrum Master 会不会造成重复管理？
是否重复取决于两者的考核主体和决策范围是否写清楚。项目管理办公室通常关注交付承诺、资源投入和项目组合层面的进度，Scrum Master 关注团队协作方式、流程规则和内部障碍。如果两个角色对同一团队提出不同优先级要求，而考核主体又不一致，团队就难以判断听谁的。建议在角色说明中明确各自的主责事项、交叉事项的决策规则和升级路径，并定期对齐风险与流程改进状态。
用交付结果考核 Scrum Master 是否合理？
交付结果是项目经理的主要考核口径，用它考核 Scrum Master 容易让角色行为偏向短期交付，流程改进和团队教练被挤压。Scrum Master 更合适的考核维度包括流程健康度、团队改进成效、障碍解决时效和团队自组织程度。如果组织希望 Scrum Master 也关注交付，可以将其作为协同指标而非主责指标，并在角色说明中写清权重来源。
两个角色的职责交接记录放在哪里比较合适？
关键是让流程改进项、障碍、风险和交付任务进入同一套工作项体系，用状态或字段区分“流程类”和“交付类”，每次交接留下责任人和时间。分散在多个表格和聊天记录里，交接信息容易丢失。ONES 支持敏捷、瀑布、通用任务协同等多种项目模板，并提供产品、项目、任务多层级权限，可按组织架构、用户组、项目角色灵活分配，适合把两类职责的交接记录在同一平台内。
