完美软件开发：量化管理法

软件是一种固化的思维→思维的本质是概念和逻辑→概念和逻辑无法直接度量和精确度量→度量过程中需要很多的主观判断→以目标为导向的，以个人为中心的量化管理（相关的激励和惩罚）将崩溃→参照无歧义数据（函数复杂度等）的判断将成为程序员评价中的辅助手段。

公平公正是管理的基石，为达到这一目的很多人会想到量化管理，但量化管理的基石却往往被忽略。

对人进行量化管理的基石是：量化后的数字主要受个人表现这一个因素的影响，否则将产生巨大的不公正，并对个人工作意愿产生不良影响，是真正的事与愿违。

好比说，不同的工人在同等条件下生产杯子，一个人一小时生产5个，一个人1小时生产6个，那显然后者要好于前者。这时，5和6可以用来比较的前提是两个人的生产条件相同，比如生产工艺等。在这种情况下，量化后的数字为个人表现的函数，因此量化管理基本上是公正的。

这时可以进一步来考虑下面的情形：两个人同时生产杯子，厂方安排一个人用工艺a，另一个人用工艺b，这个时候前者一小时生产5个，后者1小时生产6个。这个时候单纯比较5和6事实上是不公平的，因为这1个杯子的差距可能是工艺造成的。

大多时候，软件的情况比后一个情形还要糟糕一些。

在软件开发中，往往既没有办法清楚地界定一个人的输入，也没办法清楚地界定一个人的输出。软件开发的输入是需求，但同一个需求不需要做多次，所以对需求自身的复杂程度眼下来看还只能依赖判断，而不能精确度量。软件开发的输出是代码，而代码自身属于固化后的思维。在度量思维时，多少、大小、长短、厚薄这类惯常的度量方向，并不具有多大意义。就好比说，不能讲一个人代码写的越多贡献就越大一样。

诚然思维的表现形式则是可以度量的，我们可以通过页数来度量一本书的厚薄，通过分钟来度量一部电影的长短，通过代码行来度量软件，但这种度量所反映的内涵是有限度的，精度也是有限度的。最终结果很可能是人员之间的差距是由误差或其他非主观因素造成的，而不是由个人工作好坏所造成的。

总结来看，在软件开发中，数字含义的模糊性会导致使用数字进行评价包含非常多的不公正，这种不公正会对工作意愿构成致命伤害。所以个人层面的量化管理在软件开发面前，必然崩溃。(www.xing528.com)

但也不是所有数据都不能用于评价，无歧义数据是可以的。比如，函数的圈复杂度、对既定风格的遵守等都可以根据静态代码工具获取，这些数据是可以用来辅助评价的。但这些数据由于不能完整的表现一个人工作价值，所以只能成为判断的辅助手段。

为避免矫枉过正，最后需要强调的是：并不是说项目管理中不需要收集数据，只是说在软件这个行业中，各种数据的精度天生是有限的，因此必须用在允许有限精度的工作上（估算、任务安排等），而不能用在对人进行评价、对项目进行评价这样需要高精度数据的工作上。

换句话说，任何数据其天然模糊性所导致的偏差和其他输入（问题等）导入的偏差如果很容易区分，那么量化管理可以使用这些数字，因为数字可以直接映射到问题；否则数字不可用，因为分不清数字的真实含义。

软件项目中的评价

很不幸，基于这一节里的结论，软件项目中的评价只能基于判断。我们可以对这种判断进行重重分解，比如，把工作分拆为日常工作和具体项目工作，项目工作又可以进一步分拆为需求、设计、编码等，但归根到底还是判断。

剔除主观因素后，正确判断的基石是对事实的理解，这一点反过来限制了可管理软件团队的规模。假设说，一个人可以比较清楚地了解9个人的工作，那么可管理的软件团队规模必然为10人左右。大的软件团队则需要拼接很多个这样10人左右的团队。

一旦规模过大，由于评价者对事实了解的不够清楚，往往就会偏颇。比如，会因为某人智力、想象力、知识渊博等而印象较好，进而给出较高的评价，但事实上考评更应该以成果为标准。