主题：【原创】闲聊敏捷开发——SCRUM（一） -- 哈酷

所以平衡记分法很难使用。scrum和xp里面的point都不是man-day或者man-hour，它只是一个相对的评估值。比如我对某个任务的估算是3个velocity，那只是说明我做这个任务所需要的时间是坐另外一个1velocity的时间的三倍。那么熟手来做可能是1个velocity，新手可能是大于三个，所以这个是不能做量化指标的。

hp是一个销售硬件和服务为主的公司，所以他的工作可以比较容易量化，这时候用平衡记分法和全方位考核法都有相当的价值。但是我基本没有听到什么大的软件公司或者小公司用这种方式进行绩效考核的。

我们之前也曾经尝试过几年量化考核，采取的做法就类似哈库这样。比如一个任务我进行拍卖，这个任务做完有100块的奖金，你多久做完是你的事，初期看起来效果不错，当时到了中后期就发现，成本大幅度提高，不单是奖金成本，管理成本也大幅度提高，但是项目的进度和质量并没有显著变化。有些程序员为了多拿钱，7*12小时的工作。

这样的直接后果就是工作质量下降，后期维护成本增加，bug多了，收入就下降，积极性也跟着下降。

另外不同任务有不同的价格，大家都有明确的倾向性，虽然说是团队的考核也占一个比例，但实际做起来很难，所谓罚不责众，只要大家都想好钻空子，有的是办法。而且争议最大的就是任务的评估，很难真正做到公平公正，特别项目到了一定规模，而我们当时项目普遍都超过1万个功能点，计算这个任务的工作量可能就会耗尽核心程序员的所有时间。到了后期有些项目基本就是指定一两个人说了算，引起的矛盾也相当多。

另外还有个问题，项目经理（pm不直接从考核中拿钱，而是根据项目进展考核，和你说的类似）为了不得罪程序员，保证项目进度，所以很多时候挣一只眼闭一只眼，我自己统计过，大约70%的任务评估都是有水分的。而认真评估考核任务的项目，项目成员收入反而直线下降，项目经理反而被程序员集体造反，最后就出现假币驱逐良币。矛盾很大。

虽然对外宣传方面，我们当时有些部门吹嘘的还是很牛的，但是私底下都承认，几个软件部门采取的不同路子最后都失败了。其实道理也很简单，如果软件真的容易做到量化考核，软件危机早就不存在了。

我觉得这种模式可能在小公司小项目做还不错。管理成本增加不明显。