差不多每个程序员都要写工作计划，尽管工作计划的格式和提交流程随公司和项目组的不同而有所差别。但不管是哪种方式程序员的工作计划都是在详细设计完成之后编码开始之前进行的。有些项目组会根据它来制定进度计划，有些则用于进度计划的修订。无论是哪种情况，它都会在项目结束前影响着程序员的开发。
对于写工作计划，程序员(至少是我和我认识的大多程序员)都会觉得头痛。这里的原因是多方面的，但又都集中在时间和工作量的预估上。从详细设计中考虑各子功能点的代码长度和算法难度并结合自身的技术实力来进行时间预估是时间预估的一般方法。然而，无论是代码长度还是对自己技术实力的预估又都受到工作经验的限制。实际的开发时间超出预计时间一倍并不是件罕见的事情。当然也有预估过于悲观的时候。这时对程序员的影响并不会十分严重。除非你的工作计划因此被项目经理驳回或者因为是新加入团队的成员而被人小觑。
预估过于乐观的情况就大大不同了。一个预估为10个工作日的工作实际上做了20个工作日，这会给程序员带来灾难性的后果。我带过的一个应届生就曾经发生过这样的事情。当时她对一个功能模块的工作量预估是5个工作日，尽管进度会上我对此提出了质疑，可是项目经理还是通过了工作计划，并据此进行了进度安排。我当时的考虑是经理是怕打击她的积极性（刚刚毕业又是女孩子），而且她的模块是边缘模块，进度并不影响整个项目的推进。结果时间一天一天过去了，在5个工作日过去后我按照制度催促她提交延迟报告。她自然也非常焦急，每日延长了工作时间，想尽可能早的结掉项目。但因为缺乏经验，她在开发中又屡屡出错，延迟就这样继续着。直到第17个工作日（或18个工作日，具体时间有些忘了）她第一次提交了代码。简单的验收后，发现好多问题，甚至是功能上的问题（出于着急的遗忘或是偷工减料），我写了验收报告打回源码，她就又开始了漫长的修改阶段。如此反复多次后，她的项目终于算是验收合格了。而此时据她开始编码已经过了30个工作日。这个案例极其极端，它的形成有着很多的原因：程序员自身经验不足；程序员希望尽快完成工作的“热情”；项目经理的纵容；包括作为项目组长的我考虑到项目经理的“威慑”没有过于干预……但无论怎样，预估的失误给程序员本身带来了极大的影响。加班、负面情绪、受挫感、以后做计划的怯懦（不仅仅是保守）甚至是自责，影响范围已经远远超出了项目本身。
因为工作上经常做工作计划，过去也负责参与审核其他人的计划，我对工作计划的制定有一些心得，写下来给大家参考：
1、任务评估。如果你的项目组在编码前有详细设计这个步骤（很多小公司或者小项目可能处于鲁莽编码阶段），那会大大的降低误差。但详细设计不是编码，它可能仍然“不够详细”，需要程序员继续将之细化成更小的单元。这样做的另一个好处是你可以在细化的同时发现许多隐藏在任务中的子任务，比如某些数据结构的创建与维护，某些出于程序健壮性和安全性考虑的子任务。
2、子任务性质划分。根据不同情况，对子任务进行属性划分。有些子任务偏重算法实现，算法困难但代码量低；有些子任务算法简单，甚至只是赋值和转换，但代码量却很高。两种情况需要区分，不能一概而论。
3、根据子任务不同属性评估代码行。这还要建立在有“自知之明”的基础上，需要平时多总结，了解自己对某种子任务的代码编写能力。
4、留出调试和单元测试时间。它们不是某个子任务的附加任务，而作为单独的一个或多个子任务存在。
5、根据个人性格评估。就像学生估分一样，有些人总是高估有些则总是低估。应该注意自己的性格特点，在预估时加入“权值”。
6、不要精确或给人精确的感觉。这是十分重要的。如果你预估时写时间区间，如XX工作日-XX工作日，则一定要考虑到边界的设定。如果你写时间点，如XX工作日，那一定不要出现“0.5”这种字样。它会误导你的项目经理，给人以“你可以控制误差在1个工作日内”的假象。
7、预估的单位是工作日。除非万不得已，否则不要将工作与自然日期挂钩。因为你将“工作日”的概念扩展到“自然日”的同时，连自己是否会在此区间内请病事假都要一起评估了。
8、及时调整评估。在编码过程中，如果发现预估误差过大，超出“微调”范围，要及时调整开发计划并向项目组汇报。一定要“亡羊补牢”，不要“一错再错”。
最后我想说，预估的手段再高明方法再科学也无法做到分毫不差（除非巧合），就像你无法预估今天上班路上是否会堵车一样。要牢记，我们做工作计划的目的只是为了使开发过程可视化更强，工作上更有条理而已。所以，不要过分追求工作计划的精准，否则就是自寻烦恼了。
