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