作为一名Senior/Lead 工程师，如何将工作拆解并委派出去
让我们用程序员的思路来解决这个问题。
让我们用程序员的思路来解决这个问题。
在同一家公司担任Senior或Lead多年后，我们总是发现自己被越来越多的需求压得喘不过气来。- -所有人。
因为：你是一个，了解一切，做事迅速，知道全部的人。 😄
你一定是过来人
看看这个, 这是你吗？你发现问题了吗？
是的，你至少应该看到：
- 你总是在第一时间把事情揽下来（eager loading，错！你应该是lazy loading）。
- 你几乎在做所有的事情 (superclass)
- 每个人都在找你! (知识分割原则被破坏)
- 在你下面有一个 “dev1”，等着被指导和帮助你。然而，他是闲置的（multi-threaded模型从未被使用过！）。
- 你被淹没在新的需求和越来越多的bug中（crash！）。
- 瓶颈开始了（blocking I/O）。
- 在最后，“你”甚至可能没有时间为任何人进行入职培训
- 你会被累死。
这个问题在编程领域看起来很熟悉吗？是的。
- Superclass
- Blocking I/O
- Synchronise
- Single-Threaded
让我们用程序员思维来解决这样的问题
Async
始终Delegate(委派)。一旦你delegate(委派)了任务，一个新的线程就开始了。你准备好获取新的“请求”，即便你是单线程的（但你确实有多线程选项，如下所示），但你仍然可以像Redis一样快速，只要你的输入/输出没有被block。
所以当你从PM那里得到一个任务时，你应该尽量避免亲自去做，而是尽量分配给一个初级开发者。使用贪婪思维。
但是如果你没有人可以委派任务怎么办？作为全干工程师，忘记前面的。这是你的工作。😄
Polling
众所周知，当开始一个新的数据库连接被创建，ORM从线程池中拿起一个新的线程。如果我们把这个模式应用于管理，会怎么样呢？
你的团队就是你的 “线程池”。你需要Take GOOD care of them。当我说Take GOOD care of 的时候，我的意思是：
- 让他们找到工作的乐趣
- 会做一些有挑战性的事情
- 他们喜欢正在做的工作
- 获得他们所需要的东西 (显示器、人体工学座椅、新的书籍、培训等等)
耐心
回答问题并指导他们。赋予他们权力，将提高团队的发展吞吐量。
权衡
你喜欢 “dev1”，因为他很好，所以你希望他做得更多？ 不过要小心！不要让任何人超负荷工作，忽略了其他人的成长。
确保有人准备好被 “安排”。你能建立的人才库越大，你的团队就能采取更高的吞吐量，这意味着更多的生产力。
Task.join()
有时，当你得到一个 “Epic的任务”，然后分解并 “开始 “多个任务时，你需要 “聚合 “结果。因此，在分配任务后，确保你发送 “让我们在下午4点进行同步 “以 “加入 “线程。
Fast path 和 Slow path
在上图中，我想解决2个问题。
- 使用队列来存储 “不紧急 “的任务，并在以后批量处理它们
- 对于紧急问题，立即回复，并委托一个开发人员 “链接 “给请求者
如果你曾经做个大数据相关的项目，你应该熟悉数据处理流程。所以这个想法在这里也适用。把 “需求 “想成 “数据”。
如果是一个紧急的需求，就走fast path，这可能意味着马上从文档中给出答案并回复电子邮件，或者 “现在就做一些事情”（从你的专家库中挑选一个人并立刻 “开始（）”）。
如果没有，就走slow path，也就是开ticket，把它分配给自己或别人。
如果可能的话，总是尝试走slow path。
同样，贪婪算法。(非常非常重要，详见下文)
Batch
正如你在上面看到的。批量处理 “碎片化 “的事情。
这个想法并不是最近提出的。意思是固定一个时间范围，然后每天做一些事情。例如，在上午10点、12点和下午4点检查并回复电子邮件和信息；或者在下午1点和5点Review所有Pull Request。
如果每件事都是一个 “片段”，尽可能尝试批处理, 这不局限于个人任务，也可以是会议。而不是ad-hoc或每小时检查状态，每天开一个站会是批处理的一个不错的方法，”收集想法或状态”。
Greedy
第一，保护自己！尽量不要自己解决任何问题。快速完成并让PM满意绝不是你的目标。
时刻牢记，你是你的团队的单一故障点。这意味着你是唯一的主节点，而且没有zoo keeper来帮助你！
第二，当你分配任务时，尽量先分配到最初级的开发人员。
第三，尽可能地估算时间。在估算一项任务时，当有人问你 “你的团队需要多长时间完成这项工作？”时，你需要先问要做这项工作的人，然后把这个数字乘以3–5倍。
如果你是PM：不要误解我，我们没有坐在那里什么都不做。
我们有bug要修复，有技术债务，有人员要培训，有文档要写，有测试要做！我们的团队需要更多的时间，为了质量！”！
Prioritizing
优先级不断变化。我们都知道，有些东西突然变成了最高优先级的事项。
只是为了让你的思想时刻准备好这种情况的发生。
做好准备，这种情况随时可能发生。
Callback VS Poll
对于效率高的人(dev1)，一旦分配了任务，那就相信他们，等待回复；对于效率差的人(dev2)，你可能需要主动检查状态。
这需要一些方法,
不要对这个 “dev2 “生气。要有耐心。
这里的目标是把每个人都变成 “可信任的”，根本不需要轮询。如何做到这一点？
首先，这可能意味着分配给他/她的任务是错误的。改变到另一个ticket，看看情况如何；其次，尝试分配一些更容易的任务，如果仍然不工作，那么下次尝试让他/她选择一个ticket，看看情况如何。
Save()/Initialize()
在早上，你想调用类似 “initialize() “的函数来快速预热。
这个技巧非常简单。在离开之前 “save() “你的一天。在你的记事本上几下你明天早上需要做的前3–5件事情。尽量写得详细一些。不要写 “Add some tests for this logout module”，你可以写 “ADD JWT token expiry test to logout module, document link can be found at xxxx”。
我们的想法是，把你现在脑海中的任何细节都倒出来，并确保你在加载所有这些 “日志 “后能立即开始。
第二天早上打开笔记本电脑，阅读 “日志”，并在几秒钟内进入到continue状态。
写在最后:
感谢您的阅读， 我自己是一名程序员， 也领导一个规模不大的团队， 在开始做leader的时候总是喜欢自己做所有的事情， 因为抱着一种别人没我做的好， 或者分配出去， 不如自己做的快之类的。 也许一开始的确是这样， 但是随着时间推移， 我逐渐变成文章开头的那样， 所有人都找我， 我成为了单点故障， 我出门吃饭得带着电脑， 我经常被迫把车停在路边解决问题， 我带着孩子和妻子出去旅游的时候总是被紧急的会议打断。
如果一开始我学会用这种方式委派（我们团队其实整体的实力还是很强的）， 那么我们的效率会更高， 而我也会更轻松。 希望这些方法也能帮到你。
延伸阅读:
