跪求领导:不要强制那些挫伤团队的假性效率指标
-
每个开发工程师每月代码行产出量不得少于xxx
-
每个开发工程师每月完成功能总数,不得低于xx个
-
每个测试工程师每月提交的bug总数,不得低于xx个
-
......
1+1=2吗?别逗了,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个月时间;
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。
如果团队成员把时间和精力放在了互相PK和竞争上,团队整体的目标谁来关心呢?只剩领导一个人关心。
翰德恩咨询(www.hardenx.cn)是一家由华为系专家联合创办,专注于企业级敏捷&DevOps落地咨询、IPD落地咨询和数字化转型教育的企业,沉淀10年+的众多500强实战经验,为企业提供从业务到交付的端到端全价值链赋能。