工作时间碎片化已经成为职场人的常态，作为一个不是那么 top 的纯技术人员，你会经常被各种各样的人打断。老板突然说xxx你过来一下，跟你说个事。产品经理突然说 xxx 有个功能要跟你对一下。其他开发同学会突然找你说，帮忙捞一下日志，查一下 xxx 问题。
解决这些问题，要有思路去解，不能单单靠 “努力” ，努力这件事情其实谁都可能做得到，只要不是特别懒没什么责任感，努力是可以通过个人主观意识改变的。但是意识到工作是可以被拆解的这件事情，可能你想破头也未必能意识得到。毕竟你已经“忙"得没有时间去思考了。或许有人想到了工作应该被拆解，但是不知道怎么拆解，也是一个比较头疼的问题，聊一套比较常规的工作管理的套路吧，期待你也可以游刃有余一点，忙得比较有秩序一些。
1、用表格给你自己排期。
2、拆解工作后再开工，列计划。
3、凡事不要急着答应，使用 "行，但是" 缓一缓。
4、搞不完就是搞不完，不要硬撑。
用表格给你自己排期
这个表格细化到天的维度就可以，具体怎么排看你自己，一般来说，平均一天不宜安排超过三个以上并行的任务，即使任务项很小，也可能会耽误你非常非常多的时间。按照这个原则，做好你自己的需求排期表。一旦你发现自己某一天的任务项超过三个了，请往后排。当然这上面只是一个原则，让你可以用可视化的方式聚焦自己计划要做的事情，让自己知道自己啥时候该干啥，自己的任务有多重。
拆解工作后再开工，列计划
有同学又要问了，那这个排期从哪来呢？是不是所有人让我干的活我都得做？其实并未必，所有的工作都是可以被拆解的，拆解到简单成一个刚毕业的同学都能在十分钟内搞定的程度，才是一个拆解的好案例，这也让你可以使用碎片化的时间好好写代码。毕竟，干活的时候不被打断，那是不可能的。比如你一个任务就定义为炒菜，那么你完成工作的粒度就只能是炒菜，只要整个菜没炒出来，你的活就算没做完，如果中间被人打断了，你就很难重新进入到炒菜的状态，毕竟你已经忘了上下文了。我们换个思路，你把炒菜拆解成 买菜、洗菜、切菜、开火、加盐、加油、炒菜、装盘。只要你把上一个阶段的事情做好，每一个阶段其实事情都很简单，回来只需要看看下一个步骤该干啥，你就可以非常快捷进入工作状态。这，让你拥有了可以被打断的能力。
凡事不要急着答应，使用 "行，但是" 缓一缓
很多刚毕业甚至工作了很多年的小伙，因为很怕拒绝别人，就总是说好的，这带来了一个问题。你并不了解问题的全貌就直接答应了，你并不知道你当前工作的负载你就答应了，你并不知道关联方的态度你就直接答应了。这会让你非常非常非常被动。并没有人要求你完成所有的事情，每个人对你的期望都是你可以完成当前最重要最紧急的事情，其他的事情都在某一个可被接受的计划里完成即可。
"这个需求可以做吗？"
"行，但是我计划是要先完成当前手头这个，你的这个需求优先级比我手头这个高吗？如果比我这个高那我先完成你这个，我手头的这个计划可能要变动一下"
"这个需求可以加吗？"
"行，但是我要跟关联方确认一下排期，晚点给你答复可以吗？"
看看是不是完全不一样？你有了思考的时间，也给被人可以接受的答复。
搞不完就是搞不完，不要硬撑
有的同学，任务都快延期了，还不敢说，一直等到最后一刻被逼着才说搞不定了，这时候又需要很多其他同学陪他一起擦屁股，搞出一堆临时方案或者延期或者加班。其实很多事情都应该被提前说出来，搞不完就是搞不完，硬撑也搞不完，每个人的吞吐量都是有一定限度的，搞不完把需求精简或者往后排期都是可以被接受的，毕竟人非圣贤，人力是有限度的。但是一个需求承诺了做完但是最后没完成，也不提前暴露风险，这是不可以被接受的，这是失信。所以，搞不完提前说，在分配任务的时候就说，在拆解任务的时候就说，在意识到已经搞不完的时候就说，越早说，解决这个问题的时间就越充足，方案也越好。
忙可以，别瞎忙还背锅，就这样。
腾讯云开发者
