創建人：X公司程序員?yunshichen ? 這篇是我讀《微軟研發致勝策略》后整理的筆記。身為一個軟件開發部門的主管，你的職責是什么？單單完成項目是不足夠的，如果你的目標是這樣，那么你會做錯很多事。我認為準確的表述應該是： 帶領程序員按進度完成項目，并且讓他們能通過項目中在技術，工資，團隊歸屬感等方面成長。 本文作者用輕松愉快的筆調討論了作為一個主管，應該怎樣管理項目，并且列出了他在微軟的一些做法?；蛘咚赡軟]意識到，他提出的解決方法，其實都是針對一個問題： 你究竟想要做什么？ 小到編程，買菜，與人交流，大到管理，人生，無非都是弄清楚你自己究竟想要做什么。弄清楚之后，通常你就能找到相應的處理方法。 讀完之后我沒有單純的記下要點，我把作者的觀點歸納之后，重寫成如下形式。希望能給喜歡讀書的同行一點思考的火花。當然了，最好建議你還是去讀讀這本書，然后寫下你自己的見解。當你，我，他都有了自己的理論，或者中國軟件業的春天就不遠了。

項目的討論

精確的項目目標
??作為主管，值得你好好花時間去設定你的項目目標。目標定下來之后，你就會清楚哪些工作該做，那些工作不該做。例如你是基礎函數庫的主管，如果你確定了“只有所有模塊都使用的函數才是要開發的函數”的原則，那么某個模塊要求你開發的工作，就不是你的目標了。
??每天花10－15分鐘想想目標，并且想些解決的小竅門。例如作者某天是這樣想的：
Diego負責該函數的開發，有可能需要一本技術手冊。
??于是他馬上去買了一本。
??就這樣，明確項目目標，提前把影響程序員專心工作的障礙（包括不必要的會議，email，電話等）一一去除。主管才能把項目做好。

開會與報告
??有些會是不得不開的。例如：
??1 當某個人必須把信息傳送給很多人時。
??2 信息需要雙向或多向交流，人們必須立即反問才能了解信息。
??3 必須親眼目睹或親身經歷，信息才能傳達給接受者，如產品示例。
??4 有些事情須通過討論才能進行。
??但開會中斷許多人的工作。所以在開會之前，你必須動腦筋想想，你開會的目的是什么，有沒有更好的方法達到同樣目的。
??會議時間應選擇工作效率比較低的時段，并且不會打擾程序員順序連續工作時間的時段為宜，例如早上剛開始上班，下午剛開始上班，快下班時。特別的，如果可以選擇的話，在星期一早上或星期五下午開會。這是最沒效率的兩個時段。
??如果會議確實召開了。一定要達到目的。即使是假設性的，有條件的結論。例如，如果其他小組的工作依賴于Diego的工作成果，那么你可以問Diego：“兩個星期能完成你的工作吧？”如果他同意了，那么以此假定作為基礎和其他小組討論工作，例如進度安排等。
??作為主管，避免在會后讓與會者遞交一份長長的發言報告。這是雙重浪費時間。如果你覺得他們的發言值得記，那么你自己記下來。再次強調，寫無用的報告浪費開發人員時間。如果你確實要報告，最好單獨進行，并且盡量短。

進度
??微軟曾有過慘痛的教訓，以進度作為項目完成的指導。任何進度落后都是不允許的，bug的不斷增加不算嚴重問題，但只要工作沒在排定的時間內完成，就是罪孽深重的。進度取代了項目目標和軟件質量，變成了首要任務，每一個人都在瘋狂的趕進度。
??以Mac Excel項目為例，每周的進度檢討加上報告，是微軟用來控制進度的主要手段。除了這些，開發人員害得每周和測試文件人員共同檢討原因和落后狀況。可想而知，只要進度落后，文件小組和測試人員只好暫時沒事做，所有目光和談話，都集中在你的程序進度落后上了。
??每周經理們會用更新的項目進度報告來更新項目總進度表，然后分發給組員。于是你一眼就會看到本周落后了多少，整個項目因此落后了多少。心痛之余，你翻到后頁看看還有多少未完成的工作，上周是幾百項，現在還是幾百項，拼命做事，結果似乎毫無進展。就像一個笑話：如果你每次咬一小口，多久才能啃完一只大象？這張進度表就是一只大象，我們一輩子也無法吃完。
??實在是太過分強調進度了。以至于無論我們做了多少了不起的事情，都沒有半點成就感。我們被落后的威脅淹沒了，再怎么努力，也看不到成功的彼岸。這不是工作本身的問題，實在是那種絕望無力的感覺所致。
??更荒唐的是，進度表是基于如下原則設定的：
??1 為期兩年的項目所有該做的事情都在進度表中，沒有任何遺漏。
??2 每人每周實際工作時間40小時。
??3 對于每件工作的時間估計完全準確。
??4 所有程序第一次出來就是完美狀態，沒有bug，不需修改。
??這真是天方夜談。
??教訓：不要利用進程表來驅使項目前進，這實在太傷害小組士氣了。

