C++ 之父说过：You cant´t measure software efficiency——软件效能无法度量

管理学之父又说过：You can´t manage what you can´t measure——你无法管理无法度量的东西

两个大佬说的是不是有冲突？没有。

为啥？两个原因：

1. 软件开发是一系列在长期最优解和短期最优解动态权衡的过程，且不断变化的，局部指标反应不了全面，甚至会出现严重的价值误判。
2. 霍桑效应，被观察者会刻意改变行为。

指标导致价值误判问题，举“千行 bug 缺陷”例子，这个指标的目的是让 bug 更少，但 bug 更少代表代码质量好？能代表效能高？一个专家写代码，可能会从可维护性角度，架构角度，做各种优化，各种激进的代码改善。但某次改善，可能引发很多 bug（经过大型底层重构的老司机都能感受到），而另外一个新手，战战兢兢，如履薄冰，每次需求都在 shi 山代码上堆积新的 shi 山，但在 bug 数量上可以控制很少（这就是 shi 山代码不要动的来源）。另外一个高级工程师用精炼的代码写完大量需求，而另外一个用大量冗余的代码写某个需求，在bug 数量相等的情况下。这两种工程师千行bug 指标完全不一样。任何指标数据都是可以通过“代码层面的无意/恶意行为”被影响。所以，c++之父说得没错，指标不能度量软件的质量，指标是只是局部信息。如果有了指标 kip，工程师就会往这个方向靠，而忽视了真正的改进。

霍桑效应，简单说，当你知道自己被观察，就会做出反应。开发，测试，产品等都会潜意识里刻意追求数据更好看的数据，这也是 kpi 的通病。但软件研发采用 kpi 非常危险，上面说过，指标和软件质量的关系非常脆弱，最后导致形式化，没有人敢提出问题，改进问题。

那没有办法度量软件，怎么管理呢

软件质量不同于产品销量，后者通过直观数据可以表达，而软件介于工业品和艺术品之间，外在的质量通过真正的用户体验和反馈获得，比如用户吐槽、生产问题等；而内在的质量依赖同行审查每行代码，比如可维护性、健壮性、优雅性等。

你的代码写得好不好，架构稳不稳，够不够 shi 山，有没有影响团队开发效率，拉出来让同行（最好比写的人更权威）看看就知道了。

这也是 Linux 高明之处，全世界的开发者都在盯着你的代码。

回到软件研发效能指标和 kpi 绑定问题，如果谁这样做，我敢说要么不懂代码，要么只是懂一点点。

那我们总是要管理软件的吧？所以回到度量本身，指标可以是辅助工具之一，管理者最好是让大家不知道，最大程度降低被观察的效应，背后再根据实际情况去分析和改进。我们度量的目的是什么？是维持指标吗，no，是改进软件。

比如生产缺陷数，目的是了解指标背后的数据，并降低它，这次生产缺陷是因为大量需求集中上线导致？是代码内部某个无关大雅小失误？ 还是长期积累的技术债引起的？这些都要具体问题具体分析、才能改进。 比如缺陷平均解决时间，我们的目的是让开发尽早解决问题，不要拖延，那缺陷解决时间过长，是因为开发需求太多？没有时间改 bug ？还是代码可维护性差，导致每个小缺陷解决起来棘手? 每个指标代表一种价值方向，要深入现场，分析每个指标背后的数据才能找到原因。这是现代软件管理的方式之一，但不能强行绑定 kpi。否则人人都在维护指标数据，而不敢改进代码，忽视长期利益。

另外，有些以软件技术主导的公司，比如 Google 不仅排斥 kpi，连宽松 ork 都在改革了（据说更重视软件工程师的内外影响力？～这种方式利弊不表态）。想简单的从局部数据去发现工程师之间软件研发效能的差别，真的很难，这是管理者不懂技术，想要走捷径的方式。

不过我一直赞同用黑客界的模式去思考软件的质量，同行/专家评审是最准确的。在有些公司，晋升不仅仅要答辩，还有专家集中评审你写的代码，打分，作为间接的参考。我觉得团队内部的研发效能度量也一样，专家团背后观测（前提不影响团队），深入软件内部，才能准确评估团队效能。但没有公司这样做，因为成本太高。另外内部专家观测，在客观性、还有权威性也不容易得到认同。

度量是被动的，自上而下的。而团队最重要的是内部信任，最好的管理是没有管理，自我驱动管理（当然这很难）。所以，指标度量实在是一种无奈、且低成本的下下策管理手段而已。

另外突然想多聊点《大教堂与集市》里面作者讲过的，有些公司为了提高代码质量，就让它开源，比如火狐浏览器，是最早开源的大型 c++ 软件。当时团队的目的之一就是让其他开发者监督这些代码，毕竟，shi 山代码会降低火狐工程师的社区信誉。其他一些知名软件 vscode、 Linux 同理。这么多人盯着你的研发流程，代码提交记录，不想好好提高质量都难，你敢说自己代码写得好，流程高效规范，那要接收来自社区同行 pk 讨论。但这种做法，只有在项目非常知名的情况下，才有较大收益，很小众的软件，大家都不 care，同行审核的价值也更低。

以上仅限于软件研发过程的度量讨论，而产品业务价值的判断不在同一个维度。