Product Developing Process in Microsoft

上圖中： QA是微軟大的產品部門下設的一個比較專業的測試部門（Quality Assurance Dept）

1.項目進度表中的緩沖時間（Padding Time）

微軟使用緩沖計劃，以在最高的效率與較好地對未來作預計之間求得平衡。這種應付突發事件的時間在開發和穩定化過程中是每一個主要里程碑的一部分。緩沖時間主要用于彌補由于對特性（Feature）的不完全理解，或者是技術困難或是由于疏忽而忘記把任務寫入進度，或者是未料到的難題而形成的漏洞。緩沖時間有助于一個項目適應意料之外的事件。

原則二：運用想象性描述和對特性的概要說明指導項目

為了給出足夠的開發框架以使工作能持續進行，并且能容納開發過程中出現的變化并保持足夠的靈活性，微軟采用想象性描述和概要的說明來指導項目開發，而不是在一開始就努力寫出一份完整和詳細的說明。所謂想象性描述是由程序經理和來自市場營銷組的產品計劃人員共同編寫的一份非常短的文件，在其中主要是定義產品開發的目標（不涉及產品的具體細節�。�。通常對一個全新的產品，想象性描述一般會相對較詳細，在其中還含有一份粗略的說明文件�？偟膩碚f，微軟對于想象性描述的要求是：

越短越好，盡量說明"產品不做什么"(而不是"產品要做什么"！)。

運用想象性描述，程序經理開始編寫功能說明文件，該文件解釋產品的特性是什么以及這些特性如何與其他特性及產品發生關系。最初它只是一個概要性的說明文件，隨著項目的進展，程序經理會隨時向其中添加更多的細節，最終的說明文件將變得象用戶手冊一樣。完整的說明不只起著對產品最新功能的描述作用，而且它還是在產品投產與發貨之前進行測試與評估的主要依據。
想象性描述有助于決定刪除哪些特性。
微軟內的各個開發組采用想象性描述幫助細化產品版本的規定主題，然后以此主題來決定是否需要增加產品各個可能的特性。通常不要輕易改變所確定的主題，否則可能造成產品開發上的混亂。

編寫說明文件
說明文件在產品小組的所有成員之間，產品小組之間以及產品小組與管理部門之間起著傳遞產品的設想與要求的作用。在說明文件中必須清楚地描述產品特性（描述每個特性如何工作，外觀如何以及從用戶的角度出發如何與用戶交互。如果特性有一個界面，還應包括一張示意圖，以顯示出界面的效果），并賦于其相應的優先級。程序經理據此建立起項目的開發進度表。此外在其中還應包括以下各項內容：用一句話表示的項目開發目的，關于產品是什么與不是什么的清單，對顧客的定義，對競爭產品的定義，產品對系統的要求（包括操作系統版本、最小內存要求、硬盤空間、處理器速度以及顯示器分辯率），對第三方（如打印機驅動程序、組件）的任何依賴性。程序經理負責協調并"寫下"說明

程序經理（Program Manager）應考慮以下問題：

這項特性的要點是什么？
用戶如何使用該特性？
這項特性有意義嗎？
該產品中或微軟的其他產品中有類似的特性嗎？
有哪些問題被遺漏了？
組內的交流令人滿意嗎？
最終程序經理通過與組內開發人員的共同討論決定有關特性的內容，并將其寫下來。

1.構造原型

構造原型是程序經理具體說明一件新產品或一個新版本的最好方法，這從許多方面來說都使開發前測試成為可能，尤其在可用性方面，并且有助于對與用戶交互情況作出好的理解，它也能使產品說明更緊湊。

微軟的開發人員通常采用VB構造用戶界面原型，但是對于構造計算機屏幕模型之類的工作，畫筆（Paint brush）也是一個很好用的工具。死板的說明變成有生命的文件，說明不應過于詳細以至限制了發明創造。在項目開發過程中，說明文件的早期版本會有相當大的增加與改變。由于說明的變動可能會導致相應開發工作的極大變動，所以微軟通常是將精力首先集中于那些沒有什么用戶界面的特性上，因為在完成開發前不必去了解用戶對它們有何反應，也就是說這些特性不大可能改變。然后再面對其它特性。但是當產品開發到一定程序后，例如40%之后，程序經理必須嚴格控制對特性的修改（主要是指增加新的特性），否則不光會造成開發延遲，而且會壓縮可用的測試時間。

