微軟研發75條心得

[一．奠定基礎]

1. 任何不能改善產品的工作，都是浪費時間或是偏離方向。

2. 領導者的任務是努力消除程式設計師工作上的一切障礙，讓程式設計師全力專注在真正重要的工作─改善產品。

3. 千萬不要把程式設計師的時間浪費在改善產品以外的工作上。

4. 永遠記得自己真正的目標，然後讓團隊用最有效又最愉快的方法把它完成。

5. 理清詳細的專案目標，可以避免在不必要的工作上浪費時間。

6. 不要因為制定目標需要花很多時間，或是別人都沒有做，就省略了目標的制定。制定明確詳盡的目標所花的時間，絕對會讓團隊得到更大的好處。

7. 事前決定最合適的優先考慮順序，以及各考慮點的質量規範，能夠指引開發團隊的工作。

[二．策略性的作業方式]

8. 錯蟲愈晚清除，時間花得愈多。畢竟，您得知道程式是怎麼寫的，才能判斷那裡出了錯蟲；剛寫完的程式記憶猶新，一年前寫的程式可能早就忘了。

9. 在開發的過程就立即除蟲，可以讓您早些學到經驗，然後就不會再犯同樣的錯誤；相反地，如果到了專案後期才發現，您可能已經犯過多次同樣的錯誤而不自知。

10. 發現錯蟲而立即除錯是一種緩衝器，提醒那些講求快速而不夠謹慎的程式設計師，以後多加小心。如果您堅持錯蟲全都清除了才能開發新的功能，就可以防止所有的程式處於半完成狀態，因為錯蟲太多而使專案延誤乃至無法推出；相反地，如果您允許錯蟲的存在，等於是埋下了專案失控的地雷，最後看似完成的專案，其實已經失控。

11. 若能保持沒有任何錯蟲，您就能比較準確估出專案的完成時間。不必猜測3 2項功能和1 742個錯蟲共要花費多少時間，只要估算3 2項功能的工作時間就行了。更重要的時，萬一到時候有些功能做不完，您可以做多少算多少，因為軟體一直保持在無錯誤狀態。

12. 不要把策略性工作方式當作訓練的教條，應該向組員解釋這些工作方式的內涵與用意。

13. 提出精確詳盡的問題，可以引匯出真正有效的策略性工作方式，幫助專案目標順利完成。

14. 策略不是死的定律，要把它當作指導原則來活用。大部分的時候都應該遵循，但也有例外的時候。

[三．保持進度]

15. 定期暫停手邊的工作，然後往前思考，隨時做必要的修正，以避免未來的大障礙。

16. 有什麼事情是我今天能做，而且可以幫助專案在未來幾個月內順利進行的？

17. 不要浪費時間在錯誤的問題上，一定要先確定真正的問題在哪裡，然後才去改正它。

18. 人們開口要求的東西未必是他真正想要的。處理他的要求之前，請務必確定他究竟想要做什麼。

19. 絕對不要答應別人自己做不到的事情，這樣對雙方都有益無害。

20. 不要為了討好別人而傷害雙方的工作程式，您永遠要根據自己的目標，做適當的決策。

21. 是您在為專案負責。不要讓任何人的建議阻礙專案的進行，包括上級的建議。

22. 天下沒有真正免費的軟體

23. 應該開發策略上具有重要性的功能，而不是把媒體的評比專案都做齊全。

24. 軟體產品的開發，不能只為了有趣、挑戰性，或是夠有個性夠令人眩目。

25. 不要把時間浪費在無法改善產品的工作上，即使這麼做在將來會有潛在的利益，也要與現在投入的時間成本做個衡量。

[四．走向極端的狂熱]

26. 確定您所要求的報告真的值得屬下暫停工作，花那麼多時間去寫。

27. 利用專案檢查報告來改進軟體開發的工作程式。為了使報告發生作用，報告中必須確實描述我們這次解決問題的每一個詳細步驟，以及將來應該如何運用這項新發現。

28. 請注意定期會議的價值，確定它值得每個人放下手上的工作。

29. 召開任何會議之前，請確定本次會議的目的是什麼，達成這個目的的條件是什麼，然後，務必達到開會的目的。

30. 試著排除不必要的後續工作。

[五．進度狂]

31. 不要利用程式表來驅使專案的進行，這對小組的士氣傷害太大了。

