计划是一种对于管理结果的预期，无论它以时间、成本、效益还是怎样的形式出现，都是一样的。因为要达到预期的各种资源，都可以在一定条件下相互转换。

几乎每次作为咨询师参加技术公司的计划会议的时候，我都忍不住想笑。因为计划会议还没有结束，我就知道计划的所有内容都百分之百地不可能按照会议上讨论的那样发生了。

为什么呢?因为我听到了这样的有关计划的对话。

功能A需要多久做完?开发需要两周，测试需要一周，那就三周以后上线吧。

这个统计怎么那么慢?是用Ruby做的，换C++吧，效率可以快一倍。

一共有六个模块，现在用了三周做了两个，那就是说还要六周?是的，老板!

在第一段对话中，有两个做开发的程序员的日历显示，他们分别要请三天和四天的事假，而开发团队一共只有5个程序员，但在会议上这件事被完全忽略了;在第二段对话中，统计算法显然存在极大的问题，本来应该线性增长的时间复杂度，成了近乎二次方的，换成汇编语言也不会对效率的改进有明显影响;在第三段对话中，6个模块中，已经完成的两个是最小的，余下的4个加起来，工作量几乎是已完成的十倍。

这些例子给我们以教训：制定管理计划是非常困难的事，因为它需要关于未来的充分信息，以及关于目的的充足知识。但计划还会带来一个非常要命的管理问题，那就是：一旦计划未能兑现，并且没有一个对此的合理解释，从此以后就不会再有人把计划当回事。

但短期的计划往往非常跟不上变化。信息瞬息万变，今天一个好好的人，明天就可能会卧病在床。对于开展工作所需要的知识，更是只可能随着时间的推移才掌握得越来越多，等到全部掌握的时候，无论成败，结果已经很明显，也用不着再计划什么了。

因此，真正有意义的计划，只有相对长期的计划。计划必须能够容忍对于未来的未知，以及必要知识的缺失。而要克服未知和无知，投入时间和资源是必要的，计划的周期越长，就越有可能在结果最终铆定之前，积累起预见所必须的信息和知识。

可是人们有强烈的倾向想要制定短期的计划，比如30天减肥，21天学会编程，等等。这其实是人类的惰性所致，想要付出微小的代价换取巨大的成果。但这样的计划一来是很难实现，二来意义也很小——30天减了肥的人往往又胖了回去，21天学会了一点编程皮毛的人往往没过多久就又忘记得一干二净。企业里面计划会议多如牛毛，但真正坚持下来做成伟大事业的产品或项目却寥寥无几。经过多年的观察，我发现了一个特别有意思的现象，不妨称之为计划悖论：先有了计划再上马的事业，大抵无疾而终;先有了很多积累最终计划才开始成形的事业，反而很有希望做大。

未来会有怎样的变数，你要从事的水有多深，都不是一开始能知道的，计划做得再漂亮也是枉然，只会让人觉得你不靠谱。

小结

大家可能注意到了一点，这篇文章里充满了很多矛盾，这正是技术和管理工作的根本区别所衍生的。技术人对于确定性的工作内容会感觉习惯，甚至驾轻就熟、得心应手。但人性就太不一样了，它充满了矛盾，并且很难有什么确定性的规律让他人像机器一样服从管理。事实上，管理的魅力也正在于此。

因此，和技术工作根本不同的是，管理不是要亲自照顾一切细节，而是要委托这些细节给被管理者，由他们自己来发挥才能。控制他人，将自己的意志传达到位，然后彻底地放手，从指挥和命令的地位调整为服务和支持的地位，这就是最高明的管理者们唯一应该做的。

计划是一把双刃剑，不要先有计划再做事，因为这个时候还不知道未来会发生什么。先积累一些经验，吃一些亏，朝向着目的推进一些，然后再一点点地形成一些长期的计划，这是做大事的节奏。如果计划未能实现，就要在结果出现之前想办法弥补，至少要做必要的解释来调整计划，否则团队的信心会受到挫折，对于管理者的信任也会下降，而这对于管理工作来说是非常不利的。