| 2021-08-20
对于一个软件产品组织来说，软件工程度量是必须做的事！
虽然「数据驱动决策」的文化有一些缺点，但总的来说，依赖数据往往使大多数决策相对客观，而不是主观臆测，这在大多数情况下，都是一件好事。
本文是《一致性，是研发效能提升的必经之路！》的姊妹篇。
从「农耕」到「工业化」
在腾讯 CI Day 上，我提到我们这个行业的本质，那就是：
一大群掌握特定技能的手工业（知识工作）者面对正在运行着的生产机器（运行中的软件），每天各自生产着不同的零件，既要不断把零件安到生产机器上，还要不影响这台机器持续生产的过程。
我们就是需要大规模协作的手工业者，也就是「工匠」，而「工业化」的目标是让软件生产流程尽可能做到「无人操作，无人值守」。
这里的区别就在于：你是「码农」？还是「工程师」？
我们就来更详细地谈一谈这个话题。2019年，我们提出：研发模式要从“农耕”到“工业化”。
什么是工业化？
这个学术命题很大。简单讲，就是「让机器做机器擅长且应该做的事，让人类做人类擅长且应该做的事。」
实现「工业化」以后，作为一名「工程师」，我都做了什么呢？
- 讨论需求，分析需求
- 写代码（包括自动化测试）
- 提交CL
- 收通知，修改 CR Comments
- 收通知，修复我的 CL 导致的流水线失败
- 收通知，修复金丝雀环境上的异常收通知
- 查看并分析我做的特性的的数据表现
这么做，好处是什么呢？
- 全流程自动化程度高，
- 我们的时间都去做高价值的事情
- 权责分明，成就感强
- 个人效率提升，拥有绝对的软件工程优越感。
然而，以上都是「吹牛」，除非工业化程度极高，具备「持续交付能力」。
工业化需要「科学与工程」，「科学与工程」需要「度量」
什么是工程（Engineering）？
工程是用系统的、科学的、明确的、量化的过程来制造高质量的产品。
什么是软件工程（Softeware Engineering）？
它是将工程的方式应用于软件开发、运营与维护，以及对这些活动的研究。
度量是必要的，然而成本也比较高
「一个事物，只有能测量它，你才真正了解它。」
虽然「数据驱动决策」的文化有一些缺点，但总的来说，依赖数据往往使大多数决策相对客观，而不是主观，这通常是件好事。
度量本身成本就比较高。因为需要人力度量我们的工作过程，并分析结果，再将结果发布给相关部门。度量过程本身可能就很繁锁，可能会减缓工程组织的其他工作。
因此，在实施度量前，你需要回答以下问题：
- 你想度量什么？
- 为什么？期待什么样的结果？
- 有了结果，会采取什么样的行动？
什么情况下不应该度量？
这种跟踪过程可能会改变工程师的行为，从而掩盖了潜在问题。
那么，是不是就不应该度量了呢？当然不是。
只有在以下情况下，就不要做度量了：
- 你无力变更过程或工具度量的结果
- 不久后就会因为其他因素而无效结果
- 只是作为虚荣指标，以支持你无论如何都要做的事情
- 仅有的度量指标不够精确，不足以度量问题，而且可能会与其他因素混淆
效能在企业之外，效率在企业之内
彼得·德鲁克说：
效率是“把事情做对”，
效能是“做对的事情”。
做对的事情，比把事情做对更为重要。
效率和效能不应偏废。
我们当然希望同时提高效率和效能，
但在效率与效能无法兼得时，
我们首先应着眼于效能，然后再设法提高效率。
在双环理论中，价值探索环存在高度的不确定性，而其结果只能由企业外部来评判。
所以，现在我们说的“效能”其实更多指的是“效率”。
对于改进效果的衡量，应该尽可能从外部视角来看，更多地聚焦于「团队外部的结果性指标」。
对于日常改进的指导，则应更多关注引领性的过程指标，如下图所示：
并且，要有全局思维，关注这些过程指标之间的内在关联，如下图所示：
在 IT 组织改进条件不具备的情况下（特别是改进初期），可以先以「CLCT」做为改进的北极星指标。
尽管这很可能也是一种局部优化，但它可以改善 IT 组织与企业中（或外）其他团队的协作关系，以争取实施深化改进的机会。
什么样的度量理念，才不会走偏？
任何人的改变，都会经历下面的七种状态
