1982年，王小波在美国留学，主业是数学，课余就给导师打工，写程序。

他在《革命时代的爱情》中对这段经历做了精彩的描述：

第一次从系里领来了编软件的活儿时，我想道：好！总算有了一个我施展才华的机会了！

虽然那是个大型软件，好几个人合编，但是我想这样更好，可以显出我比别人强。

越是这样想，就越是心绪纷乱，一行源码也写不出来。

所以我就对我老婆说，你出门时，把我锁在屋子里。我就是这样一个变态分子，但是我老婆一点没觉察出来。

锁在房子里时，精力能够集中。所以我编的第一批软件极有诗意，李后主有词云：红豆啄残鹦鹉粒。我的软件就曲折和弹性而言，达到了此句的境界。

后主又有残句云：细雨流湿光。我的软件就有这么简约，别人编十行，我只用一行。

等到交活时，教授看了吃一惊：这么短！能跑（run）吗？

我说你试试嘛。试完了他和我握手道：谢谢！

但是到了开支时，我的钱比别人都少。原来是按行算钱，真把我气死了。

等到交第二批软件时，我就吃棉花屙线屎。古诗云：一个和尚独自归，关门闭户掩柴扉。

我的第二批软件到了这种境界。简言之，别人编一行，我就编了二十行。

等到交活时，教授根本不问能不能run，只说：你这是捣蛋！就打回来让我改短。

资本主义就是这么虚伪。

王小波难题

王小波当年遇到的难题，表面上是：如何给程序员“发钱”？

实质上是：如何评定程序员的绩效。

这个问题很大，从当年到现在，中外组织发明了和演进了很多解决方案：KPI、PBC、OKR……，可谓：引无数英雄竞折腰。

1970年代之前，西方工程界普遍参考了“文字工作者”的经验——作家与记者是按照“字数”来计算产量的；

所以，程序员可以按照代码行来计算产出规模，然后根据规模“发钱”。

但是，这种办法无意地混淆两个重要的概念：工作量与规模。

1975年，实践并思考了多年的Brooks发表了著名的《人月神话》，这篇文章反思：用“人月”来度量软件“规模”是“神话”。不过在这篇著名的文章里，他其实也没有给出明确的解决方案。

也就同一个时期，他的同事Allan Albrecht先生正在解决这个“神话”，最后形成即是：“功能点分析”（FPA）方法。

什么是功能点？

功能点分析的“第一性原理”是：

对用户有价值的是软件的功能，这个才是“规模”；而不是过程中的消耗与成本（代码行、工作量）。

功能点分析是站在“用户视角”（而不是开发者视角），将软件的功能需求分解为一系列最基础的功能单元（BFC，basic function component）。

这些基本功能单元，主要分为两大类、五小类。每类功能组件都有逻辑严谨的定义，是最小的、不能再细分的“软件原子”。

数据+行为，是不是有点面向对象的感觉？

我拿在用户在手机上点外卖举个例子，外卖app的BFC如下表：

从这个例子可以看出，“功能点”其实是每类BFC大小的“计量单位”。

上图的例子，就是在我国最常使用的“估算功能点”方法，约定了1个“ILF(内部逻辑文件)”值10个功能点，1个“EI（外部输入）”值4个功能点。

可能有同学马上就想到：同样是ILF，有的业务对象包含了50多个“字段”，有的只有5-6个。难道大小一样，都值10个功能点吗？

答案：在“估算功能点”方法中，就是一样大小的。BFC的固定功能点数值，是经过统计分析、并实证校验得出的。在统计学上来看，50个字段的ILF与5个字段的，其规模大小是没有差别的。

功能点有什么用？

软件度量师只要先分析某个软件包含多少个BFC，然后将他们的功能点数值汇总加起来，就能够数字化这个软件的规模。

就像是在乐高世界，软件就是由五类乐高积木搭成的，每一类乐高积木的重量（质量）都知道；我们只要统计出某个软件各类积木的数量，就能够计算出其总重量。

在统计学上，如此度量出的软件“规模”与开发实际投入的“工作量”之间，有较强的“相关性”。

（国外的文献显示，两者之间的R^2=0.89，spearman相关系数为0.85，对应的P值都低于0.0001。）

在国内也有很多的实践，证明规模与工作量之间的相关性普遍也很高。

由于定义逻辑严谨，且有这些“数字化”证据，功能点分析的方法发布后，很快就被ISO/IEEE认定为国际标准。在我国，基于功能点方法的“软件研发成本度量规范”，也先后成为了工信部标准（2013年）与国家标准（2018年）。

目前，在国内政府、金融、电信等领域，软件的客户购买（或租用）软件，很多都是基于功能点来计算软件规模，在以此计算工作量、合同（预算、结算）金额。

在个体绩效管理层面，很多工程师也承认：在众多KPI中，只有功能点是比较客观的。

当年，如果王小波也知道了这个方法，就可以给他的导师“上一课”了。

我的公司怎么没用功能点呢？

不过可能大家有疑问了：这么好的东西，为什么在互联网公司没用起来呢？为什么大家都习惯用人天来估算工作量呢？

我想主要的原因还是功能点分析法略显复杂，把需求分解成基本功能单元本身就有难度，需要经过一定的训练才可以。

“人天”就简单多了，任何人，拍拍脑袋，想想其中代码实现的难度，很快就能估算出来。

互联网公司的需求变化也快，还没等你实现完，估计又变了，用功能点分析法分析来分析去，累死人。

再说了，互联网公司也擅长工期倒逼法：别给我扯什么方法，下个月必须上线！

这时候，什么方法都不管用了......

（完）

点击下方图片，查看更多精彩