1. 什么是计划
“计划”是一个多涵义的术语。计划的本意是人们对事业的未来发展所作的部署和安排。莫里斯·博恩斯坦曾给计划下了一个不褒不贬的定义：“计划”是未来行动的方案，它包括三个主要特征：
⑴它必须与未来有关；
⑵它必须与行动有关；
⑶必须有某个机构负责促进这种未来行动。
作为一种日常行为，计划可以看作是一般的 “有意识、有目的”的活动，但作为在学术上有价值的计划概念，显然就不能停留在这个层次上。
百度百科：工作或行动以前预先拟定的具体内容和步骤。
管理学中计划的定义：确定组织未来发展目标以及实现目标的方式。
详解：计划是一个使用得非常广泛的用语，在不同场合的含义可能不完全相同。有人给计划下的一个“简明的、不带褒意或贬意的定义”是：“计划”是未来行动的方案。
在软件开发的过程中，它也是软件开发过程中的一个重要活动，软件开发活动中到处都充斥着评审活动的存在，比如：测试计划、软件开发计划、配置管理计划、风险管理计划、需求管理计划等计划的评审。
2. 评价你们的计划状态
很多书中和资料中都可以查阅到计划的制定和执行过程以及相关的一些问题，但是，在软件开发中，我们的评审活动做得如何，不妨做一个评估，大家那下面的几项内容来做个测试，看看你们公司的评审是否真得起到了评审的效果：
1、 你们公司的项目有计划么？
2、 你们公司的项目开发计划都有哪些？只有一个整体计划，还是有其他计划？
3、 你们公司的项目计划中都有哪些内容？
4、 在按照模板填写计划的时候，你是否感觉有很多内容总是无法下手？
5、 在计划的执行过程中是否总是遇到与计划时候不一致的地方？处理这些不一致的地方的时候，你对你们的操作手段感觉合理么？有没有一个评价手段是否合理的办法或者标准？
6、 如果计划发生变更，你们会如何操作？修改，评审之间的过程关系是怎样的？
7、 你们的计划变更频率有多少？或者说一个项目执行过程中会发生多少次变更，每次变更都修改计划么？是否有变更的时候你们会不修改计划而继续执行，甚至最终抛弃了计划？
8、 项目结束的时候是否会审核实际执行过程与计划的一致性问题？他们真的能够保证一致么？
9、 对项目计划执行过程中发生的各种情况是否有统计数据可供后续计划制定和项目执行的时候参考？这些数据都存放在哪里？他们是否是有效的？如何保证他们有效性？
请大家记录一下上面这九个问题的答案。我们来看看一个计划应该如何制定和执行，什么样的计划和执行才能起到效果。
3. 项目中的计划
本文只考虑整个项目计划，不考虑测试计划、质量保证计划等非整体项目时间任务安排的计划。
项目中的计划大体上可以分为整体计划和阶段计划。项目的整体计划一般来说只有一个；阶段计划包括里程碑计划、月计划和周工作计划，里程碑计划对于小项目（两三个月内的项目）一般不需要考虑，月计划在一些控制较好的项目中只是作为给领导汇报的材料而已，周工作计划则是具体执行的细节计划。
这里只讨论最常用的整体项目计划和周工作计划。
3.1 整体项目计划
项目整体计划一般是对项目的全过程进行计划的起始，中国有句古话：一年之计在于春，一日之计在于晨。这里说到的就是计划的问题，一年之计可以类似于把一个项目的整个过程对应到一年的各个阶段上，可以称之为春夏秋冬四大法则。
春天，万物复苏，计划从这时候开始制定，似乎一切都很美好，一切业好像都在按照刚刚完成的计划在进行。
夏天，天气炎热，各个物种在不同的阶段进入繁盛时期，项目的开发情况一片火热，大家热情高涨，但是，问题也在随之发生，虫子和各种病原体也都逐渐出现并开始生长。
秋天，似乎到了收获的季节，可是我们的项目还没有结束，因为夏天的一些疾病到了秋冬季节才开始爆发，比如流感的大面积暴发，大都发生在气温骤降的深秋，这时候人们会进入各种集市进行商品交换，为冬天做储备，而随着大量人与人接触的发生，也给了这些病菌快速传播的途径和机遇。
冬天，万物萧条，气温降低，冰雪覆盖大地（南方除外），都已经过了项目验收的时间，可是客户还是不签字，因为有些问题仍然没有被解决，时间越拖越长，开发组成员的心也越来越凉，老板因为项目无法结束，项目款收不回来而开始从项目组抽调一些人员到其他新的项目中，为明年做准备，人手严重不足，加上历史问题的存在，计划再一次濒临绝境。
3.2 周工作计划
一日之计在于晨说的就是周计划的内容，因为我们不可能把一个人的行为直接附加到一个项目组的团队上面，随着人数的增加，计划的周期必然扩大，否则，每天24小时就只剩下开会和制定计划了。
另外项目中的每一个具体任务都可能会持续几天甚至几个星期或者几个月，所以，每天都制定新的计划对于项目来说是不太现实的。
周计划，一般来说是项目组的最小计划范围，这个计划可以细化到天，这个计划的审核点应该细化到小时，比如，星期二下午2点对模块A的设计方案进行评审，那么模块A最迟应该在星期一下午5点以前完成设计方案并提交到配置库，由配置管理员或者项目组内部的分发机制软件将该模块设计方案的审核权利分配给参加审核的具体人员，同时发送邮件或者其他告知方式将星期二下午2点的评审会时间确定，同时星期二上午每一个要参加下午评审的人应该留出相应的时间来对模块A的设计方案进行阅读并在上午11点以前提交评审问题表。（关于评审如何做，请参考2008年5月份完成的《评审如何做》这篇文章）
4. 计划的生命周期
所有的计划都有其生命周期，一般来说，计划都存在制定期（撰写完成计划），执行期（执行计划，产生问题），修订期（分析问题，修订计划，进行审核）三个阶段，如此往复，不断轮回。
根据项目管理者的经验和项目的执行状况，这个生命周期的长短也是各不相同的。这个生命周期有些可能是一两个星期，也可能是一两个月，也可能是一两天。
所以，所有的计划，尤其是大的计划，都是要在即将结束的时候才有可能出现一个完全可以执行到结尾的状态，否则，变化始终是计划的唯一特性。
那么，一个项目计划到底应该包括哪些内容呢？
4.1 计划的内容
项目的计划一般来说，应该包括如下内容：
1、 人员安排
项目组中有多少人，每一个人有什么特点，专长和职责分配的内容。
2、 任务安排
大体上各个阶段的任务由哪些人来参与完成，需要什么样的资源配置。
3、 资源分配
每个阶段可以从公司或者投资方获得哪些可用资源，这些资源的数量和持续时间等特性都需要描述清楚，比如，公司会在什么时候发奖金作为激励，奖金的数量和获得的前提条件是什么，又比如，什么时候可能需要安排加班突击进度，那么是否要给大家安排食宿并解决一些生活上的问题。另外，公司可以提供什么样的计算机配置，和其他设备资源配置以便于大家使用，这些资源的持续时间是多久，是否会因为其他项目组的使用而发生冲突？等等
关于这三个方面的内容到底如何使用，如何表述，就属于计划制定的范畴了。
4.2 计划的制定
一个完整的项目计划在制定之初只能绘制出大的阶段划分情况，因为有可能不同的阶段，人员、资源都会发生变化，任务也可能因为用户方的变更或者前期的分析不到位而产生变化，所以绝对不要奢望已开始制定的项目计划就细化到了天，只要能粗略的根据进度和要求做一下大体合理的划分就可以了。
计划每次制定如下一节那个例子的样子就足够了，剩下的时间就是根据项目的进展情况不断的丰富和细化，将它丰满起来，完善起来。
除了甘特图以外，需要有一份文档说明，这个文档的内容也可以很简单，只需要包括上面计划内容的三个方面即可。
4.3 计划的审核与修改
计划的审核过程可以这样执行（因为没有找到我以前的一个项目计划示范例子，这里拿我新公司以前的一个产品计划作例子）：
图暂略。
从上面可以看到第二代产品开发的计划是比较细致的（因为第一代的产品已经开发完成了），执行到了具体的阶段才会细化出来，到了第三代和第四代产品就没有细化，只是一个大的阶段展示。
甘特图如下所示：
图暂略。
4.4 计划的执行
计划的执行就不必多言了，按照计划的内容，把任务分配给具体的执行人即可。
执行过程中对于小的任务只需要考虑结束前的审核即可，较大的任务一定要考虑分阶段进行审核至少是与任务承担者进行沟通，确定任务执行过程个中的有效性，及时发现项目风险，并尽早进行处理。
这个事情可以列举我当年内在某集团商务处的工作审核方式作例子：
在那里，一个已经熟练的工作人员——业务主办或者更高级别的人员，平均每个时刻手头都有四到五个项目在进行，领导会根据每个人的特点和专业方向把具体的项目分配到每个人头上，每周五都要向处长进行面对面的工作汇报，处长会把你叫到他的桌子前进行询问你这一周，手中项目的进展情况，周三有可能随机由副处长询问一些进展情况，其它时间都是自己做自己的事情，没有人管你，除非发生了大的有争议的事情，比如厂商投诉到处长这里，处长才会根据情况进行判断，并当面询问——当年国内某通讯设备生产商因为一个项目在和我的谈判中遇到了很大的阻力，派了一个北京分部的部长要找我们处长谈这个项目的事情，我们处长根本没有找我，直接回复：这个事情是小白负责，你们找他就可以了，不用找我。根本就没有见那个部长的面。于是那个部长就只是见了我一面，谈了几句，就走了，接着很快发出话来，说他们和集团还有很多项目可做，大家不要为了这个小项目伤了和气（这可是个初始报价一千七百多万的项目，最后签定为九百万刚出头的合同，而且所有硬件小型机都从半配变成满配），云云。
这个案例就是说一个项目进展过程中的审核和放权的问题，如果管理者管理过死，事事过问，那么开发者就不可能放手来施展自己的能力解决问题，但是，承担者是否有足够的能力来解决这个任务的全部问题，那就要看管理者如何管理和衡量，如何判断和审核了。
4.5 计划的变更
计划的变更一定要有一个具体的变更流程，并且每一次变更都要经过评审和修订，修订的时候，应该在修订说明中写明是因为什么原因产生的变更，并经过了哪些人参加的评审确定下来的变更，评审修订后，每一个参加评审的人必须对修订结果进行确认，将来一旦发生问题，这些人也应该因为这次评审的失误（假设这个问题是因为这次评审的结果造成的）而承担相应的责任，但是，如果没有发生任何问题，评审的结果使得项目更好的进展下去，那么，项目的收益也应该给参与评审的人考虑，具体的模式请参考2008年发表的《全程建模之绩效管理模型》。
4.6 计划的终结
当一个项目进行到最后结束的时候，我们应该完成如下的工作内容：
1、 对项目中发生的变更、风险、评审和修订等信息进行统计，同时对这些数据根据解决情况和发生原因等进行归类总结，以便于后续项目在同样的阶段进行参考以避免发生一些可以避免的同类问题的再次出现。
2、 对项目计划进行最终的修订，补充项目的完成时间和最终评审情况。
3、 对项目进行全过程中所有参与人员的绩效进行审核和计算，获得每一个贡献者的绩效贡献数值，以便于在项目将来获得收益时候采取有效的分配方式，避免因为分配不公平出现公司赚钱员工反而大量辞职团队反而消失的现象。
4.7 计划中的常见错误
4.7.1 一开始就制定大而全的项目计划，细致非常
非常致命的错误，这样的计划一个不可能得到执行，因为随时都可能产生新的问题和新的变化，另外，这个过程非常费力，经过几次修改调整，项目管理者会发现自己的精力都用在修改这种细致非常的大而全的项目计划上了，根本没有时间进行项目内的其他管理工作。随后就会出现，因为疲劳，而不再对项目计划跟踪修订，最后项目计划就逐渐失效了，计划就成为了空谈，一切都重新回到最原始的混乱无计划开发状态下了。
4.7.2 对于有多次迭代的项目计划，最开始就要写清楚各次迭代的内容么？
如果是这样，假设出现计划制订完，大家都做得很好，项目经理不就没事可做的现象了？
这个回答必然是否定的，因为在实际项目中对于时间跨度越大的行动的计划就会越概括，对于迭代也是如此。因此在很多时候，项目的迭代计划刚开始只能写个大概，也就是初步对项目的认识和评定后的结果，随着项目的进展逐渐细化，只需要把你下一迭代要做的内容填写细致，那样这个迭代的计划也就制定完成了。
在每一个迭代完成后，下一个迭代开始前，要修改计划，调整迭代内容，补充细化马上要开发的迭代细节。同时对前一个迭代进行总结分析，进行数据管理和统计，这个行为也将对下一个迭代计划的执行和制定产生直接的影响，同一个项目内的两个迭代之间的参考性是最强的，通过他们之间的关系可以最大力度的将一些可能发生的问题尽可能的避免或者解决掉。
4.7.3 项目计划有一般的格式吧？
格式无所谓，只要大家都能接受，那就是格式。不一定别人的格式就对你的项目有效。每一个项目都有自己的特点，必须根据项目特点来做修改，不能完全使用同样的内容来填写。
rup的模版太繁冗了。
4.7.4 计划模板内容很多，都不会填写怎么办，删除掉如何？
如果你们已经采用或者必须采用一些传统的计划模板来填写内容，那么，你应该做好下面两个方面的事情：
1、 对于无法确定的内容，就把可选的几个方面都写上，不用太多，简明扼要的关键描述，加上三到五句的说明内容，每段内容不超过200字就足够了（这个200字是个概数，不用刻意限制，有可能不到100字，甚至十几个字就足够描述了，也有可能需要四五百字的描述）。
2、 对于无法填写的内容，比如因为时间未到，或者资源缺乏而无法填写，那么就明确的注明无法填写的原因，然后放在那里即可。
3、 对于和当前项目不适用的内容，比如部分不需要硬件的项目，而项目计划中却有硬件部分的内容描述，那么，你完全可以将它空在那里，或者只需要简单的写上：不适用，三个字。
模版不能说没写的内容都删除掉，其实很多内容是要根据项目的进展，才能逐渐补充上去的。项目结束的时候，所有的内容也就全部都写完了。
4.7.5 项目开发计划应该给哪些人看？谁又是最需要看的？
所有相关的人员都应该看。没有谁更需要，只有根据任务的分配，不同角色的关注点有所区别而已。另外，参加项目计划审核的人不仅仅是看，每个人都应该参与到与自己工作内容相关的计划的制定工作中，这样才能使计划更客观，更具有可行性。
5. 总结
计划是软件开发过程中的一个重要活动，本文并没有对计划的所有方面都进行描述，因为那需要专著类型的书籍才能较为完整地说清楚，本文只是立足于针对具体项目的执行过程问题而描述，表达一些可以解决问题的办法和处理手段。
本文的产生因为在最近几年的咨询工作中发现很多软件公司都存在一些概念甚至操作上的严重问题，因此打算把软件开发过程中的各个活动都单独撰写出来，作为提示要点来进行，本文是第二篇。
本文首发于IT168，今已过一月有余，故再发于blog。