转载：软件项目计划的制定

注：此文是转载其他人写的文章，连接地址忘记了，希望写这篇文章的老兄不要误会

软件项目计划的制定

一个良好的计划对项目的管理至关重要，看到过很多介绍软件项目计划制定的文章，但主要还是依据项目管理的要点来进行，总感觉理论性过强，不便于操作，下面则根据个人经验来讨论一下软件项目计划的制定。

笔者认为制定计划的意义是在于可以真实客观的反映项目全貌，及时的发现问题，纠正问题，确保项目可严格按照计划执行，项目的进展是由众多因素来构成的，所以，如何快速的了解项目的真实情况，并加以控制，制定计划是一个最好的手段，但并不意味着制定了一个良好的项目计划，就可以成功的完成项目，前面说过项目是由众多因素构成，制定了项目计划仅仅是项目的开始。所以，项目应该有个好的开始，并努力朝着好的方向发展。

一、了解制定计划的先行因素

简单的讲项目计划的先行因素是你在制定项目计划中所依据的内容：包括项目范围、项目资源及质量标准。以一个最简单的任务来分析，至少要具备这三点因素，任务的执行时间如何确定？任务由谁来完成？如何判断此任务已经真正的完成？

如果再进一步分析，则需要风险管理计划，针对在项目过程中出现的各种风险进行评估、分析、应对及补救。其他的内容从一定的程度上可以制定在计划中完成，譬如测试计划。

任何一个项目的启动通常情况下都会先制作项目范围说明书，只是有时候名称会有所不同，此类文档可以支撑计划的制定，譬如，项目需要完成的内容、项目完成的约束时间、项目资源的评估、项目费用的估算、项目质量的考核标准、及项目最终验收的标准。但此类文档通常情况下不能够很明细，所以，建议将此类文档中的内容进行摘要，并制定在计划中逐一落实。

二、开始制定计划

第一：要明确项目中到底需要做哪些工作内容，这也是通常所说的活动定义。譬如：针对软件项目而言会存在系统设计、编码、测试等工作内容，这些都属于项目活动，但可能还会有前面提到的需要细化的内容。通常情况下软件项目会有需求调研、需求分析、概要设计、详细设计、编码、测试、集成、试运行等内容。在此基础上，将业务需求进行自上而下的分解，然后制定出最基本的项目工作内容。当然除此之外，还有很多工作要做，这则需要根据项目的实际情况来进行确认了。

在谈到活动定义中，不得不说的就是WBS（工作分解结构）。实际在确定有哪些工作内容的同时，也是在制定你自己的工作分解结构。

第二：制定好工作内容后，则需要对这些工作内容进行排序，即活动排序，排序过程需要明确的有：工作内容的优先级，前后完成的顺序及工作内容之间的依赖关系。

就好像编码需要依赖于设计的成果，而设计又依赖于需要的分析，需求分析又依赖于需求的调研结果和用户的要求，这是一个前后的次序，同时又存在一定的依赖性。有时候这种关系会复杂一些，譬如用户的要求可以分解为对业务功能的补充和系统考核要求，这样，这种依赖关系就会产生分支，业务功能的补充会作为需求调研成果进行完善，而系统要求则作为质量计划进行最终的系统考核。同时，如果结合业务需求进行考虑，这种前后的依赖关系和顺序将更为复杂。

但有些任务也并非完全一定要依赖于另一项任务，所以在确定其依赖关系的时候要将此种情况考虑进去。实际很多项目经理已经这样做了，当需要赶进度的时候，通常就会打破这种依赖关系让任务先行的运行起来。

针对外部依赖关系的工作内容，笔者不认为有特别好的办法可以进行控制，只能是通过加强风险意识，提早制定风险计划以应对此类事情的发生。毕竟PM的权限是有限的，而且也需要PM要有很好的协调处世能力。这也是PM面临的实际问题。

第三：则需要明确里程碑，不要小看这个东西，里程碑是严格用于控制项目计划的重要指标。里程碑如果出现了变更，则表示项目出现了重大问题，有可能直接导致最终项目无法按照指定要求完成。

第四：重点讨论一下进度的制定和资源的分配，即安排活动资源，制定时间计划。这是弹性最大的一个过程。或者说这是人为因素最大的一个过程。很多项目都是在已知了最终的项目提交时间的情况下来制定的项目计划，所以，时间计划的制定是通过倒推来完成的，当然也存在根据时间计划制定最终的项目验收时间的情况，但通常在计划的制定过程中，无法细化项目中的很多内容，故制定的最终进度计划也可能会出现很大的偏差，或者是甲方无法接受的情况。最终还是要通过项目提交时间来进行倒推。经常听到的一句话就是以市场为导向，所以项目也好、产品也罢最终要为市场服务，既然为市场服务，则需要根据市场的时间来安排了。但并不是说时间可以压缩人力就可以无限增加，所以，这个过程通常是一个比较痛苦的过程。

