最愚蠢的程序员考核方式

我估计按照代码量来考核程序员的工作是最扯淡、最愚蠢的了，真是无出其右的强，无以复加的蠢，罄竹难书的变态啊～～～～～

 

偏偏这个世界上就是有这样的人，还抱着“代码量是一个非常好的量化指标，按代码量考核工作业绩是非常直观合理的方式”不放。自己手里攥着大粪还说香的人确实是令人无法可想了。和放言“会用php在网页上输出’hello world‘，就敢在简历上写’精通php‘”的人有一拼啊。

 

不过这老问题仍然没解决，到底怎么考核？

 

首先看看考核的目的吧，毕竟这是进行考核的最原始发源地。先排除那些考核者自己心里打小九九的情况，只说正当的那些。

 

我想考核是为了评估什么东西，比如工作量、业绩、忙闲程度、劳动生产率，找到扣或奖的理由等等，其实就是想找到一个指标，用来说明工作是否有再继续进行改进的必要以及指明改进的方向，如果通过考核能够找到问题，那么就达到目的了。那么，也就是说考核的目的是为了发现问题。比如考核一个团队，是为了发现这个团队以前、现在存在什么问题，以后可能出现什么问题。因此，考核方法如果不能暴露可能存在的问题，那么这个方法就失效了。

 

以程序员为主要构成的团队到底都在干些什么？或者从另一个方面来考虑，如果他们从事的是新产品的研发工作，那么他们可能出现哪些问题呢？大概是：

项目可以按时交付，但不会达到要求

项目一定会延期

方向错误

在可预见的未来无法看到项目交付

 

不考虑人的问题，比如项目组里的人用不同的语言、办公室恋情、有仇等等，怎么发现以上的问题？

 

我来想个主意。首先，在开始的时候，就制订清晰的项目目标，但要保证能够按照实际情况随时进行调整。比如，临时增加了新的任务，那么项目必然会延期了。其次，要多次对项目的进展进行评估，比如两周一次，如果它发生延期了，那么要尽早知道。评估的办法，核心是看实现了什么。最后，要客观对待偏离预订轨道，因为可能开始画出来的轨道就不是实际中可能遵循的。这算一种考核方法吗？