灵魂拷问四：没有度量就没有改进，这是真的吗？
管理学之父彼得·德鲁克说过：“你如果无法度量它，就无法管理它。” ，或者说，你想管理什么就度量什么，想管理效能就度量效能，想管理质量就度量质量。度量可以帮助我们获得相对准确、客观的信息，没有度量，就缺乏对某个事情的客观认知，就不知自己团队所处的准确位置，不知道自己有什么弱项、弱点，所以就无法克服这些弱项、弱点，也就没有改进。这些都说明度量的重要性，而且表面上看起来，没有度量就没有改进。
“没有度量就没有改进” ，就一定成立吗？
虽然在传统制造业总能成立，但在软件行业不一定成立。
软件行业不能搞 “计件工资”，软件的规模估算也一直是一个难题，虽然有一系列的估算方法（如功能点方法IFPUG、对象点方法等），甚至都有国家标准了，但绝大多数企业都不用这些方法或标准。
“没有度量就没有改进”，换句话说，就是“想改进就一定要度量”，但事实是，改进可以不用度量，可以通过其它途径来改进。例如：
吃一堑长一智，出现问题，做根因分析（root cause analysis），吸取教训，也能进步。在敏捷Scrum中，就特别强调反思，每个sprint之后都有Retrospective，就是为了帮助团队改进，在下一个sprint做得更好；
建立规范，包括需求规范、设计规范和代码规范，再辅以相应的评审，无论是人的评审还是借助工具进行评审，发现问题，解决问题，也可以做到不断改进；
优化系统架构，也能提高开发效率和提高系统的质量，相当于帮助团队获得改进；
团队或个人的能力提升，如对团队进行培训、开展小组读书活动、招聘越来越优秀的人才；
… …
那么有度量就一定改进吗？
也不一定。
度量什么就获得什么，只是获得你想要的数据。
有一个十分有趣的 “古德哈特定律（Goodhart's law）”，即 “当决策者试图以一个事物的客观度量指标作为指针来施行政策时，这一指标就再也不能有效度量事物了”，这意味着你度量什么指标，下面的人就会给你造出你想要的、漂亮的指标数据；你如果只想通过KPI来考核绩效、只通过KPI指标来制定策略、引导大家改进时，你就会得到符合这些KPI指标的结果，但实际的结果却没有KPI相关数据那么好，真正的改进是非常有限的。
你想要什么就度量什么，但最终不一定得到你想要的东西。
假如你想提高开发的效率，然后就用“代码行数/人日”来衡量开发效率，那么除了会得到一堆臃肿、难以维护的代码之外，没有得到任何改进。
你想提高开发的效率，如果觉得代码行度量不靠谱，改为用“功能点”或“用户故事点”来度量，这样的度量也会带来团队玩数字游戏，也不能真正提升团队的开发产出。
你想提升开发的产出，觉得上述度量都不行，就很自然会采用工作时长作为度量指标，总觉得员工的工作时间越长，员工就会做更多的事情、完成更多的工作任务，这就是现在人们常见的996状态，之前我们讨论过（研发团队的忙碌能代表高效率吗？），其实这种情况下，这种状态下产出并没有提升，甚至会下降。你度量工作时间，的确会得到更多的工作时间，但不一定产出更多的价值。
你想提升测试效率，于是度量自动化测试的比重，的确可以提高自动化测试用例所占的比重，但往往不意味着自动化测试水平会有提升，更不意味着测试效率的提升。
这也就是为什么，今天在软件行业 KPI犹如过街老鼠人人喊打，人们开始关注、推荐OKR。人们更应该关注目标的达成，而不是具体的指标数据。你不能盲目地让数据来指挥实践，不能混淆目标与手段之间的关系，KPI或度量指标仅仅是手段，而且是辅助手段，更应该走进软件研发的具体实施过程中，仔细调研，以调研的事实为前提，做出决策或制定改进计划，进而实施、驱动实践。
其实度量这项工作，本身并不增加软件研发的价值，即不给客户带去直接的价值，所以，从敏捷、精益开发观点看，任何不增加价值的流程和任务都是浪费。
如果度量不能自动采集数据而耗费团队太多精力、如果度量不能显著降低缺陷所带来的浪费、如果度量不能显著提升研发效率，度量其实就是一种浪费，更谈不上改进。
所以度量只是辅助手段，更不能让度量成为目标。
《代码大全》一书作者 Steve McConnell 指出 “不要指望任何单个纬度的生产力指标能够呈现个体生产效率的完整景象”，简单的度量数据并不能让我们直接做出结论，更多时候可以向我们揭示有价值的问题。即使度量是辅助手段，还要看你会不会度量？
度量指标是否设置合理？ 度量是否具有体系？ 有没有相应的措施辅助度量体系的实施？
如果需要提升开发的效率，可以考虑采用度量作为辅助的手段，但不要粗暴、简单地处理这件事，而是需要精心设计能够度量开发效率的指标。没有单一的指标可以衡量研发效率，用上面提到的 “代码行数/人日”、“功能点数/人日”、“故事点数/人日” 、“迭代速率（一个迭代中完成的平均用户故事点数）” 等这样单一指标不行，还需要考虑交付周期、前置时间、代码合并频率、构建频率、部署频率、平均修复时间(MTTR)和变更失败率等。而且仅仅用多个效能指标也不行，还需要采用交付质量指标（如Bug#/KLOC、上线缺陷数等）来制约，也就是说，在保证质量情况下效率越高越好，效率提升是有前提的。
而且，上述那些关键指标（即故事点数/人日、交付周期、构建频率和部署频率等）的结果数据可以告诉我们交付效能的整体状态和变化趋势，即可以告诉我们效能有没有得到改善。但万一效能没有改进甚至还下降了，这时我们就想了解：究竟问题出在哪里？哪些地方需要改进？但上面这样的指标其实对改进没有直接对帮助，我们需要设计更具体的指标来帮助我们获取其它数据，找到问题产生的原因。这时需要其它一些度量的指标，如平均构建时间、单元测试覆盖率、代码圈复杂度、缺陷密度、平均缺陷修复时间等。
度量这件事，其实不容易，需要知道自己真正想要什么，明确界定手段和目标，为什么度量？度量会带来什么的负面作用？例如，不应对那些看似繁忙但只产出了一大堆无效工作输出的团队或人员进行奖励，而是引导到那些对促进组织达成目标有实际帮助的工作上去。由于指标的作用在于发现潜藏于表面之下的问题，事先不应当提前规定只能从哪一类数据作为关联查询的起点，或者必须以哪些维度数据进行统计分析，而是需要在获得数据后做进一步探索、调研，变化不同的数据组合分析，寻求真正能揭示问题本质的数据组合。所以，做好度量工作，一般要遵守下列几个原则：
回归第一性原理，度量是为目标服务的，搞清楚软件研发（效能/质量）管理的核心目标和有效性原理——即如何尽可能促进团队交付更多的价值、如何尽可能地促进团队协作、如何激发员工的内驱力等，进而明确度量的目标和价值是什么。
遵循“目标-度量-指标-行动”的规则，指标最终服务于目标的达成，必须根据指标给出 “该怎么做”的辅助建议，即为了达成目标，需要进行哪些优秀实践、具体要开展哪些活动或做哪些事情等；
系统性的思考，聚焦在全局指标而不是局部指标，通过精心设计以构建较完整的指标体系，包括指标间存在合理的制衡关系；
合适数量的指标。单一指标或太少指标一定有问题，过多的指标会对团队造成不必要的管理成本，也容易让团队失去关注焦点；
聚焦在结果产出，包括效能、交付质量等，但为了找出问题原因，也需要阶段性结果。