1.工具不能代替思考
在我多年的諮詢工作和與許多組織和管理者的共事中，我發現了修復問題的共同套路，那就是管理人員相信工具可以“解決”給出的問題。當問題域被理解透徹，並且不可能有很多例外，以及每個人的行為方式相同的時候，這樣的做法很管用。不幸的是，很多現實問題並非如此。
太多次我目睹管理者使用組織範圍的工具鎖定到特定的工作方式。自然，該工具未能解決問題，並且阻塞了工作的真正完成。工具應該是用來提供幫助的，用來幫助防止已知錯誤的，並幫助我們記住重複的任務，而不是取代思考。
2.除非管理小組能夠真正懂得敏捷“轉變”的價值，否則它就不能發揮作用
許多管理者都犯過這樣的錯誤，那就是認為組織的其他部分在做出改變的同時，只有那些參與工作的人才需要“接受敏捷”。在企業中做這樣的統籌需要花費大量的時間和技能，因為你要關注於同步組織在不同水平的變化。
那些想要組織的一部分接受敏捷的組織面臨著真正的威脅。正如有句話所說，“要麼改變組織，要麼改變組織的方式。”
3.學習需要一個安全的環境
學習的必要經過是犯錯誤。在德雷福斯模型中，這意味著，特別是位於高階初級階段，人需要通過犯錯誤來學習。但是，當人們覺得犯錯會對工作造成壞的影響，會失去同事的尊重或在過程中會傷害到其他人時，那麼他們就不會冒犯錯的風險。
因為我熱衷於教和學，所以我想辦法創造了一個安全的失敗空間，在這裡失敗的話，可以通過犯一些基本的錯誤來學習。
4.每個人都可以成為領導者
我以前寫過這個話題的內容，因為這是一個非常重要的觀察結果。我看到的一個常見的思維模式陷阱是，人們覺得為了像一個領導，你需要去擔任領導的職位。但其實人們可以展示他們的領導力而不論其頭銜如何，並且可以通過很多不同的方式做到這一點，只需在沒有明確期望或要求的事情上採取行動。
5.架構師去寫程式碼往往能作出最佳決策
在我執行的Tech Lead courses中，我提倡技術領導者至少將他們30％的時間用來寫程式碼。花時間於編碼上有助於建立信任，尊重和理解當前的系統。在做架構決策時，不考慮到當前系統的約束條件往往會造成錯誤的決定。
6.改變需要勇氣
我記得曾有人談論過XP values，其中有一點就是勇氣。勇氣是領導時所必須的，因為你要冒失敗的風險，以及嘗試一些新事物的風險/回報。沒有風險，往往就不會有很大的回報。
7.建立信任的關鍵是言行一致
有這麼一條古老的箴言，“依其言而行事，勿觀其行而仿之。”在現實中，不管你說什麼，人們首要的是會記住你是如何行動的。你得始終記得要言行一致。不一致的言行會損害相互之間的信任。說“no”或“現在不行”比答應做一件事卻沒有辦到要好得多。
8.成功的結對程式設計與良好的協作相關
雖然不是所有的結對程式設計環境都是健康的，但是我相信，當結對程式設計有效工作的時候，團隊往往具備一種更好的協作文化。許多開發人員更喜歡（長期）branch-based development的反模式，因為它推遲了反饋和潛在的衝突來源。
我把（可導航的）衝突當作協作團隊的一個健康標誌。推遲反饋，例如長期分支程式碼審查的情況往往會導致更多的不滿，因為它交付得這麼晚。
9.多模式思維促進更強大的結果
我在大學中最喜歡的科目之一是哲學概論，在那個學期中我們每週都會研究不同的哲學家。在我職業生涯的過程中，我漸漸體悟到多樣性的價值，並且開始通過多個角度來看問題。系統思想還認識到，事實可以用不同的方式來解釋，從而促進產生新的想法或解決方案。
10.認識到每個人都有不同的優勢
每個人都是獨一無二的，每個人都有自己的長處和短處。雖然我們傾向於尋找志同道合的人，但是擁有廣泛優勢的團隊才能走得更好。這一區域中的優勢可能會成為某個上下文中的弱勢，所以當團隊成員擁有更廣泛的優勢時，團隊會變得更強大。雖然優勢的差異可能會導致衝突，但健康的團隊會接受彼此之間的差異，而不是憎惡差異。
11.終身制學習
世界在不斷的變化，我們總有機會去學習一些新的技能、技術和工具。我們甚至可以去學習如何善於學習，有很多書籍，例如《Apprenticeship Patterns》和《The First 20 Hours》可以教你怎麼做好這些。
12.積極的影響迸發幸福感
《Drive》，一本膾炙人口的書，談論了人們如何通過朝某一目標前進而生出幸福感。根據我的經驗，幫助別人找到解決方法，對他們產生積極的影響，才是幸福的源泉。
結論
以上這十二個要點並非我在ThoughtWorks的12年時間裡所學到的全部經驗教訓，但它們確確實實是幫助我為客戶服務的比較重要的經驗教訓。
評論(1)