成为负责人以后

刚成为小团队负责人时，我觉得工作还是差不多，需求要做，代码要写，问题也照样需要排查，只是多了几场会议，还要分配任务、跟进进度。

过了一段时间才发现，自己能把事情做完，和团队能稳定地做完，是两件不同的事。

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

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

一项任务只有我知道该注意什么，就每次亲自检查，一个系统只有少数人会排查，就在故障时及时介入，短期确实省事。时间久了，事情都要经过我，团队成员也很难自己判断。

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

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

程序的输入、输出和执行结果通常有相对清楚的定义，团队沟通却没有这么明确。

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

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

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

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

我知道任务从哪里开始，就容易觉得别人也应该很快找到入口，提醒过一次的问题，也期待对方下一次就能改掉。

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

负责人要给出反馈，也得接受变化没有那么快，先看对方有没有理解问题、是否愿意修正，再看团队能为这种修正提供什么条件。

从技术岗位走向管理以后，也容易想把专业工作都交出去，自己只管目标、排期和汇报。

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

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

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

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

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

这些工作没有写完一个功能那么直观，但也是我成为负责人后需要花时间处理的事。