软件开发中的道德风险

道德风险（Moral Hazard）是一个经济学术语，1980年代由西方经济学家提出。是指——人们执行活动，却不用全部或部分地为此活动的后果负责，所以会选择自身效用最大的自私行为。

要说明——道德风险不是道德败坏。

例如：一个十多岁的孩子刚考了驾照，通常都是其父母来买相关的保险。某些孩子在这样的情况下，就特别喜欢开车出去“撒欢”，因此发生事故的几率较大。而一旦发生了交通事故，明年的保险费率肯定就要上升了。

再例如：中层管理者在聘用新员工的时候，也或多或少要面临着这这样的风险，因为他也不能确定新员工是否真的能够胜任工作。

只要有经济活动，就难免会产生道德风险。

相比较于制造和建筑业，软件行业还是属于新兴领域，很多管理制度不科学，所以这种道德风险普遍存在。本文只讲“开发成本”有关的风险，其他的风险，例如——最根本的“需求风险”并不涉及。

理论基础

我们很多人都有写论文的经验，当教授在给学生们布置工作时，聪明的学生们肯定会问道：评分的标准是什么？

（1）字数

（2）句数

（3）页数

优秀的讲授肯定会说道：以上答案都不是，我看重的是内容。（看到这里，也许很多中国人，都会回忆起自己不幸的小学时光了——为了作文的页数和字数而努力拼凑）

在软件开发领域，也是同样的问题。对于软件产品的内容（价值）——如何来衡量？

软件行业的初步尝试，就是用“代码行”来度量。由代码行的数量来决定软件的价值，表面上看起来还是很符合逻辑的——代码行越多，交付的价值越高。

然而在现实中，这种方法有很多弊病：

（1）就像句子数量不能体现论文的内容；同样，代码行数也不能反应程序的内容；

（2）同样的内容，如果使用不同的开发语言，就有不同的代码行数。越是新的语言，所需的代码行越少。

（3）同样的内容，使用同样的开发语言，由不同的程序员来开发，最后的代码行数差距也是很大的。

（4）代码行数很容易“作弊”，很容易“虚假繁荣”。

为了解决上述方法的缺陷，在1970年代的后期，IBM公司的Allan J. Albrecht团队，研究并发明了“功能点法”（Function Point）。这套方法的逻辑模型，就是通过度量软件的“数据处理能力”——来度量软件的“内容”。这个数据处理能力，就是被称之为“功能”；计量的单位就是“功能点”。历经尽40年的实践，功能点方法已经成为了ISO标准。

功能点方法，与开发语言、程序员个人能力、代码行数都没有关系，它只关心“内容”本身。这种方法得出的结果，几乎不能被“作弊”。

使用这套度量方法，客户按“功能点”来买软件，就像按“斤”买苹果一样。

优秀的软件开发团队更喜欢使用这套方法来进行度量，因为得到相关的数据可以帮助团队很好地解答如下问题：

（1）每一个功能点的成本是多少？

（2）交付一个功能点，需要多少人天？

（3）交付软件的成本与速度，在整个行业中处于什么水平（即：行业对标）？

（4）如何更精确地控制项目的成本？

道德风险

第一个道德风险：团队拒绝进行软件开发的度量。

经过统计，团队拒绝的原因主要有以下：

（1）不想基于“内容”来度量；

（2）不想进行“行业对标”；

（3）不想被精确的预算所控制；

（4）担心度量不准确。

对于软件项目而言，开发团队是成本活动的执行主体，却不用为此负责。为此“买单”的是组织管理层，但是由于没有度量，就不能掌握项目的实际进展情况。

第二个道德风险：进行度量，但是方法不当。

很多组织是希望度量的——能够对软件开发的预算和成本进行量化管理，但使用了代码行法，而不是功能点法。

有些组织之所以选择了代码行法，还是出于对“度量”根深蒂固的偏见。这个风险在本质上来讲，还是软件开发团队不想担负“全责”。有些开发团队特别“推荐”代码行法，就是希望能够更方便地“操作”。

另外一方面，也反映出了——度量人才的缺乏。其实，很多组织是希望能够进行科学地度量，但是真正懂这方面的人才很匮乏——国外都匮乏，就更不要说国内了。

结论

产生道德风险的原因是什么呢？——软件开发团队的“经济利益”与“组织目标”相矛盾。就软件开发而言，“组织目标”之一，肯定是在项目预算内交付。但是，项目团队也许会受到这样或那样的影响，而不去实现此目标。

在现实中，无论是国内还是国外，软件开发超预算的情况非常多；而组织的高层管理者对此也是“百思不得其解”。项目团队负责花钱，而最后成本超支的黑锅却由管理层来背。

为了真正解决这个问题，高层管理者就应该将“经济利益”与“道德利益”的方向设为一致。

在实际操作层面，组织里应该有一个或多个“调解人”（honest brokers），向管理层去灌输和推荐科学的度量方法，也就是基于功能点的度量方法，在组织里，建立相关的制度，并不断升级。

以下是几条国外专家给出的“最佳实践”：

1、老板（Boss）要了解科学度量的基础理论，并建立起相应制度。一定要将度量的制度规范化，在组织中能够进行落地。

2、度量的团队能够直接（或有直接的通道）向老板（或老板代理人）进行汇报。他们一定不能被放置在组织的底层，否则他们的产出和建议会被管理层过滤掉。

3、软件开发团队也要接受功能点方法的培训。

4、度量项目实施成功后，度量团队一定要被及时奖励。

以上的内容，很多部分参考了美国Marymount大学Charley Tichenor教授去年8月的文章。在这里表示感谢。

西方文章如果是完全直译的话，有很多思路会觉得很奇怪。但是深刻去理解其“语义”，就会发现很多情况，东西方已经是共融的了。例如：西方人也一直在强调“一把手”（Boss）的作用。

这些年，我们的团队在国内实施了多个软件度量项目，对上述的最佳实践也是深有体会。