Scrum Master与项目经理的考核重点落在不同对象上：前者考核团队与流程的健康度，后者考核项目目标的达成度。角色定义不同，指标就不能互换。本文从职责边界出发，给出两类角色的同口径对照、可观察的指标设计方法，以及身兼两职和角色转换时的处理办法。
要点总览（TL;DR）
- Scrum Master的考核对象是团队协作方式与Scrum机制运行质量，项目经理的考核对象是项目目标的达成与约束受控程度。
- 典型指标上，Scrum Master看事件有效性、障碍清除时长、回顾改进项落地率；项目经理看里程碑达成率、进度与成本偏差、变更受控率、风险应对完成率。
- 指标应从职责推导而非从岗位名称套用，每项指标都要有可观察的行为和可核验的证据来源，核心指标控制在三到五项。
- 一人身兼两职时角色分开、指标分开、评价分开，按实际投入分配权重；角色转换期设置一到两个迭代的过渡指标。
- 团队成熟度低时加重Scrum Master式考核，交付确定性要求高时加重项目经理式考核，两者可按角色分别设定指标集并存。
考核重点差异：一个看团队与流程，一个看项目目标
两类角色的考核对象不同，决定了指标、周期和证据来源都不同。Scrum Master的考核对象是团队协作方式与Scrum机制运行质量；项目经理的考核对象是项目交付结果与约束条件的受控程度。把两者放在同一张表里对照，差异会更清楚。
| 比较维度 | Scrum Master | 项目经理 |
|---|---|---|
| 考核对象 | 团队自组织程度、Scrum事件质量、障碍清除效率、交付节奏稳定性 | 范围、进度、成本、质量、风险等项目目标的达成与受控 |
| 典型考核指标 | 团队对迭代目标的承诺与完成情况、回顾会改进项的落地率、障碍从提出到解决的平均时长、跨职能协作顺畅度、团队自管理事项的比例 | 里程碑达成率、进度偏差与成本偏差、范围变更受控率、缺陷逃逸率、风险应对完成率、干系人验收结果 |
| 评价周期 | 以迭代或固定短周期为主，关注趋势变化而非单点结果 | 以项目阶段或里程碑为主，项目收尾时做整体评价 |
| 数据与证据来源 | 迭代看板与燃尽图、回顾会记录与改进项跟踪、障碍清单、团队反馈与观察记录 | 项目计划与基线、进度与工时数据、质量报告、风险登记册、验收与结项文档 |
| 职责边界依据 | 对Scrum框架的正确运行和团队效能负责，不直接对交付内容拍板 | 对项目目标的规划、执行、监控与交付负责，对资源与干系人协调负责 |
| 适用团队阶段 | 团队处于形成期、 Scrum机制尚不稳定、需要提升自组织能力时更适用 | 交付确定性要求高、跨团队依赖多、合同或合规约束明确时更适用 |
同一人身兼两职时，指标必须分开设定。可以按角色分配权重，但两类指标各自独立取证、独立评价，避免用项目交付结果替代团队与流程成效的评估，也避免用团队氛围好掩盖项目目标失控。
职责边界如何决定考核指标
考核指标应当从职责推导，而不是从岗位名称套用。Scrum Master的职责是确保Scrum按框架运行、帮助团队理解并实践敏捷原则、清除团队无法自行解决的障碍、保护团队免受外部干扰。对应的指标就应指向机制运行与团队能力：Scrum事件是否按时且有效开展、障碍是否被记录并推动解决、团队是否逐步承担起任务拆解与进度管理、回顾会的改进项是否真正落地。
项目经理的职责是整合项目目标、制定计划、协调资源、监控进度成本质量与风险、管理干系人期望。对应的指标就应指向目标达成与约束受控：里程碑是否按期、预算是否在基线内、变更是否经过评估与批准、风险是否被识别并落实应对、交付物是否通过验收。这些指标评价的是项目层面的结果，与团队内部协作方式不是一回事。
职责交叉地带需要明确归属。例如迭代进度跟进，Scrum Master关注看板是否真实反映状态、团队是否在每日站会中对齐风险；项目经理关注该迭代在整体项目计划中的位置与依赖影响。同一份数据可以共用，但评价角度和责任人要分开写清楚。指标错配会带来明显的行为偏差：用交付结果考核Scrum Master，会促使其越位替团队做决定、压缩回顾时间赶进度，团队自组织能力反而退化；用团队氛围指标考核项目经理，会弱化其对范围、成本和风险的管控，项目目标失守时缺少明确的责任信号。
指标怎么定：可观察行为与结果证据
把考核重点转成指标，关键是让每一项都能被观察到、被取证。建议从行为和结果两个层面设计：行为层面看角色是否做了该做的事，结果层面看这些动作是否产生了可核验的变化。定性评价同样需要证据，不能只凭印象打分。
Scrum Master的指标设计与证据
- Scrum事件有效性：站会、评审、回顾是否按节奏开展，参与情况与产出是否完整。证据为会议记录、回顾会改进项清单。
- 障碍清除：障碍是否被记录、是否有人跟进、从提出到解决用了多长时间。证据为障碍清单及其状态变化。
- 团队自组织进展：任务拆解、进度更新、改进项认领是否由团队完成。证据为看板更新记录与团队分工情况。
- 流程改进落地：上一轮回顾确定的改进项在本周期内的完成比例。证据为改进项跟踪表。
项目经理的指标设计与证据
- 目标达成：里程碑与关键交付物的完成情况。证据为项目计划与实际完成记录。
- 约束受控：进度偏差、成本偏差、范围变更的评估与审批记录。证据为基线对比与变更单。
- 质量与风险：缺陷分布、风险识别与应对完成情况。证据为质量报告与风险登记册。
- 干系人结果：评审与验收结论、关键干系人的反馈记录。
定性评价可采用结构化方式：由直接协作对象按固定维度描述具体事例，评价人结合证据给出等级，并写明判断依据。要避免把指标简单数字化，例如用会议次数代替会议质量、用看板卡片数量代替进度真实性。数字适合做趋势参考，结论仍需结合证据判断。指标数量宜少而准，每个角色聚焦三到五项核心指标，其余作为观察项。
这些证据大多来自日常研发过程数据。ONES的敏捷研发管理方案支持团队通过敏捷看板管理任务状态，在每日站会中对齐迭代进度与风险，并通过燃尽图评估研发效率；迭代结束后可结合燃尽图、工时日志等报表复盘进度、质量和成本偏差。系统会记录资源投入、缺陷分布、工作项滞留时间等过程数据，ONES Project也提供多种报表用于呈现项目表现。这些数据可以作为Scrum Master与项目经理考核的取证来源，考核制度本身仍需由团队自行设定。
身兼两职或角色转换时怎么考核
小团队中一人同时承担Scrum Master与项目经理的情况并不少见。处理原则是角色分开、指标分开、评价分开，再按投入比例分配权重。例如以项目经理职责为主、兼任Scrum Master时，项目目标类指标可占较大权重，团队与流程类指标保留独立评价项，避免被项目结果吞并。权重分配应结合当期实际投入，并在考核周期开始前与当事人确认。
从项目经理转为Scrum Master时，需要设置过渡指标。转换初期可保留部分项目交接类指标，如交接文档完整性、遗留风险移交情况；同时逐步引入新角色的指标，如Scrum事件是否规范运行、团队是否开始自主管理任务。过渡期一般覆盖一到两个迭代或一个项目阶段，之后以新角色指标为主。
评价人与评价周期也要相应调整。Scrum Master的评价应纳入团队反馈，周期与迭代节奏对齐；项目经理的评价以项目阶段和结项为主，评价人包括发起人与关键干系人。兼任时两类评价人分别给出意见，不做简单平均。常见冲突是项目进度紧张时挤压回顾与改进时间，处理原则是明确哪些Scrum事件不可省略，把因此产生的进度影响记录为风险，由项目层面决策，而不是让Scrum Master单方面承担后果。
适配场景与选择建议
侧重哪类考核，取决于团队成熟度与管理目标，不必二选一。团队刚组建、Scrum机制运行不稳、协作方式需要重塑时，应加重Scrum Master式考核，重点看事件质量、障碍清除和团队自管理进展。团队已能稳定运行Scrum、但项目面临跨团队依赖、合同节点或合规要求时，应加重项目经理式考核，重点看里程碑、偏差控制和风险应对。
交付确定性要求高的场景，例如对外承诺上线时间、涉及多方验收的项目，项目经理式指标应作为主考核；团队能力建设目标明确的场景，例如推动自组织、改善回顾实效，Scrum Master式指标应作为主考核。两者并存时，可按角色分别设定指标集，在同一考核周期内各自评价，再汇总为个人或团队的总体结论，避免指标相互抵消。
落地时建议按以下步骤验证和调整：
- 先写清角色职责与决策权限，再据此列出候选指标，确保每项指标都能追溯到职责。
- 为每项指标确定证据来源和取证频率，确认数据可获取、口径一致。
- 在一个迭代或一个项目阶段试运行，观察指标是否引发预期外的行为，例如为凑数据而频繁开会。
- 根据试运行结果删减难以取证或误导行为的指标，保留三到五项核心指标。
- 每个考核周期复核一次指标与职责的匹配度，团队阶段变化时同步调整权重。
考核重点的差异最终来自角色对什么负责：Scrum Master对团队与流程的健康负责，项目经理对项目目标的达成负责。把这条线划清楚，指标设计、兼任处理和场景选择就有了共同依据。
常见问题
Scrum Master的考核要不要看迭代交付结果？
可以看，但不宜作为主考核项。迭代交付结果受需求变化、外部依赖、团队能力等多种因素影响，Scrum Master能直接影响的是机制运行与障碍清除。更合理的做法是把交付结果作为观察项，主考核仍放在Scrum事件质量、障碍从提出到解决的平均时长、回顾改进项落地率等可归因于该角色的指标上。若把交付结果直接作为主考核，容易促使Scrum Master越位替团队做决定，团队自组织能力反而退化。
团队规模很小、没有专职Scrum Master，考核怎么简化？
简化的是指标数量，不是指标归属。可以只保留每个角色两到三项核心指标：Scrum Master侧看回顾改进项是否落地、障碍是否有人跟进；项目经理侧看里程碑是否按期、风险是否落实应对。两类指标分别取证、分别评价，再按实际投入比例合成个人考核结论。规模小不构成合并指标的理由，合并后容易失去责任信号。
定性指标容易变成印象打分，有什么办法约束？
给定性指标配上结构化证据。评价时要求评价人按固定维度描述具体事例，并对应到可查的记录，例如回顾会改进项清单、障碍清单的状态变化、评审结论。评价人给出等级时写明判断依据，团队反馈与直接协作对象的意见分别收集。这样定性评价仍然有据可查，减少凭印象打分的空间。
考核指标定好后，多久复核一次比较合适？
建议每个考核周期复核一次指标与职责的匹配度。团队阶段发生变化时同步调整权重，例如团队从形成期进入稳定运行期，Scrum Master侧的流程类指标可以适当减少，转向团队能力建设的观察项。试运行阶段可以更短，用一个迭代或一个项目阶段观察指标是否引发预期外的行为，再决定删减或保留。
过程数据从哪里取，才能支撑两类角色的考核？
Scrum Master侧的证据主要来自迭代看板、燃尽图、回顾会记录与改进项跟踪、障碍清单；项目经理侧的证据主要来自项目计划与基线、进度与工时数据、质量报告、风险登记册与验收文档。这些数据大多产生于日常研发过程。ONES的敏捷研发管理方案支持通过敏捷看板管理任务状态、在每日站会中对齐迭代进度与风险，并通过燃尽图评估研发效率；迭代结束后可结合燃尽图、工时日志等报表复盘进度、质量和成本偏差。系统会记录资源投入、缺陷分布、工作项滞留时间等过程数据，ONES Project也提供多种报表呈现项目表现。这些数据可作为取证来源，考核制度本身仍需团队自行设定。
