【好文推荐】敏捷绩效考核如何做？

前言

一个 Scrum 团队有三个角色：产品负责人、开发团队和 ScrumMaster。在 Scrum 里没有项目经理这个角色，传统项目经理的主要职责被分配到产品负责人和开发团队这两个角色中。产品负责人负责管理产品待办列表，开发团队自己组织和管理他们的工作。跨职能、自组织的开发团队是 Scrum 的四大支柱之一。“跨职能”指团队拥有完成工作所需要的全部技能，不需要依赖团队以外的人。“自组织”指团队自己选择如何更好地完成工作，而不是由团队外的人指导。这与单一职能、接受金字塔式层级管理的传统项目团队有很大不同。跨职能的自组织团队既是 Scrum 的最大亮点，也是理解和应用好 Scrum 的难点。对于自组织团队，管理者是否需要对其进行绩效考核？没有项目经理，去除微管理，怎样进行绩效考核？笔者广泛了解国内外应用 Scrum 的理论和实践，结合自己的实践经验，总结心得如下，和大家分享。

考核原因

考核原因需要考核吗？不需要，为什么？需要，为什么？

不少初涉敏捷的实践者认为不需要。他们觉得，敏捷团队是由一群技术精湛、积极敬业的顶尖高手组成的梦之队。自组织是管理中的乌托邦，不需要绩效考核。笔者部分认同这一观点。对于由志愿者组成的非盈利组织，或初创企业的合伙人来说，一方面，无人考核他们，另一方面，他们所追求的事业、市场直接考核他们。

然而，对于成型企业中的开发团队来说，不可以没有绩效考核。工资涨幅、奖金分配这些关乎员工切身利益的问题总要面对。即使说“不考核”实际也考核了，只不过默认绩效相同，等同于大锅饭。所谓考核，实质是区分绩效，奖勤罚懒。剖析当今成功实施敏捷的互联网公司，不难发现他们不但有绩效考核，而且还有一套运作良好的方法。梦之队不会从天而降。Scrum 联盟以创造愉快、繁荣、可持续的工作环境为己任，旨在培养人、提升人的能力，打造梦之队。绩效考核作为组织管理的一部分，势必对梦之队的打造产生决定性影响。所以，关键问题不是需不需要绩效考核，而是怎样搞好绩效考核。搞的好，员工士气倍增；搞不好，员工士气受挫，想继续实施敏捷，难上加难。

考核对象

考核谁？团队成员个人还是整个开发团队？

多数实践者认为应以开发团队作为最小单位实施考核，也有实践者提出团队、个人两级考核。他们的理由是，Scrum 开发团队规模在 3 到 9 人之间，适合作为最小考核单位；开发团队是自组织团队，团队集体做出承诺，自主管理，共同达成 Sprint Goal，适合给出集体的评价。考核成绩好，团队成员全部得到奖金，考核成绩不好，团队成员全部得不到奖金。这种同舟共济的考核制度将极大提升团队凝聚力，团队成员更倾向于从团队的角度出发去思考和解决问题。

只关注考核个人的制度在需要体现团队精神的问题上无法起到正面引导的作用。软件工程中有一些反复强调，但开发者仍然出工不出力的活动，例如 code review。技能强的开发者持有自扫门前雪的观念，做好项目经理指派给自己的工作，对帮助别人进行 code review 常敷衍了事。技能弱的开发者因缺乏来自其它团队成员的帮助，想要提高技能往往求助无门。以开发团队作为最小单位的考核制度转变开发者观念，让开发者认识到帮助别人就是给团队做贡献，给团队做贡献就是帮助自己。能力强的帮助能力弱的，在团队中收获尊重和社会认可；能力弱的虚心向能力强的学习，在团队中收获知识和友谊。最终集体能力得到提高，集体绩效得到提高。

考核指标

考核什么？软件开发的中间数据还是软件产品的运营数据？

已经有成功经验表明，采用产品运营数据作为考核绩效的指标颇具优越性。这是因为，从有用性来看，跨职能的开发团队具备开发和维护一个产品所需要的全部技能，这样的考核指标把开发团队的绩效目标与组织的业务目标对齐，纠正了开发者单纯追求技术先进性，而对产品商业价值理解不足的常见问题。从客观性来看，产品运营指标来自市场，比来自组织内部其它途径队的数据更客观，更具说服力。以某知名互联网企业为例，该企业以客户访问量和营业额作为其网络产品运营指标，基于这两个指标考核开发团队绩效。访问量提升，营业额提升，说明开发团队绩效好。

反观使用中间数据的案例，比如软件开发行业常采用的“缺陷密度”，既组织内部测试团队发现的“缺陷”数除以项目开发的代码量。因测试者报告的“缺陷”中有误报的情况，所以只统计已修复并关闭的真正“缺陷”个数，未关闭的缺陷不确定是否是真正的缺陷，不参加统计。代码行数由开发者统计提供。从有用性来看，“缺陷密度”只说明已完成的工作情况，并不提示“产品发布前还有多少问题没解决？发表后用户体验如何？”这些更重要的问题。从客观性来看，开发团队迫于考核压力，把代码量搞大的现象屡禁不止。对照上述案例，使用产品运营数据作为考核指标的优越性显而易见。

考核频率

多长时间考核一次？半年一次还是每月一次？

Scrum“透明、检验、调整”三大理论支柱指出，频繁地把绩效反馈给开发团队非常必要。仍以上文提到的某知名互联网企业为例，他们采用每月一个 Sprint，产品每月发布一次，配套的绩效考核也是每月一次。开发团队直接感受来自市场的业务绩效的压力，要么提高绩效，让产品越做越红火，自己随产品的成长而成长；要么原地踏步眼看产品衰落，团队解散，自己另谋出路。可见，在 Scrum 中，来自项目经理微管理的约束少了，挑战却更严峻了。

但也有实践者指出密集的考核周期导致严重的问题：开发团队寻求短期最大利益，忽视可持续发展的长期战略；考核成绩暂时不理想的团队即使努力也需要一个过程；团队成员压力过大，离职率高。这些都与 Scrum 致力于建设一个长期的、自管理的团队的初衷相违背。什么样的考核频率，多大的压力是最佳的，不仅涉及到当前的业务，还和长期的组织文化有关。在这个问题上求得平衡和可持续发展不是一件简单的事情。

后记

绩效考核只是绩效管理的内容之一，绩效管理也只是组织对内管理的内容之一。怎样创造员工的最佳工作场所，怎样创造组织的最大利益，很多话题值得继续讨论，不断探索。

参考资料

1.www.scrumalliance.org

2.《Scrum 指南》，作者 ken Schwaber，Jeff Sutherland；译者 王军，李麟德

3.《Scrum 简章》，作者 Peter Deemer，Gabrielle Benefield，Craig Larman，Bas Vodde

4.《敏捷开发之绩效考核》，钱魏， 2013 年

5.http://www.cognology.com.au/learning_center/agile-performance-management