1)首先应该进行工作量的核算，针对工作量的核算，可以采用用例点估算法（曾经写过一篇博文介绍此方法，有兴趣的可以参看：http://www.mypm.net/blog/user1/feiw/archives/2005/604.html ），或者经验法的方式来进行。在这个过程中不建议考虑到任何的限制条件，只需要你考虑工作量的核算，作为项目经理而言自己心里一定要知道工作量到底有多大，这是一个底线，只有明确工作量的大小，才好完成项目，不要通过实际的行动来告诉你工作量的大小，那样就迟了。但无论采用何种方式，工作量的大小并非完全可以在项目制定计划的阶段就可以完全计算出来，即便采用了用例点估算的方式，也只是一个大概，所以，计划的制定本身就是一个循序渐进的过程，不断的完善，不断的细化，不断的调整。但大概的工作量一定要估算出来，这样才好作后续的工作。

2)其次，充分考虑关键技术的难度及最终应用环境的技术难度。现在一个项目通常会用到很多的技术，甚至是一些新技术。所以，一定要认真对待这个问题，PM很多都是技术出身，所以本身对新技术的探索就有一定的兴趣，但不要忘了你是在管理项目，新技术需要攻关、团队的熟悉掌握，最终才可应用到你的项目中，这其中每个环节出了问题都会影响项目进度或质量，所以，这种风险一定要提前预知。我曾经做过一个项目就遇到过此类问题，因此以后在做项目规划书的时候都会将应用到的关键技术进行独立介绍，以引起大家的重视。由于对关键技术掌握不足而导致项目严重超期的例子并不少见。

3)人力资源安排，在安排人力资源之前，一定要对你的团队每个人都要有充分的了解，这样有助于项目的进展。每个人员的技术能力是否可以满足要求？每个人员的独立解决问题的能力是否很强？每个人员对技术的探索欲望是否也很强？哪些人员渴望掌握新技术？哪些人员又渴望采用成熟的技术来完成？这些都对你进行人力的安排有帮助。最重要的就是你安排给的任务是否可以完成？

4)制定时间计划，人力资源安排完成后，结合工作量的分析，时间计划就会自然而然的制定出来，当然在这个过程中还需要考虑到一些外部因素，譬如业务的复杂程度、技术应用的复杂程度等。这个过程可以在工作量核算的时候作为调节因子进行计算，也可以在时间计划中给予调节。

三、计划的调整

结合前面所有的介绍包括工作内容的制定、排序、里程碑的制定，到此基本上一个完整的计划就可以完成了，但并非项目计划就已经完成，此时需重新分析整体计划是否可以满足项目要求，如果不满足，开始进行调整。实际计划的调整就是在保证质量的前提下，在资源不变的情况下，压缩时间。但在此过程应重点结合风险计划来共同完成。

1)从项目进展来看，每个人员的工作效率是会逐步提高的，因为先期的任务带有一定的技术难度和不熟悉程度，但当项目进展到一定程度的时候，工作也就会慢慢熟练起来，所遇到的问题会越来越少，这样效率自然就会提高。而且在项目不断的推进过程中，可复用的内容也会越来越多，工作量也会降低，自然工作效率也会提高。所以，从时间的安排来讲，可以在此多做一些工作。而且项目整体压力来看也应该是先紧后松，不是项目越做压力就越大。

2)前面提到过，针对活动排序，要进行分析，哪些活动是存在必须的依赖关系，哪些是存在可斟酌处理的依赖关系，这些活动时候可以跳过这些依赖内容而直接进行，节约的人力是否可以安排到其他活动中以加快项目进展。

3)活动的排序通常是一个顺序型的，但也要认真分析，哪些任务可以并行展开，项目在开始初期，并非所有人力都可达到饱和状态，此时，是否有些任务可以先行开始。也就是说这种排序关系是否可以在合理的范围内进行调整，为人力资源的充分利用做一定的让步。

4)通过以上调节还是无法完成项目指定要求，那就需要申请新的资源了，或者需要斟酌项目提交时间了。不建议项目计划在制定初期就将项目的压力加的很大，这样会将后期调整的空间压缩的很小，不便于对变更、风险等突发情况进行处理。

到此，可以说计划初步制定完成。但计划的制定决不是一蹴而就的事情，需要不断的完善，不断的修正才可真实的去反映项目的实际情况。

四、其他问题

1.实际前面并没有涉及一个重要的内容就是质量，质量标准的高低也将直接影响到项目的实际进展情况。尽管在项目初期已经有了质量考核指标，但无法对项目内部很多工作内容的交付成果进行质量考核，所以，质量计划尤为关键，最好可以在项目初期就制定完成，来指导项目的进展。在计划制定过程中，也要充分考虑到质量考核标准的因素。

2.PM只是计划的一个起草人而已，不要认为计划制定是PM一个人的事情，计划要与团队充分的沟通才可很好的完成。而且笔者建议计划一定要透明，因计划的后期维护、跟踪管理是要靠团队共同完成，所以，计划的制定不是PM一个人的事情，是团队的所有人都应承担的责任。

3.工具的使用首推MS Project及MS Project Server。有关MS Project Server的配置使用可参见我的另一篇博