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之成?。ㄉ希?/strong>