【IT168 技术文章】
前言
著名的项目管理泰斗Harold Kerzner博士在他的可以比作项目管理“圣经”的经典之作《项目管理—计划、进度和控制的系统方法》中说：“项目经理最重要的职责是做计划、整合计划和执行计划”。“项目经理是成功项目计划的核心”“计划是一种必备的管理职能，它增进了对相互作用的不同部门之间复杂问题的理解”。对于软件开发这个特殊的领域，制定项目计划、执行项目计划对项目进行控制的知识和经验的积累非常重要。
一、项目计划目的与作用
根据软件能力成熟度模型集成CMMI1.1，软件开发项目计划的目的是：建立和维护定义项目活动的计划。项目计划属于CMMI的第2级，其过程域包括开发项目计划、与相关人员交流、获取对计划的承诺、维护计划；项目计划为实施和监控项目活动提供了基线。
项目计划的第一个目的是建立估计值，即建立和维护项目计划因素的估计值。为此应该确定项目范围，即通过建立高层工作分解结构来估计项目范围；监理工作产品和任务属性的规模与复杂度；确定项目的生命周期阶段、以此来限定计划范围；基于估算的原理进行对工作产品和任务的项目工作量和成本的估算。
项目计划的第二个目的是开发项目计划文档，即文档化项目计划，维护项目计划，并以此作为项目管理的基线。为此应该建立和维护项目的预算和进度表；要识别和分析项目风险；确定如何采集和管理项目数据；确定实施计划所需要的各种资源；确定项目实施所必需的知识和技能；确定各项任务或活动的承担人；编写项目计划文档。
项目计划的第三个目的是获得并维持所有项目干系人对项目的承诺。为此应当评审影响项目的所有计划使所有项目干系人理解项目承诺；必要时调整项目计划以适应有效的和已经估计的资源；获取所有项目干系人特别是项目任务或活动的承担人对项目计划的承诺。
项目计划是项目实施的基础。通过所有项目干系人认可的项目计划形成文件，便于本企业高层领导、相关管理部门粮道、相关参与部门领导、项目组成员、客户、协作单位、分包单位等等所有项目干系人之间的交流沟通。项目计划是项目组为实现项目目标而科学地预测并确定项目生命周期的行动方案。任何项目计划都是为了解决三个问题：一是确定项目目标，二是确定为了达成项目目标的各项行动的顺序和时间，三是确定项目中每项行动所需要的资源。所以制定项目计划就是在明确项目目标的基础上，确定项目行动方案，分配相关资源的项目综合管理过程，就是通过对历史的、当前的、项目或组织内部的和项目或组织外部的有关信息进行分析和评价，对项目生命周期过程中可能的发展进行评估、预测，对新项目实施工作进行的各项活动做出尽可能周密的安排，最终形成一个所有项目干系人认可的、约定项目各项活动、作为项目实施工作基础的文件—项目计划。项目计划围绕项目目标的完成系统地确定项目的任务、安排任务进度、编制完成任务所需的资源预算等，从而保证项目能够在合理的工期内，用尽可能低的成本达到尽可能高的项目质量要求。在制定项目计划过程中必须明确五个基本问题：做什么、如何做、何时做、谁去做、需要多少资源。
简单地说，项目计划可以起到如下作用：
1、 确定完成项目目标所需的各项任务范围，落实责任，制定各项任务的时间表，明确各项任务所需的人力、物力、财力；
2、 确定项目的工作规范，遵循的标准，成为项目实施的依据和指南；
3、 明确项目组各成员及其工作责任范围以及相应的职权；使项目组成员明确自己的工作目标、工作方法、工作途径、工作期限要求；
4、 保证项目进行过程中项目组成员和项目干系人之间的交流、沟通与协作，使得项目各项工作协调一致，增加客户满意度；
5、 为项目的跟踪控制提供基础。
6、 项目计划在项目中起到承上启下的作用，计划批准后应当作为项目的工作指南。
二、项目计划制定的原则
1、 目的性。任何项目计划的制定应当围绕项目目标的实现展开。制订计划的第一步就是必须分析目标、进而找出为了完成目标所要完成的所有任务。
2、 系统相关性。项目计划由一系列子计划组成，如范围计划、人力资源计划、进度计划、资源计划、质量管理计划、风险管理计划等等。各个子计划不是孤立存在的，彼此之间相对独立，又紧密相关，应当形成一个有机的整体。构成项目计划的任何子计划的变化都会影响到其它子计划的制定和执行，进而影响到项目计划的正常实施。
3、 经济性。项目不仅要有较高的效率，而且要有较高的效益，因此计划过程是对多种选择权衡、优化的过程。
4、 动态性。由于项目环境一般处在变化之中，特别是软件开发先把棺木的多变性，经常使计划的实施偏离项目的基准计划，因此项目计划要随作环境和条件的变化不断调整和修改，以保证项目目标的完成。如何防止项目计划多变，对出现的问题及时加以处理以保证进度按原计划实现，在一定的意义上说甚至是更为重要的。防止项目计划多变，就要改进计划的编制工作，提高计划的质量，这首先要求项目经理和项目计划制定人员应当较好地掌握项目的环境条件，对各种条件进行深入的调查落实并做出有根据的预测，据以制定实施方案，适当留有余地，以使编制的项目计划切实而可行。其次就是要使这种计划能够得到贯彻执行，因为再好的计划，如果不能认真执行，也不过是毫无意义的一纸空文。根据各方面的经验，实行各种不同形式的责、权、利机制是保证计划实现的关键。
三、软件开发项目的特点
与其他类型项目的共同点：项目成功与否不仅取决于项目过程中所采用的技术方法工具，还取决于项目管理的水平，特别是计划与控制的水平。了解软件开发项目的特点对于项目的计划制定和管理控制非常必要的。
与其他类型项目的不同点：
1、 软件产品和其他产品不同，软件产品是一种“逻辑”产品，是无形的，没有物理属性的，看不见、摸不着、难以理解；
2、 需求难以明确且频繁变更：由于用户的成熟度或责任心的原因。用户已开始无法给出明确的需求。在开发过程中，需求可能要经常及修改，因此需要经常地修改程序与文档；
3、 难以在早期发现问题：需求不明确，加上后期修改可能没有进行全局性的考虑，产生的问题难以从早期的文档中直观地发现，需要等系统设计出来后才会发现。
4、 项目成员对文档的重视不够。符合用户需求的高质量软件需要依赖于大量准确规范的文档编辑工作，但项目组成员对他并不感兴趣，很少愿意认真去做，因而直接影响了软件的质量。
5、 劳动密集型＋智力密集型：软件开发过程需要大量高强度的脑力劳动，并且都是手工劳动，这些劳动非常细致、高度复杂、容易出错，质量那一用简单的度量来衡量，使得软件的正确性难以保证。对于不深入找掌握软件工程知识或缺乏软件开发实践经验的人员，是难以做好软件开发项目管理工作的。
四、软件开发项目计划的常见问题分析
有人说：“做项目计划，如同给一个待出生的婴儿写传记那样困难。如果允许项目结束后再写计划，那就轻松多了，并且可以 100% 地准确”。确实是这样，为什么项目的计划这么难呢？
在软件开发项目实践中，关于计划主要有以下一些常见问题：
1、项目目标不够清晰明确
这实际上在软件开发项目中是一个普遍的现象。缺乏详细的工作目标以便在项目结束时验证是否取得了预期的成果。对于软件开发项目而言，在进度、任务范围、质量、成本等项目目标中，进度是最容易清晰明确的，也是用户最为关心的。不管是献礼工程或一把手工程，进度都是项目目标诸多方面中最先制定的，并且能够很快在招标文件或合同中订下来。当然，这种进度的合理性未必是经得起考验的。而统计数字事实说明，大部分的软件开发项目的进度是不合理的。无论是急于求成的客户还是缺乏软件开发经验和软件工程知识的项目经理都存在对进度过于乐观的问题，其原因较多是因为他们对项目范围的认识是在一种比较粗的颗粒度基础之上。大多数的软件开发项目在开始阶段可能存在项目范围不够清晰的问题，需要经过需求调研之后才可以清晰。质量目标是最不容易清晰和明确的，这主要是因为软件系统的质量量化比较难。由于质量目标的不确定性，它在进度、成本、范围等目标的压力之下就很容易被忽视。这似乎说明了，质量目标是这些目标中最不重要的一个，最有可能被牺牲的一个。成本目标可能用户方面不太关心，确实软件开发组织最为关心的，软件开发的成本主要是人力资源的成本，其他的设备基础设施都是可以重复使用的。所以，在进度、任务范围、质量明确以后，人力资源的成本就可以经过经验等方式估算出来。
2、对编写计划的过程在思想意识上重视不够
实际上是对项目计划的重要性认识还不够充分，虽然大家都知道知道“作计划”很重要，是项目成功的关键，但又认为计划就是写文档，也许是因为一些人善于写程序但不善于写文档，所以有些项目经理会认为写文档是一种走形式，或对繁琐的文档有一种排斥心理。其实不能把计划当成仅仅是写一个计划文档的问题，而是要通过编写计划文档的过程，理清项目目标、项目范围、项目所需资源、制定合理的项目进度、制定完成项目所需的各种约定（沟通、变更）、制定应对风险的有效对策。对于这一问题的解决，首先应当提高项目经理的计划意识，采用项目计划制定相关各种知识、技术、工具，加强对开发计划、阶段计划的有效性进行事前事后的评估与评审工作。
3、制订计划时没有进行充分的沟通
项目经理制订计划时没有和项目主要成员和主要项目干系人共同讨论协商，达成共识；或者最终计划没有发布到所有相关的项目干系人，取得他们的认同、理解，最重要的是对计划中共同责任、目标和各自责任、目标的承诺；由此而造成的后果是：项目计划缺乏项目组成员的支持，没有成为项目组成员的共识，没有使每个项目组成员努力实现在项目计划中所作的承诺。因此项目经理制订计划时首先要分清或确定主要项目成员和主要项目干系人，然后与他们进行充分的沟通协商，使项目计划是一个大家都认同的，形成共识的有效文件。
一种更为严重的情况是遗漏了重要的项目干系人。在制定计划时没有考虑到所有项目干系人，特别是那些对于项目的成败有重要影响的项目干系人，在制定计划时要和他们进行充分沟通取得对项目进度、资源、验收标准等计划的共识和保证。
4、对总体计划、阶段计划的作用认识不足
项目经理认为计划不如变化快，项目中也有很多不确定的因素，做计划是走过场，因此制定总体计划时比较随意，不少事情没有仔细考虑，或者是有一种等一下再说的想法；阶段计划因工作忙等理由经常拖延，造成计划与控制管理脱节，无法进行有效的进度控制管理。那些号称“所见即所得”的OA，边做、边提需求、边改、边完善的“四边形”的所谓“快速”软件开发也可能竟然是本企业周期延续最长的项目，因为无休无止的需求变更而永无止境。从项目的计划阶段来看，因为边做、边提需求、边改、边完善，所以他们首先就对计划没有信心，基本上计划对他们来说只是应付，久而久之，对计划方面的锻炼意识不如其他项目，甚至养成不容易改掉的习惯。
5、任务和职责划分不够清晰或有遗漏
目标、任务的分解不够清晰、工作有遗漏，没有确定项目组成员职责的差别，如程序员的职责都笼统地写成“编码”。其主要原因是一些新任的项目经理是由程序员提拔起来的，不太熟悉软件工程各阶段工作职责中某些具体工作的分配，无法按任务分清每个人的责任。如应该分清楚需求人员该做什么、设计人员该做什么、编码人员该做什么、测试人员该做什么。责任似乎很容易分清，但大家却经常听到“这是需求的事”、“这是设计的事”这样的争论，严重的造成项目组内部的纠纷扯皮。就是因为这些新的项目经理对一项具体工作，如界面设计、数据规格等应该由需求分析人员来做，还是设计人员来做分不清楚，还有就是做到什么程度算概要设计，什么程度算详细设计，职责上也要搞清楚。建议新上任的项目经理应该多学习软件工程的相关知识。
6、项目任务分工或进度计划表的颗粒度太大
常见的现象有对任务持续时间进行不切实际的估计；或未考虑到任务的相互依赖关系而造成遗漏工作。其主要原因是软件工程的分析与设计经验的不足，无法细化系统需求，并从需求推导出设计，根据设计去分配任务。根据细化的需求也可以分配任务，但是由于需求中的功能点和设计中的模块往往不是一一对应的，如一个需求功能点需要一系列的模块来实现，多个需求功能点也可以共用同一组模块加上不同的设置参数来实现。所以根据设计来确定程序代码阶段的任务分配比较合理。需求是整个项目的基础、需求的清晰颗粒度对后面的工作及工作计划的准确性至关重要。项目计划的准确度是以一开始以需求（包括设计层需求）为基础得出的工作结构分解的完整性、清晰性为基础的。如果没有这个基础，项目计划就不可能做得很准确。在无法准确制定项目计划的情况下，对其风险要足够重视，并制定出具体可行的对策。如果对整体的需求或工作结构分解无法一次完整的清晰，就应当把它先分解为几个大块，分块进行，已经清晰的先制定本块（阶段）计划，下一环节的工作也可以开始（分块）进行。再项目开始阶段往往还没有得到详细的需求成果，因此根据项目计划渐进明晰的特点，在需求调研分析阶段过后，需求成果清晰是，应当及时细化项目计划，在概要设计完成时，要更进一步地细化后面编码测试阶段的详细计划。
7、与上一种情况相反的是计划表的颗粒度太细
就是说软件开发的工作虽然可以被划分为若干阶段，但是这些阶段不应该是整齐划一的。虽然每个环节阶段成果是下一环节阶段成果的基础，但即使在阶段成果通过评审之后下一环节对上一环节也应当随时进行检查验证，上一环节根据下一环节的验证检查情况进行调整。在上一环节没有得出可以供下一环节开展工作的基本成果时，下一阶段的投入可能是浪费时间。“按任务分清每个人的责任”并不是说上一环节的人员在初次完成本环节后交给下一环节就了事了，而应该继续与下一环节的人员共同作战、相互影响、不断进行同步完善,及时地解释和调整上一阶段的成果。如果上一阶段与下一阶段的负责人是同一个人，就没有这方面的问题，但是在实际工作汇报时要考虑到在某个阶段可能进行着前一个阶段或后一个阶段的工作。
8、资源需求没有经过较为周密的估算
软件开发项目的资源因为因为其自身的特点和受到各种因素的影响，很难做到“精确”。尽管如此，还是应该尽可能地做到“周密”。需要重点考虑的软件开发项目的资源主要是人力资源，没有尽可能足够详细精确地估计整个项目的每个阶段所需要的人时（或人日、人月）数；这是因为对软件开发的工作量没有进行精确的估算。为了估算软件开发项目的工作量和完成期限，首先需要根据较为完整的需求来预测软件规模。度量软件规模的常用方法有、代码行估算法和功能点估算法。这两种方法各有优缺点，应该根据软件项目的特点选择适用的软件规模度量方法。根据项目的规模可以估算出完成项目所需的工作量，我们可以使用一种或多种技术进行估算，这些技术主要分为两大类：分解和经验建模。分解技术需要划分出主要的软件功能，接着估算实现每一个功能所需的程序规模或人月数。经验技术的使用是根据经验导出的公式来预测工作量和时间。可以使用自动工具来实现某一特定的经验模型。精确的项目估算一般至少会用到上述技术中的两种。通过比较和协调使用不同技术导出的估算值，我们可能得到更精确的估算。软件项目估算永远不会是一门精确的科学，但将良好的历史数据与系统化的技术结合起来能够提高估算的精确度。
9、遗漏重要的假设或约束条件
如一些政府机关的管理信息系统软件开发项目隐含的需求是必须遵守一系列的国家和行业标准，但由于没有考虑到这些要求，致使项目计划失败，开发出某些功能、性能或数据不符合国家和行业标准的软件，造成返工。所以应当尽可能地将将任何设想和约束编入文档。做项目计划时应该尽可能地把假设条件和约束条件考虑清楚，这些假设和约束可以是乐观的、悲观的或者是最可能的估计。例如，可以假设能够及时获得应用程序服务器的新发行版，或可以得到熟悉项目正在采用的技术和技巧的开发人员；还可以假设，项目能在一些约束下工作，如影响计划的强制截止期限或资源限制等等。应该把这些假设和约束条件编入计划文档中，在项目的实施过程中，当项目计划需要细化和调整时，就应该考虑到这些约束条件，而不是以一种“无限资源”的方式做计划。一般来说，假设、约束和风险的区别是：假设、约束是一些比较明显、明确、已经发生或肯定会发生的情况，而风险这是不一定会发生的，具有不确定性。
10、项目计划没有突出重点
软件开发涉及到方方面面的工作，有些是主要的，有些是次要的，项目计划应当反映有价值的工作任务、环境条件。项目计划不能写成一个大杂烩，也不能写成一个包罗万象的百科全书。在项目计划中要简洁精确地反映对项目有价值的事情、任务和活动，避免罗嗦。项目管理的理论方法、成功的项目管理经验都是在实施项目时应该参考的。但是，每个项目是特殊的，具有“唯一性”的，一次需要为每个项目做专门的计划，选择适合的项目，适合的团队的方式和方法。
11、忽视次要工作任务对项目的影响
软件开发项目计划不仅要安排需求分析、概要设计、必要时的详细设计、系统实施和测试与维护等实际的重要工作，而且还应该安排项目中的支持性辅助活动，这些支持性辅助活动虽然不能成为关键活动，但是它们却对项目的进展又作重大的影响。这些辅助活动包括：体系结构定义、文档评审后文档编写的返工甚至是需求调研的返工，测试之后的编码返工、系统交付、与软件复用相关的活动、项目组内沟通交流、休假和法定假日、培训和教育、团队成员的生活（如饮食、住宿、交通等）、项目规划、人员管理等管理活动、会议和回复电子邮件，等等。做项目计划时应当尽可能完整地列出这些影响项目的活动，或者按照固定的模板进行计划的制订，免得遗漏必要的计划内容。有时候，小的疏忽会带来大的问题，次要矛盾会成为或引发主要矛盾。例如，加班安排不当，会引起员工的厌倦甚至离职，造成软件项目的人力资源问题，从而影响项目的进度，甚至导致项目失败。
12、工作任务的分解不便于人员分工
在确定了系统构架之前应该考虑在编写文档的同时是否有些其他基础性的工作可以先做，如是否在需求分析的同时进行部分的系统概要设计；是否可以先进性技术预研，环境架构搭建、后台数据库框架搭建、软件系统框架搭建等等。迭代法使得在上一阶段的部分任务完成后，下一阶段的对应工作就可以投入进行。在确定了系统构架之前之后工作任务的分解都要考虑模块编码独立性、开发编码工作的负载均衡、编码进度安排优化、预防人员流动（如生病、其他更紧急的任务、离职等）对开发的影响：一个好的项目计划同时应有助于减少项目组的压力和紧张，提高软件开发效率。
13、不了解项目成员的工作能力
项目成员的工作能力多种多样，需要根据项目的岗位角色来分配。如软件开发的编码人员至少需要编写代码的能力、单元测试的能力、跟踪查找问题的能力、解决问题的能力。而需求分析人员就至少要有业务理解学习能力、业务分析能力、沟通表达能力、建模及文档能力等等。这些能力很难量化，不过项目经理最好是心里大致有数，能够大致估算出每个项目成员在正常情况下完成不同目标要求的各项任务所需要花费的时间。
