一 团队效能的影响因素

1 团队效能的影响因素

首先探讨下企业人员规模增长对效能的影响。刚开始公司初创期，十几二十人组成全功能团队，此时团队分工边界并不明确，大家在一个非常敏捷的状态下工作，互相会进行一些补位，比如技术去做一些产品的事情，开发去做测试和运维。这种情况下团队协作起来基本上没有太多沟通损耗。往往瓶颈在个人能力上。此时初创团队为了更快的完成业务需求，在效能工具选择上更关注单点效率，比如好用的流水线工具、测试工具等等，上手门槛是第一考虑的因素。

当团队逐步扩张，人员分工开始专业化，多职能协同的问题开始凸显出来。如何合作，权责如何分配，大家之间的协作流程是怎样的，是团队非常关心的问题。此时团队并不太会因为个人能力而决定产品的成败，如何提升中位能力是关键问题。此时在效能工具的选择上会更偏向于有一定解决方案的产品，比如分支管理模式，测试环境管理模式，DevOps如何落地等等。这些工具的使用可以很大程度去提升团队之间透明度，提升沟通效率。比如分支管理模式的选择，解决开发与测试团队沟通的问题，DevOps模式更是将绝大部分运维工作交给开发独立完成，从而通过减少沟通来提升效率。

随着团队业务进一步扩大，开始出现有明显业务边界的产品，此时在沟通协作成本会被进一步放大，大家更加重视目标、共识和结果。当然可以以战役模式去承载目标、共识和结果，是非常好的一种汇聚人力资源，topdown的提升执行效率的手段。从另一面也要意识到，战役并不能解决所有边边角角的跨产品、跨团队协同问题，如何在日常状态下去解决这种兵力分配、业务技术拉通的问题才是关键。

2 软件服务架构对研发效能的影响

接下来看另一个问题，就是服务架构对研发效能的影响。服务架构其实和组织架构有很强的关联关系，比如在扁平化架构下，团队各自独立互相关联性不强，有很高的自给率，这里的自给率是指独立完成某个需求的能力。

在网状架构下组织形式往往是一体式的，由同一个部门老大带领，团队之间紧密配合，我中有你，你中有我。在这个阶段架构复杂度高，缺乏抽象。但是因为业务流程相对简单，做起需求来各团队点对点沟通也不是太大问题，决策链路短，共识快。从另一方面看，技术债务也在累积，当业务之间耦合到一定程度的时候就会出现维护债务的人力投入开始大过新需求人力投入。中台架构是解决此问题的一个路径。

到中台模式下，各种业务模块开始被抽象出来，随之技术侧也需要组建技术中台，将原来各自团队持有的工具开始收敛，流程开始统一。不过随着前台和中台出现分工后，各自发展路线独立设计，此时就会出现部门墙、前台业务自给率低、达成优先级、交付时间等共识很困难的问题。

经过这三种产品架构、技术架构、组织架构的分析，相信大家可以理解团队不断演进过程中面临的效能困局。

3 技术演化带来的效能变化

说完了协作问题，再来看技术的演化是如何影响研发效能的。先粗略的看看过去几年的几个技术变化。在2008年开始业界提出了微服务、持续交付、DevOps等等一系列的概念，延续至今。与此同时阿里巴巴也对电商核心系统进行了服务化改造，后来又发现服务多了，管理出现了难题，只有DevOps可以消除瓶颈，释放生产力。这几件事其实内部是有一定逻辑的，也就是业务驱动技术变革，技术促进架构变革，架构又推动研发模式变革。

再看最近几年日益兴盛的k8s生态，大致相同，新技术的应用，造就了很多新的架构模式比如serverless，小程序等，这些新的架构给原有的研发模式也带来了巨大挑战，比如在Function as Services模式下如何管理代码分支和环境，测试工具和方法会不会发生变化，测试团队的职责会不会发生变化等等。当然，大家可以再设想下，当未来服务数量进一步爆炸，架构复杂度进一步提升，这种复杂度超过人的掌控时，会出现什么样的变化，我们需要使用怎样的工具去解决那个时候的效能问题。

4 企业研发效能的制约因素

结合上面从人员、架构、技术三方面的分析，在进一步提取中间的关键因素，会形成这样的一个环。这三个关键因素就是成本、人、和人与人之间的协同损耗。成本是不可能无限放大的，所以是这个环里面的最关键约束。另外因为人的能力参差不齐，那么就无法创造出完美的架构和完美的组织设置，这里面就会出现大量的协同消耗。刚才也提到了，技术债务是会累积的，协同消耗往往会随着时间不断放大，消耗更多的人力，在固定的成本约束下会导致更少的业务人力投入。这个环就会出现负反馈，也就是越来越差。所以才有了探讨研发效能这个问题的必要性。

