管团队这几年，我最大的教训

我刚带团队那会儿，干了一件特别蠢的事——把自己当成了队里技术最强的那个人。

哪个服务出问题了，我冲最前面排查；哪个方案有争议，我拍板定；谁请假了，我顶上去。那段时间特别充实，充实到什么程度呢？每天加班到十一点，周末也得盯着群消息。我老婆说我跟手机过日子算了。

后来有一次我发烧请了两天假，结果团队差点炸了——线上出了个中等故障，三四个人在群里讨论了一下午没结论，最后还是我躺床上打了几个电话才搞定。那次之后我彻底想明白了一件事：我这种干法，不是在管团队，是在害团队。

团队真正的竞争力，从来不是leader有多牛，而是你离开之后这帮人还能不能正常运转。要做到这一点，你得花心思去搭一套制度——不是那种写在文档里没人看的制度，而是大家日常真的在用、且用起来不别扭的制度。

我折腾了几年，踩了不少坑，慢慢摸索出五个模块，今天聊聊。

Owner精神

最开始我的分工方式很原始——leader派活，大家干。效率看上去还行，但有个致命问题：所有人都等着我安排，没人主动思考"这块业务下一步该往哪走"。等于我是一个人的大脑，连接了十双手。

后来我改了规则。每个人圈一块自己的领域，明确是"Owner"。

举个真实例子：我们组有个同事叫老陈，负责网络这块。主责的意思不是说网络相关的活儿都他干——而是说网络这个领域，技术选型他来定，方案他来出，出了故障他来组织排查。功劳是他的，锅也是他的。年终述职的时候，他讲的是"网络这块今年我做了什么、解决了什么问题、明年打算怎么优化"，而不是"领导让我做了什么"。

这个转变看起来很小，但效果非常明显。老陈开始主动研究SDN方案了，主动找其他团队对齐网络规范了，甚至开始主动排查一些潜在风险——因为这块是他的，他比任何人都上心。

当然，光有主责会出另一个问题：老陈休假了怎么办？老陈离职了怎么办？所以我们同时搞了"Backup"——每个Owner配一到两个Backup成员，平时跟着Owner干，慢慢熟悉业务。一来降低了单点风险，二来等Backup成员成长起来，就能独立接手新的领域。

另外，固定分工之外还得有个弹性机制。我们时不时会冒出来一些临时项目，比如安全加固、性能优化专项之类的，如果大家都只守着自己的领域，这些跨领域的事就没人牵头。所以我们搞了个"虚拟小组"的机制——遇到临时项目，从各领域抽人组成小组，定好目标和周期，干完就解散。大家轮流参与不同项目，对整个系统的理解也更深了。

轮值分享

这方面我之前也做得不好。最早的时候，组里技术分享就是随机性的——谁想起来就讲一讲，想不起来就算了。结果就是，永远是那两三个技术好的人上台讲，其他人默默当观众。时间一长，这几个人讲倦了，观众也听腻了。

后来我定了死规矩：技术分享轮流来，每两周一次，按名单轮，轮到谁谁讲，不许缺席。这个"不许缺席"很重要——很多人不是不想分享，是有轻微的社交恐惧，总觉得自己讲的东西不够高大上，怕被笑话。强制轮值以后反而放开了，因为反正都得讲，不如讲点自己真正踩过的坑。

我还加了一条：分享内容必须来自实战，不许拿网上的架构图念PPT。你可以讲最近解决的一个线上问题，可以讲你调研一个新技术的心得，可以讲你踩过的什么坑——但必须是你自己的东西。

每次分享完，讲的人要写一篇文档存进知识库。这个动作看起来多余，但其实非常关键。口头分享听完就散了，三个月以后谁也不记得了；写成文档以后，新人入职的时候可以自己翻，遇到类似问题也可以搜。

还有一个我觉得特别重要的制度：故障复盘。

我见过很多团队处理故障的方式——先恢复服务，然后开个会，气氛沉重，追问"谁干的"。这种方式只会让所有人都害怕出问题，出问题了第一反应是捂着不说，小问题拖成大问题。

我们的做法是：复盘会只做两件事，第一，找到根因（用5-Whys连续追问）；第二，产出改进措施。改进措施必须落地——要么更新操作手册，要么写个自动化脚本，要么加个监控告警。如果复盘完没有任何实质性的产出，等于白开。

而且复盘会上绝对不追个人责任。这个原则说起来简单，执行起来需要leader带头——你自己遇到问题的时候也坦然讲出来，大家才会觉得这是安全的。

多维考核

考核制度是个很微妙的东西。你考核什么，团队就会往什么方向使劲。

