文档介绍：理想流
创建超一流方法论,为培育超一流的软件公司贡献力量
程序员第二定律:量化管理在程序员身上永无可能
分类: 项目管理理想流 2012-02-15 00:11 18117人阅读评论(43) 收藏举报
恰如标题,第二定律表示为:在思维可以精确量化前,量化管理在程序员身上永无可能。
这次估计会有争议,所以这里给出具体的逻辑链以及对应的分析。
逻辑链:
软件是一种固化的思维 →思维的本质是概念和逻辑 → 概念和逻辑无法直接度量和精确度量 → 度量过程
中需要很多的主观判断 → 以目标为导向的,个人中心的量化管理(相关的激励和惩罚)将崩溃 
具体分析:
公平公正是管理的基石,为达成这一目的很多人会想到量化管理,但量化管理的基石却往往被忽略。
对人进行量化管理的基石是:量化后的数字主要受个人表现这一个因素的影响,否则将产生巨大的不公正,并对个
人工作意愿产生不良影响,是真正的事与愿违。
好比说,不同的工人在同等条件下生产杯子,一个人一小时生产5个,一个人1小时生产6个,那显然后者要好于前
者。这时,5和6可以用来比较的前提是两个人的生产条件相同,比如生产工艺等。在这种情况下,量化后的数字为
个人表现的函数,因此量化管理基本上是公正的。
这时可以进一步来考虑下面的情形:两个人同时生产杯子,厂方安排一个人用工艺a,另一个人用工艺b,这个时候
前者一小时生产5个,后者1小时生产6个。这个时候单纯比较5和6事实上是不公平的,因为这1个杯子的差距可能是
工艺造成的。
大多时候,软件的情况比后一个情形还要糟糕一些。
在软件开发中,往往既没有办法清楚的界定一个人的输入,也没办法清楚的界定一个人的输出。
软件开发的输入是需求,但同一个需求不需要做多次,所以对需求自身的复杂程度眼下来看还只能依赖判断,而不
1
软件开发的输入是需求,但同一个需求不需要做多次,所以对需求自身的复杂程度眼下来看还只能依赖判断,而不
能精确度量。
软件开发的输出是代码,而代码自身属于固化后的思维。在度量思维时,多少、大小、长短、厚薄这类惯常的度量
方向,并不具有多大意义。就好比说,不能讲一个人代码写的越多贡献就越大一样。
诚然思维的表现形式则是可以度量的,我们可以通过页数来度量一本书的厚薄,通过分钟来度量一部电影的长短,
通过代码行来度量软件,但这种度量所反映的内涵是有限度的,精度也是有限度的。最终结果很可能是人员之间的
差距