带团队以后，有一种场景特别常见。
一个问题讨论了很久，大家都说得有道理，但就是没有结论。
前端觉得接口这样设计更方便。
后端觉得这样会把复杂度放到服务端。
测试关心异常场景怎么覆盖。
产品说用户其实只关心页面能不能顺。
每个人都没错。
但项目不能一直停在“大家都有道理”这里。
这种会开到最后，空气会有点微妙。大家都不太想继续争，但也没人愿意说“那就这样”。会议纪要里最后只剩一句“后续再确认”，看起来挺客气，其实问题被原封不动地留到了下一次。
我以前很讨厌这种状态。后来才发现，真正要处理的不是会议拖长了，而是大家都在等一个能承担后果的人。
这时候技术负责人就要判断：是该继续等等，还是该拍板。
一、不是所有讨论都需要马上结束
我以前挺怕讨论发散。
一看大家说不拢，就想赶紧定一个方向。项目时间本来就紧，会议再开下去，感觉像在浪费时间。
后来发现，有些讨论确实需要时间。
尤其是涉及边界、数据模型、外部接口、长期维护的事情，如果太早拍板，后面返工成本会很高。
有些问题表面看是实现方式不同，其实背后是大家对业务理解不一样。
比如一个“设备状态”的字段。
有人理解成实时状态，有人理解成最后一次上报状态，有人理解成业务可用状态。你不把这些东西说清楚，直接拍板一个字段，后面一定会乱。
现场系统里这种词特别多。
“在线”到底是 TCP 连接还在，还是五分钟内有数据上报？
“完成”是工序完成，还是数据已经上传到平台？
“异常”是设备报警，还是人工判定不合格？
这些词如果不拆开，会议上大家都点头，写代码时就会各写各的。
所以有些时候，等等不是拖延，而是在让问题暴露得更完整。
二、但有些事情必须及时收口
另一边也一样。
有些讨论不能一直拖。
比如已经确定不会影响长期架构，只是两种实现方式都可以，那就不要为了“最优解”耗太久。
比如项目已经进入联调阶段，接口字段还在争论命名，这时候更重要的是稳定下来，让测试和前端都能往下走。
比如一个风险已经明确存在，再讨论“会不会发生”没有意义，应该讨论“发生了怎么办”。
技术负责人拍板，不是因为你一定比所有人聪明。
很多时候只是因为需要有人承担收口责任。
团队可以讨论，但不能没有结束点。
三、我判断拍板时机，一般看三个东西
第一个，看这个问题是不是会影响后续很多人。
如果一个决定会影响前端、后端、测试、实施、数据迁移，那就要慎重一点。不是说不能拍，而是要把影响面说清楚。
第二个，看现在缺的是信息，还是缺的是决心。
如果大家还没搞清楚业务场景，那就继续补信息。
如果信息已经差不多，只是没人愿意承担选择后的代价，那就该拍板。
第三个，看拖下去的成本是不是已经高于选错的成本。
有些技术选择并没有绝对对错。继续讨论两天，不一定能得到更好的答案，但一定会让项目往后推。
这时候选一个能解释得清楚、后续能调整的方案，反而更实际。
四、拍板以后，还要把代价讲出来
我见过一种拍板方式，挺伤团队。
负责人说：“就这么定。”
然后会议结束。
大家照做，但心里不一定服。后面一旦出问题，就会有人说：“当时我就觉得这样不行。”
所以我现在更愿意把拍板说完整：
我们为什么选这个方案；
它牺牲了什么；
它适合当前哪个阶段；
如果后面出现什么信号，我们再调整。
我还会把这几句话写进会议纪要。
不是为了留证据，而是为了让后来的人知道：这个选择当时不是没想过别的方案，只是在那个时间点，我们更能接受这个代价。
这样团队至少知道，这不是拍脑袋，也不是谁声音大谁赢。
五、小结
技术负责人不是每次都要最快给答案。
该等等的时候，要让问题被看清楚。
该拍板的时候，也不能让团队一直悬着。
判断的关键不是“我是不是有权决定”，而是“这个问题现在最缺什么”。
缺信息，就继续问。
缺收口，就及时定。
缺承担，就你来承担。
本系列：
- 上一篇：不是所有问题都要自己上
- 下一篇：有些技术风险，不能只跟老板讲技术
- 系列目录：带团队以后，我才明白的事
暂无评论