英文原文：10 mistakes that software team leads make
本文是roy osherove在skills matter的一次發言，他介紹了團隊領導經常會犯的十個錯誤，並提出了一些解決方案。
roy首先提出幾個團隊領袖可能遇到的一些問題：
我如何說服我的團隊做某件事情?
我該拿團隊裡的那個專門搞事的傢伙怎麼辦?
我該如何做乙個團隊領袖呢?
我們為什麼無法遠離無謂的爭吵（編者注： fighting fires 譯為「救火」更合適 ）呢?
我會不會失去朋友呢?
…他說這些問題其實纏繞他多年，接下來他也逐一做出解答。他正在寫一本叫《開發團隊領袖手記》的書，裡面也涵蓋這些方面的內容。
下面就來說說這十個錯誤:
#1沒有認識到團隊的成熟度
這點是首要注意的地方，因為後面談到的問題都是提及團隊的成熟度。roy說，可以從3個層面來評價乙個靈活團隊的成熟度。
混亂學習
自我引導
混亂
乙個混亂的團隊就是哪都覺得很忙。可能他們總是在救火，或一直都被要求在非常有限的時間做太多的事情。但其實結果都一樣：混亂。沒有人有任何時間變得有條理，沒有人有任何時間學習新的知識，因為他們一直都在忙這忙那。如果你問我的話，這個團隊明顯成熟度不高。因為所有人，要麼耗盡精力，要麼感到沮喪，因為缺乏機會學習，而最終好的人都會離開。但是，roy說這種混亂其實非常常見，而我也很贊同。如果你是在這麼乙個混亂的團隊裡當領袖，秘訣就是要正確的行動起來，你必須自信和強勢。
當船快要沉的
時候，你需要的是乙個
發號施令的
領袖，而不是開會。
乙個混亂的團隊裡的領袖，必須堅定立場，而且可能必須要和領導層說清楚，整個團隊並不能把他們要求的所有的事情都完成。這是乙個艱難的角色。他必須堅定的做出一些艱難的決定。
管理要做得
對、做得好是一件很
艱難的工作。
但為什麼作為乙個團隊領袖，你必須自己做出這些艱難的決定，而不是和團隊商討呢？答案很簡單，因為沒有足夠的時間。通過你自己做出這些執行上的決定，你讓你的團隊得到一些喘息的餘地，可能也就是這些餘地讓他們把手上的事做完。當然，可能有些你做的決定是錯的。這沒關係，人生就是這樣。但這是為了更重要的正確的事情，也就是讓你的團隊有成長到另乙個層次的空間，乙個不斷學習的團隊。
學習
這個層面的成熟度是團隊自我管理的昇華，但是團隊成員還是有需要得到指導的。乙個團隊領袖必須持續不斷的為他的團隊成員帶來一些挑戰和質疑，甚至可能是功課。目標就是讓團隊裡的成員每週都有進步，開始學會解決自己遇到的問題。
所以，你要怎麼做？
作為乙個學習成長的團隊裡的領袖，你要讓團隊裡的成員學會解決自己遇到的問題，然而成長為自我引導的團隊。如果某乙個人帶著乙個問題來找你，你應該鼓勵他們自己想辦法解決，並問「你會怎麼來處理這個問題？」來強迫他們思考。
自我引導
成熟的第三個層次就是自我引導型的團隊。這是我們所有人都想去到的地方。在這樣的團隊裡面，領袖更像是乙個導師。他不需要像在乙個混亂的團隊裡那樣為團隊做各種執行方面的決定或告訴人們該做什麼。但即使是在乙個自我引導的團隊裡，團隊領袖還是需要最少50%的時間在團隊上面。
所以，第乙個錯誤就是不能正確認識到你的團隊是在什麼成熟度，也因此不能夠正確的領導你的團隊。如果你當他們是自我引導型的團隊在運作，但其實他們事實上還是在混亂的狀態，那麼不久你就會在一條河上像沒有槳似的亂竄。
#2 害怕授權
如果你常常習慣自己一手包辦，可能要你下放責任給其它人是比較不容易接受的，尤其是你覺得其它人並不能把事情做好的時候。
如果每個人都
對目前手上做的事情都感到很舒服，沒什麼挑戰的
時候，就是你做的不對的
時候了。
當你要授權的時候，你必須做到責權對等。這些外加的責任，會把他們拉出那個安全區，這是一件很好的事情。適時挑戰一下你的團隊和拉他們出安全區才可以讓他們成長。
#3害怕參與
這一般來說是溝通不夠有效，但roy談得更深入。
#4安撫
公共要素(bus factor)——這是什麼？公共要素指的是開發過程中的一些共同因素。這其實說的就是某些個體掌握太多資訊。我看到太多地方有這種情況，無論是好的還是壞的專案。所以我覺得這很正常。但roy提到的是你不應該因為他們掌握了大量重要的專案資訊就只安撫這些個體。你對待乙個公共要素為1 (也就是說他乙個人如果被公車撞了的話，專案就倒了)的人應該和別的任何乙個人一樣。我非常喜歡在人身上定義乙個公共要素的主意，因為它讓我想起了六度分離理論。
#5疏遠
這個應該是說由於太多的會議或郵件等煩雜事情要處理，導致基本上和整個團隊實際的工作脫節了，最終疏遠了。這個和六度分離理論沒有關係。
#6太理想化
不確定我是否同意這個術語，但roy的意思是認為所有人都能清楚明白你說的意思，但實際上你並沒有把自己的觀點闡明。我想這點的關鍵是說當你和一群人相處，尤其是對乙個靈活的團隊來說，假定他們擁有和你同樣的知識水平和理解力是不正確的。你應該用最合適的方式去溝通，而不能做太多的假設。
#7責備
如果你認為某個人是垃圾，那你就會有意無意的以這個為藉口，不讓他參與到團隊的事務上來。這世界上總有這樣的垃圾人物，但你所要做的是了解他們的短處，並把他們提公升到整個團隊的水平，而不是疏遠他們，因為這樣就意味著一直揹負這些沉重的包袱。
#8忽略影響行為因素的力量
你必須認識到那些會作用到個人身上的行為因素的力量和知道它們是如何影響個人的。主要有這麼三種行為因素：
所有這些因素都會影響到乙個團隊是否能夠成功。所以你必須找到有沒有什麼因素正在影響團隊的敏捷度。其中乙個外界環境的因素可能是硬體裝置不足夠支撐你所需。比如說你沒有預算添置一台持續整合的伺服器，那你幾乎永遠無法變得敏捷起來。
#9害怕太獨斷
很明顯這在英國和挪威是很普遍的，但在丹麥不適用。我敢打賭你不知道。但這據稱是真的。獨斷，就是堅定自己的立場並拒絕任何你感覺不能接受的事情。如果你是在乙個處於混亂狀態下的乙個團隊裡面，那你必須非常獨斷。在乙個處於混亂狀態下的乙個團隊裡面，懼怕獨斷是致命的。
#10不重視承諾
這裡說的是模糊其詞。roy說你應該任何時候都對專案期限負責。當你對團隊談論的時候，確保他們也告訴你每個任務的具體完成時間。很明顯，讓他們作出承諾，他們會更有激情的完成任務。roy的建議是當你開會結束的時候，並問每乙個人他們下一步要做的事情是什麼，確保他們的回覆是什麼時候前做完什麼事情。但是，任何人都只應該承諾他控制範圍內可以完成的事情。承諾一些要別人替你完成的事情是沒有意義的。還有，一但你發現你無法按時交貨時，讓整個團隊的人都知道，他們可能有辦法幫忙並讓你及時完成任務。
問題和解答
下面這些問題和解答其實持續很長時間才得出。我用bullet表單總結了一下，因為bullet的樣式非常好。
SQLSERVER DBA容易犯的十個錯誤
翻譯自 除了排名前十的錯誤之外，其他排名靠前的錯誤 拋開sql server方面的錯誤,這些錯誤主要體現在開發或者是設計的時候 1 不合理的規範和不合理的資料庫設計 2 沒有設計好可伸縮性的需求 3 沒有資料庫效能基線或基準 4 索引的問題 5 對語句調優不夠重視 錯誤倒數第十位 磁碟 只要磁碟空間...
SQLSERVER DBA容易犯的十個錯誤
翻譯自 除了排名前十的錯誤之外，其他排名靠前的錯誤 拋開sql server方面的錯誤,這些錯誤主要體現在開發或者是設計的時候 1 不合理的規範和不合理的資料庫設計 2 沒有設計好可伸縮性的需求 3 沒有資料庫效能基線或基準 4 索引的問題 5 對語句調優不夠重視 錯誤倒數第十位 磁碟 只要磁碟空間...
初創團隊最容易犯的十個使用者體驗錯誤
怎樣才能提公升我的 或應用 的使用者體驗？這是乙個即常見又沒有標準答案的問題。特別是對於初創型團隊及產品來說，這個問題所涉及到的影響因素更是多種多樣。幸好，有一些實踐準則可以幫助我們朝著正確的方向前進。在本文中，我們將了解一下初創團隊在塑造產品體驗的過程中有可能犯下的錯誤，以及怎樣避免這些問題的發生...