计划是软件开发过程中的一个重要活动，本文并没有对计划的所有方面进行描述，只是立足于针对具体项目的执行过程问题提供一些可以解决问题的办法和处理手段。

　　计划的本意是人们对事业的未来发展所作的部署和安排。莫里斯?博恩斯坦曾给计划下了一个不褒不贬的定义：“计划”是未来行动的方案。

　　什么是计划？“计划”是一个多涵义的术语。计划的本意是人们对事业的未来发展所作的部署和安排。莫里斯?博恩斯坦曾给计划下了一个不褒不贬的定义：“计划”是未来行动的方案，它包括三个主要特征：

　　⑴它必须与未来有关;

　　⑵它必须与行动有关;

　　⑶必须有某个机构负责促进这种未来行动。

　　作为一种日常行为，计划可以看作是一般的“有意识、有目的”的活动，但作为在学术上有价值的计划概念，显然就不能停留在这个层次上。

　　百度百科计划的定义：工作或行动以前预先拟定的具体内容和步骤。

　　管理学中计划的定义：确定组织未来发展目标以及实现目标的方式。

　　在软件开发中，计划也是软件开发过程中的一个重要活动。软件开发活动中到处充斥着计划的存在，比如：测试计划、软件开发计划、配置管理计划、风险管理计划、需求管理计划等。

　　如何评价项目计划状态

　　很多书籍和资料都可以查阅到有关计划制定和执行过程的相关问题，但是，在软件开发中，我们的计划评审活动做得如何呢？不妨做一个评估，看看项目计划评审是否真得起到效果：

　　1. 你们公司的项目有计划吗？

　　2. 你们公司的项目开发计划都有哪些？只有一个整体计划，还是有其他计划？

　　3. 你们公司的项目计划中都有哪些内容？

　　4. 在按照模板填写计划的时候，你是否感觉有很多内容总是无法下手？

　　5. 在计划的执行过程中是否总是遇到与计划时候不一致的地方？处理这些不一致的地方的时候，你对你们的操作手段感觉合理么？有没有一个评价手段是否合理的办法或者标准？

　　6. 如果计划发生变更，你们会如何操作？修改，评审之间的过程关系是怎样的？

　　7. 你们的计划变更频率有多少？或者说一个项目执行过程中会发生多少次变更，每次变更都修改计划么？是否有变更的时候你们会不修改计划而继续执行，甚至最终抛弃了计划？

　　8. 项目结束的时候是否会审核实际执行过程与计划的一致性问题？他们真的能够保证一致么？

　　9. 对项目计划执行过程中发生的各种情况是否有统计数据可供后续计划制定和项目执行的时候参考？这些数据都存放在哪里？他们是否是有效的？如何保证他们有效性？

　　请大家记录上面这九个问题的答案。我们来看看一个计划应该如何制定和执行才能起到效果。

　　项目计划分类

　　本文只考虑整体项目计划，不考虑测试计划、质量保证计划等非整体项目时间任务安排的计划。

　　项目中的计划大体上可以分为整体计划和阶段计划。项目的整体计划一般来说只有一个;阶段计划则包括里程碑计划、月计划和周工作计划：里程碑计划对于小项目(两三个月内的项目)一般不需要考虑，月计划在一些控制较好的项目中只是作为给领导汇报的材料而已，周工作计划则是具体执行的细节计划。

　　这里具体讨论最常用的整体项目计划和周工作计划。

　　1. 整体项目计划

　　项目整体计划一般是对项目的全过程进行计划的起始。中国有句古话：一年之计在于春，一日之计在于晨。这里说到的就是计划的问题，一年之计可以类似于把一个项目的整个过程对应到一年的各个阶段上，可以称之为春夏秋冬四大法则。

　　春天：万物复苏，计划从这时候开始制定，似乎一切都很美好，一切好像都在按照刚刚完成的计划进行。

　　夏天：天气炎热，各个物种在不同的阶段进入繁盛时期，项目的开发情况一片火热，大家热情高涨。但是，问题也在随之发生，虫子和各种病原体也都逐渐出现并开始生长。

　　秋天：似乎到了收获的季节，可是我们的项目还没有结束，因为夏天的一些疾病到了秋冬季节才开始爆发。这时候人们会进入各种集市进行商品交换，为冬天做储备，而随着大量人与人接触的发生，也给了这些病菌快速传播的途径和机遇。

　　冬天：万物萧条，气温降低，冰雪覆盖大地(南方除外)，而我们的项目都已经过了项目验收的时间，可是客户还是不签字。因为有些问题仍然没有被解决，时间越拖越长，开发组成员的心也越来越凉。老板因为项目无法结束，项目款收不回来而开始从项目组抽调一些人员到其他新的项目中，为明年做准备，人手严重不足，加上历史问题的存在，计划再一次濒临绝境。

