阿里巴巴超大规模中台型团队研发提效实践
简介： ALPD及云效DevOps平台在超大规模中台型团队如何进行研发效能提升
中台型团队效能提升遇到的挑战及应对策略
“数字供应链中台”支撑了阿里巴巴旗经济体30余个“大业务”，100余个“二级业务”；该中台团队由1000多人组成，分为26个域；来自不同行业的需求会被不同的行业PD（产品经理）拆解为不同的子需求，协同不同行业或中台团队一起才能完成交付，生产关系错综复杂。如何在这种业务优先级高、团队规模大、协作关系复杂的团队里提效，是我们遇到最大的挑战。
在这样大规模大中台团队里提效，首先要面对的一个“灵魂拷问”是：中台团队是先做好平台沉淀，还是先支撑好业务发展？阿里巴巴有一句土话叫做：既要、又要、还要。所以我们对这个问题的回答也是：既要沉淀中台服务化能力，又要快速响应业务。 中台的服务化能力是一个基础，只有基础打牢，才能更快地响应业务。基于这个思考，核心TL一起共创，并确定愿景：打造世界最先进的软件交付供应链，赋能经济体业务发展和高效创新。为此，制定了两个目标： 一、加速各行业需求的交付速度：需要做到将业务需求平均交付周期缩短到21天；其中7天内完成需求分析，14天内完成需求交付。 二、持续提高中台的服务化能力：拆解到各产品域的需求支持策略满足“3、6、1”，即30%的需求通过配置化支持，60%的需求通过扩展点开发支持，10%的需求才需要中台定制化开发。
基于“7+14”和“3、6、1”两个目标，我们制定了“目标牵引、组织升级”的策略。首先，对组织架构进行升级。新组建了实施团队和行业特种兵团队。对于一些可以由套件直接支持的需求，由“实施团队”进行快速实施落地；可以基于中台服务化能力扩展开发的，则由“行业特种兵”牵头交付；而“中台团队”则更专注于沉淀中台的服务化能力。
行业特种兵团队的“7+14”最佳实践
基于当前的现状，提效目标设定的非常有挑战。为了证明这个目标是可达成的，我们选择在新组建的行业特种兵团队，来打造一个最佳实践。
在改进前，特种兵团队的研发流程跟大家通常接触到的比较类似，交付的周期也比较长。业务方提出需求，并在MRD通过审核之后（即业务价值得到认可），行业PD会将MRD进行全链路PRD（产品需求文档）拆解，然后再进行技术方案评审、交互评审、测试评审等，最后拆解成开发任务。研发人员进行开发和自测，最后完成集成测试和UAT测试（用户验收测试），即可正常发布上线。那如何做到“7+14”呢？
首先，我们在特种兵团队内部组建了全功能团队。将行业PD、前后端开发、测试等职能拉通，这样当需求从行业PD流转到前后端开发，从开发流转到测试，都不再需要再进行层次的“排期”等待了。
第二，引入“EDA+SBE”方法进行高效的需求分析。这两个方法，是阿里云研发团队总结和沉淀的。EDA 是 “Event Driven Analysis”的缩写，这里不展开讲。通过这个方法，首先会组织业务需求的核心干系人（一般是业务方、PD、开发PM、测试PM、交互等关键角色）对业务需求的流程做一次彻底的分析，确保大家对业务需求流程理解是一致的。接下来再通过SBE这个方法对产品设计进行细化；SBE是“Specification By Example”的缩写，听过何勉老师分享的同学应该有所耳闻，这个方法其实就是实例化需求。通过这两个方法完成了对业务流程的梳理以及产品功能的细化，接下来，大家只是对这个达成共识的需求产出设计文档。显然，后续的需求评审效率会大幅提升，返工的概率也会大幅降低；而且，经过在多个团队的实践，中小型业务需求是完全可以在7天内完成澄清和评审的。
第三，当业务需求完成评审后，需求会被拆解到不同产品域进入开发测试环节，各个域的研发人员需要对齐业务需求，确保需求可以快速上线。
第四，针对团队里之前存在的测试数据准备困难、测试环境不稳定等问题，我们也进行了改进，这属于工程领域的提效，这里不展开讲了。
第五，建立倒逼中台服务能力提升的机制；快速响应业务依赖于中台的服务化能力，为了避免中台团队闭门造车，倒逼机制也很重要。
在目标的牵引下，经过这五步，大部分中小型的业务需求在协作过程复杂的中台型团队里也是可以在21天内完成交付的。
“数字化”促进规模化提效
落地了特种兵团队的最佳实践后，我们开始思考如何在这一千多人的团队里进行规模化提效。通过“数字化”实现团队协作过程的透明化是一条必经之路。
为此，我们为大型团队设计了这张“数字化”全景图。共分为三个层次：规划层、实施层和交付层。规划层，“数字化”的是目标或者方向明确的战役。实施层，“数字化”的是基于目标的实施过程，这个过程通常是通过项目或者需求完成实施过程。交付层，“数字化”的是从一行行代码到发布上线直至完成需求的过程。这个方案，实现了从目标、需求到代码的全链路数字化；整个过程也都在Aone（云效）落地了。
再来看一看具体的落地过程：目标在线，上下对齐。怎么确保目标在被合理的推进呢？可以在图中看到，一条条的目标（部分文字做了模糊处理）已经在线了，所有的团队成员都可以看到组织的关键目标是什么。其次，目标和事情之间也实现了“链接” 。哪个目标由哪些事情（项目或需求）在支撑，哪个需求在支持那个目标，一目了然；这就完成了第一层的对齐。
接下来，再看实施层的实践：需求在线，顺畅交付。
可以清晰的看到，梳理后的供应链中台团队的整体交付流程。当业务方提出需求后，行业PD会对需求进行评估，被接受后，行业PD会指派给不同的团队去负责，后续再不同团队内对需求进行排期，以及完成全链路的PRD评审，此时，也就完成了需求澄清。
通常情况下，业务需求是比较复杂的，澄清后的需求，会拆解一个子需求（产品类需求）到不同产品域，需求的技术PM牵头，协同参与方完成自己负责的部分，最后进行集成测试和发布，整个需求才算被交付完成。
如上图中下部分所示，云效（阿里巴巴集团内部叫Aone）可以对“需求”进行分层管理，左侧是业务需求，右侧是产品需求。通过这个分层，解耦了业务和产研团队的关注点，业务方关注自己“业务需求”的交付进展，产品研发同学关注“产品需求”的交付；但是，过程中产研团队要与业务需求进行“左右对齐”，在7+4目标的牵引下，这过程变的更加的主动；这样，就实现了协作过程的通畅。
在团队提效实践的过程中，我们发现，要持续高效的交付，除了前面提到的，确保“协作通畅”，还要“高效的进行需求分析”以及有“更好的服务化能力”的保驾护航。在前面的最佳实践部分有提及，这里则不再赘述。
“数据化”建立改进闭环
通过前面的介绍，我们知道，供应链中台团队基本实现了“数字化”；这个是前提，在一个大型团队里要规模化的提效，我们还要能发现问题，改进问题。这就是“数据化”要做的事情。通过数据化建立改进闭环，让团队可以看到过程中的效能问题，然后想办法去改进。
“数据化”的关键是要定义合理的数据指标。数据并不是越多越好，有些数据甚至会起到反面效果。
关于指标的定义，应用了“黄金圈”法则来思考；先考虑“Why”：为什么要定义这个目标？一定是为达成业务结果，这就是“最终目标”。再考虑“How”：如何才能达成最终的目标？作为一个“产研”团队，就是要去提升“研发效能”，这是“代理指标”。“研发效能”实际上是一个偏结果性的东西，一切效能的提升都是为了达成最终的业务结果。再来看“What”：具体需要做哪些事情才能提升效能指标呢？这些事情还应该是产研团队能改变的，比如：协作行为、技术能力、工程能力？ 否则拿到一个无法改变的事情，也是无济于事的。
基于以上逻辑，我们确定了“数据化”指标（如上图所示）；最终目标是：加速业务发展，引领业务创新。作为产研团队，提升研发效能（代理指标）方面定义了三个指标：中台团队对业务需求的支持要符合“3、6、1”；开通新行业的时间为“2周+2周”；业务需求交付周期缩短50%。
有了这个“研发效能”指标后，再向前推导，看产研团队内部哪些指标是可以控制的：协作上可以更顺畅、技术上提升服务化水平、工程能力上缩短变更前置时间等。
ALPD+云效 助力企业10倍效能提升
最后，我对数字供应链中台团队研发效能提效的实践做一个总结。
首先，从最终目标出发：引领业务创新，加速业务发展。其次，作为产研团队确定研发效能提升的2大目标：提升中台服务化能力：中台化服务能力要符合“3、6、1”标准；对新行业开通周期满足“2周+2周”的周期；快速响应业务：业务需求到为“7+14”天交付。
为了证明目标可达成，我们在“特种兵”团队打造了“7+14”的最佳实践。 为了实现规模化；进行了“数字化”和“数据化”的建设和落地，让数字供应链这个千人的超大规模研发团队实现规模化提效。
在此过程中，我们还沉淀了一套赋能方法。 技术方面：如何评价和提升中台的服务化能力；如何梳理领域的模型和边界治理； 协作方面：需求的高效分析方法和分层的需求管理数字化； 工程方面：如何在14天交付的约束下提升行业测试效率等等。
这一整套方法，就是云效的“ALPD”(Advanced Lean Product Development)，是业务牵引、数字化、数据化、方法赋能、工具落地等组成的下一代精益产品开发体系。
通过阿里巴巴数字供应链中台提效实践，也进一步证明ALPD在超大规模、超复杂场景里提升研发效能的威力。当然，我们也在持续不断的打磨和完善ALPD，未来，希望在更多行业实践和落地。
作者：Yvonne
本文为阿里云原创内容，未经允许不得转载