32. 讓日程表維持適度的緊迫，但又是可以做到的，好讓組員振奮、不鬆懈，專心致力於專案的推進。

33. 絕對不要草率定出不可能的期限，導致組員為了趕進度而損害產品的質量。

34. 把長期的大專案，分成幾個完整而獨立的小專案，各小專案必須有一個主題。

35. 為了保持創意的活力和團隊士氣，必須讓每一個小專案都有令人興奮的結果。

36. 產品的質量遠比遵守期限重要.

[六．學無止境]

37. 不要讓程式設計師的學習停滯不前，要讓程式設計師有機會磨練不同領域的技術，培養十八般武藝樣樣精通的組員。

38. 訓練新程式序設計師時，先培養他對整個公司所有專案都有價值的技術，然後才培養本專案獨有的技術。

39. 不要捨不得放您最優秀的程式設計師到別的專案去。如果他在您的專案已經沒有新的東西可學，為了公司和他個人的前途，您應該把他推薦到別的專案，讓他的成長永不間斷。

40. 確定每位組員、每兩個月都有一項技術上進步。

41. 一發現某處需要改進，就立即採取更正的行動。

42.不要用年終考評來訂立學習目標，要利用年終考評來記錄個人的成長。

43. 絕對不要讓組員一直做同樣的工作，這樣是限制了他的學習，使他停滯在原來的領 域。一旦程式設計師精通了某一個領域，就讓他換別的領域做做看，永遠讓他們學習新的技術。

44. 各種技術的用途範圍有所不同，有的技術在一般的專案都用得上，有的技術只有在特定性質的專案才用得上。當您訓練您的組員時，必須讓他們的技術能在公司發揮最大的用處，最好的辦法就是，把應用範圍最廣的技術放在訓練的最前期，應用範圍最小的技術放在最後訓練。

45. 優秀的程式設計師是專案經理最需要的，所以經理們通常捨不得讓自己手下功力最強的人到別組去，但是如果這位第一高手在本組內再也沒有新東西可學時，經理就應該讓他到別的專案去，一方面他個人可以重新開始另一次的成長，一方面讓接替他的人學著承擔重要的工作，最後公司的平均程式技術水準因而提升，對大家都很有好處。

46. 為了確保每位程式設計師的技術都在穩定地進步，一定要讓每個人有個努力的目標，最好的方法是把個人的成長和專案每兩個月的階段性目標相結合，這樣一年就有至少六次的進步了。假定一位組員在公司待了五年，那麼他就學了3 0種新技術、或是讀了3 0本好書、或是1 5項技術加1 5本書，對他的工作能力影響多大啊。

47. 最好的成長目標是出於當時的需要。如果您發現有位組員工作缺乏效率，或總是在犯同樣的錯誤，最好抓住機會立即為他立一個目標，並且要求他立刻開始改進。這種當時設立的目標讓人印象深刻，又是馬上尋求改善，效果通常會非常好。比起年終考評那種模模糊糊的建議，更能引起程式設計師的重視。

[七．態度問題]

48. 要讓每一位程式設計師都明白，寫出零錯誤程式是很不容易的，所以應該多花功夫用各種方法做最徹底的測試。

49. 糾正程式設計師以為加除錯碼會花太多時間的觀念，應該訓練程式設計師第一個反應是考慮加上除錯碼是否有道理，第二是考慮加除錯碼是否符合專案的目標與工作的優先順序。

50. 當某人說“某件事不可能做到”時，他往往是錯的。

51. 不要讓凡事不能的態度阻礙了創新。

52. 使用者和程式的撰寫者一樣關心速度和品質的問題。

53. 不要讓程式設計師以為使用者並不在乎軟體的質量。

54. 不要給使用者次品，寧願延期交貨，務必追求質量完美。

55. 程式設計師必須經常以使用者的觀點來看自己寫的程式，程式設計師必須能體會使用者的感受。

56. 在包裝盒裡的每一件東西，都是產品的一部分。

57. 將程式的重用性當作優先考慮的目標之一，否則程式設計師將經常做重複的工作。

58. 充分利用現有資源或創造新資源，以便從每一項工作中獲得更大的價值。程式程式碼的再利用，就是很好的例子，當然，還有其他的地方可以運用“槓桿原理”。

59. 如果您創造了一項資源，並且讓別人知道，那麼總有一天會派上用場。

60. 從您的每件工作中創造最大的資源，不管是利用現有的槓桿，或是創造新的槓桿。