??在這里，作者提出了他自己的觀點：不應該deadline快到了才開始緊張，平時就應該保持適當的緊張狀態。多想想如何聰明的工作，不要把時間浪費在沒有價值的工作上，不要浪費別人的時間，用積極的態度推動項目?？傊?#xff0c;不應該在dealine快到來時，才動腦筋去想解決辦法。平時就應該養成良好的工作習慣。
??如果你覺得時間緊迫，那么你開會總結一定不會說：“這個問題，我們留待以后再討論……”你和組員一定無法容忍事情的拖拉，要不刪除這項工作，要不立刻把它完成。
??進度的急迫多數是由于不正確的考慮，不正確的工作方式所導致。如果你定的日程表讓組員產生了落后恐懼癥，為了趕上期限而犧牲了產品質量，那么該檢討的是這個進度表而不是組員。如果你定出的日程表是個無法完成的目標，那只不過是打擊團隊士氣。一旦組員發覺已深陷絕境，那你就永遠無法讓他們表現出最佳狀態。他們就會另某高就，找個是人做的工作。

項目控制
??在完成對進度的討論之后，作者提出了他對項目控制的見解：
??1 進度是基于某些因素上軟件的大致完成日期。不要迷信它。不要草率定出不可能的期限，導致組員為了趕進度而不顧一切。
??2 把長期的大項目，分成幾個完整而獨立的小項目，各小項目必須有一個主題。這樣既能營造適當的緊迫氣氛，也讓大家有完成目標的成就感。
??3 制定測試和質量監控規范，這些規范可能涉及產品的速度，健壯性，安全性等，你必須考慮并定出標準。通過質量檢測規范的小項目，才算真正完成。警惕，不要把小項目寫成hello world之類毫無意義的測試程序。該有的功能絕對要有，該達到的要求絕對要達到。
??4 產品的質量遠比期限要重要。發現bug立刻清除。你不會知道一個bug到底有多嚴重，存在bug的軟件產品，會讓項目的完成比例被嚴重高估。更壞的情況下，由于bug的存在，你會不知道項目究竟什么時候能完成。

加班
??如果進度落后，那表示有個地方出錯了。在沒有找到問題并解決之前，不要粗暴的要求組員加班。這種加班是沒有用的。
??如果你以進度落后為由，強迫組員每天工作12小時。那么他們很可能把私人活動也安排到工作時間里，并且在可能輕松的時刻盡可能偷懶。因為他知道每天必定工作12小時，不妨把私人活動如看新聞等也在上班時完成。加班，通常是浪費時間的面具。
??事實上，拼命工作并不是成功的關鍵，成功的關鍵是有一個明確的目標，具體而切合實際的計劃，以及每天不斷的向這個目標邁進。
??(微軟不強制員工的上班時間，所以作者如此討論。但事實上，在中國，加班一樣是最沒有效率的控制項目的方式。即使你強迫員工每天12小時坐在電腦前，他也很有可能面對屏幕發楞。疲倦的頭腦是不可能產生任何創造性活動的。)
??加班的目的只是為了趕上進度而已。為了改善我們的工作，還有許多手段可以達到這個目的：
??1 明確工作目標：程序員是不是被太多的雜務打亂了開發工作？例如不必要的email，不必要的電話、討論、會議。作為主管，你有責任把這些障礙找到并一一清除，還程序員一個專心開發的環境。
??2 合理安排工作：例如，看email應該在早上，中午，快下班時看，不要在開發過程中讓它打亂了你的思路。早上是最有效率的時候，讓頭腦完成有創意的工作，而其他時間用來編碼等等。
??再一次強調，你必須牢記自己的目標：按進度完成項目并讓組員成長。只要你開動腦筋，你一定能想到更好的代替加班的方法來達到目的。加班并不是完成這個目標的唯一手段，事實上它是最差的，能不能趕上進度且不說，肯定妨礙了組員的成長。它并不是你的救命稻草，如果你依靠加班來完成你的管理工作，或者你該考慮走人了。??

