今天在微信群里讨论开发团队效能的问题，话题是由 小L 提问 “KPI设定的指标有啥啊，评分时候是用数据还是靠主观？有罚么？”开始……

有群友 小F 建议：

靠事实，不建议有罚…… 数据和主观都有不靠谱的地方，多维度评估。

接着 小L 问道:

那指标一般定哪些？我们现在用：bug解决用时、线上问题解决率……

显然这些 KPI 指标是有问题的，团队成员可能为此而放任 bug 的出现，同时对于认真编程很少 bug 的成员也不公平。 问到 小L 定绩效的目的时，小L 提到：

  • 团队的整体积极性不好，目前总有不按目标完成，找一大堆理由的情况
  • 经常出现前一个任务完成后，开始后面的任务，又回头解决前一个任务的 bug，占用较多时间，导致后一个任务的进度也拖延，其他人也跟着等待进度的情况。

小F 说这是 DoD （Defination of Done）的问题，如何定义一件任务彻底完成了呢？

小L 说是完成后会给 QA 提测， 即使是让产品经理一起看，也只是看功能完没完成的大概，依旧是会在后面的详细测试过程中发现 bug 的。

小F 给了一个 B 站的视频（可以从 01:48 看起，前面是铺垫，与上面情况类似）

小L 接着问道：

我们现在的人员是一个萝卜一个坑 ，如果他不进行，另一个需求就开展不下去，这个问题算问题么？

去年我们的情况就是有人离职会导致这个需求延后到下一个周期。

眼前技术债务很多，但是需求不断，也就是在盖危楼，如果老人员突然断层，风险非常大。

这当然是个很严重的问题，小F为此直接跟小L进行了语音讨论……

我是后来上线才看到这段聊天的，想到了下面这些点，于是补充在了群里：

看来还是上层认知观念的问题，低估了开发软件的资源投入，人力和时间，这两项是要精心呵护的，对人才的有效激励和对时间的合理安排～

其实当下的解决方案已经摆在眼前了，如果你是一个建筑项目的监理，负责项目最终的实用效果，你已经看到了一个项目在盖危楼，需求还不断在提，在添砖加瓦，你要做些什么？

或者说是一个生产线，已经明显看到不良率很高，中间几个环节混乱，很多生产人员已经忙不过来，在制品堆积，你是生产线的管理者，负责最终的优质产品产出，你的第一反应是什么？

你会不会叫停？或者至少减慢投料速度？上报厂长问题严重性？

小F 问我：

TOC制约法……瓶颈理论，高德拉特？ 讲真，我接触瓶颈理论比精益和敏捷早

我说:

没错，我跟你差不多～

:D

应该说上面 小L 提出的问题在很多团队中是普遍存在的，团队成员积极性不高，责任担当不够，甚至互相甩锅（参见另一篇文章： 甩锅文化要不得），而造成这种现状的一个原因正是公司的一些绩效考核制度，所以说知识工作团队中，尽量不要有 KPI，特别是不要和薪资奖金有关联，可以整个团队进行奖金激励，不适合的成员可以沟通、辅导、培训，实在不行可以辞退，这中间团队氛围很重要，企业文化也很重要，一旦氛围破坏，人人因为 KPI 而自危，即落入恶性循环的深渊而无法自拔，整个团队的效能就更不用提了（参见软件开发团队如何高质量、高效率？）。