📚 课程目录第4章平台团队结构

第4章平台团队结构：角色、使命与协作

搞平台工程，最绕不开的就是“人”的问题。技术选型、工具链、API设计……这些当然重要，但团队结构如果没搭对，再好的技术也推不动。我见过不少团队，工具造得特别牛，结果没人用——为什么？因为平台团队跟业务团队之间隔了一堵墙。

这一章咱们就聊聊平台团队该怎么建。说白了，就是回答三个问题：谁来做？做什么？怎么跟别人配合？

根据我踩过的坑，一个成熟的平台团队至少需要三类角色。你想想看，如果只有开发没有运维，平台上线后谁来兜底？如果只有后端没有前端，开发者用的控制台谁来画？

我个人的建议：初期团队可以一个人身兼多职，但至少需要有一个人专门盯着“开发者体验”。否则过不了半年，业务团队就会开始骂平台难用。

很多团队一上来就想着“我们要做内部PaaS”，然后疯狂堆功能。结果呢？功能越做越多，文档越来越厚，业务团队根本学不动。

我始终记得一个原则：平台的价值 = 业务团队节省的时间 - 学习平台花的时间。如果学习成本大于节省的时间，业务团队必然会绕开平台自己搞。

所以，平台团队的使命不是什么“统一技术栈”，也不是“打造企业级基础设施”。说白了就一句话：让业务开发者能早下班。

我曾经踩过的坑：我们团队刚做平台时，强制所有项目必须使用我们封装的部署流程。结果有个业务需要快速接入第三方API，我们自己的流程还没支持，业务团队只能偷偷开SSH进服务器手动操作。后来我意识到——平台不是监狱，而是服务。从那以后我们改成了“推荐使用，允许绕过”。

大多数团队不会一开始就有10个人的平台组。我建议从小团队起步，逐步扩充。大概路径是这样的：

注意，不是所有公司都需要走到第4步。如果你的业务团队不足50人，3-5人的平台小组完全够用。人多了反而容易变成“造轮子部门”，跟业务脱节。

协作是最难的部分。我见过两种极端：一种是平台团队关起门来自己玩，等到发布时才发现业务根本不需要；另一种是业务团队天天追着平台提需求，平台变成“客服外包”。

比较好的做法是——嵌入式协作。每个季度，平台团队派一名工程师去业务团队“轮岗”两周。不干平台的工作，只干业务的一线开发。你会发现很多平时看不到的痛点：

另一个有效机制是共享OKR。平台团队和业务团队的OKR里必须有重叠的部分。比如业务团队的OKR是“提升交付效率50%”，平台团队的OKR就必须包含“通过自动化部署减少人工操作30%”。这样大家的力气才往一处使。

图里的三层关系你可以仔细看看。平台团队在中间，向左向右提供服务，同时通过轮岗和反馈闭环持续改进。底部共享OKR保证大家不是各干各的。

如果老板问你“搞这个平台有什么用”，你不能只说“提高了开发者体验”。你需要一些硬指标：

  一个真实的故事：我们之前帮一家电商公司搭平台，第一个季度平台采用率只有30%。后来我让一个平台工程师去业务团队轮岗两周，才发现业务团队觉得平台的文档“像天书”。我们花了一周时间重写文档，配上gif动图，采用率第二季度直接蹦到了85%。你想想看，有时候问题不在技术，就在沟通和同理心。

嗯，团队结构这部分我就聊这么多。记住几件事：初创团队人不用多，关键是找准使命；协作不能靠发邮件，要用轮岗和共享OKR建立信任；最后用数据说话，让老板看到实实在在的变化。平台工程的核心不是代码，是消除摩擦——团队内部的摩擦，以及平台跟业务之间的摩擦。

第4章 平台团队结构：角色、使命与协作