微軟專案管理培訓筆記（一）

 就像一位講師所講的那樣，每個人去參加培訓都是帶著他自己的問題去的，因此我記錄的筆記大多是針對目前我面臨問題的。 微軟進行設計的一個好的方法：假如一個十二人的小組，全部拉到外面，比如三位成員一組分為四組，每組針對問題進行設計再發表自己的看法；然後兩兩合并相近的設計，再進行討論協調……直到最後大家同意通過。這樣既可以發揮群體智慧，又充分調動了開發人員的積極性，由於是大家協調的結果，也比較容易實施。 微軟的“三駕馬車”——program manager、developer、tester。developer負責開發，tester負責測試，program manager只管事不管人，對developer和tester沒有人事上的管理權，但是必須要推動整個項目流程。program manager分為兩類，一類基本是由developer轉換而來，常常負責設計，一類是process pm，類似傳統意義上的專案經理，推動整個項目流程。program manager產生設計文檔，developer根據文檔做開發，tester根據文檔做相應的測試，凡是和設計文檔不一致的地方都當作是bug，在developer和tester之間出現的衝突和矛盾由program manager負責仲裁協調。微軟流程設計的作用就是用法治來代替人治，微軟把這種團隊結構當成“三權分立”，專案經理是立法權，開發人員是執行權，測試人員是監督權，在開發流程的不同階段不同的人起著主導作用。 在項目進度制定的評估上，先是專案經理進行總體評估，估計出大概的時間；然後由負責各個具體部分的開發人員估計各自每個功能需要的開發時間，並詳細記錄；各個開發組長、測試組長評估組員的開發時間，並進行協調匯總；專案經理評估從各個組長收集的時間和功能進度，並制定出進度表，設定裡程碑。 微軟Team Dev的日常工作：開發人員上班第一件事是查看昨天Daily Build的結果，擔心由於自己代碼的check in而造成build broken。如果造成了build broken，則當天最緊急的任務就是修改代碼，使之能通過build，因為每天的工作都是建立在昨天的build版本上的。如果沒有出錯，則開發人員接著開啟bug管理工具，查看指定給自己的bug，解決高優先度的bug或新功能，在本機上build和單元測試，如果可以則請開發組同事做code review，再check in 代碼，在bug管理工具中修改bug狀態。開發人員以一封daily report結束一天的工作，包括修改了哪些bug或添加了哪些新功能，哪些問題沒有解決等等。測試人員上班第一件事情是開啟bug管理工具，看看指定給自己的bug，驗證已解決的bug。接著測試人員從發行伺服器上去的當天的build版本，根據測試案例檢查當天的build，並在bug管理工具中登記新發現的bug，等待開發人員解決。下班前測試人員會發送當天或者一周的bug報告和測試案例報告。專案經理的工作是主持bug專家會診，更新專案計劃、議程表、產品規格書、風險控制列表，發送status report等等。 根據微軟Team Dev的日常工作，目前我們做的不足的地方有：daily build、unit test、code review以及daily report。在code review上，微軟有三種方式，一種是peer to peer，互看代碼；一種是group review，比如一個團隊每個禮拜三下午抽出兩個小時，一起通過投影片等方式瀏覽，另一種是從其他團隊或請第三方公司來做code review。本來公司是有daily report的，不僅下班後需要提交一天的工作報告，原本我還規定上班後半個小時內需要提交一份當天的工作計劃（模板固定），可惜是沒有能夠堅持下去，不少開發人員認為這是浪費時間，如果對於計劃性很強的開發人員來說，這項工作的確是浪費時間，但是對於大部分計劃性不強的開發人員，先把當天的計劃寫下來，便於提醒他當天需要完成哪些任務，不至於A事還沒做完，又去做做B事，導致每樣事情都完成一點點，卻沒有一樣能夠拿出手來。一位講師一句話說的非常好，他說其實微軟也沒什麼，無非在一些細節和執行上做的非常好，我對這個觀點很贊同。其實上面的很多觀點我們都知道，但是細節上的處理和能否堅持下去就成了我們和微軟的區別。 

