技术领导力实战笔记2022_25_23大型研发架构团队的AOM实践
你好，我是林世红。
二零一一年我加入京东，负责京东零售供应链研发架构工作。
基于这些年我在京东的探索，我们来聊一聊大型研发团队的AOM实践这个话题啊，或许听上去和团队管理的关系不大。
但是呢从我的实践角度来看啊，他在团队效率、团队协作上都发挥了重要的作用。
希望呢这节课对你有帮助。
为了帮助你理解，在介绍AOM之前呢，我们先来看另外一个你比较熟悉的概念。
Aop面向切面编程，利用AOP呢我们可以对业务逻辑的各个部分进行隔离，从而降低业务逻辑各个部分之间的耦合度，提高程序的可复用性，同时呢提高开发效率。
Aom和AOP有异曲同工之妙。
Aom的全称呢是面向方面的管理。
在软件开发过程管理中啊，需要对开发过程中的多个切面进行管理。
即AOMAOM的主要目的呢是把握质量，提高效率。
例如，在进入开发前呢加入需求评审，在编码前加入方案设计、指导方案设计与评审、代码交付前呢加入代码评审等等。
在不少大型开发团队中开始设置专门的角色进行切面管理。
这个角色呢大多是架构师来担任，有的公司呢甚至设置专门团队来管理。
一般是横向架构。
团队通过纵横交错的矩阵式组织架构呢，就可以在保障项目交付的同时啊，在各个环节以切面的形式呢保障质量及效率，让各个团队更加专注。
而且呢整个架构的扩展性也非常强。
那AOM的职责范围是什么呢？首先啊是强化研发过程中各个切面的管理。
其次是支持研发过程中的各个切面，不断的演化出其他更高级的职责。
例如，为了提效，就需要提供高效的工具平台，不断的提升自动化能力。
为了能够承接公司的技术战略呢，推动部门技术体系发展，制定技术规划目标和举措。
而这些高级职责呢，恰恰需要强化管理研发过程中的各个切面，从而制定标准化的流程和规范，甚至啊改变研发过程和模式。
Aom工作本身呢就是要在项目交付多个过程节点上啊，帮助或者说约束团队，需要改变大家的习惯和方法，甚至在某些重大技术战略上呢要改变交付模式。
所以啊挑战很大。
从事AOM工作的架构师呢本身具有多重角色，与各个项目交付团队既是合作伙伴关系，又充当着甲方乙方中间方的角色。
这里面呢我们来展开讲一讲合作伙伴的决策。
Aom架构师和项目交付团队在宏观上呢具有统一的目标，高效高质量的去交付项目需求，支持好业务发展。
所以呢是合作伙伴甲方的角色。
理想情况下，横向架构师呢是提出软件高质量交付目标的，一方是软件交付的。
甲方因为他在平衡多方利益的情况下呢，提出了最合理的架构、目标以及方案，兼顾了短期交付以及长期架构的合理性。
乙方的角色现实中啊，横向架构师大多数场景下呢是乙方。
因为一切最终结果和最高优先级呢是保障项目按时上线，所以横向架构师呢需要在此最高优先级下呀服务好项目交付团队，使其在保障项目上线的同时呢最大化的实现架构合理性目标。
另外横向架构师呢立足于多个项目之上，他从宏观的角度啊，可以找出共性有效的提效方法工具机制。
然而在实施过程中呢，由于交付团队最高优先级的目标啊是按时交付项目。
那么在交付压力大的情况下呢，提效的方案呢通常推迟或者取消落地。
如果说横向架构团队无研发团队，那么最终结果呢通常无法改变交付现状的怪圈。
中间方的角色横向架构团队呢不能只服务好交付项目，他还要服务好集团自上而下的大的技术战略。
在这些工作中啊，除了要承担主架构师负责技术方案制定，还要承担技术项目经理的工作，包括资源工时、排期、立项等等。
接下来呢我就围绕这个横向的架构团队的工作啊来展开。
以案例的形式呢，从组织架构、团队、文化、绩效考核等几个方面与你讨论一下。
如何做好AOM中台啊，是一场效能的变革。
本质上呢是要沉淀中台能力，消除重复建设，实现前中台的分离，实现需求的并发闭环交付，所以呢推动起来会面临很大的挑战。
由于项目交付团队呢直接面临交付压力，直接推动中台建设呢比较困难。
所以啊需要专门的横向架构团队来探索方法，打标杆，定标准逐步推广，推动中台建设会面临哪些挑战呢？首先呢就是没有先进的经验可以借鉴，全凭团队自己摸索。
其次啊，这是一个相当庞大的工程。
由于领域业务产研团队啊非常多，涉及到业务啊、产品啊、开发测试等多种角色，整个大部门呢要在认知层面达成共识。
第三，对于产研来讲啊，中台战略呢将改变产品交付模式，需要在产研交付过程中的多个环节，同时改变习惯和规范，这有着相当大的难度。
在开始的半年里呢，各个部门啊积极性都不高。
大多呢都处于观望当中，对中台的理解呢也是五花八门。
为此呢我们不断的进行头脑风暴，灵魂三问，为什么要做中台？中台能给我们带来哪些价值？是否有其他的手段能够达到中台的效果，需要哪些重点工作，预计投入的资源需要多少，年底会达到什么样的效果等等。
从高层到一线的实施人员呢一起讨论。
最终啊大部分成员呢在共识上都认同，中台呢确实是值得做的。
中台是一种新的分工合作方式，把原来一个团队的工作啊分成两部分。
通用的功能呢由中台的人做个性化的功能呢由前台的人来做消除中台接活的瓶颈。
前台可以根据自己的需求快速定制开发，加快业务创新中台，做通用能力沉淀和打磨，形成可复用的产品。
中台的工作呢在本质上做的是前中台分离的事情，解决的呢是前中台分工合作的协同问题。
让离业务更近的前台产业啊，快速而灵活的去支持业务发展。
让中台团队呢不断的沉淀中台能力，赋能更多的前台业务。
在团队共识以及领导的支持下呢啊我们确定了整体实施策略，制定了中台建设的二十七字经。
具体呢就是理痛点、求共识、定标准、建机制造底座、打标杆、办培训、做检查、晒指标。
在这个实施策略的指引下，整个中台建设进程非常顺利。
不到一年的时间呢就完成了大部分的中台改造。
另外呢我们确定了指标通晒机制，制定了核心考核指标，包括中台复用率、啊中台参与度、中台成熟度、需求、交付周期、需求自助化率等等指标。
对各项指标呢每周每月进行通晒，每月按时发布月报，表彰并奖励指标。
较好的部门鼓励优秀的团队呢内部分享，甚至到集团层面去分享汇报，激励各个部门的建设热情。
随着中台指标的逐步提升啊，我们发现仅从需求维度呢很难再有较大幅度的提升。
而且啊需求相关的指标呢会更偏宏观。
需求下呢隐含着不同的实现方式，不同的质量。
所以啊我们从需求层面下探了一层，对需求实施的底层技术资产呢进行了分类，例如扩展点啊、配置点啊标准化组建业务技术工具等等。
并将这些技术资产带来的价值进行量化，形成积分。
将积分呢从个人到组织，层层汇总，最终形成了体系化的积分制。
通过积分呢来反映组织个人对中台的贡献，制这部分的工作呀目前正在实施当中，相信呢会对中台建设的推动起到更加重要的作用。
组织保障方面呢亦实亦需。
我们建立了负责中台建设横向统筹工作的实体中台架构组和虚拟的架构委员会。
实体中台组统一对接集团的中台建设工作。
同时啊负责整个部门的中台落地，制定中台规范呀、验收标准呀、实施指南呀等来辅助各个部门进行实施。
架构委员会呢则是从架构层面进行各个部门的技术工作统筹，从各个部门抽取核心的架构师组成虚拟组织，用于架构优化改造和技术推广。
人才方面呢，我们制定了领域架构师的培养计划，从各个部门选出核心架构师进行强化训练。
为中台建设培养能担当、能补位、共身。
入局复合型传帮带人才培训内容啊主要包括DDD、事件、风暴、建模、设计模式扩展点以及实战交流等等内容。
经过一年时间呢，培养了近五十位领域架构师，为后来的中台落地呢提供了强有力的人才保障。
各个部门在各位核心领域架构师的带领下呀，自主实现的需求逐步攀升，系统内部呢也产生了本质的变化。
中台实施一段时间后啊，我们进行了价值的量化分析与总结，以及在实际交付中啊带来的变化。
在价值量化之后呢，更加坚定了大家对中台的信心。
首先，在需求受理阶段，复杂的需求呢整体下降了百分之五十左右。
第二，在设计开发阶段。
如果仅考虑中台工作，那么节省了百分之五十左右。
加上前台一起考虑的话，长期来看呢，在现在组件化基础上呢再下降百分之二十以上，问题不大。
降低的主要原因呢是基于业务身份缩小了影响范围。
第三，测试阶段，功能测试和预发测试呢下降了百分之三十以上，降低的原因是基于业务身份缩小了回归范围。
第四，上线阶段，细分为线上验证，切量降低了百分之三十以上，降低原因呢是基于业务身份缩小了验证范围。
接下来来讲，第二个案例，开发模式变革实践团队在领域技术中台实践中啊沉淀了不少的中台能力，支持，业务的效率呢也有了明显的提升。
但是随着公司业务扩张，业务需求增长非非常快。
研发资源呢逐渐成为瓶颈。
为了消除瓶颈架构，团队啊规划深度引入低代码技术。
一方面呢提升研发交付效率，另一方面可以将部分的工作转移给业务和产品啊，以此来缩短需求实施链路，还可以将工作转移给ISV,这样呢可以极大的解开资源瓶颈，为中台能力啊规模化复制，打开了空间开发习惯，改变困难大，需求交付压力大。
低代码开发模式呢要求能力建设啊是基于模型驱动的。
通过模型定义和构建应用扩展能力呢也是基于模型和设计的。
大多数系统啊已存在多年了，应用模型演变无序，技术障碍非常复杂。
如何在高速飞驰的汽车上换轮子呢？如何说服上下级的人员为短期看不到收益，还需要消耗成本啊，重构业务系统的平台，投入时间和精力呢研发资源紧缺，流动性大，做一个低代码技术平台啊，它需要大量的抽象平台，思维好的产品经理、架构师、高级研发人员。
然而他们都是在业务交付当中，在哪里去找高水平的人员呢？互联网文化冲击以及挑战互联网文化呀以快为主导，它讲究速度ROI价值。
一个低代码平台。
在业界，通常需要投入百人耗时一到三年，且看不到短期的业务价值。
如何在这样的环境当中去打造这样一个平台呢？京东内部的打法价值认同。
我们把低代码价值空间与集团研发效能啊、口径对齐上升项目战略，进而得到领导强有力的支持。
在此基础上呢，解决互联网文化下的IOI以及项目立项问题。
另外呢我们把大项目分解成若干个，短期可以看到过程指标的小项目。
每个小项目呢可以快速迭代，快速的产生实际价值，树立团队的信心。
技术上呢新的突破为解决大量存量系统的低代码升级难题。
啊，我们探索并实现了技术栈无关的标签买点扩展点的标准化开放技术来实现扩展能力的技术无关性。
用领域模型驱动方法实现已有的各水平层低代码引擎的无缝融合。
用较低的成本解决了京东内占绝大多数的存量系统的零代码架构升级难题。
最快呀可以在一天内复制到几乎任意的主流存量系统中，以零代码低代码能力呢实现业务产品、技术角策自助式的一站式开发，缩短了交付的链路共建共赢。
研发人员虽然忙于交付业务系统，但是在研发人的心目当中呢，都有一颗技术创新的种子。
基于此呢，我们建立了新的内部众包，分级开源机制，让研发在做业务交付的间隙呢贡献自己的力量，提升自己技术能力，打造部门的技术文化。
同时啊各个团队承接的能力建设，首先在团队内部呢快速达磨并复制之后，再推广到各个团队。
另外啊也要利用好积分制度，奖励能力、贡献者和能力，复用者提升大家积极性。
这三点呢恰好解决了开发模式变革面临的三个挑战。
最后呢我们短短两个月呢，创新了七项技术，迭代了三个小版本，实现MVP版本的上线，后续应用陆续接入，实现多角色快速交付，打开了规模化空间。
我们虽然在UMM工作上取得了一些进展，但还不能说是成功，各种挑战呢依然存在。
这里啊我总结一下UM工作成功的关键。
第一呢AOM团队自身的素质和能力，专业能力需要有足够大的技术影响力。
别人愿意跟随他完成这个项目，同时啊需要有大型的项目设计经验，可以统筹设计方向以及技术方案。
Aom团队成员呢还需要有较强的平台产品运营能力。
在孵化阶段呢还要担当产品经理啊以及平台运营的角色沟通管理能力。
Aom团队成员呢需要具备高效的向上、向下的管理能力，推动协同能力。
需要具备较强的协调推动能力，统一设计思想、协调角策职责，保障项目进展。
第二呢，领导的强力支持。
横向工作在直观上往往是对大家日常工作的一种指导和约束，甚至为了长期架构合理性会影响到短期的交付。
所以呢领导的支持十分关键，包括呃冠宣啊长期主义上升战略高度来看待整个架构工作，用绩效考核来保证架构、工作推进等等。
第三呢激励机制可以借助积分制啊激励能力建设者和复用者、创新者和标准执行者。
第四呢，整个公司对效率质量的强力追求，部门的技术背景和积极向上的研发文化。
这里总结一下，AOM呢是软件开发过程中必不可少的工作。
即使在小型的研发团队啊，也需要在软件开发过程的重要环节植入事前指导工作，以保证后续工作啊沿着正确的方向进行或者植入事后审核工作啊，以保证质量。
此类工作呢一般是由比较有经验的架构师承担，嗯，也可以设置对应的岗位来对此负责。
当研发队伍负责的业务领域较多的时候呢，则需要各个领域、统一原则、方法、工具等等。
因此啊有必要成立虚拟的组织来保障。
当一个组织面临的交付压力，使短期交付和长期架构合理性变得难以平衡，多个领域之间统一工作变得困难，或者说技术变革必要性增加时候呢，可以考虑成立专门的横向架构团队。
Aom团队呢需要洞察研发过程的痛点，啊，以专业性呢来解决问题。
能够建立标准并嵌入平台工具，提高AOM管理效率。
能够与各领域团队啊建立共识，培养人才，建立机制，推动技术措施在各个团队落地。
最后呢我想给你留两道思考题。
Aom工作中呢如何平衡短期交付压力和长期架构合理性AOM团队，实体团队还是虚拟团队更适合呢？欢迎你在评论区留下自己的见解，也欢迎你把这节课分享给有需要的朋友。