不是所有问题都要自己上

我以前有个习惯：只要看到方案不太稳，就忍不住自己补上。

接口怎么设计，我来想一下。

数据库表怎么拆，我来画一下。

线上问题怎么查，我先上服务器看一下。

需求说不清楚，我去跟业务再聊一轮。

当时觉得这很正常。毕竟我是负责人，项目出了问题最后也会落到我这里。与其等别人绕一圈，不如我先把坑填掉。

后来我才发现，这样做有一个很隐蔽的问题。

团队会越来越顺。

但不是团队变强了，而是越来越顺手地依赖你。

一、你以为是在兜底，其实可能是在抢判断

有一次做一个设备接入相关的功能，协议不复杂，但现场情况比较乱。设备状态、断线重连、补传数据，几个点混在一起。

开发同学拿了一个方案过来，我看完觉得问题不少。

如果按以前的做法，我大概率会直接改掉：这里加状态机，那里加补偿逻辑，再把异常场景列出来。

那次我忍了一下，只问了几个问题：

如果设备连续断线三次，页面显示什么？

如果数据补传晚到了，原来的统计要不要刷新？

如果服务重启，哪些状态能恢复，哪些不能？

当时是在一间很小的会议室里，白板上画着设备、网关、平台三段链路。开发同学一开始还有点紧张，觉得我是不是要推翻他的方案。

问到第三个问题时，他自己停了一下，说：“那我这个状态是不是不能只存在内存里？”

我说，你先别急着改，我们把会丢状态的地方圈出来。

问完之后，对方自己就发现方案少了很多场景。

这件事让我印象挺深。

我直接给答案，确实快。但他下次还是会等我给答案。

我把问题问出来，慢一点，但他开始知道自己该怎么想。

二、不是所有问题都值得你亲自处理

技术负责人当然要兜底。

但兜底不等于所有问题都自己做。

有些问题你必须亲自下场，比如：

方向错了，会影响整个系统后续演进；
风险很高，可能影响上线或数据安全；
团队没有相关经验，需要先建立一个参考做法；
外部压力很大，需要有人把边界讲清楚。

但也有很多问题，不一定要你亲自处理。

比如某个接口命名不够统一，某段代码还有优化空间，某个实现方案不是你最喜欢的方式。

这些问题如果每次都由你拍板，团队就会慢慢失去自己的判断。

最后你会发现，你不是在带团队，而是在带一群等你确认的人。

三、技术负责人要学会忍住

这句话听起来有点奇怪。

但我觉得挺重要。

看到一个不完美的方案，先别急着改。

看到一个人踩了小坑，先别急着替他填。

看到讨论绕了一点路，先别急着把答案扔出来。

你可以问问题，可以补边界，可以提醒风险，但不要每次都替团队走完最后一步。

团队要成长，必须有机会自己把事情想完整。

当然，这不代表放任。

如果问题会伤到项目，那就要及时介入。如果只是过程里必要的绕路，就让它发生。很多判断能力，真的不是听别人讲出来的，是自己被问题硌过以后才长出来的。

四、我现在更常做的事

现在遇到类似问题，我一般会先判断它属于哪一类。

如果是方向性问题，我会直接说清楚，不让团队在错误方向上耗时间。

如果是经验不足，我会给一个参考框架，但不把细节全部写死。

如果是普通实现问题，我会让负责的人先讲清楚自己的判断，再一起看哪里不稳。

如果是团队反复出现的问题，我会把它变成规范、清单或者复盘，而不是每次靠我临时提醒。

比如接口评审时，我现在会要求至少说清楚四件事：正常输入是什么，异常输入怎么办，失败后能不能重试，日志里能不能查到原因。

这不是为了显得流程正规。

只是因为以前这些问题太容易在联调时才冒出来。与其每次靠负责人临场补，不如把它们变成团队默认会问的问题。

这个变化不算快。

一开始你会不放心，觉得不如自己上来得稳。

但慢慢会发现，团队能自己处理的问题变多了，你才有精力看更远的东西。

五、小结

不是所有问题都要自己上。

技术负责人真正要做的，不是把团队所有坑都填平，而是分清楚哪些坑必须马上填，哪些坑可以让团队自己看见。

你当然要兜底。

但更重要的是，不要让团队只剩下你一个人在判断。

本系列：