跪求领导：不要强制那些挫伤团队的假性效率指标

经常在企业里看到公司领导面临提升效率的压力，定了类似这样的指标，并纳入绩效考核：

1. 每个开发工程师每月代码行产出量不得少于xxx
2. 每个开发工程师每月完成功能总数，不得低于xx个
3. 每个测试工程师每月提交的bug总数，不得低于xx个
4. ......

一、在团队效率上，1+1不等于2

在组织效率上，1+1真的不等于2！每个人都忙的团团转，多产出代码，多开发功能，多测出bug，整个团队产出的价值就多了吗？NO, NO, NO!

笔者发现一个有意思的现象，凡事拿每个人产出的代码量或功能产出量来激励效率的领导，多数是技术出身，而且曾经他就是非常牛的技术大拿，一人顶十人，最擅长上山头攻破难关。但是，殊不知，此时非彼时。现在做项目都是团队作战，非单兵作战。激励单个人高产出没有错，但是，纯粹拿单个人的产出以工人计件的方式考核绩效，不仅挫伤每个人的积极性，而且会对整个团队的效能产生负面作用。

为什么这么说？

系统思考学告诉我们：只要不触动系统的内在连接和总目标，即使替换掉所有的要素，系统也会保持不变，或者只是发生缓慢的变化。

这个道理听起来抽象？放在组织效能的领域里，用人话来说：在多人协同作战的情况下，（即：不是单兵作战的情况）对于团队效率产出起关键作用的要素有两个：

1. 团队的整体目标
2. 团队成员之间的如何协同

不信是吗？那么尝试把所有人干掉，初级的工程师全部换成资深的工程师，但是团队的目标，以及涉及到团队成员之间如何协同的以下要素：流程、工具、环境工作氛围、企业文化、每个人的沟通方式、协作方式、领导的管理方式等等一切不变，你试一试，团队效率是否会有大幅度突破？如果有，请务必留言联系我。

为什么不会产生大幅度变化？因为在团队整体的目标，以及流程、工具等人与人直接协同方式等要素不变的情况下，单个人的努力会被团队整体所产生的低效和浪费所“吃掉”。

二、识别低效环节比单兵努力更重要

下图是某网络游戏公司，从一个创意提出来，到上线给用户使用的整个TTM(Time To Market)周期的价值流映射。

1. 从一个新游戏的创意在脑海里浮现处理，2天后，花了2小时写下创意，然后等待了1个月的时间给管理层做概念演示，整个演示过程花了4小时；
2. 演示完毕还不能马上开始做，因为没有设计人力，所以先放到Backlog里排队。等待6个月后，Lisa终于花了1个小时分配了人力；
3. 又继续等待1周，开始做游戏的图像设计；图像设计做了1个月后，花了3周做声音设计。到此为止，游戏的图像设计、和声音设计完毕，只需要开发实现即可。就差一个程序员了-:)；
4. 由于没有开发人力，设计完稿后又等待了6个月开始开发；
5. 开发花了1个月的时间，又花了2个月的时间修改bug, 所以一共花了3个月时间；
6. 开发后还不能发布，因为很多产品排队等到部署，游戏排队6个月后，部署团队花了3周的时间将游戏上线；
7. 整个产品交付周期TTM(Time To Market)共花了25个月，而其中只有3个月在从事价值产出活动，在精益里称为“增值活动”，其他的22个月在等待或者修复bug，没有价值产出，在精益里称为“非增值活动”。

开发一共只占了1个月时间，每个开发奋力地更快地产出代码，优化的空间也只是占到了团队整体效能的1/25。

三、莫让内部竞争冲击团队的凝聚力 

要小心保持内部的竞争与整体凝聚力的平衡。引入激励措施，牵引每个成员关注效率没有错，但是，如果采用的是挫伤整体凝聚力的措施就得不偿失。下面历数领导经常制定的这样几条考核对团队产生哪些挫伤。

1. 每个开发工程师每月完成功能总数，不得低于xx个。

直接的影响是：每个人只关心自己完成任务，越多越好。谁还会为了团队的整体目标而互相帮助？我帮了你，我的绩效受影响，搞不好还给我排名排到后面，我又不是雷锋。

2. 每个开发工程师每月代码行产出量不得少于xxx。

直接的影响是：为了多产出代码，来，一个功能300行，来我写他个600行。不然显得我工作量少啊。产品里堆积了大量冗余代码，又隐藏了一大波bug，日后的维护、优化都更加困难，平添了更多的隐形工作量。

3. 每个测试工程师每月提交的bug总数，不得低于xx个。

直接的影响是：测试人员和开发人员立马成为对立关系。你提交了代码我就提一堆bug，多提，多提，提少了我绩效不好了。明明没有确认是不是bug，也提上再说；提完了，再跟开发挨个PK。