技术负责人到底负责什么

刚开始做技术负责人时，人很容易有一种错觉：是不是我得比所有人都懂，所有问题都能答，所有代码都能接？

这种想法挺正常。

毕竟很多技术负责人都是从开发里长出来的。以前靠的是把代码写好，把问题解决掉。突然有一天要带几个人，第一反应还是用老办法：我多看一点，我多兜一点，我多写一点。

短期确实有效。

但时间久了你会发现，如果团队所有关键问题都绕不开你，这不是能力强，而是系统有点危险。

刚开始做技术负责人时，很容易把自己当成“高级救火队员”。

哪里卡住了我去看，哪里写不动了我去补，哪里上线有风险我去扛。短期看很有效，团队也会觉得有你在比较稳。

但时间一长，你会发现自己越来越像一个瓶颈。所有稍微复杂一点的问题都绕到你这里，团队反而没有机会把判断长出来。

这时候才会意识到，技术负责人负责的不只是解决问题，还有让团队慢慢具备解决问题的能力。

一、技术负责人不是万能接口

很多团队会把技术负责人用成一个万能接口。

产品问：这个需求能不能做？

测试问：这个问题算不算缺陷？

开发问：这里应该怎么设计？

老板问：什么时候能上线？

线上报警了，大家也会第一时间看你。

这些问题你当然不能躲，但如果每个问题都只靠你临场判断，团队会越来越像一个单点系统。你在，事情就转；你不在，很多人就开始等。

技术负责人的价值，不应该只是“我来回答”。

更重要的是让团队逐渐知道：遇到这类问题，我们应该按什么原则判断。

二、真正要负责的是判断标准

技术负责人很重要的一件事，是建立判断标准。

比如一个需求要不要做，不只是看能不能写出来，还要看：

它是不是当前阶段必须做。
对现有系统影响有多大。
会不会引入长期维护成本。
有没有更轻的替代方案。
做完以后谁来验收，谁来维护。

比如一个技术方案能不能上，也不只是看技术上漂不漂亮，还要看团队能不能掌握、线上能不能运维、出了问题能不能定位。

很多技术问题看起来是选型，实际是取舍。

取舍背后需要标准。标准不清楚，团队就会在每个问题上重新吵一遍。

三、你要比团队早一点看到风险

技术负责人不一定要比每个人都写得快，但最好能比团队早一点看到风险。

这个风险可能是需求风险。

比如需求描述里有一句“支持灵活配置”，你要能听出来这句话后面可能藏着很多未定义的边界。

也可能是技术风险。

比如一个临时字段加进去很快，但它会绕过原来的权限模型，以后所有接口都要补判断。

也可能是协作风险。

比如前后端都说自己这周能完成，但接口文档还没对齐，测试环境也没人准备。

风险越早说出来，处理成本越低。等到上线前一天再发现，就只能靠加班和妥协。

四、不要把所有事都扛在自己身上

技术负责人很容易陷入一种“我不扛谁扛”的状态。

项目要延期了，你去补代码；新人做不动，你接过来；线上有问题，你熬夜排查；需求没说清，你去和产品沟通。

这些事偶尔做没问题，关键时刻也必须有人顶上。

但如果长期这样，团队不会变强，只会更依赖你。

有些问题你应该接住，有些问题你应该带着团队一起拆，有些问题应该让对应的人自己面对后果。

比如新人不会做，你可以陪他把问题拆开，但不要直接替他写完。比如接口设计不清楚，你可以给方向，但最好让负责开发的人自己把文档补齐。

培养团队的判断力，比替团队解决所有问题更重要。

五、向上沟通也是技术工作的一部分

很多技术负责人不喜欢向上沟通，觉得那是“管理层的事”。

但真实项目里，很多技术风险如果不能被业务侧理解，就不会得到资源和时间。

你说“这个模块耦合太高”，别人可能没感觉。

你换一种说法：“如果这次继续在这里加功能，下个月做会员折扣时，订单、支付、财务三块都要一起改，测试范围会翻倍。”对方就更容易理解。

技术负责人要学会把技术问题翻译成业务能理解的风险、成本和选择。

这不是话术，是让决策信息对齐。

六、小结

技术负责人到底负责什么？

不是负责所有代码，也不是负责回答所有问题。

更准确一点说，是负责方向、标准、风险和团队能力。

方向不清，团队会忙乱。标准不清，质量会漂。风险不提前说，交付会失控。团队能力不成长，你就会一直被困在救火里。

一个好的技术负责人，不是让团队离不开自己，而是让团队越来越有能力处理复杂问题。

本系列：