对软件研发项目管理的深入探讨

对软件研发项目管理的深入探讨第一章简介1.1研究背景我之前曾在厦门一家中等规模(合计开发人员50人)的软件公司担任项目经理，开始由于对软件工程的不怎么重视，些失败的软件项目给我留下了极深的映象。

在失败和困惑中，我们开始反思，也总结了一些经验教训。

后来，我们在开发过程中引入了MSF(Microsoft Solutions Framework)软件开发模型，并结合公司的具体情况进行了裁减。

实践证明，我们的软件工程过程管理能力大为提高，软件的质量也有较大程度的提高，软件的交付期也得到了基本保证，已经没有再发生那种永远也完不成项目”的情况。

1.2研究动机在这篇文章中，主要谈论了在产品开发中的项目管理问题，此处的产品开发”是指做一个通用的软件产品或者一些具体的领域性系统集成项目。

下面我主要结合我们公司实施MSF的情况，谈谈自己对软件工程的一些初步看法。

第二章MSF概要介绍MSF主要由几个模型构成，其中包括：组队模型、开发过程模型、应用模型、风险管理模型。

下面只对组队模型进行较详细的介绍，其他模型则简要说明，更详细的资料请查阅[2]。

2.1组队模型MSF把软件开发分成了六个小组，分别是：程序管理组、产品管理组、开发组、用户培训组、测试组、安装管理组。

组队的原则是小队(一般3-8人)、多侧面；角色交叉、目标一致；人员技术、业务精;关注能力和交货期；对项目的前景认识一致;人人参与设计；善于总结经验；共同管理、共同决策，项目人员同地工作等。

程序管理组的工作是：①推动开发过程；②负责产品规范说明；③沟通和协调各组关系；④管理项目进度，报告项目状态；⑤把握总体决策。

产品管理组的工作是：①代表客户(customer);②描述项目产品轮廓③负责需求定义；④平衡功能和进度要求；⑤负责市场、宣传、公共关系等。

开发组的工作是：①概要、详细设计；②完成产品开发；③准备安装的产品。

测试组的工作是：①制定测试策略和计划；②尽可能发现问题。

用户培训组工作是：①代表终端用户（end user）；②负责用户需求定义；项目管理者联盟文章③把握可用性和用户性能指标。

项目管理培训安装管理组工作是：①负责产品安装；②把握可管理性和可支持性。

项目管理培训各组的地位同等，非领导关系，并充分授权，保证目标清晰一致，由各组的负责人共同管理项目。

项目管理者联盟2.2过程模型项目管理者联盟文章MSF过程模型主要确立了四个重要的里程碑：前景范围确认、项目规划确认、开发完成、对外发布，通过控制这四个里程碑来分解管理项目过程。

2.3应用模型项目管理论坛MSF应用模型是分层次的应用模型，大体可分为三层，用户层、业务层和数据层，各层次通过标准组件进行封装，互相通讯调用来完成系统任务。

项目管理论坛2.4风险模型MSF风险管理过程主要包括：风险识别、风险表述，通过分析、计划、跟踪和控制过程，最终解除风险。

第三章MSF在项目中的具体应用项目经理圈子3.1组队模型裁减在中小软件企业中，一般项目的规模不会太大，通常是十几个人，少的只有几个人，所以必须对MSF的组队模型进行简化。

通常的做法是划分成三个组，程序管理组：一般对应于原来的项目经理，通常就项目经理一个人，如果需要还可以给他配个组手，通常称为项目秘书”产品管理和测试组：一般包括MSF中的产品管理组，测试组、用户培训和安装管理，主要代表用户确定软件需求并测试产品是否满足需求；开发组：和MSF的开发组相同。

这样的组队，比较符合中小项目的需要，在实践中也证明是比较合理的。

首先，确立项目经理角色，符合一般公司的管理模式，比较容易被接受。

