微軟的新產品開發

4.3 微軟的新產品開發 

        若要談到當世最具影響力的軟體產品企業，微軟（Microsoft）絕對是首屈一 指的大企業。只要是非麥金塔系統的個人電腦，大多數都是使用視窗（Windows）

的作業系統（2008 年十二月之市佔率為 89.62%；iThome，2009），而應用程式方 面，現今大家習慣傳遞的文件檔案格式，也大多是基於微軟所開發的 Office 系統 所制定而成的，這些再再都顯露了微軟在個人電腦軟體上霸主的姿態。 

        如此龐大的企業，其成功的產品是如何開發的，相信是大家所關心的；同時，

在產品相繼成功的保證下，其開發流程也是很值得討論的。以下將探討微軟在產 品開發的作法，並與在上章提出的模型進行比較。 

4.3.1   個案內容描述 

        在微軟的新產品開發中，首先被定義的就是「里程碑」和「目標遠景」的概 念。目標遠景是一個終極目的，但在訂定這樣一個遠景的時候，微軟內部並不對 如何達成這樣的目標作限制，也就是說，工程人員可以自由發揮他們的創意在產 品的構築上。但在發想上未加以限制的情況下，就需要其他的手段去確保過程的 進行是有品質、並且不致於失控的；所以，在這套新產品開發的流程中，就有「里 程碑」的設計，透過逐步的追蹤與要求，以力求產品在發展的過程裡，不會因為 過度的發想或因不對作法加以限制而產生無法控制，導致產品失敗或需要付出額 外資源成本的情況。也正因為具有「里程碑」的概念，所以對於產品的要求並不 是無上限的完美，而是在有限時間內，將事情做到最好的方針；這點是對於十分 有限的資源──時間，所做出的最重要控管。 

        此外，在一個專案開發中，因為複雜度的不同，可能會將一個產品劃分成幾 個部份，讓不同的工作小組去協力開發；在開發的工作中，該如何調配這些小組 之間的互動與資源的分配，將會直接的影響到工作的士氣，同時也間接的影響產 品開發的順利性。正因如此，在創造思考上相當開明的微軟，將工作小組的工作 地點限制在同一個地方、並且使用相同的工具來工作，這樣可以避免掉外見性的 資源分配不均；從另一個方面來說，在相同基礎上工作，對於小組間的溝通和交 流也是有利的。在工具的公平性之外，在產品開發中，微軟同時也十分強調整合 與溝通的重要性，除了上述提到的額外優點，各小組也被要求以 E‐mail 進行及時 性的溝通，一方面可以早期發現在開發中的問題，另一方面也可以隨時讓各小組 間得以配合其他小組的步調，以使開發的過程雖然分割成各種不同的部份，但仍 然保有一定程度的整體性。 

        在以上的流程控管中，十分重要的一點是，要使「管理架構隱形起來，讓人 覺得可以為所欲為。」。這樣的管控方針乍看之下十分瘋狂，但是有它設計的作 用：一方面是可以讓管理者清楚的看到各個員工的真面目，以便在組織的構成或 發展上，可以達到『適才適用』的管理目的；二方面則是要讓員工享受充份的自 由，除了前述的里程碑外，完全不做任何的限制，如此來鼓勵工作者的創意性，

而不會只有管理者或管理制度壓制下的一元產物。 

        當產品有了初步的成果後，在上市前的驗收是很重要的；而這個步驟就是「測 試」，也可以說是在上市前的最後一道把關程序──但在軟體開發中，測試意味 著除錯和改寫的重覆過程，雖然在流程上只是一道看起來與其他無異的程序，但

箇中的複雜度與要求程度，絕對是十分重要的。微軟過去曾基於分工專業化的考 量，將其測試的工作外包，交由 Arthur Andersen 進行；但最後的結果卻不甚理 想，經過重新的評估後，微軟決定仍然測試的步驟保留在自己內部。 

        微軟對於測試的重視性，從其人力的配置上就可以看得出來；微軟將 10%

左右的人力資源都放在這一塊上，如果這樣沒有辦法給一個清楚概念，那另一個 比較相信會更清楚：測試工程師的人數和軟體開發工程師的人數是相同的。微軟 之所以投入這麼多的人力在測試上，目的就是希望可以隨時驗證軟體開發的可行 性和穩定度。而在組織的架構上，也將測試部門獨立出來，除了在專業性的考量 外，同時也希望可以提升測試的效率，並使開發成果有獨立考核的空間；雖然測 試部門是獨立的，但其和軟體開發者之間仍十分強調朝同一目標合作的關係，測 試者需要儘快對於撰寫完成的程式單元進行測試，以免開發人員因時間過長而忘 記其內容。 

        在測試的著力點不僅僅只是在開發端上，同時也要關注與預測顧客端的反 應，所以，一個測試員除了要可以針對程式本身發展測試的模式、設定各種可能 的狀況以模擬軟體的實際使用情況外，對於業界的評論和顧客批評聲音也必需特 別加以重視。如此一來，才能夠有效的確保產品能被市場所接受，以達到測試的 真正目的。不過近年來，由於網路的發達，使得傳遞訊息甚至軟體本身都十分的 便利，微軟便把握住了這種便利性，將軟體測試的末端工作推展到一般的使用者 手上；諸如大家所熟悉的網路即時通訊軟體 MSN 就在大改版前總是先推出加註

