带团队以后，我才明白的事

我刚开始带项目的时候，理解得挺简单。

需求来了，拆一下任务，排一下时间，谁负责前端，谁负责后端，谁负责测试，最后盯着进度往前推。那时候我以为，只要自己技术判断还可以，项目大概率就不会太失控。

后来才发现，事情没那么顺。

一个团队真正麻烦的地方，经常不是没人干活。很多时候大家都很忙，消息也一直在回，会议也没少开，但项目还是慢慢偏了。需求理解偏了，风险没人说，代码质量开始松，测试发现的问题越来越靠后，最后所有人都觉得自己挺累，但结果并不好。

我印象很深的一次，是周一例会上每个人都说“我这边差不多了”。进度表看起来也挺好，前端 80%，后端 90%，测试用例也在写。

结果到周三联调，才发现大家说的“差不多”不是同一个意思。前端说的是页面静态效果差不多，后端说的是主流程接口差不多，测试说的是用例框架差不多。真正把设备数据跑起来以后，状态流转、异常提示、历史记录全都没对上。

那天晚上开完会，我才有点后知后觉：团队不是没有干活，是我们没有在同一个画面里干活。

这时候我才慢慢意识到，带团队不是把任务分出去那么简单。

一、以前我只看代码，后来开始看系统

做开发的时候，我最关心的是代码能不能跑，设计是不是清楚，性能有没有问题。

这些当然重要。

但带团队以后，你会发现代码只是结果的一部分。代码背后还有很多看不见的东西：需求是不是被理解清楚了，任务是不是拆到了可以执行的程度，开发过程中有没有人卡住，测试是不是提前介入，项目风险有没有被放到台面上。

这些东西不处理，代码写得再漂亮，也可能在交付时变成一堆麻烦。

以前我看到问题，会想着怎么把它改掉。

后来我会多想一步：这个问题为什么会走到这里？是某个人粗心，还是团队机制本来就会让这种问题反复出现？

这个问题一旦问出来，视角就不一样了。

以前看到 Bug，我会先看代码。现在我会顺手看一下：需求评审时有没有说这个场景，任务卡片里有没有验收标准，测试有没有提前拿到接口说明，开发过程中有没有人提过风险。

很多问题最后当然还是落在代码上，但它不一定是从代码开始坏掉的。

二、技术负责人最容易误会自己的作用

技术负责人很容易把自己活成“最后一道防线”。

方案不稳，我补。

进度不动，我催。

代码有问题，我改。

线上出事，我上。

短期看，这样确实有效。项目能往前走，问题也能被压住。

但时间一长，你会发现团队开始等你。稍微复杂一点的判断，大家会习惯性地问：“这个你看怎么做？” 不是他们不愿意思考，而是团队被训练成了这样。

你越能兜底，团队越容易依赖你。

这件事挺别扭的。因为你明明是在帮忙，但有时候帮得太多，反而把团队成长的空间拿走了。

三、带团队以后，很多事都变成了取舍

交付要快，质量也要稳。

需求要响应，边界也要守。

新人要成长，项目也不能停下来等。

团队要有自主性，但关键节点又不能没人拍板。

这些问题没有一个标准答案。很多时候你只能看当时的项目阶段、团队状态、业务压力和系统风险，然后做一个相对合适的选择。

这也是我后来越来越觉得，技术管理不是把事情安排得更满，而是让团队少一些无效消耗。

目标清楚一点，风险暴露早一点，决策及时一点，质量底线稳一点。

不用每件事都完美，但不能一直靠人硬扛。

四、这个系列想聊什么

这个系列不准备写成管理课。

我更想写一些真实项目里会遇到的小场景：

不是所有问题都要技术负责人自己上；
什么时候该拍板，什么时候该让团队再想一想；
技术风险不能只用技术语言往上讲；
交付很急的时候，有些底线还是不能丢；
团队不能只有一个人最懂系统；
技术负责人到底要不要继续写代码；
最怕的不是慢，而是问题没人说；
有时候你以为是在帮忙，其实是在替团队做决定。

这些都不算新鲜道理。

但真正放到项目里，每一件都挺磨人。

因为它们通常不会以“管理问题”的样子出现。

它们会伪装成一个接口没对上、一个字段理解错了、一个人今天状态不太好、一个需求突然改了、一个上线窗口被压缩了。

你要是只盯着表面，很容易头痛医头。带团队久一点，才会慢慢学着去看后面的那条线。

五、小结

带团队以后，我最大的感受是：很多问题不是靠更努力就能解决的。

有些问题要靠提前说清楚。

有些问题要靠团队自己长出来。

有些问题要靠负责人及时拍板。

还有些问题，要承认它就是取舍，不是某个人再加一会儿班就能变好的。

这个系列就从这些事开始聊。

本系列：