成为负责人以后

成为小团队负责人以后，我最初并没有觉得工作发生了根本变化。

需求还是那些需求，代码仍然要写，遇到问题也照样需要排查。区别似乎只是多参加几场会议，多分配一些任务，再对项目进度负责。

真正的变化过了一段时间才显现出来：过去我主要确保自己把事情做好，后来则要让一群人能够稳定地把事情做好。

自己会做，不等于团队能做到

个人开发遇到问题，可以依靠经验快速处理。团队工作却不能长期依赖某个人的经验。

如果一项任务只有我知道应该注意什么，我可以每次亲自检查；如果一个系统只有少数人能够排查，我也可以在故障时及时介入。短期看，这是最高效的方式。时间久了，负责人会成为所有事情的必经节点，团队成员也很难建立完整判断。

因此，一些过去可以依靠默契完成的事情，需要被说清楚：目标是什么，为什么这样设计，什么情况必须同步，哪些质量标准不能因为时间紧而放弃。

这并不意味着建立越多流程越好。流程只是把重复判断固定下来，让团队把精力留给真正需要判断的问题。

程序的反馈通常明确。输入、输出、成功和失败都有相对清楚的定义。团队沟通则不是这样。

同一句话，不同的人可能根据各自掌握的背景作出不同理解。会议上没人提出异议，也不代表所有人已经形成一致认识。有些人记住了目标，却没有理解优先级；有些人理解了方案，却不知道它受到哪些约束。

负责人不能只负责“说过”，还要确认关键信息是否真正到达。重要目标需要重复，复杂问题需要写下来，分歧也要在执行之前尽量暴露。

这件事看起来低效，但很多返工恰恰来自对沟通效果的高估。

刚开始带团队时，很容易直接拿自己的做事方式作为标准。

我知道某项任务应该从哪里开始，便会觉得别人也应该迅速找到入口；一个问题已经指出，便期待对方下一次立即改变。

后来才意识到，经验无法通过一次提醒完成转移。人对问题的理解、工作习惯和风险敏感度，都需要在具体事情中逐渐形成。

负责人要给出反馈，也要接受变化没有那么快。真正需要观察的，不是对方是否立刻变成理想状态，而是有没有理解问题、是否愿意修正，以及团队能否为这种修正提供条件。

从技术岗位走向管理以后，还有一种诱惑：把所有专业工作都交出去，只保留目标、排期和汇报。

但小团队负责人如果完全远离实际工作，很快会失去对成本和风险的判断。无法判断方案是否合理，也很难知道成员遇到的困难究竟来自能力、资源还是目标本身。

保持专业能力不等于包办实现。更合适的状态是，关键问题能够深入，日常工作敢于交给成员，并对最终标准负责。

成为负责人以后，产出不再只体现在自己写了多少代码。

一项目标是否清楚，一次分歧是否及时解决，一个新人能否更快理解系统，一个重复问题有没有形成改进机制，这些都开始成为工作的一部分。

它们不如完成一个功能直观，也很难全部量化。但团队能否减少无谓消耗，往往取决于这些看起来不够具体的工作。

负责人不是拥有更多控制权的人，而是需要处理更多不确定性的人。这是我在角色变化之后才逐渐理解的区别。