「beta」的使用者測試版，甚至 Windows 作業系統也推出了 beta 和 RC 等測試版 本，再蒐集使用者的意見和實際發生的問題，據以做為正式版推出前的修改參 考。這使得測試人員的工作發生了本質上的改變，必須處理和過去──經由內部 測試制式而系統化──完全不同的改進訊息。 

        除了以上所述的各項工作外，還有另一個十分重要的工作，但卻十分容易被 忽略：程式管理。如果把程式開發人比擬做「明星」，那管理人相應上就應該類 似於「經紀人」。程式管理的工作成果雖然不能直接的在軟體中表現出來，但卻 可以說是無所不在。在開發之初，需要和開發人員緊密合作，制定出軟體的規格，

如同將框架定下來一般；在開發中則要能掌握進度，並且負起與非技術人員溝通 聯繫的責任；最終則要將整個開發過程忠實的紀錄下來，做為內部重要的技術資 料，以利於日後的改進和開發。 

4.3.2   微軟之實例與模式之比較 

        軟體的開發，從實務的操作上來看，有點像是製造業的產品開發概念；但從 軟體帶給使用者的反應上及後續需提供的服務（更新等）來看，軟體似乎又可以 被稱之為一種服務。而個人認為，綜整來看，目前微軟所提供的軟體，同時具有 服務和實體產品的兩種特性，而這兩種特性也將影響到它的開發流程製定。 

        本個案一開始先揭露了微軟的兩個在軟體開發時所著重的重點：「里程碑」

與「願景制訂」；這兩項對應到先前提出的模型中，分別是「資源計劃」和「概 念發展」這兩項。此外，讓各工作小組「在相同時間，使用相同設備工具進行程 式開發」的觀念，也是一種資源的計劃。而雖然這裡並沒有提及財務的部份，但 是探究軟體開發的本身，其實最重要的資源就是「時間」與「人力」；時間的掌 握上，微軟使用里程碑的概念，讓整個軟體開發可以在一開始就進入被框架化的 時間流程中，而人力的部份，一方面是隨著各工作小組需要的硬體資源，有調配 的動作，另一方面則是直接對於人事的管控。 

        在對於人事的管控上，將整個專案劃分成許多工作小組的做法，和「任務團 隊組成」的階段是相當的；但在這之外，微軟的個案中，也有很大一塊是在談如 何對員工進行管理的部份，這是和之前提出的模式有一點不同的部份。對於微軟 來說，是在整個時間及進度管控的大架構下，對於個人的自由，給予最大限度的 尊重；個人則認為，這不僅代表了此種開發的特殊性，也同時是一種公司文化的 表現。然爾企業文化卻不太能表現在開發的模式架構中，或者換句話說，它是較 開發流程還要高的層次，是在開發流程形塑時就已經混雜在其中的元素，個人認 為，雖然它很可能色彩鮮明，但卻不一定是一個放諸四海皆準的原則，需要由因 地制宜的角度去觀察。 

        另外，在管理方面，力求公開協調、使用 E‐mail 等方式，個人認為是對於「資 訊流通平台」的呼應。這一點並不在模型的各階段中，但它是被列為在整個開發 流程中，十分重要的要素；特別是像這種將一個 case 劃分成多個工作團隊的情 況下，溝通平台的建立就更顯得重要。值得一提的是，溝通平台原意是希望在組 成一個跨部門團隊後，可以再透過這樣的平台，讓團隊內、部門內、甚至團隊外 的各員工可以有效的溝通，使得組織更加具有彈性，而在微軟的個案當中，溝通 平台則是連接起了在同一專案內，各個不同的開發小組，以進行協調和合作，在 概念上是有些許的不同的。是故，個人認為，資訊平台的建立不應該過度窄化其 功能，不管是維持各工作小組間的溝通、或者是保持專案組織的彈性，都是該平

台的功能。 

        而程式撰寫的行動本身的重心就在「設計」，這個自不待言。但這裡值得玩 味的是「測試」的行動；微軟以各種方式（獨立測試團隊或使用者測試）來力求 測試的準確度，同時，也將設計與測試綁在一起，使之有良好的效率及表現。這

        而程式撰寫的行動本身的重心就在「設計」，這個自不待言。但這裡值得玩 味的是「測試」的行動；微軟以各種方式（獨立測試團隊或使用者測試）來力求 測試的準確度，同時，也將設計與測試綁在一起，使之有良好的效率及表現。這