一. 传统管理思维和管理模式不支持敏捷实施
在与许多客户和朋友交流时，大家都谈到了一个非常现实的问题——在组织敏捷转过程中，其组织的管理思想和管理模式不支持敏捷实施，这给组织的敏捷转型造成了障碍。
Mike Cohn在其著作《Scrum敏捷软件开发》中是这么阐述这个问题的：“我亲自见证过几个失败的敏捷实施案例，而这些失败本来是可以避免的。第一个例子，一个公司在敏捷转型上投入了100多万美元。他们聘请了外部培训师和教练，以及招募5名人员组成“敏捷办公室”，为新创的Scrum团队提供建议和帮助。他们最终失败了，因为他们认为实施Scrum仅限于开发团队就够了。发起敏捷转型的管理层认为，只要给开发人员提供培训和支持就足够了。他们没有考虑到Scrum会触及销售部门、营销部门甚至是财务部门的工作。而如果这些领域得不改变，那么“企业惯性”会把公司又拉回到原点。”
Mik Kersten也在其著作《从项目到产品》中进一步指出：问题不在于组织没有意识到需要变革；问题在于，虽然身处软件与数字化时代，但是我们的许多企业依然在使用着由石油和大规模生产时代延续而来的管理框架和管理模式来管理业务，这就导致组织变革起来非常困难。
今天，我想在此探讨一下组织管理的核心——绩效管理。我会阐述传统绩效管理模式的来源、特点以及在软件研发管理中应该破除的三大绩效管理理念。
二. 传统绩效管理模式的来源及特点
在传统的大规模生产中，强调分工和标准化：把整个生产过程细分成一道道工序，并精准地规范每一道工序的工作要求，工人只需在各自工位上按规范完成加工操作，就能高效地生产出合格的产品。
管理总是服务于其业务，绩效管理也是如此。于是，就形成了如图1所示的传统绩效管理模式：将生产流水线分解成生产工序，定义出每道工序的操作规范，为每道工序上每位员工制定绩效目标，度量获得真实绩效产出情况，通过培训和辅导提升员工的绩效产出能力，通过金钱奖惩手段来激励员工，通过淘汰绩效差的人员来鞭笞员工，以实现高绩效。
图1 传统的绩效管理模型
这种传统的绩效管理模式，可以总结为以下三大管理理念（或者称为假设）：
- 能通过工作分解与标准化来实现高绩效：能将整个价值生产与交付工作分解成工序，并针对每道工序制定标准化的工作方法、工作规范和质量标准，只要遵守这些标准化的要求，就能实现高绩效。
- 能通过个人绩效管理来实现组织高绩效：能针对每位员工，制定明确的绩效目标——每道工序单位时间要完成多少合格的半成品，度量和跟踪绩效目标达成情况，通过培训和辅导来帮助员工提升能力，淘汰无法胜任工作的员工，当每道工序上的员工都实现了高绩效时，自然实现了整个生产线的高绩效。
- 能通过金钱奖惩来实现有效的激励：能通过计件工资制和末位淘汰等手段，来促进工人奋力提高自己的操作熟练度和加大工作时间地投入，以实现更高绩效。
这些绩效管理理念形成于大规模生产时代，进入教科书成为经典管理理论的重要组成部分，并成为传统管理者根深蒂固的管理指导原则，继续沿用到了软件与数字化时代。
三. 传统绩效管理重视分工而忽视协作
然而，传统绩效管理是重视分工和标准化、忽视人际协作的。
在大规模生产时代，这么做是有道理的：只要完成的工件符合质量标准，流水线自然会把它传送到下道工序——不同工序间的协作，是通过工作标准化和流水线来实现的，并不需要太多的人际协作。
四. 软件开发，无法通过分工和标准化来实现高绩效产出。
大规模生产流水线的工作分工和标准化是精准而有效的——只要输入标准的原料，进行标准化的工序加工操作，就一定能得到符合标准质量要求的产品。
然而，在软件开发中，完全无法做到这一点。软件开发无法实现精准有效的工作分工和标准化。
从20世纪70年代到21世纪初期，在软件工程中出现了一场试图实现软件开发过程标准化的运动，这场运动由美国国防部发起，由美国卡耐基梅隆大学软件工程研究院负责研究和组织实施，这就是著名的CMM/CMMI运动。大量的企业，包括中国企业，通过了CMM/CMMI认证，并宣称自己实现了标准化的软件开发过程。然而，实际结果往往却是，这些企业建立了一个臃肿而低效的软件开发过程，而当软件开发团队需要追求高效时，就出现了“两张皮”现象——流程是一套而实际执行又是另一套。
经过几十年的发展，虽然在软件工程中确实总结出一些行之有用的实践方法，但众所周知“软件开发中不存在银弹”——也就是说，无法通过一种标准化的工作方法实现高绩效的软件开发。
皮之不存，毛将焉附！当无法通过分工和标准化来实现高绩效时，传统绩效管理的管理理念还能继续有效吗？
五. 软件开发，无法通过个人绩效管理来实现组织的高绩效
在传统的大规模生产中，能把绩效分解到每道工序上，并针对每道工序来管理其绩效产出——某道工序在单位时间产出了多少合格工件，最终实现组织的高绩效。
于是，传统HR也把这套绩效管理方法也搬到了软件研发中：
- 软件开发过程难道不也是由一道道工序和岗位（项目管理、需求、设计、开发、测试）组成的吗？难道不能针对每道工序和岗位进行绩效管理和考核吗？
难道不能评估需求分析岗产出了多少条需求吗？
难道不能评估设计岗产出了多少设计方案吗？
难道不能评估开发岗产出了多少行代码？
难道不能评估测试岗发现了多少个Bug吗？
难道不能评估项目管理岗是否控制住了项目进度吗？
- 这个逻辑没毛病呀？！
于是，出现了以下现象：
- 臃肿的需求文档
- 臃肿的设计文档
- 大量的烂代码
- 各种吹毛求疵的Bug
- 项目计划申请“头戴高帽”，高层审批“拦腰一刀”，像是在菜场讨价还价
当软件开发中的每个岗位都去追求本岗位的“高绩效”时，就变得“马路警察，各管一段”了，而团队也早已不再是团队。
区别于大规模生产，软件开发更强调“协作”。软件开发的绩效产出最小单位是端到端的团队，需要整个团队通力协作，才能实现高绩效。如果只追求单个岗位的高绩效，结果往往只能导致整个软件开发和交付过程的低绩效。这就是所谓的“系统思维”。
所以，软件研发的绩效管理对象，也只能是整个端到端实现价值交付的团队，而不能是工序和岗位。
需要补充说明的是，我并不是在说员工个人不需要绩效辅导，我的意思是说不能象传统绩效管理那样，把组织绩效分解到个人头上，设置岗位的绩效目标和进行考核。
六. 软件开发，无法通过简单的奖惩来实现有效激励
对于简单的工作，例如搬砖，本着多劳多得的原则，通过简单的计件工资制就能激发工人的热情。因为工人们非常清楚，自己多出一份力，就能多得一份收获。
然而，软件开发的环境，远比搬砖更为复杂。影响软件产品成败的因素非常复杂，有时候就算团队再努力也无法实现高绩效。这种情况下，就无法通过简单的金钱奖惩来实现有效激励。
Daniel Pink在其著作《驱动力》中指出，存在三类驱动力：第一类驱动力，来自生物的本能，例如：生存、温饱、繁衍；第二类驱动力，来自于外在，例如：奖励、处罚；第三类驱动力，来自于工作本身，例如：工作的本在意义、能满足员工的好奇心，能带来成就感和荣誉感。
Daniel Pink还指出，存在两类工作：第一类是推算型工作，能够根据一系列现存的指令，按照某种途径达成某种结果，例如简单、重复、机械的搬砖工作；第二类是探索型工作，没有现成的算法可用，必须试验各种可能性，设计出一个新的解决方案，例如研究性工作、艺术性工作等。对于推算型工作，第二类驱动力和第三类驱动力都能发生作用。而对于探索型工作，往往第二类驱动力会产生破坏性作用，而第三类驱动力仍然能发生作用。
软件开发，是一种探索型工作，所以简单的奖惩并不能产生有效激励，反而可能会导致破坏性作用——让人过于关注工作收入是否足够和公平，反而丧失了工作本身能引发的好奇行、成就感和荣誉感等。
当然，我并不是说，对程序员来说金钱不重要——丰厚的薪酬收入能够让人安心工作，反之则会令人想另谋高就。但这只能表明，金钱奖惩是属于Fredrick Herzberg的“激励一保健理论”中的保健因素，而非激励因素。
七. 您怎么看
您是如何理解传统绩效管理的？在您的组织中，仍然在使用传统绩效管理方法来管理员工的绩效吗？还是说，您的组织中，已经采用了更加了促进团队协作和更加能够激发员工主动性的做法？
欢迎在评论区留下您的观点。
本文作者：
李洁（Jerry Li），CSP，CSM，Scrum中文网资深敏捷顾问和培训师，敏捷教练