原則三：根據用戶行為和有關用戶的資料確定產品特牲及其優先順序

對于一個開發項目而言，如何確定最終產品中應包含什么特性通常是比較困難的一件事。為此微軟采用了一個稱之為“基于行為制定計劃”的方式來進行特性選擇與優先級安排。

基于行為制定計劃法從對用戶行為，諸如寫信或做預算，做系統研究開始。然后，根據某一特性在支持重要的或者是經常的用戶行為上的程序對其進行評價。這樣做的優點是對特性取舍更具理性：討論對顧客想要做什么加以更好的安排，對某個給定特性是否方便了特定任務的更集中的辯論，可讀性更強的說明，以及在市場營銷、用戶教育和產品開發中更好地同步。

1.特性選擇和優先級安排中的基于行為制定計劃

基于行為制定計劃法中的關鍵點在于按用戶行為、產品特性以及行為和特性之間的內部聯系來分析產品。程序經理和產品計劃者把產品試圖支持的用戶任務或方案分成大約20個“行為”，然后他們努力把行為（以及任何子行為）映射入微軟的現行特性和競爭對手產品的特性中去。他們也把行為映射到不同的顧客形象或不同的市場部分中去。

當說明產品的新版本時，基于行為制定計劃法幫助程序經理和開發員集中他們的精力與創造力。象Excel之類的項目，爭取在每個新版本中加入的主要行為不超過四個。絕大多數特性直接映射入這些行為之中。該做法使項目可以按特性對用戶的價值來進行分級。通過分級，促使程序經理和開發人員都行動起來，使他們的特性支持盡可能多的行為。這種良性競爭對于用戶有益，同時也利于提高生產率。

2.為顧客行為而非產品特性準備資料

基于行為制定計劃進度，項目在計劃階段首先集中于行為，其次才是特性。程序經理和市場營銷人員并不去思考和排除他們喜愛的特性，再圍繞它們搞出想象性描述的草案。他們真正做的是列出一份顧客都做些什么的清單，然后把想象性描述集中于支持那些行為的特性上。

3.以行為為中心對產品進行全面考慮

由于基于行為制定計劃法是從整個產品的觀點著眼，因此有助于在不同職能上工作的項目成員理解產品做什么，以及其他產品的相應特性如何可能支持那些需要或不需要其他應用軟件產品的行為。

4.做市場營銷研究以支持基于行為制定計劃法

為支持基于行為制定計劃法，從市場營銷組來的產品經理與程序經理、開發人員一起開展一些聯合的研究，如指導對用戶的研究工作。然而，一般來說是產品經理做大多數的研究，并可使其更明確地影響微軟產品的演進。

原則四：建立模塊化的和水平式的設計結構，并使項目結構反映產品結構的特點

微軟產品設計中的一個關鍵概念是產品的基礎結構（Infrastructure），尤其是生命周期短的應用軟件，應隨項目的進展變得更加單一（而不是錯綜復雜）。當開發組構造產品的第一版時，他們更多地使用分級式結構，好為產品設計規定出一個最初的架構。隨著時間推移，他們向單一的結構邁進，以使項目能集中于特性開發。微軟越來越強調不同產品間的特性共享。共享有助于使不同產品的“性能與感覺”（Look and Feel）都統一協調起來；它也方便了需要不只一個應用軟件的用戶，減少了代碼的重復書寫，縮小了單獨一個應用軟件的規模。

微軟用特性小組組織產品開發，這種方法使得每個人都容易明白小組是如何與整個產品相關聯的。項目從規定概要說明開始。概要說明的形式是一份已確定了優先級安排的內容清單，涉及產品下一版本將要開發的相對獨立的特性，以便由分開的特性小組加以開發。

程序經理和開發員把項目分成特性子集，再將之分配給每個特性小組，讓他們在3到4個主要的內部項目里程碑中進行生產。這種產品組織與開發方法使微軟能靠簡單地增加開發員和創建一個大的小組來漸進地增加產品的功能。

5.把特性(與函數)作為開發單位

