带团队最怕的不是慢，是问题没人说
带团队以后，我越来越怕一种安静。不是大家不说话的安静。而是每个人都说“还行”“差不多”“在处理”，但到了联调或者上线前，问题突然冒出来。接口没对上。数据口径不一致。设备现场情况跟最初理解不一样。某个功能其实卡了三天，只是没人说。这时候再补，成本就很高了。我以前最容易被“差不多”骗到。周三问进度，说差不多。周四问联调，说还行。周五下午准备合并，才发现核心流程还没完整跑通过。那种时候你再想拆风险、调资源、改方案，选择已经很少了。一、慢一点不可怕，假装顺利才可怕项目慢一点，有时候是正常的。需求复杂，系统历史包袱重，新人需要时间，外部依赖没到位，这些都会让项目变慢。慢本身不是最大问题。最大问题是慢了没人说。因为没人说，负责人以为进度正常。测试以为开发能按时提测。业务以为上线时间没变。等到问题暴露时，所有人的预期都已经被打乱。这时候团队就容易进入一种很糟的状态：白天解释，晚上补锅，第二天继续说“快好了”。而且这种状态会传染。一个人不说问题，另一个人也不好意思说。大家都在撑，最后撑到谁都撑不住。二、为什么大家不愿意说卡住了很多时候，不是大家故意隐瞒。有的人觉得自己再试试就能解决，不想显得能力不行。有的人怕一说卡住，就被追问为什么没早点处理。有的人不知道这个问题会影响别人，以为只是自己这块慢一点。还有的人之前说过问题，但得到的反馈是“你先想办法”，后来就不太愿意说了。所以风险不暴露，往往不是一个人的问题。它跟团队氛围、反馈方式、任务拆分和负责人处理问题的方式都有关系。如果每次有人暴露问题，迎来的都是责备，那下次大家就会更晚说。三、技术负责人要让“说问题”变得正常我现在更愿意在项目开始时就讲清楚：问题早点说，不代表你不行。真正麻烦的是你已经卡住，却让别人以为你没卡住。这个口头说一次没用。要在日常里形成习惯。比如任务同步时，不只问“做完了吗”，还要问“有什么卡点”。比如有人提早暴露风险，不要第一句话就问“为什么现在才说”，而是先处理影响。比如一个问题连续卡两天，就要主动拉人一起看，而不是让负责人靠感觉猜。风险暴露得越早，处理方式越多。暴露得越晚，就只能靠加班和妥协。四、卡住不是失败，没反馈才是失败有些复杂问题，本来就会卡。比如旧系统迁移。比如设备协议兼容。比如性能瓶颈。比如跨部门接口联调。这些事情不可能一路顺。所以团队不能把“卡住”当成丢脸。真正要建立的是一种反馈机制：我现在在哪里，遇到了什么问题，预计影响什么，需要谁帮忙，下一步怎么处理。这几句话说清楚，团队就还有机会调整。后来我会让大家用很普通的话说卡点，不需要包装：我这里卡在设备回包不稳定；我这里缺一个确认口径；我这里需要后端帮我看一下日志；我这里如果今天过不去，会影响明天提测。说清楚这些，比一句“还在处理中”有用得多。五、小结带团队最怕的不是慢。慢可以调整计划，可以拆范围，可以加资源，可以换方案。最怕的是问题没人说。没人说，所有判断都是假的。技术负责人要做的，不是逼大家每天报喜，而是让团队敢于报忧，并且知道报忧以后事情会被处理，而不是人先被处理。本系列：上一篇：技术负责人离代码多远比较合适下一篇：有时候你以为是在帮忙，其实是在替团队做决定系列目录：带团队以后，我才明白的事