|
分析其原因，发现其中一个主要的“败因”是范围管理失去了控制，从而引发“范围蔓延”(Scope Creep)，以这种方式失败的项目表现为：项目已经比原定计划大大延期，客户仍在源源不断地有新需求，或者对已经完成的功能提出各种修改意见，开发团队士气低迷，总有完不成的开发任务，项目预算已几乎消耗殆尽，而距离项目收尾却遥遥无期。 项目范围取决于产品范围，软件产品范围则来源于软件的使用者——客户对软件所提出的需求。由于认识到软件需求的重要性，在20世纪80年代中期，从SEI中分离并形成了软件工程的子领域——需求工程。 与软件工程提出的生命周期类似，需求工程也有需求生命周期，它将最初用户的设想和要求通过一系列过程，并采用适合的工程方法转化为可以指导软件开发的需求规格，并提出要对这些需求进行相应的管理以跟踪和控制。 从上述特征来看，需求工程与PMI的范围管理实质上都是过程管理，而且重点在于各种说明详尽的文档编制，通过文档来驱动和指导开发，以求做到任何的进展和变动都有文档记录和跟踪，在开发流程和开发文档的双重保险机制下，尽可能避免发生差错，提高过程控制能力。 过程式管理的一个出发点和作用是防范整个过程体系中有个别人能力不足或者由于人员流失而给组织带来损失，防范由于人的自由性使事情偏离预想轨道，因此通过在一系列过程中安排检查点及时进行纠偏，并且设置层级的组织结构对此进行制约。 依靠过程式的管理是否完全适合软件这样一种特别的项目制品？回答这个问题可以从三个方面入手：第一，软件这种制品有什么特征；第二，如何衡量一个软件开发项目的成功；第三，管理的本质又是什么。 一、软件项目特征 （1）软件不同于可见的有形物品，有形物品可以用计量单位和计量方法进行描述和标识，软件是运行于计算机中的代码，它不是有形实体，无法进行严格而且形象的量化。软件要模拟并解决人在现实世界中发生的活动事务，不同组织不同人其行事方式各有不同，期待的结果也不一，这就是具备相同功能的同一个软件产品不能完全适用于所有客户的原因。将解决和能解决什么问题，最终达到什么样的一个效果，这个过程需要双方的沟通，以达成对要构建系统的较为一致的认识。但是正如我们熟知的，在沟通的过程中，人们所处的观察角度不同，思考方式不同，表达方式也不尽相同，这都会导致信息在传达过程中发生丢失与变形，会出现客户所想不是开发方所做的这么一种状况。 （2）项目是一个过程，它跨越一个时间阶段，在这个阶段中客户的活动方式和事务内容往往会发生变化，在这个时候软件的开发也随之发生变化是一个再自然不过的事情，而且规模越大、时间跨度越大的项目就越是要面临这种挑战。 过程式管理模式要求项目一开始就能较清楚地确定要完成事项的大致范围，进而安排计划进度，确定投入的成本与资源，显然这与软件这一特殊项目制品渐进和反复式的构建特点以及构建过程有相违的地方。 二、软件开发项目的成功界定 由于软件项目牵涉两方，那么自然成功的衡量标准是同时满足两方的期待。 过程式管理强调计划、控制，而审慎详尽的计划往往耗时费力，又难免遇到范围信息输入较少这样的尴尬境界，因而如果项目经理死守一份僵化的计划，为了维护“项目三角”关系，有意无意地利用事先设置的种种流程环节以拖延、回避、拒绝合理的范围变更，所导致的严重后果势必是交付给客户一个不符合期待、不能创造价值的平庸软件产品，甚至可能成为客户日常作业的“累赘”，或者是“食之无味”的“鸡肋”。 三、管理的本质 管理可以并且必须充分发挥各个组织以及成员的潜能。软件开发说其特殊，是因为其主要的“生产要素”是人。软件生产的产出并不是线性的，当遇到技术难题的时候，开发人员会被搁置在难点攻关上而不产生任何可见的成果。 “软件产品开发主要基于人”这样一个最大的生产特性被过程式管理所忽略。因为过程式管理的一个出发点和作用是防范整个过程体系中有个别人能力不足或者由于人员流失而给组织带来损失，防范由于人的自由性使事情偏离预想轨道，因此通过在一系列过程中安排检查点及时进行纠偏，并且设置层级的组织结构对此进行制约。 过程式管理在生产型组织中做得非常成功，但在软件项目开发中并没有预期的理想，因此软件开发应该需要这么一个管理体系，它能够发挥人的主观能动性，激发团队合作潜能，实现客户提出的有价值的业务“思维”，开发出软件这样一种“纯思想”的制品，最终提供客户价值。这个更能适合软件项目开发的管理体系需要引入的是“敏捷”。 |
|
|