微軟軟件產品的特性是用戶最終可見的相對獨立的功能單位，就如建筑材料一般，對應用軟件產品更是如此。系統軟件產品，如NT或者95的特性，對最終用戶通常不直接可見。微軟和其他公司有時簡單地稱這些不直接可見的特性為“函數”。

程序經理承擔開發一組特性或函數，實現從說明經測試、文檔化直到最后完成的過程。他們必須與開發員合作，后者負責估計進度表與完善每個特性。開發員還要在一臺聯網開發計算機上存儲一到幾個文件，用以保存特性的程序源代碼。大多數特性的開發與改進只要一名開發員，而有的大型特性則要一個小的小組。

6.產品結構是決定其長期結構完整性的基石

產品結構是產品內部的基干，它規定了重要的結構構件以及這些構件如何組裝到一起。產品結構及用于組裝結構的構件，提供了實現產品特性（即做詳細設計與編碼）的支柱。產品的結構對最終用戶而言，通常并非直接可見。只有結構要實現的特性是可見的。產品結構也是決定產品長期結構完整性的基石。產品功能的任何改變都不應造成潛在的產品結構散架。

7.產品的層次結構

對于產品，也可以采用層次結構的方法加以分析。通常定義良好的層次結構有助于對產品特性進行靈活的增加、刪除與改進。此外良好的層次結構有助于產品在不同平臺上的移植。（例如Excel總共定義了五層，其中只有最底層的操作系統層是與平臺相關的，其它各層均是通過調用其下層所提供的API接口加以實現的，所以其移植極其方便。而在Windows 95中通過“虛擬機”的概念實現了對16位、32位以及DOS程序的支持。）

8.小的結構文檔：源代碼是唯一文件

除了API文檔，微軟不對其產品結構生成相應的文檔，雖然有時高級開發員可能會寫下高層結構。對復雜的特性，許多開發員在某些點記錄并復查特定于他們所負責的結構細節，但此工作是可選的，并不強制執行。除了源代碼文件與特性說明，為數不多的組為新程序員準務了描繪某層結構的文檔（主要的數據結構，如何工作等等）。但是這些文件并不時常更新，經理們也不要求項目組生成此類內部文檔。在有關的說明文件中，并不涉及實現問題。開發員應該知道如何去實現，或者能夠去學會。記錄的關于結構的文檔如此之少是因為“一個開發員的工作是編寫我們要賣的代碼，而不是花時間寫高水平的設計文件”，“設計文件不應與源代碼分離”。分割代碼與“保持事情的簡單”。

9.特性小組和作為"內容專家"的小組領導

特性小組一般由一個領導和3至8名開發人員組成，工作于相關的特性領域。小組的規模常常視小組領導的經驗和能力而定。特性小組領導向項目開發領導匯報并負責項目的全部開發工作；而項目開發領導則擁有對產品的更為全局性的觀點，從而最有可能發現不互相關聯的問題。在特性小組中的每個人均是此領域的“專家”，他們了解如何使用產品、了解競爭對手的產品、了解未來將向何處去。通常為便于交流，提高軟件的組織結構（軟件傾向于映射出構造它的組織的結構），應保持特性小組的小規模。

原則五：靠個人負責和固定項目資源實旋控制

對于軟件項目而言，精確估計產品的開發與交付進度是很困難的。對此微軟采取的方法是將進度安排和工作管理的責任推到最底層，即單個的開發人員和測試人員那兒去。這保證了每個人除了作為小組的一部分外，還負有個人的責任。單獨的開發人員設立他們自已的進度表，程序經理把單獨的進度表匯總起來，再加上緩沖時間，以制定出一個全面的項目進度表。頂層的總經理也固定人員與時間等基本資源，以確保項目集中并限制其努力與創造程序。

關鍵的目標，尤其對應用軟件，是指明產品的目標出品日并爭取盡可能長久地堅持它。程序經理和開發員從出品日回溯，規定中間的項目里程碑的日期。這個“固定的出品日法“的中心在開發員身上。以避免因為項目沒有固定的結束點，導致在最終無用的設計、再設計和測試的循環中消耗一年或更多的時間。

10. 開發人員做出他們自已的進度估計

