23个项目管理经典案例——微软公司办公商务单位——WindWord之成败(下)

　　PMP认证是项目管理专业人士资格认证，是一种国际级的高级人才管理认证。它的主要考试内容就是项目管理体系知识。关于23个项目管理经典案例——微软公司办公商务单位——WindWord之成败(下)，慧翔天地在这里给大家简单介绍一下。

　　为了改进项目的实施状况，Gates决定运用当时还在规划形成中的程序管理模式。在程序管理模式中，一些人分享了新产品开发的领导权：其中有来自开发部门的项目主管和技术主管、来自程序管理部门的程序主管、来自市场部门的产品主管、来自用户教育部门的在线主管和出版主管、来自国际化分部的地区化主管。这些人作为一个小组一起工作，没人有至高无上的权威。项目主管负责监督、管理产品开发事务，包括分配编程任务、作计划表和协调开发事务技术主管作出最终的技术决策、代码检查和编程标准；产品主管分析各个市场要点，如竞争分析、定位、包装和广告；程序主管的工作是集成和协调项目中每个人的工作，他同时也直接对产品的规格和概念负责；在线主管和出版主管负责用户教育功能，地区化主管监督、管理各种各样国际市场的面向用户的问题。

　　于是，又有三个微软老手”被调了过来：Dong Kurtz,PC Word的开发主管，他在Cashmere项目中担任同样的角色；Lars Dormitze r,一个颇受赞誉的开发者，被任命为技术主管；Greg Slyngstad成为程序主管。jeff Sanderson作为一个新的营销主管也被调过来。

　　所有新成员都认为这个项目仍须很长时间，尽管Hunt己写了一堆纸来描述他所想要的特征，但究竟这个产品应是怎样的仍缺乏可理解的具体陈述。他们最终抛弃了所有己做出的东西，而从Macintosh使用的字处理编码开始。这样一来，相对原始计划表，他们从第一天开始就已落后了一年。

　　项目被重新命名为Opus,一个新的开发者队伍形成了。这个队伍的成员几乎都是新雇来的，缺乏软件开发经验，其中只有少部分曾参与过微软的其他项目。

　　1986年下半年和1987年上半年中，项目小组大量的精力用于制定新的产品计划书。随着时间流逝，为了展示可见成果，项目小组感到压力越来越大，项目计划进度一直拖延到了1988年，而压力也已增长到了令人难以忍受的程度。Sean McDermott,当时Opus的软件开发工程师回忆这个阶段时说道：我们承受看很大的进度压力，一些主管似乎把项目进度当成他们和开发人员之间的合同。更有甚者，当开发人员提出了新的进度计划时，管理层要仔细询问每一项估计。

　　高层管理人员继续施压。在1988年3月初的一个会议上，一个经理发表意见认为Opus队伍是应用开发部中最差劲的。办公商务单位的开发主任Chris Mason回忆当时的情景时说道：

　　Opus进入了一种可以称之为“无限缺陷”的模式中。当你对开发人员施加很大的进度压力时，他们倾向于只做一个特征所必须的最小的工作盘。当该特征运行良好时，他们就认为已经完成该特征的开发，该项特征就被从计划表上划掉了。如果数月后出现了不可避免的错误，他们并不认为是与此项特征有关的。更糟的是，当错误被发现时，开发人员已记不起那段编码，因此需要更长的时间来修理。这些问题并不是微软所特有的，几乎业内所有企业都面临这个间题。

　　在1988年4月，Donnitzer不得不请病假。只有不到2年经验的McDermott被任命为技术主管。McDermott也是一个杰出的技术专家，虽然McDermott相对较年轻且对这项职位没有经验，但难以找到一个经验更丰富且对程序有很详细了解的人。2个月后，Kurtz由于厌倦了持续的压力，向公司告假。身体恢复了一些的Dormitzer重新回来担任开发主管。

