团队里不能只有一个人最懂系统

很多团队里都有这样一个人。

系统哪里有坑，他知道。

线上问题怎么查，他知道。

客户现场某个奇怪配置为什么不能动，他也知道。

大家遇到问题第一反应是找他。

短期看，这个人很重要，项目也离不开他。

但从团队角度看，这其实是一个风险。

这种风险平时还挺不显眼。

只要这个人在，群里一有人问，他三句话就能把问题讲清楚。客户现场打电话过来，他也知道哪个配置不能动。数据库里某个奇怪字段为什么不能删，他也记得当年那个版本怎么来的。

大家会觉得：幸好有他。

但团队不能一直靠“幸好”。

一、最懂系统的人，往往也是最累的人

我见过不少这样的情况。

一个老同事负责某个系统很多年，业务、代码、数据库、部署、客户现场情况，他都很熟。

平时看起来挺好。

需求来了，问他。

线上报错，找他。

实施遇到问题，还是找他。

直到有一天他请假，或者同时被几个项目拉住，团队才发现很多事情没人接得上。

我遇到过一次类似情况。一个老同事出差，现场突然反馈数据对不上。群里一开始很热闹，大家都在猜：是不是设备时间错了，是不是接口漏了，是不是同步任务没跑。

最后绕了一圈才发现，是某个客户现场有一套特殊配置，只有他知道。

问题不大，但那一刻很提醒人：系统知识如果只存在一个人的脑子里，它就不是团队资产。

这不是某个人的问题。

这是团队把知识放在一个人脑子里太久了。

二、知识不扩散，团队就很难真正变强

有些技术负责人会觉得，团队里有一个高手挺好。

确实好。

但如果所有关键判断都靠这个人，那团队能力其实没有沉淀下来。

新人永远只能问。

其他开发永远只负责自己那一小块。

测试不知道系统真正的风险点。

实施只知道操作步骤，不知道异常背后的原因。

最后这个系统看起来有人维护，其实是一个人在撑。

这件事最危险的地方在于，它平时不明显。

只要那个人还在，项目就能转。

但它会慢慢限制团队上限。

三、知识扩散不是让人写一堆没人看的文档

一提知识沉淀，很多人第一反应是写文档。

文档当然需要。

但如果只是让人补一堆“系统说明书”，最后大概率没人看，也没人维护。

我更倾向于把知识扩散放到日常动作里。

比如关键模块不要永远一个人改。

比如线上问题复盘时，不只是那个人讲结论，而是把排查过程讲出来。

比如复杂需求评审时，让其他人先说理解，再由熟悉的人补边界。

比如 Code Review 不只是看代码风格，也顺便讲一下这个模块为什么以前这样设计。

这些动作看起来慢，但它们会让知识慢慢从一个人身上移到团队里。

还有一个小办法我觉得有用：每次线上问题处理完，不要只在群里回一句“已修复”。

至少补三句话：

问题是什么，为什么发生，下一次怎么查。

这三句话积累久了，比临时补一份厚文档更容易被团队用起来。

四、技术负责人要主动拆掉单点依赖

单点依赖不会自己消失。

因为它短期太方便了。

大家都习惯找最懂的人，最懂的人也习惯快速解决问题。

所以技术负责人要主动拆。

可以从几个小地方开始：

让第二个人参与关键模块修改；

让新人跟一次线上问题排查；

把常见问题整理成排查清单；

把关键业务规则写进测试用例；

每次项目复盘时，记录一个“以前只有某个人知道”的点。

不用一下子做得很重。

但要持续做。

知识扩散这件事，最怕运动式整理。

某天突然要求大家补文档，补完以后再也没人看。真正有效的，反而是每次项目、每次 Review、每次故障后顺手留一点。

五、小结

团队里有高手是好事。

但如果只有一个人最懂系统，就要小心了。

真正健康的团队，不是每个人都一样强，而是关键知识不会只挂在一个人身上。

一个人可以是专家。

但系统不能只靠专家记住。

本系列：