我之前看过一个特别典型的反面案例：某团队leader觉得团队产出不够，开始在周会上统计每个人的代码提交行数。结果你猜怎么着？一个月之后，代码量涨了三倍，但质量直线下降——有人把一个方法拆成三个，有人把注释写得比代码还长，有人开始大量复制粘贴。因为制度告诉他"行数=产出"，他当然会想办法把行数搞上去。

所以考核制度的设计，你必须想清楚你想鼓励什么行为。

我们用的是OKR加KPI的组合。OKR管方向——比如"提升平台资源利用率"，这是一个需要动脑子的挑战目标，没有标准答案，需要团队自己想办法。KPI管底线——代码质量不能低于多少，按时交付率不能低于多少，线上事故数不能超过多少。底线达不到，OKR完成度再高也不行。

但光看这些硬指标还不够。我还加了几个软性维度：方案设计有没有考虑扩展性和容错、遇到陌生问题的排查能力、知识贡献（文档和分享）、对业务结果的责任感。

这些东西不太好量化，但可以通过日常观察来评估。我的做法是，平时多跟团队成员一对一聊，了解他们在做的事情、遇到的困难、自己的想法。考核不是到了年底才开始做的，是平时就在积累素材。

梯队建设

我最怕的事情之一，就是团队里某个关键岗位的人突然要走。

曾经有一个同事，在组里干了三年，负责核心服务的运维。他做事非常靠谱，但也是唯一一个熟悉这套系统的人。他提离职的那天，我整个人是懵的——他的工作量、他脑子里的经验、他跟其他团队建立的各种协作关系，这些东西没法通过交接文档在一两周内转移给新人。

从那以后，我开始认真搞梯队建设。

核心岗位必须有Backup，这个是硬要求。每个Owner至少安排一个Backup跟着学，能独立处理日常问题。关键时刻Owner不在，系统能正常运转。

然后是识别和培养高潜成员。每半年我会做一次全面的评估，重点关注这几个特质：自驱力——不推不动和推了也不动是有区别的；技术基本功——不能只会照着文档操作；沟通能力——跟其他团队打交道能不能把事儿说清楚；分享意愿——愿意把自己的经验输出给团队。

对高潜成员，我会给更大的空间。让他们主导一些重要项目，安排对外技术分享，把有挑战性的任务交给他们。成长这个东西，光靠"学"是不够的，得真刀真枪干才能练出来。

内部轮岗也很有用。让A跟着B做一个季度的项目，然后B再跟着A做。这种交叉接触能让大家对整个系统有更全面的理解，也为未来可能的岗位调整做准备。

经验沉淀

最后说一个我觉得很多团队都忽视的事情。

很多团队不是没有经验——上线踩过的坑、故障排查的思路、跟其他团队对接踩过的各种弯路，这些东西每天都在发生。但问题是，这些经验全在个人的脑子里，人一走就全没了。

我的组里有一个新人，入职第一天我就跟他说：你在这个组待一年，你解决过的每一个问题、踩过的每一个坑，最好都有记录。不一定写成特别正式的文档，哪怕是在wiki里写几行关键信息也行。因为这些信息对你来说可能是"我当然知道"，但对下一个接手的人来说，可能是"我找了一天也没找到"的救命线索。

经验的沉淀有一个逐步升级的过程，我总结成五个阶段：

1. 标准化——先统一规范。代码怎么写、部署怎么做、文档怎么记，先有个统一标准。没有标准，后面的所有沉淀都是空谈。
2. 流程化——把常见操作写成SOP。上线流程、故障处理流程、迁移流程，全部固化成文档。新人照着做就行。
3. 工具化——把SOP里的手工操作变成脚本。人手动的环节越少，出错的概率越低。
4. 自动化——把脚本集成到流水线里。提交代码自动检查、自动构建、自动部署。减少人为干预。
5. 产品化——把内部好用的组件封装成公共产品，让其他团队也能复用。这个做到后面就很有成就感了。

这五个阶段不是一次走完的，是慢慢迭代的。先从最痛的地方开始标准化，跑通了再往下一步推。别想着一口吃成胖子。

总结

说了这么多，其实归根到底就一句话：好的管理是让团队可以不需要你。

这不是说要把自己搞成可有可无的人——而是说，你最大的价值不是亲自干每一件事，而是搭建一套机制，让团队在没有你的时候也能运转良好。做到了这一点，你才有精力去思考更大、更远的事情。

当然，这些制度不是一天建成的，也不是一成不变的。我在执行过程中也在不断调整——有些制度推行不下去，说明要么时机不对，要么设计本身有问题，得回头看。别怕改，制度是为团队服务的，不是用来供奉的。