带团队最怕的不是慢，是问题没人说

带团队以后，我越来越怕一种安静。

不是大家不说话的安静。

而是每个人都说“还行”“差不多”“在处理”，但到了联调或者上线前，问题突然冒出来。

接口没对上。

数据口径不一致。

设备现场情况跟最初理解不一样。

某个功能其实卡了三天，只是没人说。

这时候再补，成本就很高了。

我以前最容易被“差不多”骗到。

周三问进度，说差不多。

周四问联调，说还行。

周五下午准备合并，才发现核心流程还没完整跑通过。那种时候你再想拆风险、调资源、改方案，选择已经很少了。

一、慢一点不可怕，假装顺利才可怕

项目慢一点，有时候是正常的。

需求复杂，系统历史包袱重，新人需要时间，外部依赖没到位，这些都会让项目变慢。

慢本身不是最大问题。

最大问题是慢了没人说。

因为没人说，负责人以为进度正常。

测试以为开发能按时提测。

业务以为上线时间没变。

等到问题暴露时，所有人的预期都已经被打乱。

这时候团队就容易进入一种很糟的状态：白天解释，晚上补锅，第二天继续说“快好了”。

而且这种状态会传染。

一个人不说问题，另一个人也不好意思说。大家都在撑，最后撑到谁都撑不住。

二、为什么大家不愿意说卡住了

很多时候，不是大家故意隐瞒。

有的人觉得自己再试试就能解决，不想显得能力不行。

有的人怕一说卡住，就被追问为什么没早点处理。

有的人不知道这个问题会影响别人，以为只是自己这块慢一点。

还有的人之前说过问题，但得到的反馈是“你先想办法”，后来就不太愿意说了。

所以风险不暴露，往往不是一个人的问题。

它跟团队氛围、反馈方式、任务拆分和负责人处理问题的方式都有关系。

如果每次有人暴露问题，迎来的都是责备，那下次大家就会更晚说。

三、技术负责人要让“说问题”变得正常

我现在更愿意在项目开始时就讲清楚：

问题早点说，不代表你不行。

真正麻烦的是你已经卡住，却让别人以为你没卡住。

这个口头说一次没用。

要在日常里形成习惯。

比如任务同步时，不只问“做完了吗”，还要问“有什么卡点”。

比如有人提早暴露风险，不要第一句话就问“为什么现在才说”，而是先处理影响。

比如一个问题连续卡两天，就要主动拉人一起看，而不是让负责人靠感觉猜。

风险暴露得越早，处理方式越多。

暴露得越晚，就只能靠加班和妥协。

四、卡住不是失败，没反馈才是失败

有些复杂问题，本来就会卡。

比如旧系统迁移。

比如设备协议兼容。

比如性能瓶颈。

比如跨部门接口联调。

这些事情不可能一路顺。

所以团队不能把“卡住”当成丢脸。

真正要建立的是一种反馈机制：我现在在哪里，遇到了什么问题，预计影响什么，需要谁帮忙，下一步怎么处理。

这几句话说清楚，团队就还有机会调整。

后来我会让大家用很普通的话说卡点，不需要包装：

我这里卡在设备回包不稳定；

我这里缺一个确认口径；

我这里需要后端帮我看一下日志；

我这里如果今天过不去，会影响明天提测。

说清楚这些，比一句“还在处理中”有用得多。

五、小结

带团队最怕的不是慢。

慢可以调整计划，可以拆范围，可以加资源，可以换方案。

最怕的是问题没人说。

没人说，所有判断都是假的。

技术负责人要做的，不是逼大家每天报喜，而是让团队敢于报忧，并且知道报忧以后事情会被处理，而不是人先被处理。

本系列：