但个人以为，越是“赶不上”变化，越需要有计划。怎么说呢，两点体会，权当胡诌。
第一点，当你没有计划的时候，乱七八糟的事情会特别多，但当你有了计划之后，很多意外的事情会减少。听上去有点玄学的味道，但也不是完全没道理。
拿我自己来说，我是一个有“拖延症”的人。当我有了一个目标但没有制定计划时，我十有八九会拖延，一边拖延，一边做了很多其它不相干的事情，这些其它的事情可能就会给我带来额外的麻烦，对我实现原本的目标产生干扰。但如果我做了计划，分解目标，制定时间表，我就能有效地治疗“拖延症”，因为我时刻都处在自己构建的过程管控中，每一步的衔接都有安排，这样我的注意力就容易保持集中，甚至全程高能。而我发现，精力涣散最容易发生在当你不知道下一步该干嘛时。
第二点，确实存在变数很多的客观场景，在这样的险恶环境中，你更应该加倍地做计划，改计划。一方面，这是唯一让你在风云变化中能有所依靠、有所参照的资本。就好比，需求的变更是无法避免的，但我们可以做好需求管理，至少知晓变更的发生，这同样也是一种经验的积累。另一方面，在迭代计划的过程中，熟能生巧这个规律会让你逐渐得心应手地面对变化，除非你是傻子死不开窍另当别论。永远不要低估积累的力量，你努力应对变化，慢慢地，你就能驾驭变化，变化就不会成为干扰。能力就这样成长了。
说到计划，自然要说到“时间表”这个概念，做计划的方法很多，无一例外会涉及到时间表。脱离时间的计划是伪计划，因为人的时间是有限的，而且很多事情是有时效性的。
这就需要估时。
也是个棘手的技术活，毫不夸张地说，这是世界性难题。所以如果你总是估不准，完全不用自卑，全世界都一样。当然，办法还是有的，事实上，根据不同的计划范围，我们并不一定需要很精确的估时，过日子又不是开火车。
大约 20 年前，大名鼎鼎的 Joel Spolsky（稍等，也许你没听过这个名字，但我100%肯定你用过他的产品 - Stack Overflow， 如果你不幸没用过这个网站，那我200%肯定你用过他的产品 - Excel）总之，这位大人物在 2000 年写过一篇博文 "Painless Software Schedules ", 介绍了一套他自己的“软件开发时程”方法论。虽然有些久远了，甚至作者自己都修改了文章的开头，提醒读者他已经有了更好的替代方案，但这并不影响该方法的价值，而我自己在学习了他这套“过时的”解决方案之后，一直将其用于自己的工作、生活中。
概括来说，该方法的核心思想有两点：目标分解 & 估时修正。
目标分解是做计划的基石。罗马不是一天建成的，大事化小是所有干大事的必经之路，这也是强迫你认真做目标分析的手段，合理的分解只可能建立在对目标的充分认识之后。
分解的颗粒度要足够细。因为原文讲的是软件开发，所以作者明确提出，在编程中，任务要按“小时”来评估，而不是按“天”。这个单位的变化很重要，单位大了，误差就大。按照作者的经验，超过 16 小时的任务都应该进一步拆分，因为在这个时长之上，意味着你并没有真的想清楚要做的步骤是怎样的。说得直接点，就是在糊弄人。
当然，我们在做个人全年计划时，不必生搬硬套拿小时做单位。这里的要点在于计划要足够细才有意义，至于说具体细到什么程度，这个其实需要根据自身经验去琢磨。非要说有什么窍门的话，也许拿大众的普遍标准再进一步就可以了，比如大家都按天算，你就试着按小时计，大家都按月算，你就试着按周来计。群众的眼睛也许是雪亮的，但群众的做法通常是平庸的，所谓脱颖而出，往往就是在大众平均水准之上再进一步，你就先进了。
在计划初期，你会有一个初步估时，随着进度的发展，比如到了中间阶段，可能发现之前预估的时间不对，这时你需要写下第二次估时，最后当完成任务时，再记录下实际耗时。最终，你会得到 3 个时长：第一次估时、第二次估时、实际耗时。
一开始，你可能（几乎肯定）这三个时长看上去牛头不对马嘴，随着不断地纠错、修正，从过去错误的估计中总结经验。第二次估时会和实际耗时越来越接近，再后来，第一次估时和第二次估时也会越来越接近。到那时，你对于估时的判断力就练成了。
简单的手法，坚持做，就会产生神奇的效果。
”人一能之，己百之，人十能之，己千之，虽愚必明，虽柔必强。“ 这是这个道理。（语出《中庸》）