它不是有形实体,无法进行严格而且形象的量化。软件要模拟并解决人在现实世界中发生的活动事务,而人的活动与事务又是千差万别,不同组织不同人其行事方式各有不同,期待的结果也不一,这就是具备相同功能的同一个软件产品不能完全适用于所有客户的原因,
用软件行业术语讲需要进行“本地化”和“客户化”以满足不同需求。软件所能满足的对象就是所说的客户,软件的生产者即开发方,一个软件从最初的想法到具体构思,再到设计和实现这一系列过程,需要客户向开发方描述所要构建的是一个什么样的系统,
将解决和能解决什么问题,最终达到什么样的一个效果,这个过程需要双方的沟通,以达成对要构建系统的较为一致的认识。但是正如我们熟知的,在沟通的过程中,人们所处的观察角度不同,思考方式不同,表达方式也不尽相同,这都会导致信息在传达过程中发生丢失与变形,
会出现客户所想不是开发方所做的这么一种状况,有人将客户与开发方这种矛盾做了有趣的比方,“客户奢望得到一张沙发,开发人员却提供一条板凳;客户仅要求得到一把椅子,开发人员却提供了一张豪华沙发”。也正是这种矛盾,
才会出现客户方在软件需求上面为什么会“朝三暮四”,因为第一,客户方对要做什么是一个由浅入深的过程,刚开始需求提出少是因为认识不够,随着项目深入其认识也逐步加深,对于系统要构建成什么样子更加明朗化,自然需求就提得越多;
第二,项目是一个过程,它跨越一个时间阶段,在这个阶段中客户的活动方式和事务内容往往会发生变化,在这个时候软件的开发也随之发生变化是一个再自然不过的事情,而且规模越大、时间跨度越大的项目就越是要面临这种挑战。
再反观过程式管理,该管理模式要求项目一开始就能较清楚地确定要完成事项的大致范围,进而安排计划进度,确定投入的成本与资源,显然这与软件这一特殊项目制品渐进和反复式的构建特点以及构建过程有相违的地方。
过程式管理理论源于20世纪初的机器工业生产时代,管理的对象是机器化作业流程以及流程中的生产者,典型的代表是流水线作业,这种管理对于固定生产方式是非常有效的,因为一旦作业流程和单位人员生产效率确定之后,输入和产出间有一个线性关系,自然也就可以进行量化和计划,
并通过计划来指导和管理生产,投入成本、产量、交付时间等可以做到比较准确而没有多大偏差,但是由于软件制品的上述产品特征以及其渐进的过程特征,这种线性管理模式比较难发挥作用,因为从一开始它就缺乏准确的量化作为输入,并且计划一旦形成,就很难再适应后续需求的变化。
再来看一个软件项目如何才算成功,由于软件项目牵涉两方,那么自然成功的衡量标准是同时满足两方的期待。客户方是软件产品的投入者,其期待自然就是产出,这种产出从商业角度讲就是获得价值,无论这种价值是以什么样一种方式提供,比如客户通过软件产品节约运作成本,提高工作效率,
或者是给用户提供更好的服务质量,增强企业竞争力,直接产生经济效益等。对于软件开发方来说,作为一个商业实体其期待是通过项目获取开发利润,能否获取到预期的利润自然又回到“项目三角形”这个简单的原理,当项目的范围、时间、成本符合计划预期时,项目可以获得最大的赢利,
反之如果这三个因素有一个增大,利润就减少,因此开发方的项目经理显然更操心的是计划制订的合理性,希望范围能够定得准确,希望计划能够做得完美,希望变更不要太多,希望项目进展一如预期。然而正如人们常说的,世间没有两全其美的事,“鱼与熊掌不可兼得”,
而且应该可以看到客户方和开发方两边的期待其实暗含一种此消彼长的逻辑关系,那么假定在极端情况下,如果只可以确保一方的利益,应该优先考虑哪一方呢?无论是从“甲方乙方”这个简单商业原则,
或者从项目最终是为了提供特定产品、服务、成果这个宗旨来看,应该优先考虑的是客户这一方,因为只有在客户取得成功、实现增值目标的前提下,开发方才获得真正意义的最大“利润”。
从一些著名的项目实例可以找到对这一选择的支持,“铱星”是摩托罗拉耗费巨资投入的一个项目,尽管项目进展一如预期,但是这个项目最终却没有给摩托罗拉带来商业上的成功,这无疑是个彻头彻尾失败的项目;电影《泰坦尼克号》的拍摄严重超支超时,
早期被批评家认为2亿美金打了水漂,但是最后却成为全球第一部超过10亿票房收入的电影,毫无疑问这是一个经典的成功项目。过程式管理强调计划、控制,而审慎详尽的计划往往耗时费力,又难免遇到范围信息输入较少这样的尴尬境界,因而如果项目经理死守一份僵化的计划,为了维护“项目三角”关系,
有意无意地利用事先设置的种种流程环节以拖延、回避、拒绝合理的范围变更,所导致的严重后果势必是交付给客户一个不符合期待、不能创造价值的平庸软件产品,甚至可能成为客户日常作业的“累赘”,或者是“食之无味”的“鸡肋”。应该找到一种管理方法,使得项目既能满足客户的要求,
又能为客户带来真正的价值,并且使客户方与开发方实现一种“双赢”的合作方式,很显然单独依靠过程管理难以做到这点。最后来看管理的本质。无论软件是如何一种特殊的制品,其管理仍是通常意义“管理”中的一种,它的管理目标、管理方法应该与通常意义的“管理”一致。
对于“管理是什么”这样一个深奥的本体论话题,诞生了百年的管理学界仍无法形成统一的看法,尽管如此,对于管理包含什么,具备什么职能,实现什么目标还是比较明确。管理存在于人类社会,自从出现了群体以及发生了共同劳动,就出现了管理,管理将独立分散的生产要素结合起来,
以完成特定群体即组织的共同目标,并且在实现这个共同目标的过程中,管理可以并且必须充分发挥各个组织以及成员的潜能。软件开发说其特殊,是因为其主要的“生产要素”是人,不像一个生产流水线,软件生产甚至不需要提供一个固定的生产空间—厂房,软件生产可以是分布在地球任何角落的一个或者多个个体———程序员或者开发组织;
也不需要强制规定工作时间,因为有些开发人员的晚上工作效率往往高于白天;软件生产的产出并不是线性的,当遇到技术难题的时候,开发人员会被搁置在难点攻关上而不产生任何可见的成果,比如一行代码,如果在思维活跃的时候,开发人员又可能会变得异常高效,
他可以在几天当中完成原计划需要半个月甚至更长时间的任务。“软件产品开发主要基于人”这样一个最大的生产特性被过程式管理所忽略,因为过程式管理的一个出发点和作用是防范整个过程体系中有个别人能力不足或者由于人员流失而给组织带来损失,防范由于人的自由性使事情偏离预想轨道,
因此通过在一系列过程中安排检查点及时进行纠偏,并且设置层级的组织结构对此进行制约。过程式管理在生产型组织中做得非常成功,但在软件项目开发中并没有预期的理想,因此软件开发应该需要这么一个管理体系,它能够发挥人的主观能动性,激发团队合作潜能,
实现客户提出的有价值的业务“思维”,开发出软件这样一种“纯思想”的制品,最终提供客户价值。这个更能适合软件项目开发的管理体系需要引入的是“敏捷”。

[1]   [2]