有计划才能应对变化

项目管理包括很多个过程，从整个项目生命周期和生命周期每个阶段的管理过程来看都可以划分归纳为以下五个过程：启动、计划、执行、控制和收尾。这五个过程对任何一个项目而言无疑都是不可或缺的，本文侧重讨论其中的计划管理过程。
  包括软件开发项目在内，所有的项目都有一个共同的特点，那就是项目是一个一次性事件。
  在整个项目的一次性生命周期中，如果任何一个过程出现偏差，都有可能导致项目失败！
什么样的情况表示某个管理过程出现了偏差呢？当实际发生的结果与当初的预计不同时就形成了偏差。
  在实践中这种偏差是我们不愿意看到的，但是却是不可避免的，解决这种问题的最好的办法只有尽早的发现，及时的纠正。
  要做到尽早的发现，我们必须有一个评判偏差的参照，就是笔者所说的“当初的预计”，在项目管理中称之为计划管理过程。
  将实际情况与计划进行实时的对比，我们就可以实时的、尽早的发现偏差，及时纠偏，降低项目失败的风险，避免项目出现期望以外的结果。
  显然，计划过程是很重要的。
  项目计划具体要作些什么呢？
  可以用3W+2H来简单描述，所谓3W+2H就是What、Who、When、How to do、How Much Money。这些就是做项目计划所关心的基本内容：项目准备做什么？由谁来做？什么时候做？怎么去做？花费多少？
  对于软件开发项目而言，我们同样关心这些内容，一般情况下软件开发的计划主要描述在哪些资源支撑下，在什么时间范围内怎么样去完成哪些特定的软件开发目标。其中似乎不专门考虑成本问题，但是计划中的工作量总计其实已经间接反映了成本问题，对于特殊的成本变化、风险跟踪等问题通过辅助计划进行处理。
  在软件开发项目管理过程中，具体做计划时的思路是这样的，首先要进行项目工作范围确定，其次清楚定义工作责任划分，接下来进行项目活动的定义，最后对项目活动进行排序和历时估计。
  当完成项目计划文档时，不管采用什么样的表现形式，以上这四部分都应该是被描述清楚的最基本的内容。
  工作分解结构
  项目工作范围确定是为了有效的完成项目目标，界定项目主要工作内容的过程，也就是制定项目工作范围计划的过程。
  一般常用工作分解结构（WBS）的方法来实现，确保找出完成项目工作范围的所有工作要素，同时描述可交付成果和其组成要素的具体内容。这里主要针对阶段目标或里程碑目标，项目范围确定后就为项目活动的界定提供了依据。
  有了明确的工作范围，在项目执行中，如果某个工作不包括在工作分解结构中，则该工作就会被排除在项目执行范围之外。
  当然，任何项目不是只有唯一一个正确的工作分解结构。工作分解结构一般用图表形式表达，当前常用的有两种：分级的树型结构和缩进图表，其中缩进图表类似与分级的图书目录，它能反映出项目所有的工作要素，相对树型结构直观性较差，但应用也比较多，因为有些项目分解后，内容分类很多、容量很大，使用缩进图表示比较方便，能说明问题。
  分级的树型结构类似与组织结构图，表达起来层次清晰，非常直观，结构性也较强。
  总之，两种表达方式各有千秋，可以根据实际情况选择使用。下图所示是一个分级的树型结构的简单示例。

  某软件开发项目的工作分解结构示例
  工作责任划分
  接下来，需要进行工作责任划分，通常我们利用责任矩阵来确定项目工作的各个责任接口，强调每一项工作具体由谁负责，并明确每一个人、组织、组织单元在整个项目中的地位和作用。
  这一点也很重要，实际工作过程中只有明确了某个工作目标由具体的某个人负责，才能确保项目的顺利推进，具体工作的负责人才能在推动工作的过程中利用决策的权利组织相关人员合力完成目标，这一步实际也是针对阶段目标或里程碑目标。
  比如在软件开发项目中，按照顺序首先需要进行需求分析，那么需求分析阶段就需要确定某些个人或组织负责这个阶段的工作，某些个人或组织参与、辅助这项工作等，后续工作包括概要设计、详细设计、软件开发等阶段同样要照此处理，这样才能保证每个环节不出问题或尽早发现问题，因为下游责任人会不断关注上游环节输出的结果物，这也充分证明了工作责任划分的优点所在。
  项目活动的定义
  计划管理过程中体现计划详细程度的就是项目活动的定义。
  项目活动就是为了达到项目阶段目标确定的交付成果而进行的一系列工作单元，每一个工作单元就是需要消耗一定时间和资源的明确的工作。
  比如说我们在软件编码阶段，阶段目标是完成全部编码工作，结果物是软件源代码以及技术白皮书等，那么我们的活动可能包括基础类库设计编码、公共控件提炼、软件框架搭建、A模块编码、B模块编码等等项目活动。
  在这部分我们应该尽可能全的、清晰的、详细的定义出所有项目活动，项目的具体工作单元。这样才能保证项目在执行过程中有目的的掌控每项工作内容的状态。
