在拥有众多团队的研发部门中，为了保证一致性并提升开发效率，往往需要对常见问题的解决方案进行标准化。引入“平台团队”来统一负责这些共享方案，有助于解决相关项目的维护与发展方向问题，但同时也会带来新的挑战。

为什么要组建平台团队？

从基础设施到应用开发，各类研发团队都会面临各种共性挑战。为了提升效率、保证一致性，标准化这些问题的解决方案至关重要。这样做可以加快开发进度、降低维护成本、便于人员在团队间流动，并能更好地支撑 UI 品牌统一、GDPR 合规等业务层面的需求。

起初，这些方案往往以临时性的方式共享——比如直接复制代码、引入共享库，或是接入另一个团队的 API。但如果任由这些系统自然生长，缺乏整体规划、没有人对长期维护负责、知识传递也不清晰，很快就会让它们变得难以维护，甚至无法使用。组建一支专门负责这些方案的团队，通常被称为“平台团队”，可以缓解这一问题——但也会引入一系列新的挑战。

优先级排序

新成立的平台团队最早会遇到的问题之一就是优先级排序。由于依赖平台的研发团队众多，平台团队很容易被拉向不同方向。核心问题是：到底应该先做什么？

对于研发团队，尤其是采用 Scrum 的团队来说，配备产品负责人至关重要。然而，要为平台团队找到合适的人选来担任这一角色却并不容易。这个人既要能从技术上理解工程师们提出的需求，又要熟悉业务优先级，才能在各项业务之间做出有效的权衡。现实中，往往很难找到既能胜任这一角色、又有足够时间投入的人。

一种做法是成立一个委员会来做高层级的优先级决策，成员可以包括资深工程师、架构师、产品经理和高层管理者。不过，这个委员会无法频繁开会，仍然需要有一个被授权的人来负责日常的优先级和工作范围决策，这个人可以是与团队紧密协作的资深工程师或管理者。

排期

即使已经确定了优先级，平台团队仍可能成为项目交付的中心故障点和障碍。如果不断听到项目因平台团队而阻塞，会让人倍感沮丧，也十分有害。平台的首要目标本是提升交付速度，但若跨团队依赖管理不善，反而会导致整体变慢。

一个有效的做法是采用“固定周期项目”，例如 Basecamp 的 Shape Up 模式。承诺在固定时间内交付有限范围的项目，比起短期的冲刺，能更清晰地让大家了解团队在较长时间内会做什么、不会做什么。“Betting Table”（赌桌会议）的理念也与前文提到的优先级委员会模式十分契合。

如果你的平台团队总是被多个项目压得喘不过气，就该重新审视工作方式了。好的平台应该让工程师更快，而不是用各种阻塞让他们变慢。关键在于灵活性！通过清晰的文档让常见需求实现自助化。平台团队可以扮演“顾问”的角色，通过系统设计和代码评审来支持其他团队，而不是把所有活都揽在自己身上。

不要一直被动地响应新功能需求。应该聚焦于让其他研发团队能够轻松地自行做出改动。让他们利用你提供的工具和框架去解决问题。这样一来，平台团队的大部分工作就应该集中在那些重大的新增功能或变更上。

打造真正有人用的东西

作为平台团队，你的首要使命应该是帮助其他团队解决问题。然而，一旦独立成队，就很容易与其它研发团队真正面临的痛点脱节。

配备一名产品负责人会带来很大不同。要避免一头扎进某种解决方案，却发现所支持的团队根本不想用——要么是因为方案不适用于他们的场景，要么是因为这个问题对他们来说并非优先事项。

要记住，平台本身就是一款产品，而其他研发团队就是你的客户。目标是让他们想要并主动选择使用平台，而不是被强制要求使用。要设法保持以客户为中心，如果采用率很低，先重新审视自己的解决方案，再去考虑如何“强制推行标准”。

过早共享

