这是学习笔记的第 2097 篇文章
在早些时候，为了加强个人的时间管理，开始使用一个时间管理软件日事清，目标是把每天的任务都能够拆解，及时跟进完成，目标是好的，但是随着时间的流逝，发现原本的任务开始变了味。
可以举出工作中的很多案例。
1）比如快下班了，出现了一个报警，这是一套分布式环境，结果其中一个节点出现了磁盘空间报警，为了先修复问题，只在一个节点做了操作，而忽略了整个集群，结果会导致两种结果，一种是没过多久会抛出一连串类似的错误，如果在外面，就很影响已有的生活节奏，第二种是下次做维护的时候，发现一个节点的配置信息和其他节点不一致，很自然的引出了“历史遗留问题”。
2）比如做一个设计的时候，假设有ABCDE五种场景，ABCD都设计好了，按照数据流程都是OK的，但是场景E暂时找不到好的办法，烂毛病上来之后，想先实现已有的吧，结果忙忙乎乎的开始写代码，调试，快速的发布上线，因为没有场景E，整个流程就难以形成闭环，到了不得已，开始重新梳理整个流程，发现要改动的地方还蛮多的，这无疑是对于整个需求的一次大手术，返工的代价几乎等于重新完成了一个新的需求的工作量，而这个造成的结果也比较纠结，已有的生成数据该怎么修复，是直接舍弃，还是在线修复，这些都是让人纠结的问题。
3）对于一个任务，感觉花费的时间可能不多，顶多半个小时吧，等你信心满满的打开电脑开始工作的时候，总是会被打断，在各种会议和需求讨论中游离，最后忙活半天/一天下来，那个半小时的需求还是没有动静。
4）或者在工作中，已经安排了3件事情，结果因为各种原因，又加塞进来几件事情，这样时间不变，任务数量暴增，任务的优先级就会发生变化，导致整个进度的设定都会收到潜移默化的影响。
久而久之，人总是会有一种错觉，那就是觉得设定的任务仅供参考。
等到哪一天受不了了，干脆把已有的任务都删掉，不作数了，重新设定目标，然后再开始做的时候，依然会有不同程度的延迟。
在我协作的过程中，我发现有两类问题是比较有意思的，一类是指定日期交付的任务，这类任务的时间和一个产品的里程碑差不多，那么在这种情况下，脑子里就会有一个无形的闹钟，会按照这个日子来提前做准备，尽可能按照任务的截止日期来完成。
另外一类是没有指定日期的任务，这类任务出现延迟的概率要高得多，但是在一个阶段回过头来看，也基本可以完成。
而稍微留意一下周围的情况，也发现大抵如此，也许这就是普通人之间的共性吧。
在这种情况下，我们需要解决的是问题。
1）第一种情况下，我现在采取的方式是发送一封邮件给自己，在邮件内容里面做下备注，这样我第2天的时候就会格外注意这封邮件的内容，及时进行问题状态的更新和反馈
2）从任务的场景来说，如果只是实现了一小部分的场景，那是不够完整的，设计工作在我们整体工作中的占比还是比较高的，我们没法要求自己的设计非常完美，但是我们可以提醒自己，这个方案是不是足够完整，在一些细节打磨上可以权衡，但是要实现整个产品的生命周期管理和流程闭环是我们应该着重要注意的内容。
3）第三种问题的改进，一般是会议需要提前预定，而上午的时候尽可能留出来作为一些有难度的工作内容，比如早上业务同学提交了一个工单，希望我们开通下权限，如果情况允许，我们可以和业务方达成一种默契，即任务我们是否可以调到下午，这样上午就可以做一些有挑战的工作了，而对于会议来说，我们也需要复盘，提高团队的组织效率，对目标达成共识。
4）这件事情略微有些难度，本质上还是做平衡，比如一个任务在这一段时间需要跟进，它的优先层级是不同的。我们尽可能前期去做一些性价比高的事情，比如花费20%左右的精力，能够完成那些60~80%的任务内容，这是最划算不过的了。
当然时间观念还是需要持续培养的，在工作内容方面也不要贪多求全，毕竟万精油角色在某种程度来看还是存在一些风险的。。
相关链接：
个人新书 《MySQL DBA工作笔记》