这是 2020 年滴滴 EP 研发效能的分享，出自滴滴技术公众号，现在看依然高价值。周凡，我在滴滴 EP 的老板，前谷歌工程资深工程师，前滴滴研发工具负责人。多开开天眼多看看别人做的，站在巨人的肩膀上事半功倍。现在都已经什么时代了，不要再闭门造车了。

原文标题《从铸剑到御剑：滴滴工程效能平台建设之路》

滴滴工程效能的演进

在大家的印象里，工程效能就是基于工具本身的工程项目建设，简单地说就是为研发团队铸剑——提供所需的各类生产力工具。相信大家对下面这张图中的企业都非常熟悉，国内及国际高科技头部公司在 R&D 方面的投入占比通常能达到公司营收的 10%～20%，这足以说明研发本身对于科技企业的重要性。另一方面，随着公司产品多元化，产研规模不断扩大，工程效能就成为了决定研发能力的关键因素之一。

image.png

滴滴工程效能团队成立于 2015 年，滴滴的工程效能建设先后经历了以下几个阶段：

• 第一阶段：

• 公司处于早期，研发工具团队采用一些外采和开源的方案，实现基础功能，满足业务研发的需要。

• 第二阶段：

• 随着公司人力的增多、业务的复杂，我们尝试在一些特定领域做自研工具，以弥补开源工具的不足，主要是解决一些当时的特定问题。

• 第三阶段：

• 开始做平台化，当然这些平台都是针对特定的领域，像项目管理平台、代码管理平台、持续交付平台、效果验证平台等。

  
  image.png

现阶段，工程效能团队主要聚焦在一站式研发平台的建设，完善研发的整体体验和效率的同时，也有效的形成了研发与业务的功能联通和数据关联 。对于这一点我自己感受比较深，研发状况的好与不好，不仅要让研发同学们能看到，同样要使得让业务同学们有感知。这里解释一下为什么要去做工程效能数据建设。

*2.*****滴滴为什么要做工程效能数据

这里解释一下为什么要去做工程效能数据建设。

▍看清研发成本

在研发过程中，企业的人、财、物到底如何使用，应该是清晰可见的。滴滴目前不到 2 万的员工里有大几千的研发人员，研发在成本上确实是一个大头，业务需要看清楚人财物是怎么分配的。

▍看清研发水平

业务本身在多元化，需求越来越多、产品也越来越多，此外还有一些国际化的市场场景。我们需要在工程效能的维度上让大家清楚产研到底做的怎么样。

另外，我们可以通过分析数据化的效能状况来提高研发水平，辅助研发决策。——届时，我们不但能为研发团队铸剑，我们还能指导研发团队提高其御剑术。

*3.*****工程效能数据建设的总体思路

结合着滴滴的研发现状，我们的数据建设主要从研发工具层面和数据产品两个方面去努力。

▍工具层面

• 一是打通研发阶段和非研发阶段的工具，形成可以延伸到业务视角的全流程工具规划。我们希望需求侧、项目侧和一些偏产品侧的同事能直接感知到研发整体进度及关键的状态进展。

• 二是研发工具链本身形成标准化的一站式工具体验。通过这种方式，我们可以把研发最佳研发实践低成本的从一个业务线推广到其他更多的业务线，另外，一站式研发工具也使得工程效能数据本身更加统一和规范。

▍数据产品

滴滴的工程效能平台共分三层：第一层是数据层，第二层是计算层，第三层是应用层

• 数据层

• 主要目标是获得跟工程效能相关的数据，核心是数据收集的自动化和准确性。如果通过人工去收集原始数据，由于大家对数据的解读并不统一，会产生更大的歧义。因此必须通过自动化工具实现，最终形成准确和统一的数据。

• 计算层

• 计算层就是生成工程效能的指标。我们根据工程效能的关注点，通过建模加工处理数据，然后展示这些特征即可。

• 应用层

• 这里考虑的是如何把计算层的指标展示出来。简单的一、两个指标并不能说明问题，我们希望数据的呈现不仅要具备工程效能专家视角，它同样要满足不同角色，不同业务特征的个性化视角。

*4.*****工程效能体系的挑战与对策

滴滴的工程效能数据建设在这三层上的挑战类似于金字塔，数据层的挑战是最大的。这主要源于我们工具链的演进过程，首先，原有的工具比较聚焦功能而非数据体现，数据能力有所确实；其次当前的工具比较聚焦特定的领域而非整体，数据缺乏一致的标准和关联思路；最后，不同业务线在使用中也没有形成统一的规范，数据的准确性不足。因此底层的数据治理工作非常繁杂，是最难的一层，计算层和应用层也有各自的难点，但相比数据层还是相对容易一些。下面分别讲一下这三层的应对思路。

▍数据层的挑战与应对

数据层的问题上面已经简单的介绍了，归纳一下，首先是数据不完整；其次数据标准不统一；最后，数据不具备明确的关联信息。

相应的，我们按照场景明确了数据要求，而非工具现有的数据作为标准。以我们的代码评审工具为例，它的数据应该能直接反映代码审计领域的问题，而非体现工具实现的特征。基于这个标准，我们对数据结构进行了梳理和标准化，最后进行相应的进行工具本身数据能力的改造，补齐欠缺的部分。

