人人都爱写总结, 却少有人做计划 (2)

  但个人以为,越是“赶不上”变化,越需要有计划。怎么说呢,两点体会,权当胡诌。
  第一点,当你没有计划的时候,乱七八糟的事情会特别多,但当你有了计划之后,很多意外的事情会减少。听上去有点玄学的味道,但也不是完全没道理。

  拿我自己来说,我是一个有“拖延症”的人。当我有了一个目标但没有制定计划时,我十有八九会拖延,一边拖延,一边做了很多其它不相干的事情,这些其它的事情可能就会给我带来额外的麻烦,对我实现原本的目标产生干扰。但如果我做了计划,分解目标,制定时间表,我就能有效地治疗“拖延症”,因为我时刻都处在自己构建的过程管控中,每一步的衔接都有安排,这样我的注意力就容易保持集中,甚至全程高能。而我发现,精力涣散最容易发生在当你不知道下一步该干嘛时

  第二点,确实存在变数很多的客观场景,在这样的险恶环境中,你更应该加倍地做计划,改计划。一方面,这是唯一让你在风云变化中能有所依靠、有所参照的资本。就好比,需求的变更是无法避免的,但我们可以做好需求管理,至少知晓变更的发生,这同样也是一种经验的积累。另一方面,在迭代计划的过程中,熟能生巧这个规律会让你逐渐得心应手地面对变化,除非你是傻子死不开窍另当别论。永远不要低估积累的力量,你努力应对变化,慢慢地,你就能驾驭变化,变化就不会成为干扰。能力就这样成长了。
  

  说到计划,自然要说到“时间表”这个概念,做计划的方法很多,无一例外会涉及到时间表。脱离时间的计划是伪计划,因为人的时间是有限的,而且很多事情是有时效性的。
  这就需要估时。
  也是个棘手的技术活,毫不夸张地说,这是世界性难题。所以如果你总是估不准,完全不用自卑,全世界都一样。当然,办法还是有的,事实上,根据不同的计划范围,我们并不一定需要很精确的估时,过日子又不是开火车。
  大约 20 年前,大名鼎鼎的 Joel Spolsky(稍等,也许你没听过这个名字,但我100%肯定你用过他的产品 - Stack Overflow, 如果你不幸没用过这个网站,那我200%肯定你用过他的产品 - Excel)总之,这位大人物在 2000 年写过一篇博文 "Painless Software Schedules ", 介绍了一套他自己的“软件开发时程”方法论。虽然有些久远了,甚至作者自己都修改了文章的开头,提醒读者他已经有了更好的替代方案,但这并不影响该方法的价值,而我自己在学习了他这套“过时的”解决方案之后,一直将其用于自己的工作、生活中。
  概括来说,该方法的核心思想有两点:目标分解 & 估时修正
  目标分解是做计划的基石。罗马不是一天建成的,大事化小是所有干大事的必经之路,这也是强迫你认真做目标分析的手段,合理的分解只可能建立在对目标的充分认识之后。
  分解的颗粒度要足够细。因为原文讲的是软件开发,所以作者明确提出,在编程中,任务要按“小时”来评估,而不是按“天”。这个单位的变化很重要,单位大了,误差就大。按照作者的经验,超过 16 小时的任务都应该进一步拆分,因为在这个时长之上,意味着你并没有真的想清楚要做的步骤是怎样的。说得直接点,就是在糊弄人。
  当然,我们在做个人全年计划时,不必生搬硬套拿小时做单位。这里的要点在于计划要足够细才有意义,至于说具体细到什么程度,这个其实需要根据自身经验去琢磨。非要说有什么窍门的话,也许拿大众的普遍标准再进一步就可以了,比如大家都按天算,你就试着按小时计,大家都按月算,你就试着按周来计。群众的眼睛也许是雪亮的,但群众的做法通常是平庸的,所谓脱颖而出,往往就是在大众平均水准之上再进一步,你就先进了。
  在计划初期,你会有一个初步估时,随着进度的发展,比如到了中间阶段,可能发现之前预估的时间不对,这时你需要写下第二次估时,最后当完成任务时,再记录下实际耗时。最终,你会得到 3 个时长:第一次估时、第二次估时、实际耗时。
  一开始,你可能(几乎肯定)这三个时长看上去牛头不对马嘴,随着不断地纠错、修正,从过去错误的估计中总结经验。第二次估时会和实际耗时越来越接近,再后来,第一次估时和第二次估时也会越来越接近。到那时,你对于估时的判断力就练成了。
  简单的手法,坚持做,就会产生神奇的效果。

  ”人一能之,己百之,人十能之,己千之,虽愚必明,虽柔必强。“ 这是这个道理。(语出《中庸》)
  

内容版权声明:除非注明,否则皆为本站原创文章。

转载注明出处:https://www.heiqu.com/wpsfjy.html