如果有多人同时负责的话，容易产生责权理不清楚，互相扯皮的现象。

有一个项目经理对项目完全负责，遇到问题容易很快得到解决；他作为项目组代表，负责向上级汇报工作，能使其他人全力投入到项目中，而不至于在日常的事务中耽误太多时间，从而在某种程度上也提高了工作效率。

项目管理者联盟在原来的很多项目中，大多都没有设置产品管理角色，他的工作一般由项目经理兼任。

这样的做法已证明存在很多问题，会使项目经理精力分散，而且产品管理的任务和项目的日常管理工作也不大相同，如果叫一个人负责，怕两头都顾不上搞不好。

在产品管理组中，根据项目的大小，可以设置两个负责人，一个代表用户确定需求，另一个主要负责测试，但由前一个负总责。

因为只有用户代表认可了的产品品质，才是真正可以交付的品质。

产品管理经理（以下简称产品经理）是项目中非常重要的角色，他可以对技术不是很精通，但是必须对产品所服务的领域非常熟悉，最好是领域专家，在他的带领下，项目才不至于偏离预先设定的前景范围。

他必须对产品的需求能作出很好的把握，在适当的时候能进行流程重组，对产品的可用性和易用性有最终决定权。

根据我们的经验，通过设定产品经理，主要的感觉是产品受用户的欢迎程度增加了，无用的特性少了，因而也更容易成功。

根据我们的经验，这样组建的开发团队既有助于提高工作效率，又能保证有良好的产品质量。

没有设置产品管理角色的团队最容易产生的问题是开发人员往往喜欢凭他们的主观臆想来设定产品的某些功能，最终导致产品易用性极差，不容易为用户所接受。

3.2软件过程管理MSF开发过程总的来说是一个基于里程碑的，迭代的，风险驱动的过程。

一般遵循如下原则：①进度计划留有余地；项目管理培训②通过风险管理减少不确定性因素；③通过快速原型法尽可能使产品稳定和可预测；④缩短生命周期；⑤重视创新使资源和性能效率最大化；⑥拆分大项目等。

在过程模型上，主要包括四个重要里程碑：①前景/范围确认；②项目规划确认；项目管理者联盟文章③开发完成；项目管理培训④对外发布。

我们把MSF的各个阶段对应到传统的项目开发各阶段，目的是使公司所有人员便于理解和使用。

其中前景范围确认对应传统的可行性分析”；项目规划确认”对应需求分析”和项目计划”；首次运行”对应开发完成”，发布”的意思和传统基本相同。

同时，我们也根据公司的具体情况对流程进行了相应调整，把整个流程分为可行性分析、需求分析、开发计划、开发过程和结项总结五个阶段，下面分别进行说明。

按照IS09001的要求，在软件开发前有一个可行性分析报告，讨论项目的可行性和风险，一般公司项目也都会经历这一阶段。

做可行性分析一般由未来的项目经理和产品经理共同完成，讨论该项目的技术、经济可行性和潜在的风险等。

很多小公司在做项目前都没有这个过程，往往是不管自己的实际情况，匆忙上马，遇到项目就接，结果是做一个死一个，成功的很少。

项目管理者联盟在做可行性分析的时候，要充分考虑公司以前的各种技术和市场积累，还有目前的资源可用性情况，特别是要做好风险分析。

我以前就碰到过这种情况，一个项目的领域和公司以前的领域不尽相同，在立项前没有充分考虑各种情况，认为这个项目比较简单，应该没什么问题，结果是没有做得很成功，进度上也拖了一段时间。

在后来结项分析的时候，认为主要的问题就是领域的区别造成了公司内部没有人对该领域特别熟悉，缺乏领域专家，并对上述风险估计不足，也没有对风险进行较好的管理，所以造成了项目的不成功。

转自项目管理者联盟上面提到，可行性分析一般是由未来的项目经理和产品经理完成，必要时还需要市场人员的参与，项目经理主要考虑技术可行性，包括项目最初估计的进度表和资源需求情况；产品经理主要考虑市场和经济上的可行性（主要是针对软件产品而言）。