61. 小心那種“太難了”、“太花時間”或是“太麻煩”的反射性反應。當您遇到別人有這種反應，請先問自己他有沒有認真思考過這件事的重要性、以及是否符合專案目標，如果您認為他其實未經深思熟慮，只是直覺的反應，那您就應該把您的想法告訴他，請他重新評估，也許就會有公平的答案。

62. 人們遇到經驗範圍之外的事情，多少有恐懼感，就會認為“這完全不可能”而強烈反對。試著消除這種習慣性的反應，設法給組員灌輸“只要花時間想想看，大部分的事情都做得到”的觀念。您不妨以這個問題來對付那種“凡事不能”的態度：“我瞭解這是做不到的，但是‘如果’做得到，那你會怎麼做？”然後您就會發現驚人的轉變，您馬上就會聽到組員七嘴八舌地說應該這樣做、那樣做，說的是他們剛剛堅持做不到的事情。這個“如果”把他們帶離直覺的反應，帶到全新的思考模式，這才是他們應該做的。

63. 把使用者當作什麼都不懂的外行人，是非常不好的觀念。每當您發現有人表露出這種心理，一定要立即糾正，提醒他們使用者才是真正受產品好壞影響最深的人，他們和程式設計師一樣關心軟體的執行速度和質量。

64. 槓桿原理是您最有用的觀念，找到您工作中的槓桿，您可以為小組、專案、公司、甚至軟體業創造無可限量的價值。無論如何，儘量利用資源並創造資源，這個原則是絕對錯不了的。在您寫程式的時候注意程式程式碼的共享性、訓練組員的時候注意到他對公司的價值，即使是像函式命名這種小事，都有槓桿的存在。不管做任何事，都要想到“善用資源”，為未來做好準備。

[八．沉船的感覺]

 

65. 如果進度發生落後，那表示有個地方出錯了。您應該找出問題，並加以解決，不要一味要求組員加班，在問題沒有解決之前，加班是沒有用的。

66. 別誤信加班等於增加生產能力，長期的加班只會傷害生產能力，對專案沒有幫助。

67. 週末是屬於組員私人的時間，不是公司的。公司不應該以打敗競爭對手為理由，要求員工週末加班。

68. 強調思考的重要性，而不是長時間工作。

69. 訓練開發小組懂得在正常工作時間內掌握好工作的效率，不要讓他們超時工作，因為超時工作只是浪費時間的假面具。

70. 與程式設計師共同研擬出一份每日活動的時間表，把無法預期的臨時公務變成固定時間處理的事情，並且把程式開發的工作放在最優先的地位，不要讓其他次要的事情干擾到寫程式。

71. 經常加班就是專案出問題的明顯訊號，也許是因為主管的觀念錯誤或是目標不夠清楚，不論是什麼原因，專案經理絕對不能忽視這種現象，要對這個問題正確處理，專案經理必須協助組員在每週4 0小時的工作時間裡，把事情做得更有效率。

72. 我經常聽到高層主管稱讚組員每天為公司工作很長的時間：“您對公司的貢獻值得嘉獎，做得很好！”這絕對是錯誤的資訊，員工應該是因為工作做得好而受到稱讚，而不是因為在辦公室待得久，管理者不該把“生產效率”和“工作時間”混為一談，有的人也許可以用更少的時間，完成兩倍的工作呢。

73. 為了讓組員把辦公時間用在正確的地方，並提高部門的工作效率，專案經理不但要為他們排除任何不必要的會議、報告和雜事，還要協助他們好好運用寶貴的上班時間。您應該協助組員安排適當的每日活動表，用一些小技巧，讓組員有長段又不受干擾的時間，適合進行開發工作。

74. 如果您關心組員的生活，就不要讓他們把全部的時間都投入在工作。每天只要確定他們賣力工作了八小時，就可以把他們趕出辦公室了，當然這樣做也許會有老闆看不順眼，但是如果您像我一樣相信均衡、健康的生活是一切創意的原動力，就堅持這份理念吧！

75. 每週工作4 0小時並不是金科玉律，只不過是美國的傳統，而軟體開發專案大都以此為前提編定日程表。所以如果一個專案需要程式設計師每週工作40 小時以上才能趕上進度，就表示有問題，也許是日程表定得太樂觀，也許是程式設計師需要再訓練。不管怎麼說，這個問題一定要認真解決，絕對不應該讓程式設計師加班來彌補這個漏洞。