《软件项目管理案例分析-winword之成败》由会员分享,可在线阅读,更多相关《软件项目管理案例分析-winword之成败(8页珍藏版)》请在金锄头文库上搜索。
1、案例分析微软公司办公商务单位WinWord之成败 微软公司的 OPus(微软 Windows字处理开发项目的代码名称)项目在历经了五年多的开发艰辛之后,终于在1989年11月 30日上市了。尽管产品的最终上市时间与原定计划相距甚远,但 Word for Windows(内部称为 WinWord)仍然获得了关键性的好评。这是微软首个在颇有影响的计算机周刊“InfoWorld”的评比中排名高于它的对手 WordPerfect的字处理软件,销量超过了微软预期目标。 随着 Opus项目的完成,WinWord开发之成败也引起了承担这次重大开发任务的微软公司办公商务单位的总经理 Jeff Raikes的思
2、考,究竟如何才能改进软件开发过程,提高公司项目管理的效率?公司的后继项目又应做怎样的选择?一、微软的组织 1990年,微软分成了两个部:应用软件部和系统部(负责程序语言与操作系统)。应用软件部的负责人是 Mike Maples,他直接向主席兼首席运营官 Jon Shirley报告。在 Maples以下还有六个部门:应用软件战略部及 5个经营单位,应用软件战略部由4个下属部门组成,它为所有的经营单位提供中心资源,这些资源涵盖了从编程工具、通用子程序到一间用户界面实验室(测试员们学习与使用软件的过程在此被观察与记录下来)。 所有经营单位的组织都是相似的,每个经营单位都专注于一个特定的应用领域,其中
3、办公商务部门是负责开发与营销所有微软高端字处理软件(PCWord,MacWord,Word for Windows)的,Jeff Raikes是该部门的总经理。在Raikes之下的部门是按职能结构组织的,质保部门对软件存在的错误进行测试,用户培训部负责编写文档,Chris Mason领导的开发部门则负责开发软件,产品营销与程序管理也有各自的负责部门。其他的经营单位负责别的一些应用软件(如电子表格和数据库)。 经营单位这种组织形式成立于1988年8月,以协助应用软件部的发展。在1988年以前,整个应用软件部是以职能为基础组织起来的。在这样的组织形式下,每一部门只有一个下属部门而不是几个部门对应一
4、个经营单位。Raikes是这样阐述这种变化的:“在微软,我们需要经历一个组织结构不断变化的过程这让我们保持着一种子公司的感觉,并能专注于团队合作。” 微软的开发小组通常只有12人左右,他们通常负责一个主要的开发项目,并且负责编写代码。微软的经理们为他们的小型工作小组感到自豪,因为其他主要的竞争对手经常会使用超过百人的大组来完成主要的开发工作。微软开发每行代码的成本明显要比行业的平均水平低。 Bill Gates会主动地投入到每个主要的开发项目中。他定期参加设计会议,检测设计规格和项目日程,并且阅读许多周期性的状况报告。虽然微软的许多员工时有受到他严厉的批评,但是对他技术上的专业知识和对计算机工
5、业发展的预测能力都有很深的敬意。二、Word for windows的开发 微软在 1983年末发行了它的第一个PC机的高端字处理软件PC Word。该产品受到了不甚热烈的反应,以微软的标准来衡量,它的销量一般。1984年9月,Gates决定开发一个新的革命性的字处理软件。新产品将运行于Windows操作系统(当时还在开发中)上,并将显示一些绝对创新的特征,以使微软成为PC字处理领域的领袖。 Gates分配了三个“老手”John Hunt,Andrew Hermann和 Lee Authurs,来负责这个被命名为 Cashmere的项目。其中 John Hunt为项目主管,他曾单枪匹马编写 P
6、C Word的第一版;拥有心理学博士学位的 Arthurs负责用户界面和文档,Hermann被认为了解整个字处理软件业务、他曾在王氏电脑公司工作过。 在向Cashmere 小组布置任务时,Gates提出他们要“开发出自古以来最好的字处理软件”,并且要尽快完成项目最好在一年内,因此,项目计划于1985年10月前完成。 令人遗憾的是,第一年,Cashmere项目几乎没有任何进展。Hunt和Hermann与Arthurs一起确定了软件所应包含的特征,并起用了一批软件开发者来制作软件原型。他们最初的想法是要在最低程度上集成一致的用户界面和数据结构,换句话说,他们计划把程序和数据结构化,以使它能无缝地集
7、成到其他如电子表格和数据库等应用程序中。新产品将不仅能与其他应用程序接口,而且还将包含这些应用程序的共同特征。所包含的具体特征有收发电子邮件、文档保护、建立邮件列表和初步的电子制表能力。 直到1986年初,离计划发行日期还有近一年时间,Gates开始向Hunt施加压力,要求他提供一些看得到的成果。最终,由于这个压力过大,Hunt无法忍受而于1986年7月离开了这个项目。 为了改进项目的实施状况,Gates决定运用当时还在规划形成中的程序管理模式。在程序管理模式中,一些人分享了新产品开发的领导权:其中有来自开发部门的项目主管和技术主管、来自程序管理部门的程序主管、来自市场部门的产品主管、来自用户
8、教育部门的在线主管和出版主管、来自国际化分部的地区化主管。这些人作为一个小组一起工作,没人有至高无上的权威。项目主管负责监督、管理产品开发事务,包括分配编程任务、作计划表和协调开发事务;技术主管作出最终的技术决策、代码检查和编程标准;产品主管分析各个市场要点,如竞争分析、定位、包装和广告;程序主管的工作是集成和协调项目中每个人的工作,他同时也直接对产品的规格和概念负责;在线主管和出版主管负责用户教育功能,地区化主管监督、管理各种各样国际市场的面向用户的问题。 于是,又有三个微软“老手”被调了过来:Dong Kurtz,PC Word的开发主管,他在Cashmere项目中担任同样的角色;Lars
9、 Dormitzer,一个颇受赞誉的开发者,被任命为技术主管;Greg Slyngstad成为程序主管。Jeff Sanderson作为一个新的营销主管也被调过来。 所有新成员都认为这个项目仍须很长时间,尽管Hunt已写了一堆纸来描述他所想要的特征,但究竟这个产品应是怎样的仍缺乏可理解的具体陈述。他们最终抛弃了所有已做出的东西,而从Macintosh使用的字处理编码开始。这样一来,相对原始计划表,他们从第一天开始就已落后了一年。 项目被重新命名为Opus,一个新的开发者队伍形成了。这个队伍的成员几乎都是新雇来的,缺乏软件开发经验,其中只有少部分曾参与过微软的其他项目。 1986年下半年和198
10、7年上半年中,项目小组大量的精力用于制定新的产品计划书。随着时间流逝,为了展示可见成果,项目小组感到压力越来越大,项目计划进度一直拖延到了1988年,而压力也已增长到了令人难以忍受的程度。Sean McDermott,当时 Opus的软件开发工程师回忆这个阶段时说道: 我们承受着很大的进度压力,一些主管似乎把项目进度当成他们和开发人员之间的合同。更有甚者,当开发人员提出了新的进度计划时,管理层要仔细询问每一项估计。 高层管理人员继续施压。在1988年3月初的一个会议上,一个经理发表意见认为Opus队伍是应用开发部中最差劲的。办公商务单位的开发主管Chris Mason回忆当时的情景时说道: O
11、pus进入了一种可以称之为“无限缺陷”的模式中。当你对开发人员施加很大的进度压力时,他们倾向于只做一个特征所必须的最小的工作量。当该特征运行良好时,他们就认为已经完成该特征的开发,该项特征就被从计划表上划掉了。如果数月后出现了不可避免的错误,他们并不认为是与此项特征有关的。更糟的是,当错误被发现时,开发人员已记不起那段编码,因此需要更长的时间来修理。这些问题并不是微软所特有的,几乎业内所有企业都面临这个问题。 在1988年4月,Dormitzer不得不请病假。只有不到2年经验的McDermott被任命为技术主管。McDermott也是一个杰出的技术专家,虽然McDermott相对较年轻且对这项
12、职位没有经验,但难以找到一个经验更丰富且对程序有很详细了解的人。2个月后,Kurtz由于厌倦了持续的压力,向公司告假。身体恢复了一些的Dormitzer重新回来担任开发主管。 在接下来的几个月中,Opus有了进展。所有需要的特征都已编码(尽管尚未除错),开发小组宣告“编码完成”的里程碑已在1988年10月达到了。编码完成意味着剩下需要做的就是除错和优化编码以提高性能。这段时间被称作“稳定期”,并且一旦编码稳定(所有知道的错误已修正且性能足够好),产品就可以发行了。关于时间进度,公司根据经验把稳定期定为3个月。 然而,Opus项目似乎并不服从这个三个月定律。尽管开发人员在快速地修正错误,但测试者
13、似乎正以同样的速度发现新错误。在这期间,Dormitzer尽了全力来领导这个项目,但他的病情尚未痊愈。最终,Mason作出了反应,任命McDermott兼任开发主管。那时,McDermott在微软已工作了三年。 McDermott回忆稳定期时说道: 身为技术主管却不可以专心于技术问题,如果仅仅作为技术主管而不去担任18个月的开发主管或者说是代替那些病了或累坏了的开发主管们,Opus的程序在大小、速度和内存的使用方面可以制定得更好。在这阶段,我们的队伍中有15个开发人员,6个程序员助手和7个实习生,一个主管是不可能跟踪监督每一个人。 尽管有这么多麻烦,Opus程序开始稳定了。1989年春天,可捕
14、捉的错误的数量仍相对稳定。但是,1989年夏天,公司制定了一项规定,首次强调修改的质量而不是修改的数量,于是第一次,测试部被邀请来开发部门对编码进行检查。1989年深秋,程序稳定了,并且 Word for Windows 1.0版在 1989年 11月 30日发行。三、Word for Windows的市场反应 尽管WinWord开发延迟了很长时间,但当时只有另外一家公司一Samna,有能力早一步发行了一个功能全面的Windows下的字处理软件。尽管要精确度量顾客的反应还太早,早期的迹象仍是十分令人鼓舞的。计算机杂志和期刊做出的评论全都是正面的,而这些评论对市场知觉有很大影响。WinWord被
15、描述为使用简单,而且第一版竟然令人难以置信的没有错误,许多杂志为WinWord的评分高于任何其他PC字处理软件。作为对WinWord成功 的反应,Word Perfect声明正在开发一个运行在Windows下的字处理软件。Word Perfect for Windows计划于 1991年 2月发行。 五、WinWord事后调查分析 尽管WinWord开发项目是一个极端的情况,但它所展现的问题在微软中却不是罕见。为了从以前的开发项目的失误中吸取教训,微软制定了一个政策:项目完成时对项目进行评价。评价需要收集有关项目的许多统计数据,同时,还要与项目参与者一起召开一系列会议来讨论他们对项目的看法。统计数据包括估计的和实际的项目进度,单位时间内的错误数量,单位时间内的编码数量,以及计划的里程碑和实际的完成日。这种统计数据和从参与者会议的讨论中得到的意见一起被收集在一个叫事后调查分析的文档中,接着,文档被分发给各经营小组经理和高层管理人员。大多数项目的事后调查分析文档有25页左右长度,但Opus文档长度竟然超过100页。我对Winword项目的成败分析首先我觉得winword是失败的。项目如果完成了既定目标,满足了项目三要素:时间进度、成本控制、质量要求,就可以认为项目是成功的。但有时候项目的成果被顾客接受就可以认为成功。比如在IT行业里,产品研发突破原定时间、成本要求的情况非常普遍