哪有什么中年危机，不过是把定目标当成了有计划
1、目标和计划的区别
比方说，一次军事行动，要摧毁敌方的司令部，这是目标。如果你把这当作行动计划，就带兵去打，那你的兵死得有点冤。
再比如，立了一个 Flag，来年要把前台 MM 追到手，这只是愿望。具体怎么追？才是计划。
做计划实际上是对过程管理，当你有了目标并对此做出了计划，意味著你至少是有过思考的，这就走心了。而仅仅只有目标，那就只能走肾上腺素了。
思考是一种神奇的力量，在思考的过程中，会强化目标的概念，加深对目标的理解，经过思考，你会确认目标，收获决心和动力。这里不一定非得完全靠自己冥思苦想，完全可以借助他人的智慧辅助分析。思考的结果会对行为产生指导，通常，你会获悉完成目标所需的步骤。
步骤，就是算法，就是解决方案。
从这点来看，相比写总结，做计划的技术难度要大。这可能也是“多总结、少计划”这个现象的原因之一。写总结是对已发生的事情进行回忆，只要记忆没问题，平铺直叙都能成文，尤其是流水账一般的总结，根本不用动脑子。而做计划，包含了对未来的预测，这就难多了。但所谓的建设性，也就体现在这里，正是因为要克服困难，才使得产出有了价值。
我很喜欢一句英格兰的谚语：“Where there's muck，there's brass.”一直做容易的事情，是不可能有进步的，要想管理人生和未来，怎能不舍得下工夫。
阻碍人们认真做计划的另一个原因，那就是常常听到的“计划赶不上变化”。这个在 IT 界，简直是家常便饭，今天做的计划明天就得改，于是计划就显得没什么作用了。
但个人以为，越是“赶不上”变化，越需要有计划。怎么说呢，两点体会，权当胡诌。
第一点：
当你没有计划的时候，乱七八糟的事情会特别多，但当你有了计划之后，很多意外的事情会减少。听上去有点玄学的味道，但也不是完全没道理。
拿我自己来说，我是一个有“拖延症”的人。当我有了一个目标但没有制定计划时，我十有八九会拖延，一边拖延，一边做了很多其它不相干的事情，这些其它的事情可能就会给我带来额外的麻烦，对我实现原本的目标产生干扰。
但如果我做了计划，分解目标，制定时间表，我就能有效地治疗“拖延症”，因为我时刻都处在自己构建的过程管控中，每一步的衔接都有安排，这样我的注意力就容易保持集中，甚至全程高能。而我发现，精力涣散最容易发生在当你不知道下一步该干嘛时。
第二点：
确实存在变数很多的客观场景，在这样的险恶环境中，你更应该加倍地做计划，改计划。
一方面，这是唯一让你在风云变化中能有所依靠、有所参照的资本。就好比，需求的变更是无法避免的，但我们可以做好需求管理，至少知晓变更的发生，这同样也是一种经验的积累。
另一方面，在迭代计划的过程中，熟能生巧这个规律会让你逐渐得心应手地面对变化，除非你是傻子死不开窍另当别论。永远不要低估积累的力量，你努力应对变化，慢慢地，你就能驾驭变化，变化就不会成为干扰。能力就这样成长了。
2、时间表与估时
说到计划，自然要说到“时间表”这个概念，做计划的方法很多，无一例外会涉及到时间表。脱离时间的计划是伪计划，因为人的时间是有限的，而且很多事情是有时效性的。这就需要估时。
也是个棘手的技术活，毫不夸张地说，这是世界性难题。所以如果你总是估不准，完全不用自卑，全世界都一样。当然，办法还是有的，事实上，根据不同的计划范围，我们并不一定需要很精确的估时，过日子又不是开火车。
大约 20 年前，大名鼎鼎的 JoelSpolsky（稍等，也许你没听过这个名字，但我 100%肯定你用过他的产品——StackOverflow，如果你不幸没用过这个网站，那我 200%肯定你用过他的产品——Excel）。
总之，这位大人物在 2000 年写过一篇博文"Painless Software Schedules"，介绍了一套他自己的“软件开发时程”方法论。虽然有些久远了，甚至作者自己都修改了文章的开头，提醒读者他已经有了更好的替代方案，但这并不影响该方法的价值，而我自己在学习了他这套“过时的”解决方案之后，一直将其用于自己的工作、生活中。
目标分解 &估时修正
概括来说，该方法的核心思想有两点：目标分解 &估时修正。
目标分解是做计划的基石。罗马不是一天建成的，大事化小是所有干大事的必经之路，这也是强迫你认真做目标分析的手段，合理的分解只可能建立在对目标的充分认识之后。
分解的颗粒度要足够细。因为原文讲的是软件开发，所以作者明确提出，在编程中，任务要按“小时”来评估，而不是按“天”。这个单位的变化很重要，单位大了，误差就大。按照作者的经验，超过 16 小时的任务都应该进一步拆分，因为在这个时长之上，意味着你并没有真的想清楚要做的步骤是怎样的。说得直接点，就是在糊弄人。
当然，我们在做个人全年计划时，不必生搬硬套拿小时做单位。这里的要点在于计划要足够细才有意义，至于说具体细到什么程度，这个其实需要根据自身经验去琢磨。
非要说有什么窍门的话，也许拿大众的普遍标准再进一步就可以了，比如大家都按天算，你就试着按小时计，大家都按月算，你就试着按周来计。群众的眼睛也许是雪亮的，但群众的做法通常是平庸的，所谓脱颖而出，往往就是在所处环境的平均水准之上再进一步，你就先进了。
在计划初期，你会有一个初步估时，随着进度的发展，比如到了中间阶段，可能发现之前预估的时间不对，这时你需要写下第二次估时，最后当完成任务时，再记录下实际耗时。最终，你会得到 3 个时长：第一次估时、第二次估时、实际耗时。
一开始，你可能（几乎肯定）这三个时长看上去牛头不对马嘴，随着不断地纠错、修正，从过去错误的估计中总结经验。第二次估时会和实际耗时越来越接近，再后来，第一次估时和第二次估时也会越来越接近。到那时，你对于估时的判断力就练成了。
简单的手法，坚持做，就会产生神奇的效果。“人一能之，己百之，人十能之，己千之，虽愚必明，虽柔必强。”就是这个道理。（语出《中庸》）
3、实施工具：电子表格、甘特图
该方法让我很喜欢的另外一个重要原因是，作者用来实施这套方法论的工具很亲民——电子表格。易用的产品才会有市场，易实践的理论才容易推广。再则，一份 Excel 文件，很易于交流。若干次项目中，当我把充满详实数据的"Schedule.xlsx"发送出去，会从老板和客户那收到信任的回复。
管理要出活，量化是关键。当别人在定性分析阶段时，你定量解构出工作包，水平就跃然纸上了。尤其是对于许多没学过真正管理学的一线码农转型做管理的人来说，量化是入门管理的捷径，其它的门道水太深，也学不来。
说到使用 Excel，顺带说说另一个“喜闻乐见”的概念——甘特图（Gantt）。
但凡提到计划，几乎必有甘特。尤其是在 PPT 当中，敢情不拉一张甘特图，你这项目管理的专业度都要打折扣。制作甘特图有很多专业工具，比如 MicrosoftProject，以及那些需要投入一定学习成本的资深产品。作为一名半路管理工作者，我在绝大多数的情况下，就用“Excel 手绘”，简单明了，方便快捷，重点是学习成本为零。
要说 Excel 能完成的工作，比想象中多。
我曾经就这个玩意和我的一个好×××聊过“这破图除了好看有啥卵用？”然后被教育道：“你不当老板所以这图没用。对于大领导来说，人家每天日理万机、分分钟多少万进出的，想最快地了解项目计划，甘特图就是最直观的工具了。”
所以，说到底，格局啊……
评论