original address
[一．奠定基礎]
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 小時以上才能趕上進度，就表示有問題，也許是日程表定得太樂觀，也許是程序設計師需要再訓練。不管怎么說，這個問題一定要認真解決，絕對不應該讓程序設計師加班來彌補這個漏洞。
posted on 2008-01-12 23:39
七星重劍 閱讀(422)
評論(0) 編輯 收藏 引用 所屬分類:
亂七八糟