　　2. 周工作计划

　　一日之计在于晨说的就是周计划的内容，因为我们不可能把一个人的行为直接附加到一个项目组的团队上面，随着人数的增加，计划的周期必然扩大，否则，每天24小时就只剩下开会和制定计划。

　　另外，项目中的每一个具体任务都可能会持续几天、几个星期甚至几个月。所以，每天都制定新的计划对于项目来说是不太现实的。

　　周计划一般来说是项目组的最小计划范围，这个计划可以细化到天，计划的审核点则应该细化到小时。比如：星期二下午2点对模块A的设计方案进行评审，那么模块A最迟应该在星期一下午5点以前完成设计方案并提交到配置库，由配置管理员或者项目组内部的分发机制软件将该模块设计方案的审核权利分配给参加审核的具体人员，同时发送邮件或者其他告知方式将星期二下午2点的评审会时间确定，同时星期二上午每一个要参加下午评审的人应该留出相应的时间来对模块A的设计方案进行阅读并在上午11点以前提交评审问题表。(关于评审如何做，请参考《如何让评审工作真正有效？》)

　　项目计划的生命周期

　　所有的计划都有其生命周期。一般来说，计划存在制定期(撰写完成计划)、执行期(执行计划，产生问题)、修订期(分析问题，修订计划，进行审核)三个阶段，如此往复，不断轮回。

　　根据项目管理者的经验和项目执行状况，这个生命周期的长短也各不相同，可能是一、两个星期，也可能是一、两个月，或者只是一、两天。

　　所以，所有的计划，尤其是大的计划，都是要在即将结束的时候才有可能出现一个完全可以执行到结尾的状态，否则，变化始终是计划的唯一特性。

　　那么，一个项目计划到底应该包括哪些内容呢？

　　1. 计划的内容

　　项目计划一般来说应该包括如下内容：

　　(1)人员安排

　　项目组中有多少人，每一个人有什么特点、专长和职责分配的内容。

　　(2)任务安排

　　大体上各个阶段的任务由哪些人来参与完成，需要什么样的资源配置。

　　(3)资源分配

　　每个阶段可以从公司或者投资方获得哪些可用资源，这些资源的数量和持续时间等特性都需要描述清楚。比如，公司会在什么时候发奖金作为激励，奖金的数量和获得的前提条件是什么？再比如，什么时候可能需要安排加班突击进度，那么是否要给大家安排食宿并解决一些生活上的问题。另外，公司可以提供什么样的计算机配置，以及其他设备资源配置以便大家使用，这些资源的持续时间是多久，是否会因为其他项目组的使用而发生冲突等等。

　　关于这三个方面的内容到底如何使用，如何表述，就属于计划制定的范畴。

　　2. 计划制定

　　一个完整的项目计划在制定之初只能绘制出大的阶段划分情况，因为有可能不同的阶段，人员、资源都会发生变化，任务也可能因为用户方的变更或者前期分析不到位而产生变化，所以绝对不要奢望已开始制定的项目计划就细化到天，只要能粗略的根据进度和要求做一下大体合理的划分就可以。

　　计划每次制定如下节示例即可，剩下的时间就是根据项目的进展情况不断地丰富和细化，将它丰满起来，完善起来。

　　除了甘特图以外，还需要有一份文档说明。文档内容可以很简单，只需要包括上面计划内容的三个方面即可。

　　3. 计划执行

　　计划的执行就不必多言，按照计划的内容，把任务分配给具体的执行人即可。

　　执行过程中对于小的任务只需要考虑结束前的审核即可，较大的任务一定要考虑分阶段进行审核，至少是与任务承担者进行沟通，确定任务执行过程个中的有效性，及时发现项目风险，并尽早进行处理。

　　这里可以列举笔者在中国电信集团商务处的审核方式作例子：

　　在那里，一个已经熟练的工作人员——业务主办或者更高级别的人员，平均每个时刻手头都有四到五个项目在进行中，领导会根据每个人的特点和专业方向把具体项目分配到每个人头上，每周五都要向处长进行面对面的工作汇报，处长会把你叫到他的桌子前询问这一周你手中项目的进展情况，周三有可能随机由副处长询问一些进展情况，其它时间都是自己做自己的事情，没有人管你，除非发生大的有争议的事情，比如厂商投诉到处长这里，处长才会根据情况进行判断，并当面询问。事实上有些情况领导直接就会回复：这件事情由某某项目经理负责，你们找他就可以，不用找我。

　　该案例涉及到一个项目进展过程中的审核和放权问题。如果管理者管理过死，事事过问，那么开发者就不可能放手来施展自己的能力解决问题。但是，承担者是否有足够的能力来解决这个任务的全部问题，就要看管理者如何管理和衡量，如何判断和审核。

　　4. 计划变更

