项目综合管理：软件项目管理的改进

文章作者 100test 发表时间 2007:10:08 11:11:42
来源 100Test.Com百考试题网

由于项目管理、软件工程，都是实践性非常强的学科。企业几乎每个项目组都有自己的一些看法和做法，都能够提出一些独到的见解。这些见解往往互不相同，甚至相互冲突。所以企业在进行管理改进、建立一套统一高效的项目管理体系，遇到非常大的困难。
任何管理改进都不是一撮而就的。当然，不同的人站在不同的角度，对什么是当前最优先解决的问题，往往有不同的看法。因此，应用一套科学的理论模型，是非常必要的。理论模型重要之处在于，它勾勒除了一个完整的体系，并且提供了孰轻孰重的解决次序——改进“路线图”。
许多软件行业选择CMMI模型。

1、CMMI模型是综合了项目管理与软件工程的模型。

PMI的PMBOK是当前最具影响力的项目管理模型和指南，得到了广泛的应用。但PMBOK是一个通用的模型指南，并未吸纳特定行业的项目管理特点。
软件项目管理有其重要特性，其特性就是在：软件项目可以用标准的项目管理要素如进度、质量、成本来管理，同时，软件项目也是一系列软件工程工作的集合：需求分析、软件设计、质量控制、软件测试，等等。
因此，对于软件项目管理来说，标准项目管理与软件工程，是一个硬币的两面，是必须紧密结合才能够取得成效的。如下图表示：

而通用项目管理理论，是不包含软件工程，如需求管理、配置管理、测试管理的内容的。因此，在将项目管理过程与配置、测试管理的结合上，遇到盲点。
而CMMI是针对软件项目过程的模型，在CMMI中，既包含了项目管理的内容，又包含了软件工程内容，同时还包括组织能力等很多的方面，并且最重要的是，CMMI将这几个部分融合成一个体系，从而在软件行业获得了巨大的成功。

如图（CMMI的过程域），CMMI模型包括4个“过程组”。第一个是工程，包括需求管理、需求开发等。第二个是项目管理，包括项目监督与控制、项目计划。第三个是过程管理，定义了很多组织级的过程（在PMI最新的PMBOK里面，吸收了这个思想，成为“组织过程资产”）。第四个是支持过程，包括配置管理、质量保证、度量分析等。

因此，视锐达VisualProject项目管理软件的一个重要特点就是支持CMMI体系。

2、CMMI有些工作比较繁琐，但其根本思想是非常清晰和有效的。

实施CMMI在中国国内有很多急功近利的情况。很多企业为了迅速拿到认证而突击。这种做法导致了很多“僵化”的CMMI项目。
但在实践中发现，很多CMMI认证所要求的报表和数据，其实是在管理成熟度达到一定程度之后才会达到。如果一开始就强行收集这些数据，将会使得CMMI工作变得极为繁琐。但CMMI真正有力的是其“逐步改进”的思想和一套完整的改进路线图。

管理改进，需要取得高层和一线项目的平衡

很天然的，高层与一线项目之间有需求的冲突。往往高层领导期望看到很多数据、趋势，希望精细化的管理。但是一线项目组未必很希望每天详细的书面来汇报工作。因此，在项目管理改进的过程中，如何取得高层与一线项目的平衡，是成功的关键。
在一些企业的管理改进项目中，产生的高层与一线项目最大的争论，就是“分层计划”的处理模式。
分层计划模式，是项目进度管理的一个内容。但是分层计划模式在具体的执行过程中，有很多的问题。如某企业总公司与分公司之间，有一个清晰的计划界面：主计划（MasterPlan）。分公司承接总公司的一个大型项目，需要提出一个“主计划”，并得到总公司的批准。一旦批准（也就是“基线化”），这个主计划就具有约束力，轻易不能更改。如果需要更改，则要上报总公司批准。
但是，这个“主计划”往往是一个比较粗略的计划。在分公司具体的工作安排中，其实有一套自己的详细的计划。主计划、分公司内部的详细计划，就是所谓的“分层计划”。
按照完美的管理模式，主计划与详细计划，二者应该是一致的。这样有很多的好处：

1. 高层领导可以逐级分解，甚至看到最细的任务——每人每天在做什么；
2. 当详细计划发生变动导致进度的变化，主计划马上就能够反映出来；

但是，实际上，这是非常非常难以做到的。

1、详细任务计划的变动非常频繁

我们很难做到将计划做得非常完美，甚至将3个月后每个人每天干什么都能够清晰的计划出来。而且突发事件、项目问题、各种变更和变动，都导致详细任务计划的变动非常频繁。

2、主计划有一个再分解过程，未必与详细计划一一对应

高层领导关注的主计划的一个任务，在分公司就可能是一个具体的项目。甚至一个任务分解成多个项目，或者多个任务合成一个项目，或者多对多。对应关系非常复杂。