項目檢討
??對項目進行檢討總結的意義不言而喻。但要避免大而無當的總結。檢討應該能做到：
??1 指出項目的問題所在
??2 根據問題，考慮防范措施和實際的解決辦法（雖然有可能只是建議）
??3 總結經驗心得。將來如何利用。
??以下是一個例子，給出了兩個項目檢討的對比：
??第一個：
??問題：某軟件包的Beta版使用者覺得他們的測試報告好像沒人注意。因為bug在每一版都出現，這主要是因為我們沒有建立一套系統的方法去追蹤外部的Beta測試報告。所以我們將來應更小心的追蹤外部的Beta測試報告，并加強后續處理。
??第二個：
??由于對β測試報告的疏忽。不僅影響了項目，也影響了關聯的其他項目。經理已經同意重新考慮三個追蹤Bug的系統，我們將在三者中擇一使用，以便追蹤項目的測試報告，我們還要把bug和清除bug的行動記錄下來。
??這個報告是很有效的。他提出了清楚的解決方案，詳細的執行步驟，由誰負責，什么時候該完成，應用在哪幾個項目。還建議了bug的查找方式。
??值得一提的是，不要等項目結束了才想什么是值得一寫的。應該養成平時經常記錄的好習慣，積累是隨時的。

管理藝術

評估方式
??年終評估是最沒用的評估。對員工的評估應該隨時的進行。員工有什么不足應該立即指出，并為他盡量想個改善的方法，讓他能立刻成長。不要單純在年終評估記錄員工的不足。

溝通技巧
??有些員工看起來很依賴主管解決問題，其實不過是他們的溝通方式有問題。碰到這種員工，你可以要求他們：
??1 清晰表達他們待解決問題是什么
??2 有什么解決方法，包括他贊同的和否決的
??3 陳述贊同和否決的理由。
??這樣下來，通過和員工多次溝通，或者你會發現你的員工并不笨，他們只是不懂得溝通技巧而已。
??一句話，你和員工的一起成長是你的目標之一，所以不要采用生硬粗暴的方式去對待員工。動腦筋想些更好的法子。

人員培養

態度正確
??你必須讓你的組員態度正確。
??1 發現bug立刻清除。越晚抓bug越難抓，并且能讓程序員總結經驗。還有，如果bug太多，那么程序員的功力高下立現。
??2 除非我已經完全測試過了，沒有bug了，否則程序不算完工。
??3 以用戶的觀點來看待軟件，盡善盡美。
??4 改正“這不可能”的態度。最好的方法是明確目標，然后找出正確的解決方案。
??5 鼓勵提問。他可能不知道答案，但他有權提出問題。
??6 未完成的功能，絕對不要給用戶。
??7 善于利用別人的成果。寫好的測試過的代碼，只要符合自己要求，就應該用。重復就是浪費。
??8 注意提高自己代碼的復用性。

提高技術
??如果某個程序員在你的項目已經毫無進步，并且他渴望提高，那么讓他到其他項目去吧，讓其他接他的班。短期來看你損失了一個得力干將，長期來看，你為公司培養了兩個人才。
??
??新兵訓練：先讓新人學會一些通用性技術，這樣他到其他項目組也能用。然后才讓他們學會項目專有的技能。訓練他們多思考。在設計階段，他們要想得很縝密，確定這樣的設計沒有紕漏，寫程序時要動腦筋，要懂得怎么思考怎么測試這個程序才確保沒有bug；遇到bug時，不要亂猜，要思考如何有系統的搜尋bug藏身之處，要學會判斷是否有相關bug沒有現身；不但要學習如何對付bug，還要思考如何在一開始寫程序時就避免它的發生。同時要了解這一行業新知識不斷而至，他必須不斷學習提高，才能跟上產業的步伐。

工作價值
??讓組員明白，單純的工作時間是不能衡量員工價值的，程序員對項目的貢獻在于：
??1 指出我們在哪里浪費了人力？
??2 有什么地方可以引用別組的程序代碼？
??3 有什么自動測試程序的好主意？
??4 想到一個符合用戶使用習慣的界面？
??等等諸如此類。簡而言之，你必須開動腦筋定下規則，鼓勵員工學習新的技術，養成好的工作習慣，做事更有效率，從而加快項目的進程。而不是用單純工作時間來判斷員工價值。

轉載于:https://www.cnblogs.com/SoulStore/archive/2007/06/26/796379.html

總結

以上是生活随笔為你收集整理的微软研发致胜策略读书笔记（转）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。