制定计划是一件困难的事情（在软件开发中哪一件事情不难呢？），不只是新手，就是有好几年工作经验的人，对制定计划也颇感为难，往往随便给出个时间了事。我曾亲历过不少场面，大家对任务计划的态度很随意，对时间的估计都是随口而出的。大多数时候，管理者
制定计划是一件困难的事情（在软件开发中哪一件事情不难呢？），不只是新手，就是有好几年工作经验的人，对制定计划也颇感为难，往往随便给出个时间了事。我曾亲历过不少场面，大家对任务计划的态度很随意，对时间的估计都是随口而出的。大多数时候，管理者都会对勇士们夸几句，对谨慎者报以轻视。
实践证明这些计划都是纸上谈兵，有的严重超期，有的质量不过关，有的功能遗漏，很少按预期完成的。这也难怪，就是精心制定的计划都有偏差，何况是随便给出的呢。
这里总结一些个人经验，这是对简单任务而言的。所谓简单任务指的是能分到某个人头上的任务，不包括需要一个小组协同完成的任务（当然部分也适用于小组任务的）。
1. 对任务尽可能的细划。任务分得越细，考虑得越周到，遗漏的可能越少。同时我们对细小任务的估计更准确，我想这也是大家钟爱WBS的缘故吧。
2. 建立任务的风险列表。外在环境、技术难点、甚至近一段时间工作状态，都会影响任务的进度。风险很多，列出我们能处理的风险就差不多了，至于第三次世界大战之类的风险完全可以抛开。根据风险列表，在理想的计划上，加上一定的风险储备。
3. 征求做过类似任务的同事的意见。我们不是神仙，对从未有类似经验的任务，很难估计准确，征求做过类似任务的同事的意见是明智的做法，至少我们能从中了解一些潜在的风险。
4. 不断调整计划。计划不是不变的，早期的估计或多或少的有些偏差。随着任务的进展，一些风险的消除，以及这期间的经验积累，我们可以更准确的估计时间了。一般来说在任务预定时间过去30%左右时，重新评估一下任务计划是比较好的习惯。
5. 及时反馈任务的执行情况。特别是研究性任务，出现计划与实际较大差异的情况是很常见的。让你的上司清楚任务的执行情况，很有必要，一旦出现较大偏差，他可以对你提供帮助，或者对整体计划进行调整。切记不要在时间快完了，才报告出了大问题。
6. 计划要实事求是，不是估计时间越短越好。不要因为面子上的问题，把时间估计得过短。否则你的任务太重，不但会影响你的正常休息和工作情绪，最终无法完成时，面子丢了是小，影响整体计划是大。
7. 采用PSP中一些方法，评估自己的效率。记录在执行任务过程，你的时间分配情况，估计你在做某类事情时的效率，为以后类似的任务提供经验数据。
