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