本文作者：王子嬴 — CODING 战略发展部总监 负责 CODING 团队战略规划及生态合作，长期关注软件工程领域的模式及产品创新。信通院云原生产业联盟 DevOps 工作组专家成员，参与编写信通院《研发运营（DevOps）解决方案能力分级要求》。
本文节选自《软件研发效能提升实践》一书第十五章——研发效能的规模化实践。
在数字化转型、软件“吞噬”世界的时代，软件研发效能已成为企业的核心竞争力。本书系统地阐述软件研发效能的框架，以及有关管理实践、工程实践、组织实践、技术实践、度量实践、规模化实践和工具落地等方面的内容。本书通过良好的框架设计和组织，详细介绍了前沿颇有成效的软件研发效能改进和提升案例。
本书适合 IT 行业的各类从业人员阅读，无论是技术人员、项目经理、产品经理，还是团队管理人员、资深专家和高层管理者，都能从本书中得到启发。
以下为本章正文——
IT 扩张的困境
百人左右的研发团队很难碰到研发效能规模化的问题，因为业务与研发相对合作紧密、规模有限、管理层与一线贴近，只要提高每个小团队的研发效能，整体的工程效率自然就提高了，这也是为什么百人左右的研发团队在使用了恰当的工具后，可以在无指导的情况下，自行建立软件开发的节奏，快速获得整体效率的明显提升，但在千人规模的研发团队中，情况就不同了。
部门墙高筑
千人规模的 IT 团队往往内忧外患，内部 IT 团队无序扩张，外部业务部门争抢 IT 资源。业务追求完美的 IT 展现，这与IT 部门有限的资源相矛盾，而当业务产出出现问题时，业务部门往往抱怨 IT 团队的支持不够，冲突明显。
投入和产出较难衡量
在软件研发行业内，优秀人才的薪资受互联网头部企业的影响，已然挑战了许多行业的薪资体系。IT 负责人往往顶着巨大的成本压力进行团队扩张， 但是只能获得笼统的、难以落到具体团队或个人的产出，造成了巨大的管理困难。
职能冲突
业务复杂性的加剧和微服务化带来了应用的复杂性，但在实际应用中出现的问题往往难以被定位，运维团队最终成了拉群工具人和传声筒。为了解决问题，运维团队会开发大量的运维工具，以保障在权限安全的情况下，开发人员可以获取必要的信息以解决线上的问题。运维团队进行软件开发，开发团队为线上稳定提供保障，因此开发团队与运维团队的职能边界受到了很大挑战。在开发团队与运维团队不由同一个管理者负责的情况下，这种职能边界的问题会演化成部门冲突。
不同业务类型
带来的管理统一性挑战
在传统 IT 程度较高的行业中，往往会存在不同开发节奏的 IT 产品，“双态 IT”说起来简单，做起来困难，团队目标、团队评价难以拉齐，对基础工具和上下游的要求不一致，难以统一管理。
以上这些问题，究其根本原因，是软件工程仍未完成完整的工程化，仍采用作坊模式，产出优质与否都依赖于强有力的一线管理者。优秀的一线管理者可以提高整个团队的产出能力和产出质量，好比在传统的作坊中，一个老师傅可以带好一班学徒，做出很好的产品，但这种依赖于人的模式难以复制和规模化。
传统的 DevOps 转型强调通过工具提高整体的自动化能力，强调通过人和文化提高整体的组织能力，本质上希望批量复制出大量作坊，希望有 100 个好的老师傅，带 2000 个学徒，这种策略要求老师傅可以批量化产出，并且老师傅不会流失，同时企业可以通过成熟的管理手段管理好老师傅。这种机制的理想化程度过高，尤其是在软件人才竞争激烈的今天，大概率不能达到预设的效果。
想要解决软件工程工程化的问题，长期来看就需要将软件行业的流程、规范落地到工具中来，降低团队产出对人的工程认知和质量认知的能力依赖，重塑行业内的人才结构，我们将在下一章“研发效能中台实践建设”中具体讨论这一问题。
但在短期内行业相关产品成熟度仍然有限的情况下，作坊模式仍将存在，那么，我们如何实现 IT 的规模化研发效能建设，以支撑业务的高度发展呢？我们来看一看腾讯的案例。
腾讯：从头到脚的敏捷
说到软件研发效能，就不得不提及互联网企业。互联网企业对各大行业产生了较大的冲击，除了用户广泛、玩法新颖，互联网企业高效率的最大依存点是将业务团队与 IT 团队合并，让 IT 敏捷的结果直接被反映在业务上，带来业务的成功。
腾讯就是这种模式的典型代表。
文化底色
腾讯的敏捷是写在组织和文化里的，腾讯平均 7 年进行一次组织变革，以应对变化的市场和业务的变化。
当腾讯成立 CSIG 发展云业务时，曾被质疑“腾讯的基因是做游戏和娱乐，没有基因 To B”，或许大家已经忘了腾讯最初也没有游戏业务，做游戏业务的时候也曾被质疑“没有基因做游戏”。对腾讯来说，基因不重要，重要的是持续进化和学习的底层文化。这种底层文化帮助腾讯走向开放生态，走向游戏，走向移动互联网，走向微信，走向产业互联网。
腾讯的业务团队与 IT 团队天然融合，浓烈的产品经理文化背后是产品经理对业务和 IT 团队全面负责，即产品经理无限责任制。
敏捷用人
腾讯不止面向业务持续进化，对人和岗位也一直在持续进化。虽然拥抱变化是阿里巴巴提出的，但笔者认为对这个理念贯彻最好的是腾讯，“岗位说明写成的时候就是过时的时候”，充分地向下放权和充分的自由度，让腾讯的人才可以发挥最大的价值。
“活水”机制（工作满一年的员工可以自由地在内部跳去别的部门）也是腾讯敏捷用人的力证。在腾讯处于快速扩张期时，传统自上而下的人员调动方式导致腾讯人力的宏观失能，无法对员工价值和业务进行准确判断。“活水”机制激发了组织的自我修复功能，加速了落后业务的死亡和新兴业务的发展。
在服务企业时，笔者观察到许多企业也想通过“活水”机制激发组织活力，但往往最终造成内部相互抢人，哄抬“价格”，使部门之间产生矛盾。腾讯的“活水” 机制有许多限制和原则，如“活水”不能涨薪、未晋升的员工会被主动推送“活水”消息等。
敏捷组织
腾讯相信，小的组织才是好的组织，因此赛马机制毫无意外地成为腾讯的典型文化之一。
对业务的敏感嗅觉只有在一线才能被培养出来，当业务领导走得更高，更加关注管理和全局时，往往无法提前预知业务的发展方向，如果仅仅依赖于汇报，决策的周期就会很长。赛马机制本质上是通过放权一线，相对低成本地验证最小 MVP 和可靠的团队，以便可以获得更多流量及资源的支持。
举例来说，腾讯会议团队在发展初期仅有 10 余人，依靠对产品场景的深入理解， 他们快速上线了腾讯会议的初期产品。随着新型冠状病毒肺炎疫情的到来，大家发现腾讯会议可以很好地解决远程沟通问题，最小 MVP 验证成功，这时腾讯立刻将海量的宣传资源投向腾讯会议，对研发、运维、测试资源也都临时做了调配，腾讯云的大量研发人员都参与了腾讯会议 2020 年春节的重保工作。同时，借助于敏捷用人的机制，腾讯会议团队也得以在短时间内迅速扩张，目前已有几百人的规模。
从腾讯会议的案例中，我们可以看到腾讯会议并不是有组织的、提前规划的成功，而是系统性的创新机制造就的万千成功可能性中的一种。
有关具体的组织变革方法和模型，本书的“组织实践篇”会有更多阐述，这里不做过多介绍。从腾讯的案例中，我们可以看出通过将 IT 与业务深度绑定及决策权下放的方式，让产品经理离业务和研发最近，这样产品经理就成为作坊里的“老师傅”，再以良好的创新分润模式确保“老师傅”有持续进行创新的动力。在笔者观察的企业中，笔者认为腾讯和字节跳动在作坊管理方面做得较好。
但对大多数尤其是有历史的企业而言，采取腾讯的组织方式可能是非常困难的。绝大多数企业仍然是“带着镣铐跳舞”，由于历史和组织的原因，业务依然归业务， IT 归 IT，运维归运维，这种仓筒型的组织架构在 IT 是成本的时代可以更好地复用人力资源，在 IT 是业务动力的时代就显得笨拙而臃肿，但企业整体的组织方式在短期内往往难以彻底得到调整。这类企业会通过在信息中心成立一个研发效能部、 DevOps 建设组等方式，保证有人在持续关注整体团队的研发效能改进。
进退两难的研发效能部门
传统企业的研发效能改进往往受市场变化的影响，如金融行业的供应商软件体系无法支撑业务的快速变化，不得已扩大软件自研团队的规模；汽车制造行业受到造车新势力的挑战必须构建软件体系等。越来越多的企业正逐渐变成软件企业，将业务的核心竞争力构筑于软件之上，此时，软件团队的组织能力正成为同行之间拉开差距的核心抓手。
因此，实际的改进决策是从高层发起，服务于业务部门的，但最终的落地是由研发效能部门、技术规划部门、DevOps 改进部门等承载的。这里的研发效能部门其实是 Magic Team，其人员没有权限改变组织的运作模式，无法改变实际的业务形式，甚至业务代码也不是他们写的，却要帮助企业完成业务代码的高效交付。
在实际的落地过程中，研发效能部门会碰到种种问题。
缺乏北极星指标
北极星指标是业务用语，用于表达在产品的当前阶段与业务/战略相关的绝对核心指标，一旦被确立，它就像北极星一样闪耀在空中，指引团队向同一个方向迈进，团队仅需努力提高这一数值即可代表业务的成功。
软件的生产本质上是软件设计与实施的过程，一半工程，一半艺术。软件效能提升的北极星指标是什么？发布频率？线上缺陷数？完成的故事点数量？这些数据或主观、或片面，无法成为绝对核心指标。
对缺乏北极星指标的研发效能部门来说，团队的目标如何界定呢？是否会带来一些问题呢？
研发效能部门的工作如何考核
“如果你无法度量他，就无法管理它”，百人级企业可以快速进行研发效能提升的核心在于对度量的需求小，业务模式简单，研发效能的提升与变化可以在实际产出中明显地反映出来，不需要价值证明的过程。而规模化企业内的研发效能部门想要证明自己的工作价值，往往需要通过先行设计的具体度量指标，或者过级之类的方式来佐证。
在这样的背景下，行为往往是变形的，研发效能部门的目标变成提升某个具体的指标，或者让业务团队做出满足级别要求的行为，而非帮助研发团队获得业务成功。这样，最终结果往往是，研发效能部门主导完成了 DevOps 评级，或者单元测试覆盖率达成了某一指标，但是业务团队怨声载道，因此他们需要花费大量时间来配合，但实际的效率提升却很小。
相对于帮助研发团队提高业务产出，设立一定的规范并要求团队落地是一个更容易实现和更好衡量的目标。因此，研发效能部门往往将自己定位为管理者，希望通过规定研发团队的行为来达到管理的目的。但是在作坊模式的前提下，这种通过管理老师傅的方式往往是运动式、以汇报为目标、数据失真的，非但不能帮助团队提高效率，反而会对团队造成负担。
那么，如何破除“越提效负担越重”的魔咒呢?
服务者还是管理者
在服务客户的过程中，我们也看到了比较好的案例。
某金融企业将研发效能部门定位为服务部门，其核心目标是帮助 IT 团队取得业务成功、提高 IT 团队的幸福度。研发效能部门建立了工具体系，并且基于 IT 团队的业务需求，逐步帮助各团队使用工具，还根据各团队的业务需求、工程情况等设立相应的约束及规范，而不是通过行政命令进行统一要求。研发效能团队的考核指标为服务的客户特性指标的提升情况及满意度。
在这样的运转方式下，IT 团队的整体满意度较高，相关约束的落实情况较好。同时，研发效能团队会根据改造成本对不同业务进行分层，优先辅导杠杆率高的团队，使得总体效率更高，但挑战是时间跨度长，对服务者的要求高。
核心投入是人
与常见的认为研发效能部门属于对内部门，无须业务知识不同，长期对内的部 门很难与业务部门感同身受，建立切实能帮助业务部门的流程，长此以往，研发效能部门和业务部门容易形成相互对抗的结果。
许多客户为了解决研发效能领域的专业性问题，引入了外部咨询团队来帮助内部梳理流程，为团队分层，重塑团队人员的职责。这是一个很好的思路，通过外部专业团队对业务团队进行分类，根据不同类别设定岗位职责、协作流程，快速搭建整个研发效能提升的脚手架。但这仅能解决短期问题，因为研发效能的解决方案不是一成不变的，所以客户需要长期的、跟随业务发展的工程规范。我们不能一方面希望用 DevOps 的方式解决业务快速变化的问题，另一方面希望一套 DevOps 方法和规范可以毫无演进地用三五年。
因此，在服务客户时，我们会建议客户投入优秀的业务 IT 人员组建研发效能团队，引入外部咨询团队的专业调研方法，为研发效能团队打造合适的软件研发流程规范。在这个过程中，客户应建立软件研发效能团队的方法论，打造一支熟悉业务、理解效能、内部信任、长期服务的团队，并通过与具体业务 IT 团队对应的关键效能指标对该团队进行价值衡量。这样，外部专业团队短期快速建设，内部服务团队长期打磨优化，双管齐下可以更好地实现研发产出与团队幸福感提升的目标。
研发效能规模化提升的几个阶段
对研发团队来说，用好工具，提高软件工程师的效率是第一步，而系统化地提高软件研发团队的效率是第二步，即通过提高软件研发团队的产出取得业务收益才是最终目标。因此，在服务客户的过程中，我们一般建议客户分三个阶段逐步进行研发效能规模化的提升。
阶段一
构建工具，实现自动化
此阶段的核心目标是通过自建或者外采 DevOps 工具平台，实现一定程度的自动化和线上化，通过持续集成、持续部署、自动化测试等，替代目前需要手工操作 的事项。在这个阶段，利用工具能力可以快速给业务团队带来获得感，减少不必要的工作，让业务 IT 团队更容易接受后续的流程规范。
同时，在辅助团队使用工具的过程中，咨询团队或 DevOps 资深工程师会通过访谈调研等方式收集业务团队现行的状况信息，并逐步进行体系规范的建设。
阶段二
初步建立体系规范，通过工具落地
设立体系规范的目标是让各环节的人员可以按照既定的流程，有预期、有序地完成业务需求，形成规范化的软件生产过程。
体系规范包含组织能力、工作流程和人员能力 3 个方面。
组织能力是指团队内的组织分工、岗位职责、考核方式、与外部门的权责区分。组织能力的改变往往最依赖于外部咨询团队的专业建议，他们会基于业务的复杂度 提供不同的模型。
工作流程是指工作的阶段性产物在不同职责人员之间流转的过程，包含内部工作流程及与上下游团队的对接流程。一般来说，工作流程会呈现在工具上，而不是靠人进行管理。
人员能力是指团队内关键的流转岗位人员对软件工程的认知能力，其中人员包括研发效能部门的工作人员、关键管理者、一线项目经理、产品经理等。
外部咨询团队在建立体系规范的过程中，往往需要与客户进行多次磨合，这里我们提倡用敏捷的方法推进体系规范的建立，并在过程中不断改进与尝试，直至最终形成模型，如图 15-1 所示。一般来说，外部咨询团队会依据团队的交付形式、人员规模、业务变化速度等设计多套模型，以符合大多数通用的情况。
阶段三
以业务目标为本，逐个团队服务调优
IT 最终的目标是服务于业务。在组织结构上，业务 IT 团队需要更加靠近业务， 对业务负责；而在研发流程上，业务 IT 团队也需要根据业务的变化情况进行合理的修正。
图 15-1 以敏捷的方式落地敏捷
研发效能部门在这个阶段会发挥巨大的作用，他们需要依据业务模式、业务需求对模型进行优化，并辅助团队落地实施，在工具上形成完整的闭环，最终形成团队的“无意识流程”，即团队成员无须了解实际的业务流程，仅需要根据流程的反馈行事即可，如不需要了解代码在提交后是否还需要进行代码检查，只要提交即可，有问题会被自动驳回。
研发效能规模化提升的目标是减少人的不确定性对团队的影响，但这个过程离不开优秀人才的主导，这就需要懂业务、懂软件工程的人才切实地投身于研发效能规模化提升的研究上。
DevOps 只是软件工程行业发展的一个阶段，它提倡的理念往往是现在大多数企业数字化转型所欠缺的，如 IT 业务一体化、快速落地、快速反馈、快速改进。
腾讯的实践告诉我们，工程化程度不一定越高越好，在企业战略允许的情况下，最大化地放大作坊模式的创新性产出也会给业务带来勃勃生机，但将这种做法放在注重质量和风险的 To B 或金融业务中不太合适。
DevOps 不是万能解药，当将它投射到具体某个企业时，我们需要依据企业的战略目标、业务形态进行落地化的改造，每个行业都需要走出一条有行业特色的研发效能规模化提升路径。
