微軟研發(fā)致勝策略讀書筆記

1、微軟研發(fā)致勝策略讀書筆記身為一個軟件開發(fā)部門的主管，你的職責是什么？單單完成項目是不足夠的，如果你的目標是這樣，那么你會做錯 很多事。我認為準確的表述應該是: 帶領程序員按進度完成項目，并且讓他們能通過項目中在技 術，工資，團隊歸屬感等方面成長。本文作者用輕松愉快的筆調討論了作為一個主管，應該怎樣 管理項目，并且列出了他在微軟的一些做法?；蛘咚赡軟] 意識到，他提出的解決方法，其實都是針對 個問題： 你究竟想要做什么?小到編程，買菜，與人交流，大到管理，人生，無非都是弄 清楚你自己究竟想要做什么。弄清楚之后，通常你就能找到 相應的處理方法。讀完之后我沒有單純的記下要點，我把作者的觀點歸納之 后

2、，重寫成如下形式。希望能給喜歡讀書的同行一點思考的 火花。當然了，最好建議你還是去讀讀這本書， 然后寫下你自己的見解。當你，我，他都有了自己的理論， 或者中國軟件業(yè)的春天就不遠了。項目的討論精確的項目目作為主管，值得你好好花時間去設定你的項目目標。目標 定下來之后，你就會清楚哪些工作該做，那些工作不該做。例如你是基礎函數庫的主管，如果你確定了 “ 只有所 有模塊都使用的函數才是要開發(fā)的函數 ” 的原則，那 么某個模塊要求你開發(fā)的工作，就不是你的目標了。每天花 1015 分鐘想想目標，并且想些解決的小竅門。例如作者某天是這樣想的：Diego 負責該函數的開

3、發(fā)，有可能需要一本技術手冊。于是他馬上去買了一本。就這樣，明確項目目標，提前把影響程序員專心工作的障礙（包括不必要的會議，email，電話等）去除。主管才能把項目做好。開會與報告有些會是不得不開的。例如：1 當某個人必須把信息傳送給很多人時。2 信息需要雙向或多向交流，人們必須立即反問才能了解 信息。3 必須親眼目睹或親身經歷，信息才能傳達給接受者，如 產品示例。4 有些事情須通過討論才能進行。但開會中斷許多人的工作。所以在開會之前，你必須動腦筋想想，你開會的目的是什么，有沒有更好的方法達到同樣 目的。會議時間應選擇工作效率比較低的時段，并且不會打擾程 序員順序連續(xù)工作時間的時段為宜，例如早上

4、剛開始上班，午剛開始上班，快下班時。特別的，如果可以選擇的話， 在星期一早上或星期五下午開會。這是最沒效率的兩個時 段。如果會議確實召開了。 一定要達到目的。 即使是假設性的， 有條件的結論。例如，如果其他小組的工作依賴于 Diego 的 工作成果， 那么你可以問 Diego ：“ 兩個星期能完成你 的工作吧？ ” 如果他同意了，那么以此假定作為基礎 和其他小組討論工作，例如進度安排等。作為主管，避免在會后讓與會者遞交一份長長的發(fā)言報 告。這是雙重浪費時間。如果你覺得他們的發(fā)言值得記，那 么你自己記下來。再次強調，寫無用的報告浪費開發(fā)人員時 間。如果你確

5、實要報告，最好單獨進行，并且盡量短。進度微軟曾有過慘痛的教訓，以進度作為項目完成的指導。任 何進度落后都是不允許的， bug 的不斷增加不算嚴重問題， 但只要工作沒在排定的時間內完成，就是罪孽深重的。進度 取代了項目目標和軟件質量，變成了首要任務，每一個人都 在瘋狂的趕進度。以 Mac Excel 項目為例，每周的進度檢討加上報告，是微 軟用來控制進度的主要手段。除了這些，開發(fā)人員害得每周 和測試文件人員共同檢討原因和落后狀況?？上攵灰?進度落后，文件小組和測試人員只好暫時沒事做，所有目光 和談話，都集中在你的程序進度落后上了。每周經理們會用更新的項目進度報告來更新項目總進度表， 然后分

