效能度量与工程师文化

“ 效能度量是必须做的事！不接受反驳！

另外，需要先有工程师，才有工程师文化。”

本文是2021年8月4日，乔梁老师在腾讯学院组织的技术管理沙龙上的分享。它是腾讯 CI Day 分享的关于《效能提升与一致性》话题的姊妹篇。

1

从“农耕”到“工业化”
目标状态：无人值守
在腾讯CI Day上，我分享了我对效能提升的一个观点：《一致性是效能提升的必由之路（长文慎入）》。其中，我提到：
尽管我们在现代化工业社会，但「软件开发」这个事儿真的很现代化么？并不是，而是：
一大群掌握特定技能的手工业（知识工作）者面对正在运行着的生产机器（运行中的软件），每天各自生产着不同的零件，既要不断把零件安到生产机器上，还要不影响这台机器持续生产的过程。
另外，我还问了一个问题：
今天，我们就来更详细地谈一谈这个话题。2019年，我们提出：研发模式要从“农耕”到“工业化”。
什么是工业化？这个学术命题很大。简单讲，就是「让机器做机器擅长且应该做的事，让人类做人类擅长且应该做的事。」
作为“工程师”的我，都做了什么呢？全部是创造价值的事。

  1. 讨论需求，分析需求

  2. 写代码（包括自动化测试）

  3. 提交CL

  4. 收通知，修改 CR Comments

  5. 收通知，修复我的 CL 导致的流水线失败

  6. 收通知，修复金丝雀环境上的异常收通知

  7. 查看并分析我做的特性的的数据表现

好处是什么呢？全流程自动化程度高，我们的时间都去做高价值的事情，权责分明，成就感强，个人效率提升，拥有绝对的软件工程优越感。
然而，以上都是“吹牛B”，除非工业化程度极高，具备“持续交付能力”。

2

工业化需要「科学与工程」，
「科学与工程」需要「度量」
什么是工程 （Engineering）？工程是用系统的、科学的、明确的、量化的过程来制造高质量的产品。
什么是软件工程（Softeware Engineering）？是将工程的方式应用于软件开发、运营与维护，以及对这些活动的研究。

3

度量是必要的，
成本也比较高
「一个事物，只有能测量它，你才真正了解它。」
虽然“数据驱动决策”的文化有一些缺点，但总的来说，依赖数据往往使大多数决策相对客观，而不是主观，这通常是件好事。
度量本身成本就比较高。因为需要人力度量我们的工作过程，并分析结果，再将结果发布给相关部门。度量过程本身可能就很繁锁，可能会减缓工程组织的其他工作。
因此，度量前，你需要回答以下问题：

  • 你想度量什么？

  • 为什么？期待什么样的结果？

  • 有了结果，会采取什么样的行动？

4

什么情况下不应该度量？
这种跟踪过程可能会改变工程师的行为，从而掩盖了潜在问题。
那么，是不是就不应该度量了呢？当然不是。
只有在以下情况下，就不要做度量了：

  1. 你无力变更过程或工具度量的结果

  2. 不久后就会因为其他因素而无效结果

  3. 只是作为虚荣指标，以支持你无论如何都要做的事情

  4. 仅有的度量指标不够精确，不足以度量问题，而且可能会与其他因素混淆

5

效能在企业之外
效率在企业之内
彼得·德鲁克说：
效率是“把事情做对”，
效能是“做对的事情”。
做对的事情，比把事情做对更为重要。
效率和效能不应偏废。
我们当然希望同时提高效率和效能，
但在效率与效能无法兼得时，
我们首先应着眼于效能，然后再设法提高效率。
在双环理论中，价值探索环存在高度的不确定性，其结果只能由企业外部来评判。所以，现在我们说的“效能”其实更多指的是“效率”。

所以，改进效果应该更多聚焦于团队外部的结果性指标。

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

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

在外部改进条件不具备的情况下（特别是改进初期），

应该先以「CLCT」做为改进的北极星指标。

6

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

7

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

7

工程师文化，
先有工程师，后有文化

以下为本次分享的后半部分PPT。

赞 (0)

相关推荐