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

乔梁 | 2021-08-20

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

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

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

从「农耕」到「工业化」

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

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

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

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

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

什么是工业化?

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

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

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

这么做,好处是什么呢?

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

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

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

什么是工程(Engineering)?

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

什么是软件工程(Softeware Engineering)?

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

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

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

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

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

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

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

什么情况下不应该度量?

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

那么,是不是就不应该度量了呢?当然不是。

只有在以下情况下,就不要做度量了:

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

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

彼得·德鲁克说:

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

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

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

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

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

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

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

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

什么样的度量理念,才不会走偏?

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