其他
DevMind：构建效能提升的“导航仪”和“发动机”，实现从数据到价值的跃迁
本文根据单虓晗老师在2022年TID大会同名演讲整理。文中图片里展示的所有数据、人名等信息，均做了脱敏处理，为随机数字而非实际数字。本次实践总结，致力于探索效能度量领域的终极解决方案，既充分应用了业界主流的理论、方法，又从可实施落地、可产品化复制的角度，定义了四个最佳实践。接下来，我会以字节跳动（后文中简称“字节”）为案例分享DevMind体系和最佳实践，让大家了解，如何让研发度量在公司内成功落地，不仅能获得公司内各层面各角色认可，还能进一步跃迁，成为组织级研发效能提升的关键成功要素。问题：研发效能的“黄金三角”如何落地？首先致敬张乐老师的“研发效能的黄金三角”，我自己也是这个模型的粉丝和践行者之一，它为研发效能提升工作，提供了体系化的框架和工作开展思路。但是，当你面对一个公司级的问题扑面而来的时候，你发现，如何推动这个三角，是很有诀窍的。首先，最底层的效能平台怎么做，非常清晰——建设DevOps工具链，服务好公司内的一线研发人员。但是，一位CTO或者部门负责人让你帮他们提升一下研发效能，你应该从哪里入手呢？你会发现，直接看工具链，过于微观了，一线研发的关注点通常和CTO的关注点不同。目前为止，各公司主要的实施手段，就是找一个掌握了“效能实践”方法的专家，通过“效能度量”手段，一个一个发现效能问题，推动解决，驱动组织级效能提升。可惜这种模式，往往落地效果不理想，专业效能专家的人数、精力总是有限的，很难承担大规模组织下的批量效能分析、驱动工作，尤其是千人以上的组织，往往就是小马拉大车，死活拉不动的结果。DevMind体系所要解决的问题，就是如何让效能实践+效能度量这两项工作可以在线化、低门槛、规模化的开展，从而驱动这个“黄金三角”快速运转。解法：DevMind体系思路DevMind的核心思想，相信大家在我之前的分享里已经充分的了解，有2个要点：从技术、产品的角度，构建一种“专家系统”：收集研发数据，并用一种标准化、工程化的方式，将专家的经验转换为数据，最终输出洞察结论、建议，给非专家的用户，达到可规模化服务的效果。我称之为“导航仪”。从落地实施的角度，构建一种“多边平台商业模式”：同时服务公司内多角色（领域专家、QA、PMO、Leader等），形成一套多角色在线化分析、改进、协同的生态系统，从而实现自组织、自驱动的数据驱动提效模式。我称之为“发动机”。你手握这套效能提升的“导航仪”和“发动机”，就可以快速的、有力的、持续的，推动组织级各团队研发效能提升。难点理想很美好，现实很骨感。关于“效能度量为什么这么难”的问题，早在2021年年初，张乐老师、茹炳晟老师的相关文章就已经铺天盖地了，效能度量的“血案”、“失败案例”相信大家都已是耳熟能详。我自己也是效能度量这个领域的忠实爱好者，几年来我不论负责多大范围的事情，研发模式升级也好、智能化工具链也好，手里都会主导效能度量这样的项目，我也认真考古过业界几乎所有失败的度量项目、产品，从实践落地的角度，总结了四大难点。大家先看这条工作流——从数据采集到最终产生数据洞察价值全过程，这其中，有四个极难逾越的鸿沟：数据难：首先，很多企业数据分散在工具链里，要做度量，必须打通数据孤岛，聚合原始数据，那就需要有公司授权，让各个工具愿意提供，此外，还需要获取很多公司级组织数据，比如人员、部门等等。其次，原始数据不能直接用，还需要理解它所刻画的研发过程，并对数据进行清洗，去除脏数据，再关联人员、部门、应用等维度属性，最终校验后，形成干净、可用于数据分析的“研发数据宽表”才能使用。最后，就是在线化不足或研发流程不标准，导致数据不可用。比如项目需求管理常常是重灾区，有的团队需求、缺陷都在Excel里管，这肯定不行。或者，已经用了Jira等工具了，但是需求状态常常没人管，结果一拉需求周期一看持续1年还没关闭。度量难：首先，一个事实如何被客观度量，本身就是一个大难题。虽然，早在1946年，心理学家史蒂文斯就发表了一篇名为《量度与量化的理论》，提出过一个很重要的观点叫“一切皆可量化”，在学术界尤其是社会科学领域早有共识，但是绝大部分人对量化的基本方法一无所知。我日常被问的最多的就是这个问题，你不是量化专家吗，研发效能怎么度量？人力负载怎么度量？用户体验怎么度量？人的能力怎么度量？字节的研发效能指标体系能否分享一下，参考一些指标过来。其次，就是拿到了指标也不一定会用。比如，“千行代码缺陷数”在字节早已经是一个组织级的指标，但还是经常会遇到咨询，尤其还是QA人员：“这个指标适合我们项目吗？有没有基线标准？没有标准值，我想知道我负责的团队是好是坏？应该怎么判断？”。通常来说，绝大部分做度量的项目，能跨过前两条沟壑，就已经消耗了大量的资源和精力了，但是，产出物通常就是一个“数据大盘”，对最终决策者来说，有价值，但是不高。我见过太多相似的情景，你兴高采烈的把一个做了两个月的数据大盘抛给管理者，他看了半天，结果没看懂，就说你能不能洞察出一些问题或者有价值的结论给我，所以你必须还要做数据分析，写一份有价值的洞察报告，来影响决策，这样他才会认可价值。洞察难：咱们研发效能领域的很多专家，虽然会数据分析，但是毕竟不是专业数据分析师，很多数据分析技巧是不足的，但是想体现价值、驱动问题改进，至少每个月必须做分析，出分析报告，这就导致整个过程极其痛苦，要拉数据，看大盘，验数据，跑算法，还要确认具体问题原因。投入大，成本高，最关键的就是，分析报告的结果常常也达不到决策者的预期，总是感觉数据有是有了，但是就是“差点意思”。批量&高频服务决策难：最后一点就是很多度量项目，就算有既懂研发又懂数据分析的专家配合，也是1-2个人的力量，而项目的风险在于，投入这么多人洗数据、做系统，却很难在公司规模化的服务。首先，每个业务线、部门，都会有一些定制的诉求，不同发展阶段关注的研发指标肯定不同。其次，人的需求是永无止境的，月度汇报满足了，他还想要周甚至每日看。所以，要达成这种规模化能力，必须要依靠产品作为杠杆来规模化服务公司内所有研发分析场景。唯有这样，研发数据的价值才能得到最大化体现。方法与实践因此，我结合几年来在各个大型企业的落地经验和成功案例，为DevMind体系补充了四个最佳实践及配套的产品与解决方案，希望可以帮助各个企业跨越这四道鸿沟，持续升级，最终实现从数据到价值的跃迁。实践1：数据——研发数据中台方法这个阶段的目标就是要打通研发数据孤岛，沉淀稳定、高质量、可用于数据分析的“研发数据宽表”。目前主要有2个主流方法：方法一：内部开放研发数据，服务少部分懂数据人（比如QA、PMO），依靠“群众的力量”，打磨数据，最终沉淀出一些稳定的研发数据宽表。比如，BAT的研发数据最早就是使用这个策略，面向公司内所有业务线开放，最终几年的时间内沉淀了一批公司级的研发数据宽表。这里不推荐的做法是直接开放原始表，原始表的开放会导致数据的二次加工，数据宽表最终就分散在各个团队，数据模型无法被统一，后期极难整合。方法二：不开放研发数据，基于宽表提供各类数据分析报表、大盘，满足各内部团队的研发数据需求。比如蚂蚁集团最早就是使用这个策略，把研发数据宽表接入到BI数据分析平台，创建一些通用的报表，让各个团队来使用。这里不推荐的做法是直接开发可视化大盘，大盘设计的指标比较死板，而且研发投入重、迭代速度慢，很难快速响应用户蜂拥而来的数据需求，投入产出不成正比，常常就倒在建设的路上。这里重点介绍一下字节的做法，业界说字节比较“卷”是有道理的。一般来说，用户要说我想要一个椅子，技术人员会精准评估需求、尽量裁剪，最后做一个3条腿的小板凳，你先用着。而字节的技术会说，除了椅子，你可能还想要一个餐椅、吧台椅、小板凳，那我给你做一个生产各种椅子的流水线吧，到时候想要什么椅子你自己生产。所以字节的实践，不仅清洗了数据宽表，还要配套做一个ABI（智能数据分析）型产品，服务公司内所有研发数据分析人员。技术&产品如图所示是字节这个阶段的技术、产品架构，这款子产品，我们称之为“度量（Measure）”，它服务的用户场景，主要就是分析研发数据的人员。案例接下来，为大家展示我们在2020年之前一直在使用的两板斧：宽表到图表：用户可以把宽表的字段，快速加工成一个可视化图表，直接用。而且，与传统ABI平台不同，研发数据尤其需要下钻到明细，因此，还很贴心的支持明细下钻能力。图表到大盘：用户可以把配置的图表，组合成1个大盘页面，增加全局筛选条件，用于日常的数据分析。效果如上图所示，就用这两板斧，我们像收集龙珠一样，几乎集齐了公司内所有主流研发工具的数据，甚至还有一些业务的数据，同时，又召唤了神龙，直接服务公司内所有能分析研发数据的人员，积累了大量的图表、大盘、核心用户群。数据的特点是“越用越准”，因此，这种“众人拾柴火焰高”的方式，帮助我们快速的淬炼出了高质量的研发数据宽表。实践2：度量——研发指标体系方法这个阶段的目标就是要沉淀全公司专家经验，建设专业、统一、标准、可工程化实现的研发指标体系。目前的主流方法就是基于研发过程模型搭建指标，以及，按“GQM”（G:目标
2022年9月13日