“日期設定方法"。但是開發人員一般會做出較樂觀的估計，因此開發經理還需對他們所提供的日期進行調整并加上緩沖時間以避免因因信息不完全而出現的問題。微軟這種制定進度的方法的優點在于：它從人們那兒得到更多的合作，因為日期是自已定的，不是經理定的；進度總是富有進取性，因為開發人員不可避免地會低估他們真正需要的時間。

11. 對細致的任務的進度估計

微軟的第二個進度安排方法是：對要完成的任務做非常詳盡的考慮，在此基礎上請開發人員給出他們對“實現”的估計，以此力圖“促使”更加現實主義并避免過度低估。

通常微軟把任務細化到4小時（半天）到3天之間。對于準確進度的安排，微軟的經理是這樣認識的：“任何任務只要超過一星期，那人們就一定沒有充分地全盤考慮它。任何任務某人估計只用少于半天就可完成，則他對它考慮得太多了。他應該用更多的時間去編程，更少的時間來考慮”。對于類似類于Windows NT之類的操作系統而言，進度安排更加困難，對其一般以幾天或者半周為工作單位進行進度估計。

12. 安排開發人員與小組進度時的心理學

當項目變大時，微軟把員工分成小組。然后經理把進度的責任和所有權盡可能地分發下去，直到小組和個人；這使二者都產生了一種擁用工作的感覺。它還在小組中，個人中，尤其是小組領導中造成強烈的跟上其它同事預計進度的壓力，因為經理可能再平衡進度，從落后的小組或個人手中拿走工作。這樣，同事間的壓力使經理不需要太多的努力就可以對個人或單個小組的進程實施嚴格控制。

13."固定的"出品日(　RTM: Release To Manufacture)

為了把創造力約束在時間限制之中，微軟現在在新產品或者產品新版本開始前爭取固定出品日，至少是有出品日的內部目標。這給人們施加砍去特性和集中在一個項目上的壓力，逼迫他們去苦苦思考應將哪個新特性加入產品中。雖然最終產品的交付目標可能是由高級執行人員設定，但是開發人員與小組仍然設定他們自已的進度表。

微軟一般根據預先的時間進度的大致估計出一個RTM日期，然后向前回溯相應的各個Milestone日期，如RC、Beta、Tree Lock、UI Freeze、Feature Complete以及CC（Code Complete）等等各個Milestone的相應日期。制定出十分詳盡的產品研究開發時間進度表，產品開發組的各個成員以這個進度表為目標統一協調工作。微軟十分強調軟件開發過程中的Teamwork Spirits，這種理念貫穿在微軟各個產品開發的各個階段。這也是微軟得以成功的一個十分重要的原因。

小結：同步－穩定開發法

計劃階段
定義產品的想象性描述、說明與進度

· 想象性描述 產品和程序管理部門運用廣泛的顧客意見來確定和優化產品的特性。

· 說明文件 基于想象性描述，程序管理部門與開發組定義特性的功能，結構問題，以及各部分間的相關性。

· 制訂進度表與構造特性小組　其于說明文件，程序管理部門協調進度表，安排出特性小組，每個小組包括大約1名程序經理，3 - 8個開發員，3 - 8個測試員(以1:1比例與開發員平行工作。)

開發階段
用3 - 4個順序的子項目，每個產生一個里程碑式的產品發送，來完成特性的開發。程序經理協調開發過程。開發員設計、編碼、調試。測試員與開發員配對，不斷進行測試。

· 子項目1 前1/3的特性：最重要的特性與共享的構件。

· 子項目2中間1/3的特性。

· 子項目3最后1/3的特性：最不重要的特性。

　

穩定化階段
全面的內外部測試，最后的產品穩定化以及發貨。程序經理協調OEM與ISV，監督從顧客得到的信息反饋。開發員進行最后的調試與代碼穩定化。測試員發現并清除錯誤。

· 內部測試 公司內部對整個產品做詳盡的測試。

· 外部測試 公司外在的"β"測試點，象OEM，ISV以及最終用戶處對整個產品做詳盡的測試。

· 發貨準備 為批量生產準備發布最后的“金盤”（Golden Disk）與文檔，制作之前，還需要進行各種嚴格的檢查：如政治敏感性術語檢查、病毒檢查、文件相關性檢查等。