技术管理

有一种帮忙，刚开始看起来特别有效。开发同学方案没想清楚，你帮他补完整。测试同学不知道怎么验证，你直接列清单。产品需求边界模糊，你替大家定下来。项目卡住了，你开个会，把每个人接下来做什么安排好。事情确…

带团队以后，我越来越怕一种安静。不是大家不说话的安静。而是每个人都说“还行”“差不多”“在处理”，但到了联调或者上线前，问题突然冒出来。接口没对上。数据口径不一致。设备现场情况跟最初理解不一样。某个…

技术负责人要不要写代码？这个问题挺容易吵起来。有人觉得当然要写，不写代码怎么懂系统。也有人觉得不该写，负责人要看方向、带团队、管交付，不能陷在具体实现里。我现在觉得，这事不能一刀切。真正要问的不是写…

很多团队里都有这样一个人。系统哪里有坑，他知道。线上问题怎么查，他知道。客户现场某个奇怪配置为什么不能动，他也知道。大家遇到问题第一反应是找他。短期看，这个人很重要，项目也离不开他。但从团队角度看，…

项目越急，话越熟悉。“先上线，后面再优化。”“这个版本先简单点。”“客户先能用，其他的慢慢补。”这些话不一定错。真实项目里，谁都不可能每次都用最理想的方式做事。时间、预算、人员、现场压力都摆在那里，…

技术人有时候会有点委屈。明明已经提醒过风险了，最后出了问题，别人却说：“你当时怎么没说清楚？”你回想一下，自己确实说过。比如说过这个表后面数据量会很大。说过这个接口并发上来以后可能扛不住。说过这个需…

带团队以后，有一种场景特别常见。一个问题讨论了很久，大家都说得有道理，但就是没有结论。前端觉得接口这样设计更方便。后端觉得这样会把复杂度放到服务端。测试关心异常场景怎么覆盖。产品说用户其实只关心页面…

我以前有个习惯：只要看到方案不太稳，就忍不住自己补上。接口怎么设计，我来想一下。数据库表怎么拆，我来画一下。线上问题怎么查，我先上服务器看一下。需求说不清楚，我去跟业务再聊一轮。当时觉得这很正常。毕…

我刚开始带项目的时候，理解得挺简单。需求来了，拆一下任务，排一下时间，谁负责前端，谁负责后端，谁负责测试，最后盯着进度往前推。那时候我以为，只要自己技术判断还可以，项目大概率就不会太失控。后来才发现…