PMO是project manager office（program manager office？），它的三類職責是識別和培養專案經理、為專案經理提供支援、管理專案經理。這對於國內大部分中小企業來說還是一個奢侈的機構。這個機構的出現主要是為了針對這類情況：一個公司裡面同時進行了好多項目，某些專案經理有出色的技能，能夠讓項目順利進行，但是某些專案經理還缺乏一定的技能，不能保證項目的順利完成，因此就需要一個這樣的機構來為專案經理進行支援和管理，也能從公司內部發掘出適合做專案經理的人才。要注意的是PMO是為了增加價值而不是增加負擔，enough is enough，不要僅僅是為了一種形式而去做某樣事情。

怎樣才算一個好的專案經理？專案經理需要具體一系列的技能和應有的態度，技能是可以學的，但是態度很難教會。在優秀專案經理所具有的特徵中，促進發展的能力是一個很重要的能力，而我在這一點上還有欠缺。每位經理都可以讓事情開始，但是在碰到各種各樣的困難後，如何還能推動項目往前進，去克服困難，這個我還需要提高。

微軟在人員管理上是pay for performance，not pay for effect，這一點上我們公司的做法也是一致的。一些開發人員進公司後為了完成任務經常加班，看上去很努力很辛苦，可是事實上這是他應該做的，因為分配的任務如果給同層級其他人做肯定是工作時間內能解決的事情，由於自己能力方面的問題造成一些加班和辛苦，公司是沒有什麼補貼的，要不會提倡了一種上班時間拖遝，把要做的事情留到下班後去做，獎勵努力而不重結果的文化。

微軟有一種卓有成效的“師傅”制度。因為直接請教上級會讓員工覺得不自在，擔心什麼地方做的不好會造成上級的壞印象，所以新員工進入公司後會分配一位師傅，新員工有任何問題都可以請教。員工進入公司工作一段時間後可以自願申請成為“師傅”。師傅制度一來讓員工快速上手和熟悉工作環境，二來可以培養“師傅”的領導和影響他人的能力，給工作增加心得挑戰和活力，使之感覺受到重視，與眾不同，有成就感。

唐駿先生在最後講座上講到了目前中國IT企業成功需要的一些條件：1.機會 2.成功的商業模式 3.關係。另外好幾位講師都提到了中國IT企業成功所需要的一條，就是制訂標準。

最後簡單分享一下唐駿先生講的幾個有意思的案例，由於實際上的案例比較長，這裡只是簡單寫出來，希望大家也能領會這些舉動背後的含義。

1.微軟公司的以人為本。微軟中國研究中心辦公樓的電梯有問題，六部電梯中只要有一部準備降到底樓，其他的就不會回落到底樓，結果早上上班高峰時大家都在樓下等電梯。微軟中國和物業協商無用，最後派幾位打掃衛生的阿姨每天早上上班的時候呆在電梯裡當電梯小姐，只要電梯上去了就將電梯按回到1層，已緩解高峰狀態電梯緊張。

2.中秋基本所有公司都會給員工發月餅，但是微軟中國與眾不同的是只需要員工提供一個地址，公司會把月餅快遞過去，這樣員工就可以寄月餅回給父母等等。更不同的是，唐駿先生在月餅封裝裡夾了一張賀卡，其中彙報了今年微軟中國取得的成就，感謝他（她）為微軟中國培養了這麼一位優秀的員工。

3.微軟中國規定每若干時間要選一次優秀員工，每個部門只有幾個指標能能選自己部門的人，其他都需要選其他部門員工，這樣子最後優秀員工肯定是那些做人好，會協助其他人的員工。然後微軟中國規定所有的晉陞者都必須是優秀員工，因為一個優秀的管理者必然要會做人，要善於協助別人，這樣由於晉陞者必須是優秀員工，一方面可以協助實現自己的利益，一方面就在公司內部倡導了一種互相協助的企業文化，使各部門相互合作。