此外，数据关联还存在问题，由于用户习惯的已经形成，我们没有选取在各个能力工具层面分别进行改造，而是通过一站式工具平台来统一解决，这个在计算层部分有详细描述

▍计算层的挑战与应对

计算层首要的难点是数据解读的成本高，很多工具的数据通常需要我们找到具体负责该工具研发的同学去问，有些数据经历过多次版本更迭之后，其含义变得模糊。其次是上面说到的数据之间缺乏关联性，在跨工具的场景这个问题尤为突出。最后是缺少指标体系，这个对于我们从海量的无序数据中梳理出有意义的指标至关重要。

为此我们从后往前，从指标体系的梳理入手，以团队（人）的视角为核心，通过统一工程效能的解读方式来降低数据的解读成本。同时，依据统一的指标体系，发现现有数据中关键的主体关联及属性缺失，通过一站式平台的能力逐步把这部分弥补上。

image.png

这张图比较直观地呈现了数据梳理和关联的过程。我们把所有工具的数据表都汇集到工程效能的数仓之后，通过这个平台在各个工具之间做索引和关联，最终形成具备整体解读效果的指标体系。当然，这个过程是一步步沉淀出来的，在这个过程中计算某个效能指标的最合理路径逐渐清晰，工程效能的主体（通常是部门或产品）数据和关联关系也更加丰富和详细。

▍应用层的挑战与对策

应用层的主要问题是展示，我们的平台需要找到用户最关心的效能指标数据并将它友好地展示出来。用户的使用目标不一致、解读标准也不一致，标准怎么定、逻辑怎么算，非常考验平台的能力。

首先，我们先完善指标本身，平台不能只反映阶段性的问题要反映全貌。第二，指标的呈现有不同角色的视角。第三，指标本身可扩展性。最后，工程效能数据能支撑或佐证大多数用户的主观认知，这也是指标体系迭代的方向。

*5.*****工程效能的数据体系建设

国内的国内做工程效能的主要分以下两种思路：

• 一类注重交付效率、交付质量和交付能力等业务支撑的指标；

• 一类更关注持续发布能力、需求响应、交付吞吐率、交付过程质量和交付质量等非常关键的头部指标。这是国内企业做工程效能体系的现状，下面介绍滴滴的工程指标是怎么做的。

image.png

工程效能指标结构

滴滴的工程效能核心指标分为两类：一类是偏交付指标，是给业务或者给非工程团队的参考；一类是特征指标，体现的是工具本身的状态，在特征指标方面我们比较关注有效行为和可持续性。另外还有研发过程指标，我们会比较关注研发过程的需求响应、研发过程质量、持续集成能力这几个比较突出的维度。这些效能指标，从完备性、多视角、可扩展性，以及支持主观判断等方面做到了全覆盖。

回到数据应用的视角，当我们看工程效能的时候，我们的主视角到底是什么？从一个比较自洽逻辑来讲其实有三点：第一，看主体，主体就是团队或者人；第二，看客体，就是看产品，看项目和需求；第三，看使用工具的过程。

以滴滴现在状况，我们首先选择了组织管理的视角，因此更多是从主体视角看问题。因此我们工程效能平台选择主体视角作为第一视角，当然不同公司有不一样的视角，这取决于场景。滴滴选择了主体视角，主体视角关注两大类指标：一类是团队效能，一类是团队产出。团队效能主要看团队的工程能力和水平，通常是定期的、变化频次比较低且容易量化的指标。团队产出更关注输出物、工作量，以及进度。团队产出的变化频次比较高、也会经常被查看，这方面主要呈现的都是能反映事实和状态的原始数据。

当前滴滴的工程效能数据平台还处于初级阶段。效能指标数据越来越统一和标准化，同时也支持数据的下钻；产出指标主要展示效率、质量、成本这三个维度的原始数据。另外有的团队想看一些更细致和个性化的指标，我们基于各个工具里特别细粒度的数据、打上归属标签，让用户能快速查找和订阅、放在自己的看板上，满足这部分个性化的需求。通过工程效能数据平台，我们可以辅助业务团队提效降本，同时也可以促进我们的工具生态和研发方式不断迭代，这正是我们的价值。

*Q&A. *****如何度量 DevOps 的研发数据

前文内容里也给到一部分答案。从 DevOps 角度看，这个数据可能更多是集中在研发过程指标里，我们会比较关注，第一，响应能力，第二，研发过程的质量指标。第三，持续集成能力，持续集成能力可能更多关注的是 CI、CD 里的频率、平均时长等。如果我们希望在 DevOps 过程中能够看到一些结论，可能还需要通过像具体时间的分布、协作能力数据来定位问题。

关于指标，需要先想清楚，每个工具包括它所应用的领域应该有哪些非常关键的特质，它的目标是为了快还是为了好？当我们想把结论性的指标给人看的时候，我们要能找支撑它的指标数据。

在企业做大的过程中，有很多问题我们是能够感知到的，但是我们确实缺少一个量化的方式去改善它，我们需要一把尺子使团队里的人都能够感受到变化，以及这种变化到底是不是我们希望的趋势。