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