涌现式度量五步法：基于数据思维揭示研发组织中的隐秩序

以下是回顾总结要点：

• 研发是复杂组织，内部存在许多正负循环；

• 大多数问题都处于负循环内，相互影响、动态变化，过去的静态度量方法并不适用；

• 与寻找问题相比，数据的更大价值是驱动组织目标实现；

• 许多违背直觉和常识的“隐秩序”阻碍了组织目标的高效达成；

• 广泛地利用数据验证，能够帮助组织发现隐秩序，优化目标实现策略；

• 没有“模型银弹”，数据能力将是未来管理者的关键能力素质；

• 涌现式度量五步法。

— 1 —

问题永远存在

— 2 —

误区：确定性问题与静态指标

分析上面这个案例我们不难发现，其中存在两个误区：

• 将质量问题转化为一个确定性的问题：开发质量不佳。

• 设定了一个静态指标：代码覆盖率。

然而质量保障还涵盖了必要、充分的开发测试投入时间。在满足单元测试覆盖率指标的要求下，这两项投入时间都受到了影响，很快问题转变为测试充分性的保障和交付效率的保障；最后挤压了单元测试活动投入。

代码覆盖率指标的静态性，一是它可以被团队通过分支或时间节点轻易绕过。比如只提交Master进行检查、结项后检查，都可以让覆盖率达标，但实际上在开发过程中没有起到任何指导作用，“工程实践指标”变成了“管理考核专项指标”。二是很少持续地关注覆盖率的变化，并将背后的投入成本进行关联和分析。如果我们只看到一个静态的数字，并不知道背后究竟花了怎样的成本、有哪些关联影响来得到这个数字，那么我们就无法评估它的真实价值、团队接受度和可持续性。

当我们把这些问题、分析一一呈现给客户时，会发现问题就变得不可解决了。因为上述问题的根源，是有大量缺陷、质量不佳的团队已经掉入到了“负循环”中。

— 3 —

驱动组织级改进目标

团队的问题，往往是组织现状之下冰山一角的现象反映，因此，许多问题并不被认为是问题，或者说，负循环中的问题并不值得被解决。必须朝向组织的目标，通过优化目标实现的策略，帮助组织达到新一阶段（构建正循环），过去的许多问题就自然消失了。

涌现方法#1：将负循环问题的解决措施升级为整体解决方案。

比如，更新的技术栈包含了自动化测试框架，架构可测试性更好，修改的影响范围更小，开发测试整体的投入压力都降低了；这样一来，单元测试和自动化的集成测试就有了更大的活动空间，保障良好的实践将使团队有可能进入一个“正循环”。

但组织的整体转变挑战更大，过程中的保障活动也会变得更多。以云原生转型为例，如何保障团队正确地实现了架构原则、应用的关系与边界清晰，以及最终交付上线的质量与稳定性，过去的架构评审、代码检视与测试活动，在云原生应用数量多、依赖关系复杂、部署频率更快、自动化处理更多的情况下，很难得到充分的投入保障。

在《理念的匮乏，使研发度量全面暴露行业组织管理水平》一文中，我们已经谈到了管理度量方法是应对经营的复杂度。研发组织的复杂度更高，在交付节奏加快时，传统的人工管理与监控必然会遇到问题，数据是必要的管理抓手。

这就好比，我们骑自行车时，很少需要知道行驶速度，因为它是低速模式，速度并不是关键影响因素；但当我们驾驶汽车时，不可能不看速度表，因为它关系着道路规章、前后安全车距保持等切身利害。

— 4 —

是什么阻碍了我们？

我们分享一个组织级的改进案例：由于行业竞争加剧，客户希望向轻型组织转型，以更高的数字化程度、更快的响应驱动业务保持领先位置。

在这一目标下，IT人力大量扩张，资源利用和协同效率都极大的下降了，进入了组织级的负反馈环。

在这一级，我们需要知道，复杂系统中存在着两种秩序：第一种是很容易被我们观测到的问题、现象或常识理解，称为显秩序；另一种是我们尚不知道，但正在产生作用和影响的潜在关系，称为隐秩序。

涌现方法#2：证伪负循环中的显秩序。

在这个案例中，我们通过物理看板，首先观测到一种明显的现象：卡片大量积压在设计阶段。调研发现，设计依赖于团队中的资深成员，在规模快速扩张时，资深成员比例被大量稀释，设计工作量严重积压。

主管和QA分别从自己的角度反馈了对设计积压的看法。主管认为，因为团队中大量新人还无法马上胜任工作，现状是可接受的，但是希望顾问能够提供在这种情况下，降低缺陷率的方案。QA则认为，设计投入增加正是现在的解决方案，要是没有设计的保障，她的工作压力会更大，所以设计阶段的拥塞是正常情况。

随后我们把连续18个月的相关数据调出来对比分析，发现：

• 需求量并不大，提出时间相对集中；

• 团队仅有一位资深（工作八年以上）成员，能力配比严重不均衡；