只有预先对各种问题进行完备的分析后，才能得出正确的决策。

不要到后来因为那些事先没考虑到的，但应该想到的各种原因造成项目失败；或者虽然完成了，但是没有取得预期的效果，不能给公司带来较好的收益。

只有在可行性分析通过评审，公司高层领导者认可的情况下才能付诸实施。

通过可行性分析，揭示了即将面临的各种问题及风险，使得公司内部对该项目有了一致的认识，在后来的资源申请上也更容易得到高层支持，更易于导致项目成功。

那种只有一个想法，就开始实施的做法是绝对不可取的，可以是单兵做战，但决不是公司行为。

项目管理论坛需求管理是软件开发中非常重要的部分，在一般的MIS型项目中，准确的把握需求往往是项目成功的关键。

但需求管理也是个困难的过程，据我所知，太多项目的需求都没有良好的管理过程，往往导致项目后期的大量修改或者直接使项目失败。

需求的管理主要由产品经理负责，其中最终用户（end user）的实时参与是一个非常重要的因素。

在需求采集阶段，我们主要采用了原型法，使用VB或者Frontpage建立最终产品的界面，然后把功能实现和界面一一对应起来，和用户进行讨论，并不断的修改界面。

最终在基本达成一致后，对应原型写出需求规格说明书，在评审后纳入基线管理。

在后面的开发中，我们必须保证最终产品界面和原型基本一致，如有变更，则必须提交项目组和客户讨论。

根据我们的经验，优秀的产品经理+用户参与+原型法=良好的需求说明。

项目管理论坛在需求的制定过程中，产品经理必须和项目经理、开发人员、测试人员进行良好的沟通，使项目组全体都参与到需求分析中来，并共同确定需求的关键特性：1.项目的范围：在需求分析中，首先必须明确项目的范围，去掉那些看似属于该项目其实不该在项目中的需求特性。

特别是在一些MIS项目中，客户往往把一些属于他们的日常工作但不属于该项目的需求提交给项目组，这时就必须分清项目的范围，不要在项目中加入太多不应该做的东西，否则往往会导致项目范围无限扩大，最终只能是使项目失败。

2.需求的优先级：需求的优先级是非常重要的特性，只有在准确把握的需求优先级的基础上我们才可能规划外部里程碑（产品版本）和内部里程碑（开发的阶段性，后面会讲到）。

通常是用户最关心，使用最频繁的功能应该属于高优先级，而那些不怎么重要或很少用到的功能应该属于低优先级。

我们必须在产品的开始版本和项目的开始就把重点放在高优先级的需求上，而对于低优先级的功能可以在项目后期根据需要进行裁减或纳入下一个版本规划。

项目经理圈子4.其他需求特性：如性能要求、健壮性等。

这些特性是产品的非功能性需求，也是项目成功的关键因素，特别是在一些大型的涉及重要领域的管理信息系统中。

需求分析是整个项目活动中的非常关键的部分，它的好坏往往决定了项目的成败。

根据经验，需求分析所需的时间往往占整个项目时间的12%[1]。

在需求分析中，需要防止的一个错误做法是太依靠一些所谓的分析方法，而使整个需求分析过程非常复杂，过多的图表往往使人眼花缭乱，而不能准确抓住问题的本质。

一些分析人员往往对自己熟悉的简单的业务花大力气，而对不熟悉的则一笔带过，也是本末倒置的错误行为。

在分析过程中，我们必须始终把握需求分析的目的是把模糊的流程搞清晰，把复杂的业务尽量简化，而不是相反。

项目管理培训需求的管理也是非常重要的方面。

对需求分析完后的形成的规格说明需要进行专门的评审，并且需要客户和最终用户的参与，在达成一致后形成最初的需求基线。