工业化与效能度量？如何做？

对于一个软件产品组织来说，软件工程度量是必须做的事！

虽然「数据驱动决策」的文化有一些缺点，但总的来说，依赖数据往往使大多数决策相对客观，而不是主观臆测，这在大多数情况下，都是一件好事。

本文是《一致性，是研发效能提升的必经之路！》的姊妹篇。

从「农耕」到「工业化」

在腾讯 CI Day 上，我提到我们这个行业的本质，那就是：

一大群掌握特定技能的手工业（知识工作）者面对正在运行着的生产机器（运行中的软件），每天各自生产着不同的零件，既要不断把零件安到生产机器上，还要不影响这台机器持续生产的过程。

我们就是需要大规模协作的手工业者，也就是「工匠」，而「工业化」的目标是让软件生产流程尽可能做到「无人操作，无人值守」。

这里的区别就在于：你是「码农」？还是「工程师」？

我们就来更详细地谈一谈这个话题。2019年，我们提出：研发模式要从“农耕”到“工业化”。

什么是工业化？

这个学术命题很大。简单讲，就是「让机器做机器擅长且应该做的事，让人类做人类擅长且应该做的事。」

实现「工业化」以后，作为一名「工程师」，我都做了什么呢？

1. 讨论需求，分析需求
2. 写代码（包括自动化测试）
3. 收通知，修改 CR Comments
4. 收通知，修复我的 CL 导致的流水线失败
5. 收通知，修复金丝雀环境上的异常收通知
6. 查看并分析我做的特性的的数据表现

这么做，好处是什么呢？

• 全流程自动化程度高，
• 我们的时间都去做高价值的事情
• 权责分明，成就感强
• 个人效率提升，拥有绝对的软件工程优越感。

然而，以上都是「吹牛」，除非工业化程度极高，具备「持续交付能力」。

工业化需要「科学与工程」，「科学与工程」需要「度量」

什么是工程（Engineering）？

工程是用系统的、科学的、明确的、量化的过程来制造高质量的产品。

什么是软件工程（Softeware Engineering）？

它是将工程的方式应用于软件开发、运营与维护，以及对这些活动的研究。

度量是必要的，然而成本也比较高

「一个事物，只有能测量它，你才真正了解它。」

虽然「数据驱动决策」的文化有一些缺点，但总的来说，依赖数据往往使大多数决策相对客观，而不是主观，这通常是件好事。

度量本身成本就比较高。因为需要人力度量我们的工作过程，并分析结果，再将结果发布给相关部门。度量过程本身可能就很繁锁，可能会减缓工程组织的其他工作。

因此，在实施度量前，你需要回答以下问题：

• 你想度量什么？
• 为什么？期待什么样的结果？
• 有了结果，会采取什么样的行动？

什么情况下不应该度量？

这种跟踪过程可能会改变工程师的行为，从而掩盖了潜在问题。

那么，是不是就不应该度量了呢？当然不是。

只有在以下情况下，就不要做度量了：

• 你无力变更过程或工具度量的结果
• 不久后就会因为其他因素而无效结果
• 只是作为虚荣指标，以支持你无论如何都要做的事情
• 仅有的度量指标不够精确，不足以度量问题，而且可能会与其他因素混淆

效能在企业之外，效率在企业之内

彼得·德鲁克说：

效率是“把事情做对”，
效能是“做对的事情”。
做对的事情，比把事情做对更为重要。
效率和效能不应偏废。
我们当然希望同时提高效率和效能，
但在效率与效能无法兼得时，
我们首先应着眼于效能，然后再设法提高效率。

在双环理论中，价值探索环存在高度的不确定性，而其结果只能由企业外部来评判。

所以，现在我们说的“效能”其实更多指的是“效率”。

对于改进效果的衡量，应该尽可能从外部视角来看，更多地聚焦于「团队外部的结果性指标」。

对于日常改进的指导，则应更多关注引领性的过程指标，如下图所示：

并且，要有全局思维，关注这些过程指标之间的内在关联，如下图所示：

在 IT 组织改进条件不具备的情况下（特别是改进初期），可以先以「CLCT」做为改进的北极星指标。

尽管这很可能也是一种局部优化，但它可以改善 IT 组织与企业中（或外）其他团队的协作关系，以争取实施深化改进的机会。

什么样的度量理念，才不会走偏？

任何人的改变，都会经历下面的七种状态