带了四年团队，我才搞清楚什么叫技术管理

一、2017 年，我以为技术管理就是……

2017 年我第一次主导一个项目，那时候的项目规模不大，三个后端，一个前端，一个测试。

我的管理方式很简单：把需求拆成任务，分给每个人，定好时间节点，然后盯着代码提交。每天晚上我会看一遍大家的提交记录，如果代码逻辑有问题，我会直接在 Review 里改掉或者告诉他们怎么改。

我当时的判断是：项目能按时交付，代码质量过关，这就是管理好了。

有一次一个新同学交了一段代码，判断逻辑嵌套了四层 if-else，我直接在 Review 里批了几条注释，把正确写法贴上去，附了一句”这样更清晰”。他改了，改完没有说什么，项目也按时上线了。

我以为这件事到此为止了。

二、几年后发现不对劲的地方

大概 2019 年前后，团队扩到了七八个人，我发现一件奇怪的事：技术方案层面出问题越来越少，但整体推进却越来越费力。

需求讨论会开完，大家回去做，做完了才发现理解不一样。不是哪个人的问题，是同一段话，不同的人读出了不同的意思，但没有人在开会时说出来。

Code Review 提了意见，有人改了但下次继续犯同样的错误，好像那个 Review 只是走了个流程，没有真正发生学习。

有一个经验丰富的同学，每次我们讨论方案他都点头，轮到他开口就说”都行”。我后来单独问他，他说：”你已经有想法了，说了也没用。”

这句话让我很不舒服。

三、让我真正转变的那个事件

2020 年，有一次我们在做一个比较复杂的功能——涉及多个服务之间的状态流转。我在白板上画了方案，讲了大概三十分钟，问大家有没有问题，大家摇头说没有。

两周后联调，发现两个服务的状态机理解完全对不上。我看了一下各自的代码，每个人写的都符合自己理解的逻辑，但两个逻辑合在一起是错的。

我很生气，当时觉得这是执行问题。但等冷静下来我复盘，那个设计方案是我讲的，讲完我问”有没有问题”——这种问法本质上是在等对方主动暴露困惑，但大多数情况下人不会这样做。

那次之后我把方案讨论的方式换了：不再是”我讲你们听”，改成”我先说一个方向，每个人说一下你理解的实现是什么”。暴露出来的分歧，当场收敛，而不是等到联调才发现。

这个变化看起来很小，但节省的后期成本是以天计的。

四、现在的理解

带了四年，我现在对技术管理的理解只有一句话：降低协作成本，比提升个人产出重要得多。

一个团队里最大的效率漏洞，往往不是某个人写代码慢，而是信息在传递过程中的损耗——理解偏差、沉默的困惑、没有当场说出来的疑问。这些损耗不会出现在任何一个人的提交记录里，但它们是真实存在的，而且会累积。

“管代码”和”管人”的本质差异在这里：代码的问题是确定性的，能看到，能改；人与人之间的信息传递问题是模糊的，看不到，不改只会越来越严重。

我 2017 年在 Code Review 里改那段 if-else，改的是代码。我现在更关心的是：那个同学在看到我的注释时，他有没有真正理解为什么要这样改——如果没有，下次他还会写同样的代码，而我只是在做无效重复。