通常会采用技术去武装人，提升个人能力上限，这是笔者认为的重要破局点。接下来需要适应当前团队组织和架构现状的协同流程，去降低损耗。需要注意的是这往往只能带来改进，在固有架构和组织模式不变的情况下很难根本上改变局面。最后可以使用一些工具去让我们的工作更有效率，以前手工做的现在自动化去做，可以腾出更多时间去聚焦业务价值输出。

三管齐下后就可以有效驱动这个环进入正反馈，团队效率更高，技能提升更快，协同更加顺畅，业务发展好了又可以投入更多的人力成本。

在阿里自身的实践中发现，就是在在不断地改变这些要素，遇到瓶颈投入改进，走出负反馈，进入高速发展，然后又遇到瓶颈。

那么这些问题如何系统化的被提升或者解决，就需要一套适合的效能工具体系。

二 效能工具体系的建设思路

1 三种典型的研发团队

在我们的实践中会可以归纳出以下三种典型的研发团队。

第一种是前后台的应用开发，电商、SaaS等都是典型的形态。这种业务形态在工程侧比较容易标准化，工具比较完善，尤其是云原生技术的发展，让业务的关注点更加向上转移，底层技术越来越云化，越来越黑盒。

第二种是底层基础软件研发，业务特点是用户交互简单，但技术深度和复杂性较大。这种软件往往是有状态服务，并且对硬件基础设施有强依赖，以至于在运维侧就较难标准化。另外在开发侧也存在技术栈复杂，多人在一个模块集中研发的情况，较难像前后台应用那样通过服务拆分进行解耦加快迭代，同时也衍生出比如分支管理、二进制版本管理等新问题。这种开发态和运维态的差异性导致了工具体系的差异。

第三种是线下交付型的大型软件研发，以混合云、行业软件为代表的。因为系统耦合复杂，叠加客户专有环境因素，对多团队协同能力和交付运维系统能力要求很高。相对于第一种前后台应用开发，对版本管理、集成升级、远程运维能力特别关注。

2 分层建设效能体系匹配复杂协同场景

因此，面对不同的研发场景，不同的侧重点，需要对效能体系进行分层和抽象。在这里可以把整个体系分为4个层次，从下到上是基础底座、工具层、协同层、场景化。

在基础底座中应该关注产研核心资产的数据沉淀，确保整个体系的数据一致性，通常会提取研发体系中核心对象进行下沉，比如团队、项目、应用、代码、制品等。

之上是最关键的工具层，工具定义为解决单点问题的自动化手段。其中开放性和被集成性应该是工具最重要的能力。比如常说的api first就是这个道理。

再往上是协同层，这一层产品聚焦于解决人和人之间的信息传递问题，以及将这种协同流程进行线上化、标准化。通过对不同领域协同关系的抽象，并且串联单点工具，最终让使用者们可以在线完成一个完整的工作。

通用性、可配置性和体验有时候是矛盾的，因此还需要场景化层的产品去解决各自领域的精细化用户体验问题。可以看到最近几年业界的趋势就是如此，通用的研发平台在不断成熟和做深，而场景化研发平台不断产生，通过集成下层工具能力，快速覆盖细分研发场景。

目前云效正是按照这个分层思路在建设研发工具体系，希望可以将更多开发者纳入到这个体系中来，一同构建这个复杂的生态系统。

3 每个团队定制自己的效能方案

公司除了提供标准化的研发流程体系以外，每个团队都应该有自己的效能方案来满足自己团队的文化和习惯。在这里可以有这两三个层面可以去提供定制。

一个是团队工作台，这是团队的知识沉淀场所和协同空间。里面提供多种视图来浏览工作状态以及待办事项、进度等。还会为leader提供一些列管理工具。

另外两个是团队协同流程和工具，推荐大家深入学习效能提升方法、团队管理方法，并且结合团队现状，个性化到系统中，甚至创新出更适合业务特点的工具，逐步释放团队生产力潜能。

通过统一平台可以守住团队效能的下限，但是效能上限需要团队自身的努力来突破。

4 进一步的效能提升建议

基于以上分析，笔者提出以下三个建议：

第一个是团队需要着眼于从目标、业务、产品、研发全流程进行效能提升。举个例子，一个问题：测试团队如果成为交付瓶颈，是不是完全是测试团队的责任？很显然，这里面可能是需求侧用户链路分析不全面，或者开发团队交付质量差，更或者是架构设计不合理导致可测性不强等等，这些都会加重测试团队负担，让测试团队成为瓶颈。因此团队负责人需要端到端的去思考，掌握方法并具备宏观视野，而不是头痛医头脚痛医脚。

