避免大而全 企业信息化项目计划制定需与时俱进

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

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

　　1. 计划的内容

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

　　(1)人员安排

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

　　(2)任务安排

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

　　(3)资源分配

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

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

　　2. 计划制定

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

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

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

　　3. 计划执行

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

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

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

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

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

　　4. 计划变更

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

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

　　5. 计划终结

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

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

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

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

　　避免计划中的常见错误

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

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

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

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

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

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

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

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

　　RUP的模版就太繁冗了。

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

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

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

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

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

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

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

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

　　总结

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