项目活动排序和历时估计
  最后我们进行项目的活动排序和历时估计。首先要确定工作包的逻辑关系，其次是完成各个活动间的关系确认，特别是活动间的先后依赖关系，最好同时完成活动历时和资源使用的确认，因为一项活动的历时与其先后活动和其他相关联活动有着紧密的联系。
  例如软件开发项目，当需求不明确时，肯定无法进行软件概要设计，否则设计出来的东西肯定不能满足用户需求。因此，活动依赖关系确认的正确与否，将会直接影响到项目的进度安排，资源调配和费用开支等。
  这部分内容在计划报告中通常是由Gantt图（甘特图）描述。也可以使用项目管理工具，比如微软的Project Professional，现在Project Server 2003功能更强大，不但使Project Professional和Project Server有机结合，而且还通过SharePoints Services提供强大的文档管理，风险和问题跟踪等功能。
  可以利用这些工具辅助计划管理过程，形成软件开发计划的辅助文档，同时进行有效的项目管理和计划过程管理。

案例：
  在实际生产过程中，部分软件开发负责人可能忽略计划过程，理由往往是他感觉自己心里有数或者认为作计划没用。在实际生产过程中有不少人存在这样的想法，发生在身边的案例让笔者感触颇深。
  一个有两年软件开发项目管理经验的朋友刘某，曾经负责过某商场的CRM系统的软件研发工作，当时项目的主要困难是工期要求紧张，但就项目本身而言规模相对较小，刘某根据经验认为只要让每个人清晰自己的工作，各负其责，全员迅速投入研发，尽快完成编码，到时候把所有模块组装起来就应该没什么问题，这样即可以节省人力又可以解决时间上的矛盾，所以大意的认为没必要浪费人力、精力、时间在编写项目计划上，于是协调大家简单沟通后便启动项目。
  在整个软件研发过程中大家一直都很忙碌，编码工作在一天天的进行，表面上看起来也没有任何异常，通过大家的共同努力，在项目的收尾阶段，编码工作基本完成，于是项目经理组织进行实施前的准备工作，这时候，项目启动初期没意识到的问题、没有引起足够重视的问题都不约而同的、也是必然的暴发了：系统联调卡壳、Bug层出不穷，需要测试同时纠错，但由于疏忽没有预留这步工作的时间；安装、打包工作没有进行、文档没有编制，需要调整人员应急处理，这依旧是当时没有计划这部分工作导致任务遗漏。结果所有人乱作一团，如果按照原工期要求即使全员通宵达旦赶进度也已经无法按时完成，无奈之下只能延迟进场。
  事后我们一起沟通交流过几次，刘某也认真反思得出结论，如果当时能全盘考虑，在项目初期制定开发计划，界定工作范围，分解所有工作任务，就不会到最后时刻出现任务遗漏的现象；由于开发任何一个软件项目，都不可能一次完全到位，如果当时在计划中制定项目阶段目标，按阶段控制项目偏差，严格有序的执行项目计划，在每个阶段充分的分析偏差，及时纠正，就不会出现直到最后才发现没有时间修改大量程序Bug的问题，从而产生延误工期的现象；如果当初计划中分工明确，工作责任划分清晰，就不会出现忙忙碌碌、乱作一团却无法实现项目目标的现象。总之如果项目初期制定了详细的项目计划，肯定不会到最后一刻才暴露出隐藏在平静下的各种各样的问题而无力回天。
  后来经过调整，综合分析后续剩余工作，刘某制定了详尽的工作计划，并且严格按照计划实施执行，最后终于保证项目在后延许可的时限内良好的完成。由此可见有一个清晰可行的项目计划对项目的顺利执行，影响相当重大。
  针对认为心里有数或者认为作计划没用的这两种认识，我们来做一个简单的分析。说心里有数的通常最多是潜意识中有一个很概要的总体项目目标，通常情况下是只认准了项目最终结果，我们权且认为这就是一个计划，只不过这个计划总共包含一个阶段。
  这样的计划肯定不好，因为在项目执行过程中，可能直到最后一秒前都没有时间、偏差概念，没有意识到存在什么问题，突然在工期结束时被询问结果，才意识到实际存在问题的严重性，但是时间已到，即使想纠正这种偏差也没有了回旋的余地，项目的一次性特征无情的证明项目以失败而告终。本文中的案例充分的说明了这一点。
  对于认为作计划没用，这种想法本身就是错误的，没有去使用计划就断定计划没用，显然不具备说服力，也可能有人认为计划赶不上变化，我们说有并且按部就班的去做总比没有计划想到哪儿做到哪儿强。
  在软件开发项目计划的制定过程中，项目经理应该是一个协调和沟通的枢纽，与项目干系人进行充分的交流和沟通，同时应该使项目团队成员充分认识到项目计划的重要性，因为有些技术人员往往忽略计划的地位，项目经理有义务在此阶段调动相关人员的兴趣，使其积极参与。
本文已刊载于《中国计算机用户》2004年第26期

原文转自：http://www.ltesting.net