第一種是產品規劃人員。產品規劃人員主要任務是調查，包括調查你的競爭對手，客戶，以及其他市場需求。產品規劃的過程是定義產品的過程。他們通常會做很多研究，通過跟蹤市場用戶，做市場調查，看行業的報告，從而確定產品三到五年的發展規劃。其實作爲產品規劃人員最重要的一點，就是要有前瞻性。不僅僅是能看到現在市場是什麼樣的，而更要能看到三到五年以後會是什麼樣的。我們可以看到微軟好多產品，都有一種說法叫”version 3.0”，可能在1.0, 2.0時不是很好，有可能是功能的問題,也有可能是超前於市場的緣故，像Windows，做出來時候,無論從硬件或者軟件應用程序來看,都沒有市場，但是通過不斷的改進,到3.0時就取得了很大的成功。從這一點看,產品規劃人員是非常重要的。
第二類人是產品管理人員。某種程度上有點類似於做傳統的市場人員，但是也不是完全相同。他們主要任務是把產品推向市場。包括決定產品的定位、包裝。最重要一點是向用戶傳達一個什麼信息。也就是用戶爲什麼買你的產品，或者升級到你的產品。很多人說微軟的產品除了質量好外，市場也做得好。象IE就是一個很好市場運作的例子。比如，IE最初的用戶定位,不是試圖讓Netscape已有的用戶轉到IE上，從來沒有這麼做過.而是面向新的Internet用戶。這就是用戶定位很清楚。此外，對IE不同版本，開發側重點不一樣，就需要用一條簡單的信息告訴用戶，這個版本比其他版本有什麼好處。這些都是產品管理人員要做的。
下一個角色是程序管理，我們以前叫項目管理，但是上次我在上海講的時候，學員說，他們說國內項目經理做的事情很不一樣，所以這裏我就叫程序管理。有時候我可能會交換着用。
在微軟，程序管理主要是做產品，在適當的時候推出適當的產品。他碰到的最主要困難就是如何保持控制。適當時候意味着你必須控制好產品的發佈日程，不能有延誤。大家知道產品過程中不確定的就是人爲因素，這個發佈日期控制好，這是很困難的。還有要做出正確的取捨。有些時候你會在發佈日期和新的特性之間需要做出取捨，或者是不是採取新的技術，用新的工具、算法什麼是不是必要，我們是不是需要去做，做什麼和不做什麼之間，做出取捨，從而控制產品的特性並使其能滿足市場需求。程序管理人員需要衡量做這些事情的危險性，需要衡量得特別清楚。
這三類人員把整個產品的策劃，推向市場，以及產品開發過程控制基本上定下來了，可以是說最關鍵的。
剩下的有產品設計，主要是做產品的用戶界面或者可視化方面的設計。這些人一般人都有設計方面的背景。象微軟的產品，以前對用戶界面設計或者用戶交互方面側重不是很多，因爲傳統PC，早期只是專業人員的工具。但現在越來越向消費者、初用者方向發展，那麼對於界面設計要求越來越高。公司在這方面投入了很大的人力。我不知道大家都看到新的Windows XP、或者像“MSN explorer”沒有，這些產品和傳統的產品相比，外觀，包括用戶使用方式。都是完全不一樣的，更注重的是一種整體的體驗，經歷。
產品設計還有一個重要的工作，就是保證產品所有可視部分保持一致。不同的模塊或者不同的特性可能由不同的人員開發，如何保證可視部分看起來一樣，使用戶不至於在一個產品使用時突然覺得不是同一個公司的產品，這就取決於產品設計人員。
第五種人員是產品可用性評估工程師，他們主要做的是保證產品可用，易用，而且能夠容易被用戶接受。一般在產品開發的過程中或者初期，都有一些不同的原型，就是針對一些特性怎麼做，用戶怎麼交互，設計一些不同的原型，然後交由可用性評估工程師做可用性測試。從而決定最終的方案。這方面微軟一直是非常重視的。你可能注意到在IE早期版本里，地址欄裏面並沒有“Go“按鈕，只是有一個地址欄。但是後來通過可用性測試，發現一些用戶把地址敲進去後，就在那兒等着，也不知道按回車。確實就有這樣的人。所以從5.0開始在地址蘭後加了個按鈕。用戶敲完地址以後,可以試着按一下按鈕,來連到他所需要的網頁。
下一類就是開發人員。開發人員在微軟應該是很重要的，但是我感覺相比之下,沒有象在我們國內一些企業那麼重要。開發人員主要工作,一部分是設計一些算法，對PM做出的文檔或者特性說明要提出自己的反饋。還有更重要的一塊，就是幫助PM推出產品日程，從什麼時候可以做到“beta”1、2，什麼時候可以發佈。這些跟開發人員密切相關，所以又開發人員決定它的進度。除此之外，就是通常的寫代碼，編程與調試，以及後期的缺陷修復。
下一部分是測試人員。微軟對測試非常重視。測試人員在產品開發過程中要獨立完成。就是不受其他人員的影響，獨立完成測試。另外某些情況下，要作爲用戶的代言人，把用戶的利益放在首位。如果你認爲這個產品這樣發出去不行，就一定要堅持。當然這樣往往就引起有一些激烈的爭論，決定問題到底是要不要解決。但最終的結果是使用戶受益。
再下一類就是微軟特有的本地化人員。這一點我想對大家目前可能不是很適用。但我們將來怎麼把我們的產品推向世界，有一個全球化的過程，也有通過本地化來滿足其它中國以外其它市場的要求的過程，所以將來肯定會有這方面的需求。
還有一類人員是文檔發佈，這裏麪包括網站方面的文檔，軟件裏邊的文檔，這些文檔主要是幫助用戶怎麼使用產品。還有面向開發人員的，做一些代碼示例，這是文檔發佈主要的工作。我們傳統談到的開發文檔在微軟是PM來完成的，就是所有的程序經理在項目開始針對每個特性寫非常詳盡特性說明。
還有一類人員是文檔發佈，這裏麪包括網站方面的文檔，軟件裏邊的文檔，這些文檔主要是幫助用戶怎麼使用產品。還有面向開發人員的，做一些代碼示例，這是文檔發佈主要的工作。我們傳統談到的開發文檔在微軟是PM來完成的，就是所有的程序經理在項目開始針對每個特性寫非常詳盡特性說明。
還有一類人是產品支持人員。這在微軟也是非常重要的，一方面微軟跟最終用戶打交道最常見的一個途徑，往往有很多用戶打電話提出這個問題，將來在下一個版本會把它解決掉。還有最重要的在微軟來說，用戶每打進一個電話都是要花錢的，實際上產品支持直接影響到公司的營業額。提供更快速更有效的用戶支持，是最重要的一個環節。
最後一個角色是運營管理，實際就是網站運營管理。大家也知道，微軟產品目前越來越多和Internet緊密集成，象我們現在做的“Hotmail”、”MSN Calendar”等產品，本身就是一個網站。運營管理角色原來是沒有的，這只是近兩三年來新發展出來的角色，在將來會越來越重要。因爲你跟傳統的做所謂包裝的產品不一樣。以前你可以說我把CD做完了，產品發佈了，就沒事了。因爲用戶買了產品，你已經賺錢了。實際在做連機在線服務的時候，你軟件發佈僅僅是一個開始，用戶只要使用一天你都需要花錢，都會影響你整個的贏利。實際上在線管理是非常複雜的，比如“Hotmail”，現在有一億一千多萬用戶。在前端大概有五千多個服務器運行着Windows 2000，來滿足用戶登錄。後臺還有許多服務器負責郵件的收發，存儲，是很複雜的一個系統，因爲有底層的網絡，有硬件，還有操作系統，還有上面的你的應用程序，再加上Internet本身又是不確定的環境。怎麼把這複雜的系統管理好，是很具有挑戰性的。因爲跟傳統的應用程序是不一樣，用戶隨時可以走開。而且還有很多不確定性，象我們傳統的產品，用戶買得越多，我賺的錢越多。但是在連機的時候，用戶多有時候也可能是一個問題，就是你可能支持不了那麼多用戶。比如一下有很多人來訪問，你的網站是不是能滿足這麼多用戶訪問的需求。網站運行還往往需要提前對流量，或者對用戶數滿意做出比較精確的預測。運營管理在微軟會越來越重要，而同時產品的很多設計會影響到你到底能不能好好運行。所以這對其他人員也提出了新的要求。
目前基本上來說，運行管理、產品規劃、產品管理和程序管理這四類人實際上在主要推動產品的進程。其他人扮演的是一個被動的，或者專注於做具體事情的角色。但是每一個角色，都是不可或缺的。
前面我們講了微軟現在基本上有十一個工種。怎麼把這些人組織起來，能夠更有效地去投入到開發過程中呢？微軟目前基本上是一種所謂的條塊結構。在公司內部最基本的組織是一個產品單元，比如像IE就是一個產品單元組。產品單元組的管理者會有預算，有人有錢。在每個產品單元內，在行政上按你的工作類型來劃分，像項目經理，他上面會有一個總的項目經理組長，如開發人員有一個開發組長，測試人員也同樣。這是在行政上的組織。行政組織結構主要是爲了對你的業績做出一些考覈，包括將來會不會給你加工資。在做產品的時候，在每個產品單元組內，又按不同的特性劃分爲各個不同的項目組，劃分的基本原則是希望由一個很精幹很小型的團隊來進行開發。因爲我說了要按產品的不同特性來劃分組織，這樣就要求你在產品設計時，大的產品能分成小的模塊和小的特性，然後相互之間又沒有很大的依從關係。因爲跨組的交互或者跨組的依從關係是最難管理的。每一個團隊內基本上由項目經理，或者程序經理來領導，來負責一個特性，下面會有開發人員，也會有測試人員，基本上開發人員和測試人員的比例一般都是一比一，這樣一個組差不多十個人，是最基本的開發單元。一些跟技術有關的決定基本上是項目經理做出來的，不會有上面的人左右你的決定。這種組織結構能夠使在一些商務和技術方面很快做一些決定，同時因爲每個組人少，就能使大的團隊能像小的團隊這樣很快向前移動，效率不會受到影響。
舉一下IE產品組爲例。它在不同時期有不同的人員，人數也是不同的。最早IE1.0是幾個人，IE2.0可能是三四十個人，到IE4的時候基本上就到了300人的項目組。在300人的項目組裏面是這樣的組成，一個是產品單元經理，這因爲是以產品單元爲最基本單位，所以產品單元經理是大老闆。下面有五個產品規劃人員，產品經理有二十個，項目經理五十個，開發人員一百個，測試人員也有一百個，還有文檔發佈，因爲IE也有一些SDK，也有一些聯機的網頁和幫助文件。文檔人員有十個人。這種人員結構也是根據產品的特性，或者你在這個版本中間你的側重點來決定的。同樣在IE產品組。在IE5.5的時候，也有300多個人，但這時候項目經理就只有15個人，比IE4五十個人要少好多，開發人員也只有40個人，因爲到IE5.5的時候，基本上大的特性已穩定的，IE5.5面向最終用戶方面做的工作要少一些，主要在穩定性和性能方面做提高，另外對一些公司大企業的用戶做一些支持，所以開發人員和項目經理數目減少了，但是測試人員很多，測試人員有200人，這主要是在IE4的時候覺得少，所以在IE5的時候就組織獨立的測試隊伍進行測試。
IE產業組分爲十個項目組，每個組大概有十到五十個人，基本上負責一個產品模塊，像瀏覽，或者HTML的編輯、打印。但是有一些時間一個項目經理會負責不止一個特性，甚至有一些開發人員可能他在某些方面有專長，他也需要在不同組織之間流動，所以這種組織實際上是一個動態的。
下面我們談一下微軟產品開發過程。開發過程劃分的基本原則是，希望把大的項目分爲若干個里程碑式的開發週期，並在各個週期都要考慮一些冗餘，使你的開發週期變得更實際一些。通過目標描述來保證所有的人是沿着同一個方向發展。利用產品特性描述來指導開發過程。同時利用用戶的數據來決定一些特性的取捨，或者優先級的排定。加不加這個特性，不是開發人員覺得好，我就做這個東西，往往還是從用戶角度來考慮，用戶從中間有多大收益來決定。
還有更重要一點就是統一的術語。在微軟內部剛進去時也會做類似這樣的培訓，會請的各種角色做一個講座，大概需要六七個小時。其中有對很多術語、縮寫，還有對這套開發模式的介紹。從而保證所有人理解的都是統一的。這樣你才能保證無論在做事或者討論的時候，大家的理解是一樣的。
還有一點是在開發產品過程中不間斷地測試，而不是做完了到某一個階段纔開始測試，因爲往往那個那時候往往已經太晚了。
微軟產品開發過程分爲四個階段，第一個階段是規劃階段，這個階段基本上是由產品規劃人員以及項目經理來驅動的，這個階段主要是要完成這樣一些事情：一個是目標描述。基於這個產品目標，我們已經知道了，我們需要做哪些事，做哪些特性來達到這個目標，這樣就決定了產品提供哪些的功能。然後PM就要根據這個功能來寫出相應的規範說明。一般產品規格說明，就是傳統上說得技術文檔，基本會寫兩次，第一次寫一個簡單的，裏面列出了你這個功能或者你的特性希望達到什麼要求，跟我們整個產品的目標有哪些相關的，產品之間依從性，爲什麼要做這個特性。寫完這一頁的特性描述之後，大家會坐在一起看一看，排定一個優先級別，哪些事我們先做，哪些有可能做，或者哪些是下一版本在做。把這個事情做完了，程序經理會寫一個更詳盡的特性說明，這是指導開發、測試整個過程的技術文檔。基本上一般都有一些模板。
在規劃階段，當所有的特性規格說明完了以後，還要制定日程進度表。這個日程進度表往往需要由開發人員的參與。看到了這些產品規範，根據你的經驗估計做這個需要多長時間，還需要打入一些冗餘，把這個做完之後，產品規劃階段就已經完成了。
產品階段完成的標誌，就是目標描述，所有特性規格說明，以及日程進度表的完成。這樣就進入第二個階段，即開發階段。因爲我們自己有特性描述，已經知道做什麼。所以根據這些特性，會把這一階段，分爲三到四個小的階段。基本的劃分原則是重要的或者相互依從的特性開始做，剩下的一些次重要的。會在第二或三間段做。這一間段是由開發人員去推動。所有的開發人員開始寫代碼，對於每一個開發人員都有相應的測試人員，會把開發人員寫的代碼拿去測試。這個階段完成的標誌是所謂的特性完成，或者叫代碼完成，也就是所有的這種特性都已經開發完畢。這時就進入了下一個階段，測試階段。測試階段主要由測試人員推動。在開發階段也有測試在進行，但在測試階段進行的主要是集成的測試，象安裝，兼容性測試，性能，或者其他方面的測試。此外通常還要發放一些“beta”版本，讓用戶去實際使用併發回反饋。這一階段會有更多的“bug”進來，但是這一階段基本上不會增加一些新的特性。這一階段結束的標誌是所謂的“零缺陷”。微軟有一些來跟蹤缺陷或者叫“bug”的工具，如果從這些工具看到針對這個發佈週期已經沒有任何活動的bug，這就標誌着穩定化階段已經結束。現在有一個趨勢，就是穩定化階段做得越來越長，從而更好的保證產品的質量。
到了零缺陷後，就進入了下一步的發佈階段。在這一階段大家會繼續跟蹤bug的狀態，直到確認這可以發佈了。一般會做一個CD，或者把它發到網上。最後發佈階段會由產品經理、項目經理，以及做運營管理的人來共同執行。
總結一下，微軟產品組有明確的分工及不同的角色，產品開發由四個階段組成，即規劃階段，開發階段，測試和穩定化階段以及最後的發佈階段。總的原則在微軟一個是有詳細的分工和職責的劃分，通過各個人人的角色控制產品開發過程。我剛纔談的四個過程，十一個角色，但是每個角色實際上並不是同步的。比如像產品規劃人員，在第一個階段和第二個階段產品規劃人員會有一些工作，到第三個階段因爲特性已經完成了，不會有新的特性，產品規劃人員已經開始做下個版本。但是產品經理會繼續做這個產品保證這個產品繼續進行。還有是客戶需求決定產品的方向和目標，往往在做一些決定時考慮的是客戶和市場，很少純粹爲了技術和其他原因。最重要的是把大的項目分成若干個子項目，是漸進的，不是一次性把很大的問題解決。還有目標描述和產品特性說明，就是我們傳統文檔，這是爲整個項目起到了指導作用，必須定義得很清晰，使所有人都能看到它。最後一點，從項目一開始開始讓所有人都去介入。因爲好的產品是設計出來的，不是最後開發出來的，因爲前期基本上定下來以後，開發的後期是完成的階段。如果設計有缺陷，比如沒有考慮到技術支持方面的問題，後期很難做。假使再加進去對產品質量或者發佈日期都有很大的影響。還有就是通過不間斷的測試來保證產品的質量。
（微軟研發中心楊永生談微軟產品開發）