6、發(fā)給組員。于是你一眼就會看到本周落后了多少，整 個項目因此落后了多少。心痛之余，你翻到后 頁看看還有多少未完成的工作，上周是幾百項，現在還是幾 百項，拼命做事，結果似乎毫無進展。就像一個笑話：如果 你每次咬一小口，多久才能啃完一只大象？這 張進度表就是一只大象，我們一輩子也無法吃完。實在是太過分強調進度了。以至于無論我們做了多少了不 起的事情，都沒有半點成就感。我們被落后的威脅淹沒了， 再怎么努力， 也看不到成功的彼岸。 這不是工作本身的問題， 實在是那種絕望無力的感覺所致。更荒唐的是，進度表是基于如下原則設定的：1 為期兩年的項目所有該做的事情都在進度表中，沒有任 何遺漏。2 每人每周實際工

7、作時間 40 小時。3 對于每件工作的時間估計完全準確。4 所有程序第一次出來就是完美狀態(tài)，沒有bug ，不需修改。這真是天方夜談。教訓：不要利用進程表來驅使項目前進，這實在太傷害小 組士氣了。在這里，作者提出了他自己的觀點：不應該 deadline 快到了 才開始緊張，平時就應該保持適當的緊張狀態(tài)。多想想如何 聰明的工作，不要把時間浪費在沒有 價值的工作上，不要浪費別人的時間，用積極的態(tài)度推動項 目?？傊?，不應該在dealine快到來時，才動腦筋去想解決辦 法。平時就應該養(yǎng)成良好的工作習 慣。如果你覺得時間緊迫，那么你開會總結一定不會說： “ 這個問題，我們留待以后再討論

8、 ……” 你和組員一定無法容忍事情的拖 拉，要不刪除這項工作，要不立刻把它完成。進度的急迫多數是由于不正確的考慮，不正確的工作方式所 導致。如果你定的日程表讓組員產生了落后恐懼癥，為了趕期限而犧牲了產品質量，那么該檢討的是這 個進度表而不是組員。如果你定出的日程表是個無法完成的 目標，那只不過是打擊團隊士氣。 一旦組員發(fā)覺已深陷絕境， 那你就永遠無法讓他們表現出最佳狀態(tài)。他 們就會另某高就，找個是人做的工作。項目控制在完成對進度的討論之后，作者提出了他對項目控制的見 解：1 進度是基于某些因素上軟件的大致完成日期。不要迷信它。不要草率

9、定出不可能的期限，導致組員為了趕進度而不 顧一切。2 把長期的大項目，分成幾個完整而獨立的小項目，各小 項目必須有一個主題。這樣既能營造適當的緊迫氣氛，也讓 大家有完成目標的成就感。3 制定測試和質量監(jiān)控規(guī)范，這些規(guī)范可能涉及產品的速 度，健壯性，安全性等，你必須考慮并定出標準。通過質量 檢測規(guī)范的小項目，才算真正完成。警惕，不要把小項目寫 成 hello world 之類毫無意義的測試程序。 該有的功能絕對要 有，該達到的要求絕對要達到。4 產品的質量遠比期限要重要。發(fā)現 bug 立刻清除。你不會知道一個 bug 到底有多嚴重，存在 bug 的軟件產品，會讓 在，你會不知道項目究竟什么時候能

10、完成。加班項目的完成比例被嚴重高估。更壞的情況下，由于bug 的存如果進度落后，那表示有個地方出錯了。在沒有找到問題 并解決之前，不要粗暴的要求組員加班。這種加班是沒有用 的。如果你以進度落后為由，強迫組員每天工作12 小時。那么他們很可能把私人活動也安排到工作時間里，并且在可能 輕松的時刻盡可能偷懶。因為他知道每天必定工作 12 小時， 不妨把私人活動如看新聞等也在上班時完成。加班，通常是 浪費時間的面具。事實上，拼命工作并不是成功的關鍵，成功的關鍵是有 個明確的目標，具體而切合實際的計劃，以及每天不斷的向 這個目標邁進。（微軟不強制員工的上班時間， 所以作者如此討論。 但事實 上，在中國，

11、加班一樣是最沒有效率的控制項目的方式。即 使你強迫員工每天 12 小時坐在電腦前，他也很有可能面對 屏幕發(fā)楞。疲倦的頭腦是不可能產生任何創(chuàng)造性活動的。加班的目的只是為了趕上進度而已。為了改善我們的工 作，還有許多手段可以達到這個目的：1 明確工作目標：程序員是不是被太多的雜務打亂了開發(fā) 工作？例如不必要的 email ，不必要的電話、討論、會議。作為主管，你有責任把這些障礙找到并一一清除，還程序員個專心開發(fā)的環(huán)境。中午，快2 合理安排工作：例如，看 email 應該在早上，班時看，不要在開發(fā)過程中讓它打亂了你的思路。早上是 最有效率的時候，讓頭腦完成有創(chuàng)意的工作，而其他時間用 來編碼等等。再一

