最近听朋友推荐，读了《阿米巴模式》这本书，正好最近在思考IT部门内部绩效考核的事情，所以就有了一些灵感和想法，正好在这里与大家一同分享和探讨。

团队考核存在的问题

现在创业公司的技术开发部门其实很难进行考核，无论是KPI还是OKR，我觉得在实际操作过程中都有不少问题，这不是说考核的方法不对，而是我觉得在落地操作的时候并不那么的接地气，那么问题或者阻碍有哪些呢？

 1、目标不明确

这是创业公司都会存在的问题，因为创业公司的首要任务是活下去，所以朝令夕改，边做边调整的情况是司空见惯的，而习惯于瀑布式开发的团队，对于这样的做法做着做着就不行了，关键是开发人员非常反感需求的频繁调整，这对于开发团队的士气也会造成较大的影响。

那么有人会说，敏捷开发不就解决这些问题了？是的，在一定的条件下，的确可以解决问题，但是这对于开发人员、项目经理、产品经理，甚至于部门负责人的要求都是非常高的，真正用好敏捷开发的我自己看来屈指可数。

2、考核的依据过于主观

一般来说，无论哪种考核方式，都是要评估工作量的，但是开发与卖产品不一样，开发人员在接到任务的时候，其实是不知道要做多久的，很可能都是做着做着发现其实需求并不合理，一问业务部分，然后又改了需求，但是修改之后工作量可能就变化了（这个关于工作量的问题，我也是在读《人月传说》时特别有感受），所以大部分的项目都是由项目经理来评定的，万一项目经理的经验不准，或者老板极其强硬的缩短开发周期，那么团队就会死的很难看了。

尤其是拼命干了之后，开发人员并没有得到充分的认同，对老板来说可能老板更加相信是自己的眼光和远见，团队越是这样完成任务，接下来任务会更紧，而且变得更加的理所当然，这也是程序员特别苦闷的地方，谁让我们IT人当老板的不多呢？

3、考核最终的呈现不透明

一般我们IT人员搞开发，大部分还是拿稳定薪水的，毕竟不压榨开发人员，公司哪里来的收益，资本主义的概念在现代开发项目中最有体现，尤其是老板是业务出生的，你跟他说工作量，这个用了什么技术，那个通过什么算法，老板基本都是云里雾里，那是为什么？因为不懂啊，不懂技术啊，因为不懂所以天然就会怀疑，因为怀疑所以并不理解技术人员在完成项目过程中的辛苦与汗水，完成之后，好一点的给个项目奖，但是因为整个过程没有得到最希望认可的人来理解，那么就算完成了还是成就感缺缺。

归根结底，对于技术人员开发的考核不透明，对开发人员自己不透明，做的只有自己知道，对外就更不透明，大部分开发人员做出来的功能，其实是没人去用的，处理自己和测试人员，没人知道这个功能有多棒！

那么，是不是有什么方法解决呢？

有啊，比如：招个特别牛的IT总监就可以，因为人家经验丰富，对于这些问题应该比较了解，通过他再跟老板沟通应该就会好，当然这也是很多企业解决的方法，但问题是，我看到更多的还是CTO是个大坑这样的言论（各位CTO先不要喷，并不针对人，只是存在这种存在情况）。

对此，有何方案

那么这三个问题，有没有办法解决？ 目标该怎么定？工作量怎么评估？如何通过考核透明向老板正名？

看了《阿米巴模式》之后，我就有了下面的一个实施方案，拿出来大家讨论讨论：

1. 由全体人员对工作量进行评估，而不是仅仅由项目经理负责；
2. 评估之后取全体人员评估的平均值；
3. 选3个开发人员，按照其对于团队的了解，基于平均值进行调整，最后选用最合适的方案，方案使得每个人的工作量最终应该差不多时间完成，而团队以完成最长的那个人评估的工作量作为整体项目完成时间，而方案的拟定人作为这个项目任务的负责人；
4. 项目实际开发时，计算个人实际完成和团队实际完成天数，比照原来估计的分别产生个人完成效率和团队完成效率；
5. 个人完成效率可以迭代到下一次任务中作为平均值调整的参数，团队完成效率之外可以再提供一个项目完成时的表现打分，仅仅是大家对于开发人表现的打分，其实也可以理解为，大家对于个人在整个项目完成过程中这个人对于团队的共享价值。

依次反复之后，会有一些结果， 我自己按照上述方法在我自己的开发团队执行了4次，第一次误差比较大，毕竟没有什么借鉴，但是随着一次一次的尝试，一方面团队的人员会比较熟悉这套方法，除了每个人具体评价的值不透明，所有过程都是透明的，公开的，自己都可以计算；另一方面的确有激励的作用，毕竟原先一个人评价20天完成的任务，12天完成了，成就感就非常高（无论是团队内部，还是上升到老板层面），所以解决了上述的一些问题。

但是，这个方法本身还存在问题需要继续完善，比如：除了开发其他岗位的执行并不理想、人员太少的情况下不太适合、临时或者突发增加的任务依然还需要靠项目负责人来分配等等，这也没办法。但是，我希望通过团队和大家的努力共同打造一个合适我们IT技术人员的考核方法。

谢谢各位花时间阅读！

本文由 @加减乘除 原创发布于人人都是产品经理。未经许可，禁止转载。