有了平台团队，各种各样的人都会想把自己的好点子作为“通用解决方案”推给平台。一定要克制过早共享的冲动！

仅凭一个成熟的用例就想为共享系统找到恰当的抽象层级是不可能的。过早地确定共享实现，会导致 API 变得混乱，随着新需求的出现不得不不断打补丁、增加选项。而当已有多个调用方时，再做破坏性改动的代价会非常高。

尽早意识到某个功能未来有可能被纳入平台是好事，但还是应该让研发团队自主去解决问题，即使后续有可能将其提升为平台级方案。

我发现三次法则在决定是否将某个方案纳入平台时很有用，可以作为判断的指导原则：“一个可复用组件应该在三个不同的应用中经过验证，才算足够通用，可以被纳入复用库”。

• 第一次出现需求：自行解决
• 第二次出现需求：一起看看现有方案，协作进行系统设计，但仍自行实现
• 第三次出现需求：再来实现一个能同时支撑这三种用例的平台级方案

替换遗留系统

如果你组建了平台团队，很可能是因为已经存在一些自然演化出来的共享方案，它们往往因缺乏归属、系统设计和维护而饱受诟病。这些系统可能难以维护、文档匮乏，甚至运行在早已停止维护的软件版本上。此时，推倒重来、从零重写的呼声会极具诱惑力……但也极具风险！

很可能，完全重做并不一定会更好，尤其是在用户看来。那些久经考验的生产系统虽然杂乱，却往往承载着长期积累下来的复杂业务需求。

更糟的是，新系统很可能永远无法完全替代旧系统，尤其是当旧系统在多处被使用时。迁移到新系统会给其他团队带来额外的工作和风险。如果只是部分迁移，你的维护工作量反而会翻倍——需要同时维护两套系统，还要处理两者能力上的分化。

当然要明确理想的方案是什么，但更应聚焦于对现有系统进行渐进式改进。一旦有人提议重写，就应该拉响警报。更好地理解现有系统，完善文档，并编写自动化测试，以增强团队进行改动的信心。

当然，有时大规模的替换是不可避免且合理的，但在界定工作范围时一定要谨慎。要考虑到实现阶段之外的一切——包括支持迁移、充分验证、文档编写，以及说服其他团队优先进行切换。不要在没有周密计划的情况下匆忙重写。渐进式改进或许能让你免去日后许多不必要的麻烦！

沦为知识孤岛

平台团队也很容易沦为孤岛，与其他团队在使用平台时日常遇到的问题脱节。组建团队虽然让一群人有了共同的焦点，但也在“我们”和“他们”之间划出了一条界线，可能引发矛盾。

保持沟通、主动去了解他人的问题非常重要。工程师都不想被阻塞，如果彼此之间没有建立起良好的关系，他们往往会选择绕开你方案中的问题，而不是主动来找你沟通。

建立联系至关重要。要鼓励开放沟通，让别人更容易找到你。一个有效的做法是通过工程师轮岗来共享平台知识。随着成员的流动，他们会带来全新的视角和来自过往经验的宝贵见解。

要营造协作文化，欢迎来自整个部门的代码贡献。你的用户能够提供独特的视角和有价值的改进建议。要记住，虽然平台团队对这些方案负有责任，但整个组织中的工程师都有能力为平台的发展做出贡献。

归根结底，协作与开放的对话将造就更强大、更高效的平台团队。拥抱共享知识与多元视角的力量，实现持续改进。

结语

引入平台团队是为共享方案确立清晰归属的好方法，但它也带来了一系列独特的挑战。

要想取得成功，将平台视为内部产品至关重要。找到合适的人选担任产品负责人，对保障顺畅运作必不可少。要与其他团队协作，打造出工程师真正愿意使用的平台。

要记住，文档与实现本身同等重要，甚至更为关键。要优先把 API 设计做好，快速实现，然后将重心转向编写详尽、全面的文档。