显然，领导希望主计划与详细计划紧密关联。但实际工作的项目组认为是不可能的。如果强行关联，带来的结果是，领导看到的详细计划是“假计划”。项目经理必然自己做一个内部的计划，来实际管理项目的工作。
因此，在VisualProject项目管理软件的实施过程中，都会考虑到平衡高层领导要求与一线项目的需求，取得当前的平衡。

寻找合适的管理匹配度

管理匹配度是管理软件上线的一个主要问题。无论哪个模型和最佳实践，如果和实际情况不符，需要“削足适履”，效果可能会大打折扣。这就要求项目管理系统具有很多的管理模式，能够适应多种情况，必要的时候，要进行模型的改进。

比如项目管理的重要环节是“项目工作量估算”。如果不能准确估算工作量，是不可能做出精确的计划的。但不同类型的项目，合适的估算方法是不同的。
在一些研发机构中主要存在四种主要类型的项目：定制开发型、产品实施型、推广型、维护型。这几种类型的项目的估算方法是不一样的。

定制开发型项目，比较有影响力的是一些成熟的模型，如功能点模型，或者CMMI要求的按照“生产率”估算的模型。基本上得到了广泛的应用。
但产品实施型项目就完全不同。产品实施型项目的主要工作不是软件开发，而是按模块的实施。这个时候，估算方法最有效的，是按模块的历史经验数据进行估计。
推广型项目，最合适的方法，是“类比法”。如某企业核心业务系统在全国推广时，基本上依据在某一分公司上线的数据。根据目标的规模和复杂度，根据分公司的数据进行类比，得到项目工作量和时间计划，实践证明是比较有效的。

因此，多种项目工作量估算方法，对项目管理系统提出了很高的要求。

再一个例子是人员报工和任务的进度跟踪。最好的做法，当然是每个人每周汇报在某个具体任务上花费了多少时间，完成了多少比例。项目经理审批之后，进度自动进行更新。但这种可能在国际上流行的做法，在国内几乎难以实现。

因为这种精确跟踪模式，有一个前提就是项目经理必须非常清晰和精确的给每个资源分配任务。但是往往难以做到。比如说，项目经理临时让某个员工做了计划外的一件事，如花费半天时间写了一个文档。精确跟踪模式，就要求项目经理必须更新任务计划，给这个员工重新分配一个半天时间的“写文档”的任务，否则员工就无法报工，也就无法进行进度自动跟踪。
某些比较规范的项目（如封闭开发），相对来说，项目经理可以做出较为精确的任务计划和资源安排。但是对于另外一类项目，如实施型项目、推广型项目、维护型项目，这是非常难以做到的。
因此，可能同时存在多种进度跟踪模式：自动跟踪、手工跟踪，等等。也就是说，项目管理软件系统需要能够兼容多种的管理模式，才能够获得比较好的管理匹配度。

VisualProject的进度管理可以做到：

手工进度跟踪--支持项目经理手工跟踪任务进度；
自动进度跟踪--支持员工汇报任务进度，项目经理审批报工，自动跟踪任务进度；
高层计划与跟踪 --管理高层计划：阶段、步骤、里程碑、交付物，可显示普通甘特图，基准比较甘特图；
高层计划生成任务计划--从高层计划生成任务计划；
引用生命周期模板--从系统定义的生命周期模板导入生成高层计划。

管理改进需要工具，还需要大量的咨询实施工作

项目管理、测试管理等管理改进工作，遇到的问题是会非常多的。各种不同的意见需要统一，不同的方法需要兼顾。因此高水平的咨询师是项目实施成功的保证。如同业务系统的开发一样，一个资深业务人员能够深刻理解业务需求，准确表达业务需求，同时统一不同的业务需求意见，从而为系统开发奠定基础。

在管理改进工作中，如何统一大家的思想和工作方式方法，是咨询师能力的体现。有的时候，某些想法是不能支持的，需要说服他放弃原有的工作方式，而采用更好的、或者标准的工作方式。有的时候，需要进行变通，在不牺牲管理原则的前提下，满足个性化需求。
纯粹的应用产品方式，是难以成功的，尤其对于项目管理软件。许多公司在采购项目管理软件中意识到不是简单买一个工具，而是要买一个“最终效果”。如果工具买来了，但是最终用不起来，或者用得很别扭，还是不能算成功。买来工具，用不起来，这个风险，需要咨询实施服务来进行化解。

纯粹的定制开发方式，也是很难成功的。某企业的开发中心早期就进行不少定制开发的小型系统。但是越做越难，到后来几乎难以维护。这个原因就是，每个需求未必是合理的，甚至有的是明显违背项目管理的基本原则，有些需求甚至是相互冲突。如果不具备咨询能力，不能鉴别出有效需求，“泥沙俱下”，只要是需求，就通过定制化方式实现，那么最终这个软件系统是不可能运转很好。