项目管理是一项非常有挑战性的工作,尤其是软件项目管理。做项目管理的人都知道“项目三角形”法则,也就是制约项目的三个因素———时间、成本、范围各构成三角形的一边,其中一个因素的变化必然引起另一个或者两个同时发生变化。
　　例如项目要赶进度(缩短项目时间),可以投入成本、增加人力,或者将原定计划要实现的范围缩小,如何做取舍就要靠项目经理进行权衡选择。如果要做个譬喻,项目经理不亚于是“在针尖上跳舞”的舞者,他甚至可能要在捉襟见肘的寸方三角形舞台上导出一段“不可能完成任务”(mission impossible)的“群舞”。
　　1 范围管理概论
　　项目经理如此不幸,而软件项目经理就更可以说是“不幸中的不幸”,因为根据经典数据统计,软件开发项目的成功率目前不超过50%,如果时光回退十几年,这个数字会再低十个百分点,而且对于规模越大的项目,其成功率越低。
　　到底是哪些原因导致如此低的成功率,通过对过往失败项目案例进行整理和分析,人们生了问题才临时采取行动,试图迅速地解决问题。这样的管理方式往往让项目组很被动,也大大增加了管理成本,并使项目的进度面临很大的风险,所以必须采用主动式的风险管理模式,防患于未然。
　　发现其中一个主要的“败因”是范围管理失去了控制,从而引发“范围蔓延”(Scope Creep),以这种方式失败的项目表现为:项目已经比原定计划大大延期,客户仍在源源不断地有新需求,或者对已经完成的功能提出各种修改意见,开发团队士气低迷,总有完不成的开发任务,项目预算已几乎消耗殆尽,而距离项目收尾却遥遥无期。
　　范围管理难在何处?通过对以这类原因失败的项目进行分析和总结,大致可以归为客户方和开发方两大“责任方”。这里有两种观点。
　　(1) 责任在于客户。这类观点通常是由开发方“总结”得出的,经常从开发方的技术人员口中听到诸如此类的抱怨,“我们的客户从项目一开始就不清楚需要做什么”,“他们总是在变,今天想要这个,明天又想要那个,更难以忍受的是他们的要求又往往是矛盾的”,这种来自于客户方的需求“模糊”以及“朝三暮四”,使得项目的范围充满了不确定性,而开发方头上悬着“范围”—“时间”—“成本”这一“项目三角形”达摩克利斯之剑,范围的变动就意味着项目开发周期的延长和成本增加,带来的严重后果就是项目严重超支、项目延期难以交付而导致最终的项目失败。
　　(2)责任在于开发方。幸运的是开放方的责任并不是客户“投桃报李”总结出来的,开发方拥有很好的自觉反省,自己道出了“苦水”。他们通常认为,项目失败很大的一个主因是范围的定义不够明确,做不到可量化、可验证的程度,因而在进度和成本的量度和控制上面引发了多米诺效应,最后导致项目的“滑铁卢”。
　　而为什么项目开发方的管理团队无法做到范围界定明确的程度,原因有以下几个:
　　1)开发方缺乏规范的项目范围管理过程是最主要的原因。比如缺少范围评审环节,开发方与客户方无法在项目开头就对项目范围进行很好的商讨、澄清,并达成共识而且共同签署范围确认书,给后来的范围蔓延埋下隐患;
　　又比如开发方没有对变更进行有效的管理控制,在项目进行过程中,面对客户方“漫天要价”提出的后续需求缺乏有效变更系统加以辨别、遴选、记录和处理,最终由“量变”引发“质变”,项目范围远远超出最初预计。
　　2)开发方缺乏正确的方法作为指导。这里的方法即指软件工程领域中的方法,比如需求采集方法,也指项目管理中的方法,比如在范围分解的时候,运用正确的工作分解结构(WBS)法进行范围划分。
　　3)没有使用必要的项目管理工具进一步加强范围管理以及其他管理活动,给项目成功带来更高的保险系数。典型的工具有微软的Project 2000,以及IBM的统一项目管理平台。
　　以上对范围管理失控原因的总结和分析都很有道理,从中拿出任何一条,都可以在众多失败的项目中找到支持的佐证。为了解决范围管理这个难题,项目管理协会(PMI)和软件工程协会(SEI)都提出相应的范围管理体系。
　　PMI的项目管理知识体系指南(PM-BOK)对范围管理的定义是“为了成功完成项目,需要确保项目包括所需的全部工作,但又只包括必须完成的工作的各个过程”,从这个定义可以得知PMI的范围管理是一个过程管理,它关注的是在项目进行过程中的各项工作活动需要围绕项目交付展开,既要包含所有必需的活动,也不能包含不必要的活动,简而言之就是不多不少(just-in-time)。PMI的范围管理主要划分为五个过程展开,这五个过程分别是范围规划(planning)、范围定义(definition)、范围分解(break-down)、范围核实(verification)以及范围变更控制(con-trol),这五个过程是这么定义的。
　　(1)范围规划。规划主要指的是实现范围管理的策略,比如通过什么办法来采集需求以得到项目范围,以什么方式来进行范围分解等,范围规划相当于整个范围管理的一个计划,这个过程主要是得出一份项目范围管理计划书。
　　(2)范围定义。在范围管理计划的指导下,对要交付的项目制品进行分析,或者对历史同类项目制品进行识别,编写出一份项目范围说明书。
　　(3)范围分解。利用定义过程输出的项目范围说明书,按层次将项目制品分解成较小的可交付部分,同时也将项目工作分成较小和更便于管理的多项子工作,分解后得到一个树状分解结构,“根”代表项目,底层组成部分(“树叶”)的计划工作称作“工作包”,这些工作包可以安排在进度表中,进行费用估算以及监控。
　　(4)范围核实。范围核实将对上述过程产生的成果进行评审,如开发方的项目管理委员会召开专家评审会议进行范围评估,范围核实也包括在项目收尾阶段客户对项目制品进行验收的过程。
　　(5)范围控制。范围控制将对造成项目范围变更的因素施加影响,并控制变更造成的后果,PMI认为变更是不可避免的,但是必须强制一定形式的变更控制过程,使得变更尽量可控。
　　综合而论,PMI的范围管理定义了一个过程栈,在这个过程栈中以上一个过程的输出(通常是一个或多个文档)作为输入,采用组织既有的资产(比如文档模板、表格、历史项目数据)以及方法(比如专家判断)进行处理,然后得到一份或多份结果文档,而这些结果文档又可以作为下一过程的输入。通过有序的过程将项目利益相关方以及有关资源组织起来,并且通过专家判断、会议评审等方法,使项目范围定义渐进地得到明朗化,使其定义和分解较为全面与合理,达到可量化、可计划、可控制的一个良好管理状态。
　　2 软件项目中的范围管理
　　PMI只对项目范围的管理提供指导,不涉及具体的应用领域,比如软件开发领域,因而PMBOK只是一个通用项目管理的指导体系,要完整地进行范围管理,还须结合特定的应用领域加以运用。对于软件开发项目来说,项目制品指项目要交付的软件产品,因为项目范围取决于产品范围,所以软件的项目范围管理依赖于软件产品范围管理,软件产品范围则来源于软件的使用者———客户对软件所提出的需求。由于认识到软件需求的重要性,在20世纪80年代中期,从SEI中分离并形成了软件工程的子领域———需求工程(Require-ment Engineering,RE)。
　　进入到20世纪90年代,需求工程逐渐成为研究的热点之一,1993年起每两年举办一次需求工程国际研讨会(ISRE),1994年起每两年举办一次需求工程国际会议(ICRE)。此外一些关于需求工程的工作小组也相继成立,如欧洲的RENOIR(Requirements Engineering Network of International Co-operating Research Groups),并开始开展与需求工程研究有关的各项工作。需求工程研究使用已证实有效的技术、方法进行需求分析,确定用户需求,帮助分析人员理解问题并定义目标系统的所有外部特征。
　　与软件工程提出的生命周期类似,需求工程也有需求生命周期,它将最初用户的设想和要求通过一系列过程,并采用适合的工程方法转化为可以指导软件开发的需求规格,并提出要对这些需求进行相应的管理以跟踪和控制。
　　从上述特征来看,需求工程与PMI的范围管理实质上都是过程管理,而且重点在于各种说明详尽的文档编制,通过文档来驱动和指导开发,以求做到任何的进展和变动都有文档记录和跟踪,在开发流程和开发文档的双重保险机制下,尽可能避免发生差错,提高过程控制能力。
　　但是依靠过程式的管理是否完全适合软件这样一种特别的项目制品?是否能够有效地对范围进行管理,以提高项目成功系数?回答这个问题可以从三个方面入手:第一,软件这种制品有什么特征;第二,如何衡量一个软件开发项目的成功;第三,管理的本质又是什么。
　　先来看软件这一特殊的项目制品,说它特殊是因为软件不同于可见的有形物品,有形物品比如房屋、桥梁可以用计量单位和计量方法进行描述和标识,比如建筑物的位置、高度、面积、体积及空间位置等,软件则不然,软件是运行于计算机中的代码,它不是有形实体,无法进行严格而且形象的量化。软件要模拟并解决人在现实世界中发生的活动事务,而人的活动与事务又是千差万别,不同组织不同人其行事方式各有不同,期待的结果也不一,这就是具备相同功能的同一个软件产品不能完全适用于所有客户的原因,用软件行业术语讲需要进行“本地化”和“客户化”以满足不同需求。软件所能满足的对象就是所说的客户,软件的生产者即开发方,一个软件从最初的想法到具体构思,再到设计和实现这一系列过程,需要客户向开发方描述所要构建的是一个什么样的系统,
　　将解决和能解决什么问题,最终达到什么样的一个效果,这个过程需要双方的沟通,以达成对要构建系统的较为一致的认识。但是正如我们熟知的,在沟通的过程中,人们所处的观察角度不同,思考方式不同,表达方式也不尽相同,这都会导致信息在传达过程中发生丢失与变形,会出现客户所想不是开发方所做的这么一种状况,有人将客户与开发方这种矛盾做了有趣的比方,“客户奢望得到一张沙发,开发人员却提供一条板凳;客户仅要求得到一把椅子,开发人员却提供了一张豪华沙发”。也正是这种矛盾,才会出现客户方在软件需求上面为什么会“朝三暮四”,因为第一,客户方对要做什么是一个由浅入深的过程,刚开始需求提出少是因为认识不够,随着项目深入其认识也逐步加深,对于系统要构建成什么样子更加明朗化,自然需求就提得越多;
　　第二,项目是一个过程,它跨越一个时间阶段,在这个阶段中客户的活动方式和事务内容往往会发生变化,在这个时候软件的开发也随之发生变化是一个再自然不过的事情,而且规模越大、时间跨度越大的项目就越是要面临这种挑战。
　　再反观过程式管理,该管理模式要求项目一开始就能较清楚地确定要完成事项的大致范围,进而安排计划进度,确定投入的成本与资源,显然这与软件这一特殊项目制品渐进和反复式的构建特点以及构建过程有相违的地方。
　　过程式管理理论源于20世纪初的机器工业生产时代,管理的对象是机器化作业流程以及流程中的生产者,典型的代表是流水线作业,这种管理对于固定生产方式是非常有效的,因为一旦作业流程和单位人员生产效率确定之后,输入和产出间有一个线性关系,自然也就可以进行量化和计划,并通过计划来指导和管理生产,投入成本、产量、交付时间等可以做到比较准确而没有多大偏差,但是由于软件制品的上述产品特征以及其渐进的过程特征,这种线性管理模式比较难发挥作用,因为从一开始它就缺乏准确的量化作为输入,并且计划一旦形成,就很难再适应后续需求的变化。
　　再来看一个软件项目如何才算成功,由于软件项目牵涉两方,那么自然成功的衡量标准是同时满足两方的期待。客户方是软件产品的投入者,其期待自然就是产出,这种产出从商业角度讲就是获得价值,无论这种价值是以什么样一种方式提供,比如客户通过软件产品节约运作成本,提高工作效率,或者是给用户提供更好的服务质量,增强企业竞争力,直接产生经济效益等。对于软件开发方来说,作为一个商业实体其期待是通过项目获取开发利润,能否获取到预期的利润自然又回到“项目三角形”这个简单的原理,当项目的范围、时间、成本符合计划预期时,项目可以获得最大的赢利,反之如果这三个因素有一个增大,利润就减少,因此开发方的项目经理显然更操心的是计划制订的合理性,希望范围能够定得准确,希望计划能够做得完美,希望变更不要太多,希望项目进展一如预期。然而正如人们常说的,世间没有两全其美的事,“鱼与熊掌不可兼得”,而且应该可以看到客户方和开发方两边的期待其实暗含一种此消彼长的逻辑关系,那么假定在极端情况下,如果只可以确保一方的利益,应该优先考虑哪一方呢?无论是从“甲方乙方”这个简单商业原则,或者从项目最终是为了提供特定产品、服务、成果这个宗旨来看,应该优先考虑的是客户这一方,因为只有在客户取得成功、实现增值目标的前提下,开发方才获得真正意义的最大“利润”。
　　从一些著名的项目实例可以找到对这一选择的支持,“铱星”是摩托罗拉耗费巨资投入的一个项目,尽管项目进展一如预期,但是这个项目最终却没有给摩托罗拉带来商业上的成功,这无疑是个彻头彻尾失败的项目;电影《泰坦尼克号》的拍摄严重超支超时,早期被批评家认为2亿美金打了水漂,但是最后却成为全球第一部超过10亿票房收入的电影,毫无疑问这是一个经典的成功项目。过程式管理强调计划、控制,而审慎详尽的计划往往耗时费力,又难免遇到范围信息输入较少这样的尴尬境界,因而如果项目经理死守一份僵化的计划,为了维护“项目三角”关系,有意无意地利用事先设置的种种流程环节以拖延、回避、拒绝合理的范围变更,所导致的严重后果势必是交付给客户一个不符合期待、不能创造价值的平庸软件产品,甚至可能成为客户日常作业的“累赘”,或者是“食之无味”的“鸡肋”。应该找到一种管理方法,使得项目既能满足客户的要求,又能为客户带来真正的价值,并且使客户方与开发方实现一种“双赢”的合作方式,很显然单独依靠过程管理难以做到这点。最后来看管理的本质。无论软件是如何一种特殊的制品,其管理仍是通常意义“管理”中的一种,它的管理目标、管理方法应该与通常意义的“管理”一致。
　　对于“管理是什么”这样一个深奥的本体论话题,诞生了百年的管理学界仍无法形成统一的看法,尽管如此,对于管理包含什么,具备什么职能,实现什么目标还是比较明确。管理存在于人类社会,自从出现了群体以及发生了共同劳动,就出现了管理,管理将独立分散的生产要素结合起来,以完成特定群体即组织的共同目标,并且在实现这个共同目标的过程中,管理可以并且必须充分发挥各个组织以及成员的潜能。软件开发说其特殊,是因为其主要的“生产要素”是人,不像一个生产流水线,软件生产甚至不需要提供一个固定的生产空间—厂房,软件生产可以是分布在地球任何角落的一个或者多个个体———程序员或者开发组织;也不需要强制规定工作时间,因为有些开发人员的晚上工作效率往往高于白天;软件生产的产出并不是线性的,当遇到技术难题的时候,开发人员会被搁置在难点攻关上而不产生任何可见的成果,比如一行代码,如果在思维活跃的时候,开发人员又可能会变得异常高效,他可以在几天当中完成原计划需要半个月甚至更长时间的任务。“软件产品开发主要基于人”这样一个最大的生产特性被过程式管理所忽略,因为过程式管理的一个出发点和作用是防范整个过程体系中有个别人能力不足或者由于人员流失而给组织带来损失,防范由于人的自由性使事情偏离预想轨道,因此通过在一系列过程中安排检查点及时进行纠偏,并且设置层级的组织结构对此进行制约。过程式管理在生产型组织中做得非常成功,但在软件项目开发中并没有预期的理想,因此软件开发应该需要这么一个管理体系,它能够发挥人的主观能动性,激发团队合作潜能,实现客户提出的有价值的业务“思维”,开发出软件这样一种“纯思想”的制品,最终提供客户价值。这个更能适合软件项目开发的管理体系需要引入的是“敏捷”。