蚂蚁集团（后文中简称“蚂蚁”）已经有上万名研发工程师，如何更全面、更精准、更有效的提升整体研发效能成为组织面临的重要挑战。蚂蚁集团 CEO 在总裁会上提出“任何事情不能被衡量，就不能被改善，研发效能需持续建立指标体系，收集数据，识别问题，再通过自动化工具、服务体系等去解决研发问题，用赋能（Enable）的思想，最终让研发工程师高质量、高效工作”。围绕这个目标，基于多年积累的大数据技术，蚂蚁集团构建了“蚂蚁研发洞察体系”，包括：研发洞察体系在公司内进行了持续3年的实践（2019-2021），全面实现了数据驱动提效：- 研发问题数据化：所有效能专家在线沉淀经验，问题自动诊断。
- 洞察服务规模化：所有团队每周自动体检，清晰了解团队现状&问题，持续改进。
- 研发决策智能化：公司级效能提升、技术外包管理、人员绩效&晋升等所有关键技术决策场景，均由数据&模型辅助决策。
首先，简单介绍一下蚂蚁的业务。蚂蚁的业务特点是兼具金融和互联网双重属性的。首先是稳定性第一，对于社交软件，用户忽然登录不了，刷新几次也无大碍，但是蚂蚁的业务，一个小小的失误，比如支付不了、红包发多了，就很容易演变成重大危机。其次，是唯快不破，求稳的同时，技术必须还要快速满足业务的创新、试错。因此，为了满足这种业务特点，蚂蚁的技术架构、配套的研发体系进行了多轮的升级，到2018年，研发工具链已经实现了研发全链路的标准化、在线化、服务化，并面向云化、智能化方向演进。当然，与此同时，研发人员、系统规模也大幅增长，技术人员迅速达到了万人以上。
在这个规模下，研发效能领域就面临一个重大的挑战，如何帮助组织全面、精准、有效的提升整体的研发效能？当组织达到千人以上规模后，提升整体效能，单纯升级工具是不够的，整体上，必定会出现如下问题：最顶层，很难了解和牵引团队持续提效，达到业务期望。
TL，对团队的研发状态只能通过晨会等形式初步了解，对于研发问题无法及时发现，常常是业务同学反馈交付慢、质量差，才会有行动。
一线研发，则对公司、BU的复杂的质量策略、工程要求并不一定会执行到位，而一些很有价值的工程实践，比如CodeReview、自动化测试、CI问题快速闭环，都需要一线良好执行才能保障落地。
这些问题的传统解法，就是一个领域专家站在团队外面，帮助团队诊断和分析，在蚂蚁基本上都是SQA、QA、PM等角色来承担。但这种模式有2个明显的短板：一是滞后，问题出现了再去解决。二是感性，依赖经验判断，缺少客观依据。在研发效能领域，其实早有一个非常理想化的解决思路，叫做“研发数字化”。第一阶段是规范化，就是研发过程有明确的标准和规范，且可被执行。
第二阶段是线上化，就是这些过程和要求都由工具承载。
第三阶段就是数字化，此时，不再是简单的升级工具，而是发挥这个复杂系统中人的力量，让组织中各个角色都可以依托数据来发现问题、持续改进。
“研发洞察”就是一套实现研发数字化的实例化解决方案，它的目标是依托数据，低成本发现问题，帮助团队自驱、持续提效：汇聚研发数据。
在体系内做数据的加工和自动分析。
面向不同层次的管理者提供诊断服务。
洞察全局数据，引导工具链持续改进。
当然，要达到这个理想状态是非常困难的，大多数企业和当时的蚂蚁一样，一定会面临3个巨大的挑战：
第一是数据乱：数据分散在各个研发工具中，不仅散乱、数据格式不同、脏数据也很多。所以首先必须要有足够的重视和投入，要建立一个专门服务研发度量的“基础设施”。第二是指标杂：虽然很多指标业界早有标准定义，切实符合团队实际情况。而现实中，技术团队不是没指标用，而是喜欢自己取数构建指标，衡量同一件事情，用的指标都不一样，或者是，一样的指标，实现又不一样，比如最常见的“需求交付周期”，有的是从需求创建时间开始算，有的是从需求受理时间开始算，相互之间不参考、也无法横向比较。所以这里必须要建立一套全局的、标准的、专业的“研发指标体系”，让各团队书同文、车同轨，既符合业界、公司内的共性标准，又能贴合团队实际情况，还能让大家获得基线、在团队间对比。
第三是缺标尺：只有数值是很难形成驱动力的，但是有了标准之后就不一样了。比如，一个用户每天用体脂秤量体重，140斤，没什么感觉，但是忽然有一天，体脂称告诉这个用户，他的身体健康指数是90分，满分100分，缺10分是内脏脂肪高，建议让他去游泳，他看到了差距，就更有动力去运动。当然，对于复杂问题本身是很难用单一指标衡量的，比如研发效能怎么样？质量怎么样？编码能力怎么样，因此就需要对研发领域的复杂问题建立“综合评价模型”。通过模型把专家的经验、标准转换为量化的分数，让大家清晰的看清现状怎么样？有什么差距？应该怎么改进。接下来分别分享一下这三个对策对应的具体方案和实现。3.1 研发度量基础设施
研发度量基础设施的建设目标就是让研发数据具备自动化、规模化、场景化的服务能力。领域专家：一般是研效能部的专家或者QA这类人群，他们的职责有点像医生专门给人看病，主要是要分析团队的研发问题，找到原因和改进点，帮助团队改进。
CTO（高管）和TL：有点像病人，他们想要的其实非常简单，告诉我，我的团队现在研发现状怎么样、有什么问题、应该怎么做，越简单越好。就好像是一般人收到一份体检报告，里面80%的部分都是列的指标，并不会仔细看，实际，只想看一下第一页的概要，了解一下自己的健康程度、有什么病要治疗就好了。
一线研发人员：他们想要的更简单，绝大部分人只关心一点，我的Leader关心什么？有什么要求？我保证做到做好就可以了。
所以在产品层，需要面向不同的角色提供完全不同的服务：
对于领域专家，产品提供的功能叫“效能指数、效能透视”，有点像一套体检设备，能够可视化团队研发过程，并自动进行分析。专家们也可以把分析结论按照自己的需求配置成一份体检报告，并补充专家的分析结论。对于CTO和TL，他看到的则是一份非常简单的诊断报告，他可以订阅自动推送，只需关注里面的问题和结论即可。当然，从内容上也有很多类型，有面向团队全面的体检报告，也有针对特定问题的专项报告，比如项目的交付情况、人员的研发情况、应用的研发情况等等。最后对于一线研发，他们甚至不太需要直接访问产品，通常就是收到TL通过钉钉推送的一个异常或提示，比如昨天发布的系统质量综合分很低，原因是变更覆盖率和通过率都很低，需要关注，可参考一下这个案例做改进。让他做好执行就好了。
在这些看上去完全不同的服务底层，有一个通用的模块，叫“指标详情”，是最核心的“内容”的部分，相当于是产品的“肉”。这个模块，其实是一个最小“洞察”单元，首先是指标对应的分析结论，其次才是配合结论产出的各类可视化图表。不论什么角色，什么场景，对于同一个指标下钻之后，其实看到的都是这个模块，这样最大限度保证了体验和数据的一致性。如果有些专家觉得结论不解渴，自己可以分析的更好，他仍然可以使用这些配套的分析图表进行灵活的自定义分析。蚂蚁打磨出了这种数据产品形态，在数据产品领域有一个专有名词，叫“定制服务型数据产品”。大家常见的数据产品，一般都是一个大盘，上面有很多图表，趋势图、柱状图等等，看起来很炫。或者是像Excel一样的表格，里面密密麻麻填满数据，可以很灵活的筛选、分析，这类产品有一个统称叫“大盘型产品”。但研发洞察产品并没有这样做，因为这类产品都有一个假设，就是每个用户都是“数据分析师”，他们具备数据分析能力，需要自己看数据、研究数据、得出结论。而实际情况是，研发洞察要服务的绝大部分用户是几乎没有数据分析能力的，很多用户甚至不了解“软件工程”这个领域。所以，产品定位必须是“定制服务型产品”，这类产品只是依托数据作为媒介，最终目标还是要诊断问题、给出建议。接下来，要支撑这套产品服务，还有一个重要的要素，就是“内容”。就好像很多视频平台，产品设计的好只是一部分，里面有没有用户想看的电影、电视剧，这些内容才是关键。因此，在产品的下一层，又建设了2个中台能力：1. 指标中台：它依托阿里的OneData大数据体系构建，目标是把专家经验快速变成可供用户使用的产品功能。首先，用结构化的方式把经验转化为逻辑层的一个标准定义“指标”，其次，再用工程化的方式把“指标”转化为物理层的“数据表”，最后匹配产品的“指标详情”模块的展现形式组装数据、生成结论，直接服务用户。2. 技术中台：支撑指标中台的技术中台则有3个模块：其中，“研发算法中心”指的是“自动洞察”技术，属于数据科学范畴的增强分析领域，蚂蚁把它引入到了研发领域，目的就是自动生成结论，毕竟分析数据只是过程，结论才是用户需要的。异常感知：用于判断指标是否存在异常。
异常归因：找到造成异常的主要因素，帮助定位。
风险预测：对未来潜在风险的分析。
这些能力综合起来，从用户视角上看可以实现多种效果。比如3.2
蚂蚁研发指标体系
研发指标体系的建设目标是要在公司内统一标准、形成共识，让所有专家基于一套体系持续的沉淀和扩展。蚂蚁的研发效能指标体系设计，注重科学性、系统性、实用性，强调根据不同视角、不同目标、不同功用，精准提供指标。主要搭建过程如下：研发过程建模：所有度量都需要依托实际、具体的研发过程，因此蚂蚁首先将研发过程进行了标准化的定义。
设计指标：匹配研发过程模型，再叠加上观察和评价的不同角度，就可以划分出不同的“问题域”，问题域中设计具体指标。
设计模型：指标有了之后，再聚焦一些复杂问题，比如研发效能怎么样？交付情况怎么样？人员怎么样？来聚合综合评价的模型。
输出指标到具体应用场景：结合具体的使用场景，把模型+指标，组合成对应的报告，输入到对应场景中。
在这个过程中有三个关键点，分别是：遵循度量基本原则、分层度量、区分指标属性和类型。关键点一：研发效能指标的设计和使用必须遵循基本原则。蚂蚁把整个业产研（业务、产品、研发）过程分为三层，并分别提供指标：（1）业务层：指从业务规划到价值验证的过程。这一层的目标是“做正确的事”——以业务目标为核心，创造更多有效、可验证、可闭环的价值，保障业务结果。使用的指标有盈利能力、市场份额等商业衡量指标，也有客户满意度、可用率、生产力等非商业衡量指标。这些指标的具体定义和业务特点、业务发展阶段强相关，并会随着市场变化进行调整。（2）交付层：指从需求受理到需求发布。这一层的目标是“正确的做事”——以流动效率为核心，持续、快速、高质量交付价值。交付层像是一条管道，衡量这个“研发管道”的效能，主要看交付质量、交付效率，以及过程中的研发投入、产出。（3）能力层（也可叫技术实现层）：指影响交付过程的所有研发活动。这一层的目标是“更好的研发能力”——研发过程中的每个环节（无论是人工还是自动化）能够顺畅、高效、低成本完成。使用的指标主要是每个研发活动中的工程任务的稳定性、时效性、有效性，以及关键研发活动的准出质量。根据观察角度不同，指标的属性分为质量、效率、投入、产出。根据使用场景不同，指标的类型分为结果指标、过程指标。结果指标用于评价或观察结果，具有滞后性。过程指标用于对过程中关键问题诊断，帮助持续优化，有效支撑结果性指标的达成。[质量] 万行责任故障数：统计时间内发生的线上故障和变更代码行比例。相当于软件质量工程中最常用、最重要的质量指标之一 - “遗留缺陷密度”（Residual defect density），在蚂蚁使用“万行责任故障数”来衡量线上质量，牵引各团队交付可用的软件。
[质量] 责任故障监控发现率：责任故障中通过监控发现的线上故障占比，衡量研发团队风险防控能力。由于蚂蚁尤其重视提前发现故障的能力，因此也作为比较重要的结果指标。
[质量] 应用发布回滚率：团队所负责的应用的变更有多少比例导致问题，造成回滚。对应到 DORA 调研报告中指标 - “变更失败率”（Change failure rate）。
[质量] 活跃应用客观质量分：应用综合评价模型度量复杂问题，是蚂蚁研发度量的一个特色。质量分是应用发布上线前最后一次运行的各项质量检验结果的综合评价，它的构成包含了安全问题、测试通过率、接口注释率、代码重复度等多个工程维度的客观指标。用于衡量应用迭代过程的内建质量（Built-In Quality，确保每个增量在整个研发过程中都符合适当的质量标准）。
[效率] 需求平均交付周期：从需求受理到最终交付上线的时间。它反映团队对客户问题或业务机会的整体响应速度。
[效率] 研发迭代平均交付周期：研发迭代从迭代创建到迭代发布的时间周期。对应到业界指标称为“开发交付周期”，即一个需求从启动开发到发布上线的时间周期，由于蚂蚁这个过程是由“研发迭代”承载的标准工作流，因此指标命名与业界不同。研发团队的开发能力、研发模式、交付粒度、工程效率是影响迭代周期的关键要素。
[效率] 平均发布前置时间：每一次代码提交到发布上线的时间周期（Lead time for changes，how long does it take to go from code commit to code successfully running in production），它反应了团队的工程技术能力，依赖交付过程中工具的高度自动化和稳定性。
用这套方式，蚂蚁集团累计沉淀了 2200 多个指标，覆盖了6个不同的研发工种，10+专业领域。这些指标，经过研发洞察平台的处理，自动识别异常，转化为自动分析结论，并匹配相应的解决方案 & 实践建议，分层、分角色、分场景输出，让全组织使用数据持续优化和改进。3.3
综合评价模型体系
综合评价模型体系的目标是将多个专家对同一个事物观察后的经验、观念进行客观量化，形成一个用于评价和诊断复杂事物的数据工具。
首先简单介绍一下“MCDA”。它是现代评价和度量复杂问题的科学方法，像是健康度模型、股票指数、百度指数都是基于组合套思路衍生出来的。蚂蚁将它引入到研发领域，主要是为了量化复杂问题。这个方式的优势是从评价的角度可以用1个数字来了解结果，非常清晰。而且，可解释性强，适合用于诊断、定位，一旦指标异常，可以自动解析公式，分析到主要影响指标、以及影响程度。 第一步，定义评价指标。比如如何量化交付质量，那么就需要相关的人对“交付质量”这个模糊的观念进行澄清，在现实中，到底观察到了哪些变化，可以代表质量？
第二步，单指标打分。主要是定标准，明确什么取值代表好，什么代表坏。
第三步，指标间权重确定。这里通常有两类方式，第一是德尔菲法，专家赋权，通过多个专家的独立&多轮打分，把共识沉淀下来。第二是自动赋权，比如AHP、动态规划等等。
第四步，综合计算。把这些单项分聚合成1个好理解的数值。聚合的公式也有很多，比如有希望看到持续增加的指数型公式，也有适合诊断的得分型公式。
截止到2021年，蚂蚁已经陆续构建了12个模型在解决不同程度的复杂问题，比如“研发效能指数”，用于对蚂蚁研发效能结果进行评价，并且能够分解、刻画每一个团队的研发效能。比如“代码影响力”，刻画代码复杂度和难度，在公司内的绩效、晋升的需要工作总结的场景，很多一线同学都用这个指标举证自己的代码难度。每一个模型实际都代表对于一类复杂问题的评价有了突破性的进展，都会带动一系列相关场景的全面跃迁到数字化决策的阶段。![]()
研发洞察体系是如何在蚂蚁实现规模化的推广和应用的呢？主要有两大类核心实践：4.1 公司级提效
在2018年以前，公司管理层都知道研发效能很重要，但是在全局视角下无法清晰定义什么是研发效能，更不用说用数字表达，并建立能横向对比的基线。这个实践的目的就是让大家看清楚公司整体的研发效能现状，明确全局性的问题、提升方向，达成共识、建立基线，并能自上而下牵引全局优化。首先，由研发效能部主导，和所有相关专家联合，定义了研发效能，并构建了研发效能指数1.0，其中包含14个结果性指标。之后依托主、客观数据的分析，发布了《蚂蚁研发效能分析报告》，回答了这些模糊的问题。再联合各个BU（就是业务单元）进行治理。这个实践有点像火车头拉动车厢一样，逐步把依托数据洞察和改进的氛围和工作模式带动了起来。到了2020年以后，更多量化指标、治理方案、优秀案例全部沉淀到了研发洞察平台，研发效能部就开始用产品自动的提供规模服务，提效&改进的工作就成了BU、TL的日常行为。4.2 团队级改进
这个实践的目的是自底向上让团队自驱改进，让部门负责人、一线TL能高频的关心团队情况、及时做改进。具体实施过程中，也需要一些技巧。首先，必须站在TL角度，优先满足管理上的刚需场景，比如要响应上级的基本的研发质量&效率要求，比如对于异地团队管理、关键项目本身需要依托数据进行评估、评价。其次，在这个过程中，就顺带着把公司全局要治理的一些要求、规范，植入到他们的工作界面里，比如蚂蚁对CodeReview充分性要求、及时修复发布前风险的质量要求等等。截止到现在，蚂蚁的TL已经至少每周会进行一次团队体检和问题改进，也有很多TL开始日频度的做团队数据化管理了。这两个实践下来，上下层其实使用的是同一份数据，只不过是不同的视角、不同的场景而已。大家都知道，在软件度量领域最大的问题，通常不在技术实现上、也不在度量精度上，而是产生数据的人和使用数据的人不是一波人，所以产生数据的人就很容易做手脚，让数据跑偏。而这两个实践，可以让同一份数据无论是对公司的高层、还是一线TL同时产生价值，也就最大限度避免了博弈，保证了数据的准确性和有效性。4.3 研发活动洞察
这实践是解决作为公司研发效能的一号位，研发效能部自己的问题的。研发效能部负责公司内所有的研发工具链，那么在这么多研发活动里，到底哪几个研发活动是最需要提升？在这里，工具又需要做哪些改进呢？这个研发活动洞察，就是就是支撑这种决策的。蚂蚁的效能专家和技术专家梳理了54个核心研发活动，并把每个活动拆解成222个工程任务，全部埋点，并对它们的用量、时效性、稳定性、有效性进行综合评估，找到差距最大的研发活动和原因，指导部门有针对性的优化研发工具。4.4 外包效能提升
这个实践是专门为外包管理提供的工具，用的是综合指标+指标树的展示形式，可以快速衡量整体的情况，并自动诊断到主要需要提升的指标和团队。用于供应商考核、团队外包研发结果的评价都非常有用。4.5 小结
这些实践落地3年来，让蚂蚁的研发效能提升模式，发生了根本性、范式性的转变：
最后一部分，分享一下我们构建这套体系背后的思考和总结。
其实我们最开始做之前，就在思考两个问题，这两个问题从原理层面、从根本上决定了这个体系能否成立。第一个问题是“为什么数据能解决实际问题？”这个问题决定了我们应该如何正确的应用数据。首先万事万物在人的认识范围内都可以被理解为一个“系统”。“目标”则是某个系统运行的理想状态。由于“系统”的现状和目标之间存在落差，因此就产生了“问题”。为了解决“问题”达成“目标”，一个客观的方式是对系统进行建模，并对系统的某些运行状态（包括质、量）数据化抽象表达，于是形成了“指标”。“指标”作为工具，它能用数值在从某种程度上表达系统的理想状态和现状的差异，辅助问题的定义、度量、分析、改进和控制。从一套概念和图示中，可以得出类似“公理”一样的基本原则：理解系统才能获得目标：不理解系统的运作原理（要素和要素之间的联系），就无法找到预期的理想状态，也就设计不出目标。这种情况下，“无法理解系统”才是问题，需要优先学习系统所属的“领域知识”。
有目标才有问题：很多被提出的被称为“问题”的东西，其实模糊、宽泛，达不到我们在图示中定义的“问题”标准，只能叫做“原始诉求”。这种情况下，“没有目标”才是问题，需要优先用某种方法把它对应的“目标”找到甚至是设计出来，所以需要学习和使用“问题解决方法”，尤其是定义问题的部分。
找到指标背后的目标：把体重从80kg降低到70kg是目标吗？不是，“健康”或者“健美”可能才是你的目标，同理，“赚1个亿”、“提升幸福感”都是某个系统运行中产生的“指标”。很多时候，你收到的所谓的问题，其实是达成某个指标的诉求，这种情况下，“把指标当目标”才是问题，解决因为无法达成指标所产生的问题，会本末倒置，陷入工具主义的死循环中，模型和真实系统的匹配度会越来越低，最终，让指标工具失去对系统的控制效果。
如此看来，我们的一个重要结论是，数据确实是可以解决现实问题的，但是“领域知识”、“问题解决方法”、“数据分析方法”缺一不可。而实际上，现实和理论常常有一个巨大的沟壑，现实中，很多软件工程领域的专家，领域知识丰富，但是缺少问题思维和数据思维，导致经验 > 数据。而专门解决问题的咨询顾问或者数据分析专家呢，常常会领域知识不足，造成现实和逻辑模型之间拟合度不高。都很难达到用数据真正解决现实问题的理想状态。而数据的消费者呢，他们最需要理解的是，指标只是工具而已，它所指向的问题才是“真”，比如体检报告里的一堆指标指向健康问题，汽车仪表盘里的一堆指标指向的是安全风险问题。同理，研发效能指标指向的是研发问题。落地过程中，确实存在这样的现象，我们用手指指着月亮，告诉大家，看，月亮在哪里，结果他们却只看到了手指，错把手指当成了目标。所以我们也需要不断的从认知、文化等多方面来引导我们的数据消费者，要做到“见月忽指”，不能为了指标而指标。第二个问题就是这个解决问题的过程是否可以被工程化，如果答案是不能，只能人肉，那我们大可不必这么费心费力了。当然，当我们把过程拆解之后，发现大部分单点技术都是有解的，只不过是横跨了不同的领域。比如定义指标是数据分析领域，建模和自动分析属于数据科学领域，根因分析和解决方案本身就是软件工程领域知识。最后，可视化、跟踪、监控，也完全可以用产品的方式承载和实现。这样一来，我们就可以把依赖人经验的部分，压缩到最小，仅仅是问题的定义和拆解，后面的一整套逻辑，都可以用人+系统配合的方式来完成。从技术实现的角度，为在理念层面的度量的方法&原则，找到了一个具象化的载体——“专家系统”。用一种标准化、工程化的方式，将专家的经验转换为数据，最终输出洞察结论、建议，给非专家的用户。从落地实施的角度，构建一种多边平台的商业模式，让体系能切实在公司内扎根，为不同角色同时产生价值。多个角色+研发洞察形成一套完整的生态系统，相互合作、相互驱动，最终，实现了自运营、自组织、自驱动的数据驱动提效模式。最后，再分享一下研发洞察体系完整的全景图。今天分享的内容，主要是左侧的部分，我们称之为“决策辅助”方向。实际上，我们还有右侧用数据赋能工具链、让工具链更智能的方向，我们称之为“研发辅助”方向，现在已经在蚂蚁内部孵化出多款智能化的工具，比如辅助链路查询、日志诊断等等，后续有机会再详细和大家分享。好了，今天的分享就到这里。实践出真知，希望我们这个打磨和落地的3年的方法、技术、实践，可以在研发度量领域带来范式意义上的转变，帮助希望跃迁到研发数字化阶段的公司、同行能够往前更进一步。作者简介
华为工作8年，蚂蚁集团工作3年，任研发效能解决方案架构师，主导蚂蚁研发数字化建设。