12、次強調，你必須牢記自己的目標：按進度完成項目并讓 組員成長。只要你開動腦筋，你一定能想到更好的代替加班 的方法來達到目的。加班并不是完成這個目標 的唯一手段，事實上它是最差的，能不能趕上進度且不說，肯定妨礙了組員的成長。它并不是你的救命稻草，如果你依 靠加班來完成你的管理工作，或者你該考慮走 人了。 項目檢討對項目進行檢討總結的意義不言而喻。但要避免大而無當 的總結。檢討應該能做到：1 指出項目的問題所在2 根據問題，考慮防范措施和實際的解決辦法（雖然有可 能只是建議）3 總結經驗心得。將來如何利用。以下是一個例子，給出了兩個項目檢討的對比：第一個：問題：某軟件包的 Beta 版使用者覺得他們

13、的測試報告好像 沒人注意。因為 bug 在每一版都出現，這主要是因為我們沒 有建立一套系統的方法去追蹤外部的 Beta 測試報告。所以我 們將來應更小心的追蹤外部的 Beta 測試報告， 并加強后續(xù)處 理。第二個：由于對 β 測試報告的疏忽。不僅影響了項目，也影響 了關聯的其他項目。 經理已經同意重新考慮三個追蹤 Bug 的 系統，我們將在三者中擇一使用， 以便追蹤項目的測試報告， 我們還要把 bug 和清除 bug 的行動記錄下來。這個報告是很有效的。他提出了清楚的解決方案，詳細的執(zhí)行步驟， 由誰負責， 什么時候該完成， 應用在哪幾個項目。還建議了 bug 的查找方式。值得

14、一提的是，不要等項目結束了才想什么是值得一寫 的。應該養(yǎng)成平時經常記錄的好習慣，積累是隨時的。管理 藝術評估方式年終評估是最沒用的評估。對員工的評估應該隨時的進 行。員工有什么不足應該立即指出，并為他盡量想個改善的 方法，讓他能立刻成長。不要單純在年終評估記錄員工的不 足。溝通技巧有些員工看起來很依賴主管解決問題，其實不過是他們的 溝通方式有問題。碰到這種員工，你可以要求他們：1 清晰表達他們待解決問題是什么2 有什么解決方法，包括他贊同的和否決的3 陳述贊同和否決的理由。這樣下來，通過和員工多次溝通，或者你會發(fā)現你的員工 并不笨，他們只是不懂得溝通技巧而已。句話，你和員工的一起成長是你的目標

15、之一，所以不要 采用生硬粗暴的方式去對待員工。動腦筋想些更好的法子。人員培養(yǎng)態(tài)度正確你必須讓你的組員態(tài)度正確。1 發(fā)現 bug 立刻清除。越晚抓 bug 越難抓，并且能讓程序 員總結經驗。還有，如果 bug 太多，那么程序員的功力高下 立現。2 除非我已經完全測試過了，沒有 bug 了，否則程序不算 完工。3 以用戶的觀點來看待軟件，盡善盡美。4 改正 “ 這不可能 ” 的態(tài)度。 最好的方法是明 確目標，然后找出正確的解決方案。5 鼓勵提問。他可能不知道答案，但他有權提出問題。6 未完成的功能，絕對不要給用戶。7 善于利用別人的成果。寫好的測試過的代碼，

16、只要符合 自己要求，就應該用。重復就是浪費。8 注意提高自己代碼的復用性。提高技術如果某個程序員在你的項目已經毫無進步，并且他渴望提 高，那么讓他到其他項目去吧，讓其他接他的班。短期來看 你損失了一個得力干將，長期來看，你為公司培養(yǎng)了兩個人 才。新兵訓練：先讓新人學會一些通用性技術，這樣他到其他項 目組也能用。然后才讓他們學會項目專有的技能。訓練他們 多思考。在設計階段，他們要想得很縝密，確 定這樣的設計沒有紕漏，寫程序時要動腦筋，要懂得怎么思考怎么測試這個程序才確保沒有bug;遇到bug時，不要亂猜，要思考如何有系統的搜尋 bug 藏身 之處，要學會判斷是否有相關 bug 沒有現身；不但要學習如 何對