　　计划的变更一定要有一个具体的变更流程，并且每一次变更都要经过评审和修订。修订的时候应该在修订说明中写明是因为什么原因产生的变更，并经了哪些人参加的评审确定下来;评审修订后，每一个参加评审的人必须对修订结果进行确认，将来一旦发生问题，这些人也应该为这次评审的失误(假设这个问题是因为这次评审的结果造成的)而承担相应的责任。如果没有发生任何问题，评审的结果使得项目更好地进展下去，那么项目收益也应该考虑到参与评审的人员，具体模式请参考《用绩效模型对IT技术人员进行有效管理》。

　　计划是软件开发过程中的一个重要活动，本文并没有对计划的所有方面进行描述，只是立足于针对具体项目的执行过程问题提供一些可以解决问题的办法和处理手段。

　　5. 计划终结

　　当一个项目进行到最后，我们应该完成如下的工作内容：

　　(1)对项目中发生的变更、风险、评审和修订等信息进行统计，同时对这些数据根据解决情况和发生原因等进行归类总结，以便于后续项目在同样的阶段进行参考以避免发生一些可以避免的同类问题的再次出现。

　　(2)对项目计划进行最终的修订，补充项目的完成时间和最终评审情况。

　　(3)对项目进行全过程中所有参与人员的绩效进行审核和计算，获得每一个贡献者的绩效贡献数值，以便于在项目将来获得收益时候采取有效的分配方式，避免因为分配不公平出现公司赚钱员工反而大量辞职团队反而消失的现象。

　　避免计划中的常见错误

　　1. 一开始就制定大而全的项目计划，细致非常

　　非常致命的错误，这样的计划一方面不可能得到执行，因为随时都可能产生新的问题和新的变化;另一方面，整个过程非常费力，经过几次修改调整，项目管理者就会发现自己的精力都用在修改这种细致非常的、大而全的项目计划上，根本没有时间进行项目内的其他管理工作。随后就会出现，因为疲劳，而不再对项目计划跟踪修订，最后项目计划逐渐失效，计划成为空谈，一切都重新回到最原始的混乱无计划开发状态下。

　　2. 对于有多次迭代的项目计划，最开始就要写清楚各次迭代的内容吗？

　　如果是这样，假设出现计划制订完，大家都做得很好，项目经理不就没事可做了？

　　这个回答必然是否定的，因为在实际项目中对于时间跨度越大的行动的计划就会越概括，对于迭代也是如此。在很多时候，项目的迭代计划刚开始只能写个大概，也就是初步对项目的认识和评定后的结果，随着项目的进展逐渐细化，只需要把你下一迭代要做的内容填写细致，这样迭代的计划也就制定完成。

　　在每一个迭代完成后，下一个迭代开始前，要修改计划，调整迭代内容，补充细化马上要开发的迭代细节。同时对前一个迭代进行总结分析，进行数据管理和统计，这个行为也将对下一个迭代计划的执行和制定产生直接的影响。同一个项目内的两个迭代之间的参考性是最强的，通过他们之间的关系可以最大力度的将一些可能发生的问题尽可能的避免或者解决掉。

　　3. 项目计划有一般的格式吗？

　　格式无所谓，只要大家都能接受，那就是格式。不一定别人的格式就对你的项目有效。每一个项目都有自己的特点，必须根据项目特点来做修改，不能完全使用同样的内容来填写。

　　RUP的模版就太繁冗了。

　　4. 计划模板内容很多，不会填写怎么办，可以删除吗？

　　如果已经采用或者必须采用一些传统的计划模板来填写内容，那么，你应该做好下面两个方面的事情：

　　(1)对于无法确定的内容，就把可选的几个方面都写上，不用太多，简明扼要的关键描述，加上三到五句的说明内容即可。

　　(2)对于无法填写的内容，比如时间未到，或者资源缺乏而无法填写，那么就明确地注明无法填写的原因即可。

　　(3)对于与当前项目不适用的内容，比如部分不需要硬件的项目，而项目计划中却有硬件部分的内容描述，完全可以将它空在那里，或者只需要简单的写上“不适用”即可。

　　对于模版不建议将没写(或没用)的内容都删除掉，很多内容是根据项目的进展，逐渐补充上去的。一般，在项目结束的时候，所有内容也就全部填写完成。

　　5. 项目开发计划应该给哪些人看？谁又是最需要看的？

　　所有相关的人员都应该看。没有谁更需要，只有根据任务的分配，不同角色的关注点有所区别而已。另外，参加项目计划审核的人不仅仅是看，每个人都应该参与到与自己工作内容相关的计划的制定工作中，这样才能使计划更客观，更具有可行性。

　　总结

　　计划是软件开发过程中的一个重要活动，本文并没有对计划的所有方面进行描述，只是立足于针对具体项目的执行过程问题提供一些可以解决问题的办法和处理手段。