一、背景

在互联网行业，大部分研发团队都会通过建设中台（有些公司叫平台），来提高系统的可复用性，降低重复功能的研发成本。随着有赞业务的快速发展，我们也逐渐走向了大中台道路，充分享受着中台所带来的红利，但与此同时，我们也陆陆续续遇到了不少问题，笔者希望借助本文，从效能改进的视角进行剖析，期待引发读者对「如何从组织层面协同中台」的思考和共鸣。

二、发现问题

有赞大大小小业务共有十几个（下称：业务域），在各业务域（一级）下，又细化出若干业务子域（二级），维护自己的需求优先级列表（backlog）。而中台，也并非以整体在运作，而是根据组件划分为商品、交易、营销等功能模块，各功能模块也有自己的需求优先级列表（中台没有整体的 backlog）。

1. 需求规划困难，阻碍业务发展

尽管业务域内部可以从容响应市场需求的快速变化，但因为功能托管而造成技术依赖，导致与中台的耦合度极高。当业务子域需要在中台通用能力基础上，快速叠加新场景时，就遇到跨团队协作壁垒、多个业务子域需求冲突、规划节奏不一致的问题。业务发展速度越快，对中台的诉求越频繁，问题的复杂度就越呈现出指数级上升的态势，则业务功能迭代的阻力越大。

如何在不同业务域下与各业务子域横向 PK 需求优先级，进而管理来自各业务域需求（即相当于：排出公司级的 one backlog），成为一大难题（见图1）。

图1. 业务和中台需求规划的示意图

2. 研发周期变长，交付效率下降

在图1 中，业务子域 2 的某个需求，需要被中台功能模块 α 和 β 在同一个项目中支持，但尴尬的是，α 不仅要支持业务子域 2，而且还正在支持业务子域 1（如果这两个子域分属于不同的业务域，那信息鸿沟则会更大），以至于该项目要等 α 完成上一项工作（业务子域 1 的某个项目）后才能启动，或虽然项目启动了，但 α 参与者同时并行多个项目，成为了关键路径，导致交付周期（= 等待周期 + 研发周期）变长。

在实际场景中，由于「各业务域的需求是否会涉及到中台哪些功能模块」在需求规划阶段是不确定的，直到业务域研发人员在完成上一个项目交付并介入进行评估后才能识别，以至于对中台各功能模块来说，信息延迟效应明显，计划的波动性和调整的复杂度都很大。在中台侧增加人员投入，只能缓解波峰期间的症状（增加的人数仅相当于可额外承接的项目数），难以彻底根治，甚至还会在波谷期间出现资源闲置，使得各方对中台管理持续保持关注。

图2. 中台支持多个业务子域导致交付周期拉长

在图2 所呈现的信息中，我们可以看到，尽管中台每个人的资源利用率都是 100%，但单个需求的交付周期，依然可能因为参与者被其他需求占用而变得很长。

3. 各业务旱涝不均，价值交付低

无论是经过了友好协商，抑或是协商不成先到先得，结果都只是在一定时段（我们是按月进行规划）内「让一部分业务先富起来」，而没有纳入中台各子域 backlog 的需求，则会被搁置。

一方面，尽管其中一些需求在本业务域的 backlog 中是高优先级的，但发起方（业务子域）技术团队只能做一些力所能及（不依赖中台模块）的工作，导致该业务域的发展进程放缓，业务子域成员的成就感不足。

另一方面，业务域接受了现状，做了需求妥协后，对中台交付的期望值较高（甚至会以倒排期作为交换条件），导致中台技术团队加班严重。

三、尝试解决

基于上述问题，结合各方的反馈，我们认为主要是资源协调、目标不一致、排期模式等「协作流」问题，而这也是我们效能团队最为擅长的领域，从这些方面切入的风险较低。于是，我们做了如下尝试，并快速识别出它们的可行性：

1. 建立公司级 backlog 运作机制

措施：借鉴 LeSS（大规模 Scrum）模式，效能团队牵头成立了「高优需求委员会」，定期（按月）对由各业务域提报的高优需求进行排序和决策，取 top20 的高优需求，填充到公司级的 backlog 中，作为核心交付目标。