第二点是团队需要为自己的效能负责，是第一责任人。自己最了解自己的团队，往往采取的措施也是最有效的。

第三点是提升团队产品设计能力、技术能力，减少技术债务，构建内建质量对效能提升非常重要。效能工具体系只能提供最基础保障，要让团队效能更健康，需要从最基础的软件工程细节入手，逐步改善，在这方面没有银弹。

三 效能方法体系的演进

1 从强调工具流程走向强调价值交付

当团队分工开始细化以后，从组织角度更加专业化，资源效率更高，但是从业务价值交付的角度来看，周期非常长，而且中间还伴随着各种等待。

因此可以得出这样一个结论就是局部效率，并不代表可以高效的交付业务需求。局部效率有很多工具和手段去提升，这是一个相对收敛的问题，甚至可以通过加班去弥补效率的不足，但是高效的交付用户能够感知到的业务价值并不容易做到，上面这张图就说明了这一点。同样也并不代表可以持续的高效交付，因为从本源上没有办法保障永远用全局最优的组织和架构以及流程去对应，甚至没有机制去发现瓶颈问题。当然也并没有办法去回答业务成功问题，因为业务团队与产研团队距离过远，这种部门墙阻断了产研去思考和理解业务成功与自己产出的关系。

2 实现端到端可见的业务价值

所以笔者认为效能提升首先要做到的就是端到端可见的业务价值。从业务团队到产研团队有以下几个实施路径。首先是建立以业务价值流为视角的协作链路。以往多半是通过项目管理软件解决产研团队的协作问题，以一个产品或者团队为单位组织需求、缺陷、任务等等。在新的体系中需要将业务团队也纳入其中，并且拉通业务价值与产品研发需求、任务之间的关系，从而实现端到端透明可视。

在产研侧采纳大量自动化工具仍然是基础工作，除此之外需要将工具产出的数据能够链接到价值流上，并且尽量沉淀到数据平台。这里可以采用比较简单的评判方法，比如有多少百分比的工作是在线完成的，是否有统一的数据模型去积累数据。

在前面两步完成后，仍然要解决对齐业务、产品、技术团队目标的问题，比如业务诉求的优先级是什么，时间点是什么，其中的各环节瓶颈是什么，并且在过程中实时追踪。各环节负责人可以感知到异常事件和资源瓶颈，第一时间去着手解决，达到高效的目的。

第三步要做到持续高效，一定要基于前面积累的数据去量化分析，此时数据的魅力得到展现，越多的工作在线，分析会越准确。哪个团队在积累债务，哪个团队在积累资产，哪个团队是阻塞点，是调整架构还是调整组织分工，这种决策会更加有效率。

3 ALPD—新一代的精益产品开发方法

基于以上的分析，再结合了精益思想、云思想、以及架构设计思想等多方面，可以构建出来的一套方法体系。

这个图蓝色部分是本文关注的重点。其中分为三个部分，全链路数字化的精益协作，解决业务和产品技术协作问题。第二部分是领域驱动为核心的技术实践，解决日益复杂的架构问题。第三部分是云原生的工程实践，用这套工程实践去进一步释放云原生对每一个业务开发者的红利。

4 全链路的精益协作

首先全链路的精益协作。之所以称为全链路是在这个方法中将业务、产品、技术等多种角色全部纳入。最关键的是分层理念，分为业务、产品和技术三部分。分别对应业务和目标管理、需求和产品管理和团队交付视图。

在这个模型下，配合一系列高效率在线化工具，让尽可能多的工作在线完成，数据以价值流为核心串联和透明化，最终达成精益协作的目标。

5 领域为核心的技术实践

再来看领域为核心的技术实践。这里分为三个部分，分析、架构以及对应的实现。分别为业务引领的领域建模、领域驱动的微服务架构、以及契约导向的软件实现。

领域模型的设计是产品以及架构设计的核心，良好的设计可以轻松地解决技术团队的变更、测试、交付耦合问题，提升系统可测性和可运维性，并且通过一些防腐设计，降低技术债务对整个系统的影响。

6 云原生的工程实践

最后是云原生工程实践。这张图把工程实践分为了三个部分，最底层是不可变基础设施，中间是持续交付流水线，最上层是质量守护体系。

重点在中间红色部分，也就是GitOps Engine，用这个引擎来全面落地所谓的以应用为中心的IaC体系。笔者认为IaC的设计是开发者对云的运维界面和使用方法的重大重构。通过代码这种最符合开发者习惯的形式，叠加开放更多自定义能力，可以进一步释放云原生的技术红利。