因为我自己负责的一摊事，目前都在我年初的规划和预期之内进行，没有什么超出预期的情况出现，一直处于那种按部就班的状态，所以我自己的事情不忙。
在看到其他人“看起来很忙”的状态时，我就会好奇，在忙啥。
忙碌容易让人陷入一种短视的境地，让人重复昨天，无法升维看待事物，也无法获得成长。
忙碌，让人陷入怠惰，表面看起来很勤奋，但其实是很多时候是不愿突破自己，用过去的习惯做今天的事情。
《稀缺》这本书很好的解答了怎么避免忙碌。
简单来说就三点：
- 时间管理
- 找到你要做的事情，并做归类；
- 留余；
- 求助
先说，时间管理。
一个owner，不管是团队owner，还是系统owner，或者架构师，都有自己负责的一摊事。
想要做好这摊事，owner或者管理者就需要花时间去想这摊事。
也就是说你需要预留出相当一部分时间是用于思考的，而不是用于执行的。
而且这部分时间不能是碎片的，或是马马虎虎的时间。
反而是那些对你效率非常高的整块时间，用于思考才最有价值。
如果用于思考的时间和用于执行的时间分配上不对，就会出现常说的，用战术的勤奋代替战术的懒惰问题，对整个团队来说是有害的。
一个owner，一个管理者，一个架构师，最重要的就是所谓的战略选择。
战略选择包括，战略目标的制定，战略打法的选择，战略时机的把握，战略节点的达成等。
战略执行的背后，又需要匹配相应的资源。对于团队不具备的能力，leader需要投入精力做培训，培养团队成员热情。
需要将目标清晰的传达给每个参与战斗的同学。
其实涉及到团队搭建，文化与习惯改变，制定原则等问题。
这些都是需要花时间想清楚的，想清楚了，效率和质量才会高。
不然就会出现，带着大部队胡乱试错的情况。
所以，一个管理者如果一直很忙，要么是自己不行，要么是招的人不行。
时间分配原则上，可以参考重要-紧急的时间管理四象限。
总结来说，管理者必须分配给自己足够多的时间用于思考，不要忘了大局。
再说下，找到你要做的事情，并做归类。
管理者有管理者要做的事情，owner有owner需要做的事情，架构师有架构师需要做的事情。
这个边界一定要清晰。
我见过一些管理者，做着做着就去做下属该做的事情去了。
这不仅占用了管理者关键的时间，也挤占了下属的成长空间。
让大家都陷入一种不信任，低效忙碌的境地。
所以要找到自己该做的事，并做归类。
比如上面说了，管理者该做的事情是多思考。
架构师要做的事情是划分好整个架构的边界，让核心能力在合适的边界下成长起来。架构师要关注如何低成本的实现系统的高可用，如何做好稳定性，如何让业务变更更便捷、迅速。
技术经理，要了解自己的业务发展情况，和技术系统做衔接。要知道一个系统的底线和上限，要不断提升底线和上限。
我见过一些工作非常忙碌的研发同学的代码。
说实话，他们会话很大的功夫，在堆砌很多代码，实现眼前的需求。
很少的人会停下来，想想这部分功能在短期是否是必须的，是否是核心功能。
如果不是主线任务，那应该如何低成本的方式控制好风险，同时交给二期迭代。
因为紧张的工期排在眼前，导致大量的复制粘贴代码，这部分不能形成资产的代码长期放在这里，就会形成技术债。
我之前做类似的大需求，一般会把需求划分成几个模块，这些不同模块的功能对应的代码也会出现在不同的模块下。
最后会花功夫低成本的和现有功能集成起来。
而不是花很长的功夫去修改存量代码。
某种程度也是一种“对修改封闭，对扩展开放”的OOP原则吧。
有些人经常会被自己负责系统的临时性的问题牵扯精力。
导致自己平时非常忙，这其实就陷入到了紧急时间象限的境地了。
比如你的系统老有问题，各种层面的稳定性问题，那你就要花一定时间去把自己系统的稳定性问题系统的解决掉。
如果你的每次需求迭代，都需要修改大量的代码，那你就要提前花精力做好系统需求的模块化划分。
比如我之前接手过一个系统，原有的系统负责人短时间离职了，某种程度是因为这个系统代码太烂了，维护成本和稳定性压力都很大。
我在当时缺少文档，且对系统不够熟悉的情况下，接到了一个时间紧，任务重的需求，怎么搞呢？
之前的同学可能会觉得时间紧，就在非常乱的代码体系上打补丁，先支持下需求。
而我的思路，则是通过答题纸，自测的方式，熬了几个通宵，优先把骨干链路的功能摸通了。
同时在骨干功能上，我看到不合理的地方，有风险的地方重构成我认可的理想态。
当我对核心骨干链路的逻辑知根知底之后，我在增量去做这个需求就非常容易，某种程度上我只需要关注增量代码即可。
而不会像之前同学，测出bug之后，即需要看老代码，又看新功能，感觉上就是乱成一锅粥，没有重点，没有调理。
我的方式是用4天的通宵时间换来了未来长久的低成本维护和稳定性。
而不是一直陷入短视的问题-解决-再发现问题的无效循环中。
保障主链路，保障核心功能可靠，这些都是重要的事情。
花时间做好重要的事情，可以避免紧急的事情发生。
最后一种方式就是，留余。
这个是最现实有效的方法。
如果一个需求你评估下来时间长，那就排这个时间。
如果要压缩时间，对应的也要压缩需求。
很多人出现了错误的做法。
需求不能在排期内完成，就加人。
加人有时候并不是效率高的方法。
因为新人并不能快速理解系统当前的业务知识，新人进来之后，有很长时间是不能干活，不能产生直接价值的。
反而可能会占用主R同学的时间给他讲需求。
或者用错误的方法短期实现了一个功能点，后续这部分变成了新的腐化成本。
这种例子屡见不鲜。
我们可以想想，一个需求的复杂程度和实现的时间是正相关的。
如果要砍时间，对应的有效方法是砍需求。
加人参与，效果上往往得不偿失。
其实还有一种方法是，求助。
就是你觉得自己搞不定了，但又说服不了产品，你可以把情况反馈给你老板，让他帮你和产品聊聊。
说实话，没有什么需求是不能延期的。
我见过很多系统因为上线过程出现故障，而延期上线的，不能延期，只是看天平的另一端是啥。
总结来说，忙的同学，更应该停下来思考下，为什么忙？
是因为时间分配问题，还是做了自己不该做的事情，还是说做事方法不对。
只有不断的在痛苦中反思，我们才能获得成长。