优点：将业务目标具象为 backlog 中的需求条目，以此来牵引全公司的产能配置，各方观点快速对齐，减少协调和内耗，工作变得更聚焦。

缺点：我们主要以功能的影响面和用户数等因素来评判需求的优先级程度，未考虑到尚未形成规模的新兴业务，当下仅有潜在价值，故未能进入 backlog 进行探索和试错，导致部分功能错过市场窗口。

2. 建立基于 OKR 的目标对齐机制

措施：效能团队定期组织「世界咖啡」活动，由各业务域产品负责人，根据业务进度及目标（有赞使用 OKR 来设定关键目标）向下拆解出项目（及大致描述），进行展示和讲解，中台各功能模块团队根据综合情况评估，是否存在可被沉淀的通用能力，如果双方达成共识，则该需求会被纳入双方后续的规划中。

优点：业务域在阶段性目标的制定之初，就能排除掉中台无法提供支持的需求，将风险前置，减少了目标层面的摩擦。

缺点：这种方式对产品负责人的规划能力有非常大的考验，且市场变化较快，在规划外临时发起的需求较多，很多时候难以完全按照规划执行落地。

3. 中台按比例支持各业务域

措施：业务域和中台就资源投入的分配比例达成一致。在需求规划（按月）时，按契约提供相应的资源，以支持各方的最高优需求（超出部分不再支持）。若有更多资源诉求，各业务域之间可相互协商调配（中台不介入）。

优点：由于是事前协商和平衡，故每个业务域都会被顾及到。

缺点：会出现「算账」行为。即：当多个业务子域同时求助中台某个功能模块时，且业务子域之间无法达成一致时，会要求中台「赊账、借账」。且在需求高峰期，会出现集体兑换过往的欠账，导致瞬时资源需求的峰值远超团队总可用人力（类似于银行挤兑）。

图3. 效能平台资源分配设置的示意图

4. 中台通用能力产品功能拆分

优点：从产品的视角，明确了中台目标和业务目标之间的关系。

缺点：尽管产品拆分干净了，但是在架构和代码层面，依旧是严重耦合的，无法解决实际问题。

5. 研发共建

以上尝试大多只是改变了「协作流」，故均未能解决当时中台卡点的问题。我们根据杨三角理论，认定协同中台的改进工作要从「提升组织能力」的层面出发，大致可以分为「技术框架、工具链支持、主观能动性」三个方面。

图4. 从组织能力层面改进中台协同问题

具体来说，先引导研发人员放弃本位主义思想，建立以业务目标为导向，一方面，鼓励中台各功能模块团队开放代码仓库并提供咨询服务，另一方面，鼓励业务子域团队在中台的帮助下去中台仓库中写代码。

优点：业务子域团队无须再依赖中台，能够自闭环地工作，缩短了需求的等待周期，提升了业务项目的交付效率。同时，中台研发人员精力得以释放，不再受困于业务项目，可以投入更多资源完善中台能力。

缺点：业务子域团队需要花一段时间来储备中台技术能力，在刚开始阶段会增加研发时长。但磨刀不误砍柴工，随着对中台越来越熟悉，该项风险会逐渐缓解。

图5. 关于研发共建的系统思考

四、实践效果

通过采用共建（v1）的尝试，需求的整体交付周期（= 等待周期 + 处理周期）缩短了 10%。其中，等待周期缩短了 30%。

图6. 需求交付周期缩短了 10%

图7. 等待周期缩短了 30%

后来，随着核心问题通过共建（v1）方式得以解决之后，协同中台的过程中，又出现了新问题，包括：业务技术对编码质量（如：单测覆盖率）等工程化的要求和门禁条件与中台不同、底层代码改动的回归质量未做收口控制、代码稳定性要求、如何降低学习中台的成本（参见：图5 中的「学习成本」悬摆）等。

于是，我们后续又把共建继续往前推进到了 v2 阶段。如果读者想知道我们在共建（v2）阶段具体做了哪些改进来提升中台效能的，那就烦请坐等下回分解吧。如读者有中台协同相关的话题，欢迎在底部留言，我们做进一步交流。