　　在接下来的几个月中，Opus有了进展。所有需要的特征都已编码（尽管尚未除错，）开发小组宣告“编码完成”的里程碑已在1988年10月达到了。编码完成意味范剩下需要做的就是除错和优化编码以提高性能。这段时间被称作“稳定期“，并且一且编码稳定（所有知道的错误已修正且性能足够好），产品就可以发行了。关于时间进度，公司根据经验把稳定期定为3个月。

　　然而，Opus项目似乎并不服从这个三个月定律。尽管开发人员在快速地修正错误，但测试者似乎正以同样的速度发现新错误。在这期间，Dormitzer尽了全力来领导这个项目，但他的病情尚未痊愈。最终，Mason作出了反应，任命McDermott兼任开发主管。那时，McDermott在微软己工作了三年。

　　McDennOtt回忆稳定期时说道：身为技术主管却不可以专心于技术问题，如果仅仅作为技术主管而不去担任18个月的开发主管或者说是代替那些病了或累坏了的开发主管们，Opus的程序在大小、速度和内存的使用方面可以制定得更好。在这阶段，我们的队伍中有15个开发人员，6个程序员助手和7个实习生，一个主管是不可能跟踪监督每一个人。

　　尽管有这么多麻烦，Opus程序开始稳定了。1989年春天，可捕捉的错误的数量仍相对稳定。但是，1989年复天，公司制定了一项规定，首次强调修改的质量而不是修改的数量，于是第一次，测试部被邀请来开发部门对编码进行检查。1989年深秋，程序稳定了，并且Word for Windows 1.0版在1989年11月30日发行。

　　四、Word for Wndows的市场反应

　　尽管WinWord开发延迟了很长时间，但当时只有另外一家公司一Samna一有能力早一步发行了一个功能全面的Windows下的字处理软件。尽管要精确度量顾客的反应还太早，早期的迹象仍是十分令人鼓舞的。计算机杂志和期刊做出的评论全都是正面的，而这些评论对市场知觉有很大影响。WinWord被描述为使用简单，而且第一版竟然令人难以置信的没有错误，许多杂志为Winword的评分高于任何其他PC字处理软件。作为对Winword成功的反应，Word Perfect声明正在开发一个运行在Windows下的字处理软件。Word Perfect for Windows计划于1991年2月发行。

　　五、WinWord事后调查分析

　　尽管Winword开发项目是一个极端的情况，但它所展现的问题在微软中却不是罕见。为了从以前的开发项目的失误中吸取教训，微软制定了一个政策：项目完成时对项目进行评价。评价需要收集有关项目的许多统计数据，同时，还要与项目参与者一起召开一系列会议来讨论他们对项目的看法。统计数据包括估计的和实际的项目进度，单位时间内的错误数批，单位时间内的编码数量，以及计划的里程碑和实际的完成日。这种统计数据和从参与者会议的讨论中得到的意见一起被收集在一个叫事后调查分析的文档中，接着，文档被分发给各经营小组经理和高层管理人员。大多数项目的事后调查分析文档有25页左右长度，但Opus文档长度竟然超过100页。

　　六、下一版本Winword的选择

　　Opus项目完成以后，Raikes又面临Winword项目未来的选择：第一种选择包括尽可能快地引入一种全新的Winword版本(2.0)。这是微软在一般情况下所采取的战略。在许多情况下，仅当一种新软件的第二个版本发布时其销量才会真正上扬。因此，在选用新软件前，许多关键的客户都会等待着软件的改进。这样，Winword2.0将提前一年，或是在WordPerfect发布它要进入Windows市场之前发布。

　　第二种选择是将Winword2.0的发布延期，但在他的办公商务单位内大力推行产品开发过程的改进。他可以采取正规的结构化程序设计方法进行试验，并采取核心代码重新编写Word for DOS,Mac Word和Winword,以仅证80%的代码是通用代码，仅有一小部分是某部机器特有的。Raikes预计逆行这些改进将使Winword2.0的发布延误1~2年。也许最重要的是，这将增加大量的不确定性，因为这些方法对在微软公司来说是全新的尝试。

       >>23个项目管理经典案例——微软公司办公商务单位——WindWord之成败（上）