• 缺陷数量和密度没有收敛。

进一步调研开发人员的日常活动后，我们发现存在大量的需求澄清，询问之后得知，开发人员是基于自己对需求的理解编写代码，设计方案中需求信息不完整，无法理解原始的需求。因此我们判断出：

• 缺陷数量和开发人员的实施活动相关，和设计活动的投入不相关；

• 开发人员工作依赖于需求理解，而不是设计理解。

实际参与到团队设计评审之后我们发现，在评审过程中，开发人员并不能提出问题，也不能提出更多的参考意见，说明他们并不具备评审方案的技术能力；但在实施过程中又证明了，他们具有基于需求完成编码的能力，虽然缺陷率较高，但我们可以从根本上判断，他们具备基本的实施编码能力，但尚未达到高质量水平，而现在的设计方案对他们帮助不大——因为设计知识没有有效地传递到他们的大脑中。

因此我们设计了新的工作流程，让开发人员直接接收需求，编写简单的设计方案，让设计人员进行评审；只有基于设计人员评审建议修订直到评审通过后，开发人员才能实施自己的方案。

这一措施立即取得成效，缺陷率下降40%以上，看板上的拥塞也马上解除，设计人员的工作压力解放了，QA的工作量减轻了，主管的考核（看板成熟度）也达标了。

当我们把这一成效向客户汇报时，一个负责人听完了，想了一会，说：“也就是说，我们这里的新人大多数是能力不合格的。”

另一个负责人马上说，“不对，顾问的意思是我们这里的新人能力是合格的，相反是我们的流程大大地低估了新人的能力。”

但是他又马上说，“但是在我们这里，至少要十年以上的人才能承担设计工作，八年都算还达不要能力要求的。”

但我们坚持用数据说话，并进一步说明了“Learning by Doing”思想，知识型组织最快的成长方式就是在干中学习，如果不让新人自主适应整个范围，他可能永远不能胜任高水平的工作。

最后客户终于被说服了，从时间利用率转向能力利用率，正是基于我们发现了研发团队中能力成长的隐秩序：

• 对工作完整理解的自主性决定了工作可行性和效率，而不是指导文档的细节程度；

• 对执行者自身实际行动方案的质量要求决定了执行者最终的产出质量，而不是其它人的设计或规划方案质量。

— 5 —

每个组织都有自己的数据上下文

很多公司会尝试训练一些模型来评价组织的效率，但组织的实际情况是严重依赖于组织结构、管理模式、过程、流程甚至特定的观念，这些都会产生独特数据上下文，因此，没有一款“银弹模型”来一了百了地帮助组织发现问题。

日常活动中很多步骤都由决策产生。比如要不要增加设计投入，是否引入新的自动化工具，什么时候偿还技术债务，等等。让数据成为“抓手”，最重要的是管理者建立起数据思维，在各种决定之前，利用数据来“证伪”行动是否有效。

这些数据可以通过任何方式收集，比如上面的案例中，我们是通过物理看板直观地获得，调研、访谈发现趋势和特定情况，并不依赖于大而全的数据平台；平台级建设投入，更好的节奏是积累起大量案例、规则和特定解决方案之后。

— 6 —

涌现式度量五步法

第一步是从一个具体可重现的现象出发。比如案例中我们发现的设计拥塞。对这个现象进行定性、定量的描述，并说明发现截止目前的周期。

第二步是列出直观上的因果关系。比如案例中我们可以这样描述：

• 因为团队中新人太多，设计工作量集中在资深成员上；

• 因为缺陷率较高，需要加大设计工作量投入。

第三步是对因果进行证伪。针对案例的情况，我们可以这样来证伪：

• 对新人的工时投入进行分解，找出其异常或关键投入，证明与设计方案不相关；比如我们找出大量工时投入在需求澄清上，这本应是设计方案已消除的一项活动；

• 检查设计工作投入增加后，缺陷数量是否减少；比如我们发现并没有减少，因此断定设计没有解决团队的质量痛点。

第四步是建立系统，包含参与者、行为与交互过程的描述。对研发组织而言，应该为岗位角色、职责、流程、活动。

最后对系统中非预期的行为、互动方式及沟通结构进行描述，这就是涌现的定义（杰弗里·戈尔茨坦，《涌现》（Emergence）杂志，1999）：

“在复杂系统自组织过程中产生的新颖而连贯的结构、模式和性质。”

在本案例中，实施编码过程中存在大量的需求澄清活动，从而建立了开发——需求的强沟通结构；设计评审活动中的知识传递低效性及实际指导中的偏离，形成了设计——开发的弱沟通结构；最终导致了开发低效和大量的缺陷。

在传统的管理理念里，这被称为“计划——执行”偏离，管理层会尝试去纠偏。

而我们的改进方案，则是反传统的——将这一过程新建立的强沟通结构正式化，并通过重新分配职责，使开发——设计变为强沟通结构，使问题最终得到解决。