研发效能红宝书

前言 AIGC 时代，受到新技术冲击最深的正是软件研发行业。研发团队既要在浪潮中奋勇争先，也需在过程中持续回望，以确保方向正确。我常常在和一线团队的交流中听到类似的挣扎：一边是火烧眉毛的需求，一边是捉襟见肘的交付；一边是“技术债”的包袱越背越重，一边是部门间的壁垒高耸无言。 诸如此类的困局该如何突破？行业中其实已经有了一些优秀实践，这也是我们开启《研发效能红宝书》的初衷。第一期发布后，我们收到了许多朋友的认可和感谢，这让我们确认了分享的价值，也让我们有了继续的底气。在新一期中《研发效能红宝书》中，我们拉上了更多一线专家来分享自己的实战经验。书里没什么高深的理论，都是真问题和硬办法。希望能帮你省下那些在弯路上反复折腾的时间，毕竟我们最缺的就是时间：） 核心内容 本手册将分为三大模块，层层递进，揭示高效研发的关键要素。 �. 技术与业务如何协同共振，以持续高效地交付真正有价值的产品： ·做正确的事：确保研发方向与业务战略一致·正确地做事：精益思想、敏捷原则和 DevOps 实践的落地·构建高效协同的组织结构和文化氛围 �. 如何以数据为罗盘，构建效能度量与洞察体系： ·研发效能度量的核心原则和常见误区·主流度量方法及框架，如 MARI 方法论、DORA 指标、SPACE 框架等·如何构建自动化数据采集分析平台·如何将数据洞察转化为可执行改进措施 �. AI 如何重塑研发效能： ·生成式 AI 在研发全生命周期的应用与价值·云原生、低代码等新兴技术对效能的影响·组织如何为技术变革做好准备 这本手册能为读者带来什么？ ·实用工具与方法：本书提供经实践验证的可操作方法、明确的度量指标和流程优化框架，帮助你将理论转化为行动。我们针对不同角色（管理者、架构师、工程师等）提供了具体建议，让你能立即应用于日常工作。 ·前沿视野：汇聚十余位专家的洞察，让你把握行业趋势，了解不同企业的成功经验，拓宽解决思路。 ·思考与变革动力：帮助你诊断团队效能瓶颈，根据自身特点创造性应用书中原则，设计适合的效能提升方案。 研发效能提升是永无止境的旅程。红宝书旨在帮助每一位研发从业者提升效能、创造更大价值。感谢为本书贡献智慧的专家、合作伙伴以及编辑团队的辛勤努力！ 任晶磊思码逸 创始人兼 CEO 出品单位 编写专家 任晶磊、李旺、关钦杰、吴衡林、姬俊鹏、陈靖贤刘刚、高明国、徐陈飞、王欢、张乐 01正确做事 技术人的话语权：做正确的事”真的比“正确地做事”更重要吗？�� 目录 为什么技术高管汇报一定要用数据说话？�� 02最佳实践 从�到�搭建研发效能建设体系�� 让数据说话，高效盘点企业研发效能�� 持续改进：数据驱动的指标体系演化之路�� PMO 视角下的研发体系建设六步法�� 从“人效黑洞”到“效能标杆”：去哪儿网研发数字化洞察实践�� 京东科技研发效能度量的大体系与小实践�� 哈啰一站式业产研协同平台的建设与实践��contents 03AI时代的研发效能 研发效能中的 AI 度量与度量 AI�� 从 API 测试看企业系统性落地 AI 的鸿沟�� 大咖对谈｜软件工程 �.� 时代，AI 落地研效成熟时�� 正确做事01正确做事 技术人的话语权：做正确的事”真的比“正确地做事”更重要吗？ 任晶磊丨思码逸 创始人兼CEO 为什么技术高管汇报一定要用数据说话？ 任晶磊丨思码逸 创始人兼CEO 技术人的话语权：做正确的事”真的比“正确地做事”更重要吗？ 任晶磊思码逸 创始人兼CEO 一直以来，“做正确的事，比正确地做事更重要”似乎成了某种政治正确，也成了技术人被老板、被业务 PUA 时的常用话术⸺当我们在管理会上兴奋地讲述产研团队通过各项举措把需求吞吐量提升了 ��%，下一个被挑战的问题常常是：你们做的这些需求都有价值吗？客户吵着要的 X、Y、Z怎么还没交付？ 这些质疑听起来没毛病，但如果直接回答，你就输了。因为永远有听起来极其“正确”的需求还没做，而做完的需求再没人关心它们“正确”与否。在这样的对话中，产研永远是附庸，话语权被他人拿捏。要想摆脱这种尴尬的境地，技术管理者应当勇敢地说：你们要的“正确的事”，只有通过我们“正确地做事”才能达成！ “正确的事”容易成为陷阱 “做正确的事更重要”隐含着一个假设：我们能明确知道什么是“正确的事”。但实际上，有几个人能做到呢？反正我不能。作为 CEO，带着思码逸跑了五六年，往事不堪回首。我最知道“正确的事”的时候，都是团队被带着走弯路最多的时候。 遥想当年，拿完奇绩创坛几千万投资，踌躇满志。和陆奇博士多次讨论，一致认为，从数据分析向上游 DevOps 工具链延伸是“正确的事”。于是我们做了开源项目 DevStream，成功进入 CNCF 沙箱。但事与愿违，把产品“做薄”和有足够的切入口“黏住”用户之间的磨合，不是靠谁拍脑袋就能定义“正确”的，而是要在实际场景中和大量种子用户反复迭代验证。最终，这个项目被我们挂起了。从产品战略到具体功能，“正确的事”，特别再加上“难而正确”的自我感动，往往会成为一个花团锦簇的陷阱。 当然了，我肯定没有乔布斯、马斯克的远见卓识。但你的老板、你的业务方有么？既然大部分情况下没人知道“正确的事”到底是什么，就不要上来谈比“正确地做事”更重要了。 正确做事 先有“正确地做事”，后有“正确的事” “世有伯乐，然后有千里马”。两者的关系恰恰是反直觉的：管理层更应该关心组织是否能够“正确地做事”，因为只有以正确地方式做事，才能以更大的概率、更小的代价找到“正确的事”。 软件工程几十年发展正体现了这种理念。从瀑布模型，到敏捷方法，软件工程认知变迁的核心，是承认软件项目很难从一开始就明确所有正确的需求。而只有采用正确的做事方法，在持续交付的过程中不断调整，才有可能踩准正确的事，否则后者永远是镜中花、水中月，求而不可得。我甚至觉得，小到项目、企业，大到社会、国家，“正确地做事”都更胜一筹，没有法律、标准、规则，没有“程序”正义，“结果”正义虽可能碰对，但更容易跑偏。不能本末倒置。 那反过来，我们产研团队专注于正确地做事，就可以将“正确的事”这口大锅都甩给业务方了吗？我认为也不妥。唯业务马首是瞻的产研团队，恐怕同样危险。苏格拉底说，“未经省察的人生不值得过”；一样的，未经产研提炼的业务需求也不值得做。实际上，业务与产研应当有机结合，形成共赢的合作模式，而不是错误地认定哪一方该为“正确的事”负全责。双方应该共同以“正确的事”为最终目标，并在通往最终目标的路上“正确地做事”，业务给出需求的原材料，产研对需求进行加工提炼，并且配合一起迭代和回顾。高效能团队无一例外，业务和产研都有着健康的关系。 “正确地做事”举例：需求价值评分 业务与产研正确合作模式的关键是形成有效的反馈机制。思码逸很多客户正在践行的“需求价值评分”就是一个很好的例子。常规做法很简单： ·在一个需求创立之初或者进行需求评审时，业务方和产研应共同设立需求要达成的价值目标。 ·对于可量化的目标（如点击率），建议设定具体的目标值；如果不能量化，可以主观评级，明确评级标准。 ·在需求交付后的预定时间内，业务方和产研共同回顾需求价值目标。如果有量化指标，可按实际值除以目标值计算评分，比如大于或等于 ���% 而小于 ���% 的分数为 �；如果只有主观评级，按实际达成的等级算分即可。 正确做事 这样的过程就建立起“假设 - 验证”的小闭环，通过业务和产研的协作，不断走向“正确的事”。我们还可以通过数据度量帮助团队不断精进，基于某几个迭代或周期内需求价值评分的统计，可以绘制出如下图所示的“需求价值达成率漏斗”，帮助我们直观看清楚需求交付价值的现状和改变。 可能有技术管理者紧接着会提出一个问题：我们太忙了，哪有时间这么详细地评价每个需求？ 其实需求价值评分也可以“丰俭由人”，通过需求分层分类。以敏捷项目为例，可以自然按 epic和 user story 分两层。通常 user story 数量较多，如果无法都做到价值评分，那就从 epic 抓起，这一层应当与产品乃至企业战略对齐，有明确的量化指标或达成标准。当然，user story 理想来说应符合 INVEST（independent、negotiable、valuable、estimable、small）原则，独立有价值，所以尽量能够做到评价和回顾。实际当中，只有一部分 user story 设置了目标也很好，不强求但可以引导。上图中最顶端的漏斗就是统计了多少需求带有指标值。 管理不是非黑即白，而是用数据牵引团队向正确的方向前进。 除了需求分层，还可以通过分类划定需要价值评分的范围或者排除不必要的类型。例如，我们一个客户将业务需求分为目标型、风控型、合作方要求等。目标型需要走需求价值评分的流程，但合作方要求就跳过，这种需求……懂得都懂。有了分类，很多企业还会看每个迭代各类需求做了多少，以优化资源分配。 进一步地，单纯看需求数量仍存在不足，因为需求的颗粒度不一致，导致统计结果不能准确反映实际。特别是从资源分配的角度，如果我们想回答“团队的带宽是否都花在了正确的事上”这类问题，就需要对完成需求的工作量做评估，而不能仅仅数需求个数。 通过代码度量是一种无侵入、低成本的方式，但显然又不能只数代码行数。所以建议引入程序分析来计算代码的规模和复杂度，以校准需求颗粒度，帮助看清研发带宽的分配。 “正确地做事”知易行难，如果在组织内缺乏共识和明确的指引，一样会被“高高挂起”。在这个系列中，我们将持续分享相关的技术与实践经验！ 正确做事 为什么技术高管汇报一定要用数据说话？ 任晶磊思码逸 创始人兼CEO 莎士比亚曾说：“一切不以结婚为目的的谈恋爱，都是耍流氓。”我们可以说： 丨一切不以数据为基础的技术汇报，都是耍流氓。 Linus 有句名言：“Talk is cheap. Show me the code.”思码逸公司帆布袋上一直印着：“Talkis cheap. Show me the data.”按这种逻辑： 丨技术高管汇报没用数据说话就很 cheap…… 这周 TGO 鲲鹏会北京家宴安排在德云社，让我想起郭德纲的段子：“科学家会武术，谁也挡不住！”借个押韵，我们还可以说： 丨技术高管会用数，谁也挡不住！ 重要的事情说了三遍，下面我们讨论为什么。 告别“小作坊”，数据是管理升级的必备 首先，研发团队达到一定规模后，数据是管理升级必备的手段。如果老板们对软件工程存在误解，我们不妨类比制造业，在国产车崛起之前，中国企业学习丰田的精益管理多年，其核心之一就是通过数据实现对生产过程的精细化管理。例如，软件工程中广为使用的“看板”（kanban）就借鉴自丰田的生产实践。数据在这个过程中起到了不可或缺的作用，它不仅是洞察问题的关键，更是持续改进的基础。类似地，做好软件工程，也同样需要数据驱动。简单认为靠自己和团队交流就能掌控局面，就像认为单靠“人治”能高效管理大规模工业生产一样，是脱离实际的幻象，甚至可以说是一种落后的思维方式。软件研发是一项极为庞杂的系统性工程，哪怕管理能力再卓越、记忆力再超群，也没有人能事无巨细地看到每一个细节。这些都需要依赖成熟的研发数据分析工具，下图是思码逸 DevInsight 产品中的迭代表现看板，可以清晰地回答这些问题： 正确做事 ·各个迭代的需求大部分等了多久才交付？·各个迭代交付了多少需求？·各个迭代花了多少带宽在新功能，多少带宽在修 bug ？·研发的负载中有多少同时在开发的需求？·各个迭代发现的缺陷有多少？ 管理动作“知易行难”，没有数据抓手难以贯彻执行 在任何有规模的组织中，落地管理动作都很难。“老大振臂一呼”就能“众人云集响应”，只是一种理想，而现实很骨感。没有数据抓手，管理动作全靠人盯恐怕很难落地。 我们服务的一家传媒集团，正在进行数字化转型，研发部门花了一年多、大几百万上了一系列DevOps 工具和流程，但各个新