如何激發團隊潛能？

每一個技術人員最終可能都會走上管理崗位，從最初的開發 Leader、到部門負責人、甚至到 CTO,這每個角色的轉變，都須要付出巨大的努力去進行思惟的轉變。最近讀的《受權》這本書可讓咱們更好地勝任管理這個崗位。

本書的做者馬凱特是一名海軍軍官，全書講解了做者在 1999—2001 年指揮美國海軍聖塔菲號攻擊型核潛艇，在一兩年的時間裏將本來管理混亂、士氣低落、倒數第一的聖塔菲號打形成太平洋艦隊中凝聚力、戰鬥力俱佳的艦艇，並贏得不少獎項。

書中以在聖塔菲號上發生的各類事件爲例，講述了不少觀點和方法，印象比較深入的有如下幾點：

• 領導者-追隨者到領導者-領導者的轉變
• 我計劃...
• 重要的事情反覆強調
• 高於本身的職責
• 流程是把雙刃劍
• 鼓勵質疑
• 追求卓越，而不是減小錯誤

領導者-追隨者到領導者-領導者的轉變

能夠說，大部分的企業以及馬凱特領導以前的聖塔菲號潛艇的管理方式都是「領導者-追隨者」模式。員工都是聽「命令」作事，能把安排的事情按時完成就已經很不錯了。

有一次，馬凱特下命令將電力推動裝置的轉速由 1/3 提高到 2/3，命令一層一層地傳達到最底層的執行人員，才反饋說電力推動裝置沒有 2/3 轉速。其實在接收第一道命令的人員就知道沒有 2/3 轉速，但由於是上級下達的命令，即使是錯誤的，仍是照常執行。

咱們平時工做中，相似的事情家常便飯，因此說在「領導者-追隨者」模式下，領導者的能力和眼界就成爲了團隊的瓶頸，不能充分發揮每一個人的才能。

而「領導者—領導者」模式的核心是讓員工有充分的決策權決定作什麼和怎麼作，整本書就是在講解怎樣慢慢轉變成「領導者—領導者」模式。

我計劃...

「我計劃...」是一種具體的手段，指的是，在彙報工做時，以我計劃做爲開頭，後面接本身準備怎麼作，以及可能有什麼風險等。目的是爲了讓員工能主動思考，而不是被動接受。

現狀

領導：小王，系統中須要添加日誌功能，可使用 log4？
小王：功能已經實現了
領導：日誌能存儲到數據庫中嗎？
小王：如今只能記錄到文本中
領導：不一樣類型的日誌有區分嗎？
小王：如今只記錄在一個文本文件中
領導：......

改進後

領導：小王，系統中須要添加日誌功能，想一想怎麼實現？
小王：在 dotNET Core 中，比較流行的就是使用 NLog 和 Serilog，我對比了下兩個組件，Serilog 的擴展性更好，有不少的插件可使用。我計劃這樣來實現：

• 日誌大類能夠分爲，系統日誌和業務日誌，系統日誌用來定位問題，業務日誌能夠用來作審計；
• 每一個類型中能夠根據不一樣的日誌級別進行分類處理；
• 可使用 dotNET Core 的過濾器或中間件來實現日誌記錄，方便代碼維護，使用過濾器仍是中間件，我須要作進一步分析；
• 暫時能夠先記錄到文本文件中，後續若是須要擴展數據庫或其餘方式也很方便。

領導：好的，按照你的思路先實現一版吧。

上面的例子不必定恰當，但應該能說明問題：
一、領導早安排任務的時候，不能條條框框限制太死，須要給員工足夠的空間；
二、員工在彙報時，應該有本身的獨立思考，儘量多的想到各類狀況，若是存在多種解決方案時，能夠都給出，並給出本身的建議和推薦理由，這樣領導只是作下確認就能夠了。

重要的事情反覆強調

當你引進一些全新的、亙古未有的東西時，有些人可以明白，在聖塔菲號上，咱們確實有一些軍士長立刻就明白了，好比沃爾舍科高級軍士長和拉森軍士長；有些人過一下子明白了；另一些人則要花很長時間才能明白。

什麼是重要的事情呢？

• 公司的願景
• 團隊的目標

每一個團隊成員只有充分理解了公司的願景、團隊的目標，才能將本身的我的發展和此聯繫起來，實現共贏，但每一個人的理解速度有差異，因此須要反覆強調，不能嫌麻煩。

好比目前咱們團隊的目標就是按時交付高質量的迭代版本，那麼只要是和團隊開會、或私下溝通討論，都會反覆進行強調，直到每一個人都可以深入理解，理解以後纔可能願意更多地去思考，纔可能在具體執行的時候更貼近團隊目標和公司願景。

高於本身的職責

每一個人都很習慣作「份內之事」，缺少思考，長時間下去就會從一個初學者變成一個熟練工，工做 10 年，也就是 1 年的工做經驗重複了 10 年。持續思考，總結，提高本身的技能而且能同時朝着團隊目標和公司願景在前進，這樣你的能力纔會超出你的職責，纔有升職加薪的可能。每一個人都能如此，團隊也就變得強大了。

最近有團隊成員和我溝通，說天天都只是在改改 Bug，作一些小功能，感受沒什麼挑戰，這就是典型的將本身侷限在「份內之事」的表現。

再簡單的事情也能作到極致，前提是要清楚本身要作什麼，在作什麼。在開發中最怕的就是開發出來的東西不知道是作什麼用的，只是按照要求這樣作了。

因此在工做安排或者會議溝通時，須要添加一個環節：反向交底，分配的任務，每一個人須要說出本身的理解以及「我計劃...」，會議溝通時，也不能最後問一句，你們還有問題沒有？而後沒人回答，就此散會了，也須要每一個人都談談我的的理解，每一個人都能理解，會也就不白開了。

流程是把雙刃劍

任何公司都有各類各樣的流程，流程是手段不是目的。流程能夠幫助咱們進行管理，但必定不能受到流程的束縛。

由於潛艇部隊並無將救火做爲核反應堆操做人員的訓練科目。海軍所倡導的理念是：最好的操做應該是由最專業的人員按照標準工做流程進行的。

由於流程規定救火只能是專門救火人員才能進行，因此，在演習的時候，有一個地着火了，結果周圍的人所有都撤離。潛艇的走道是很是狹窄的，這些救火的人根本過不去，那邊要撤退的人也撤不出來，卡在那兒。而後那邊的火越着越大，若是真的是着火的話，就會形成嚴重的後果。

若是是朝着滅火的這個目的，確定是離火最近的人拿起滅火工具把火滅掉就能夠了。

鼓勵質疑

可以獨立思考，纔有可能提出質疑，在「領導者-追隨者」模式下，每一個人都是你說什麼我作什麼，都認爲領導說的是對的，那質疑就無從談起了。

鼓勵質疑是發揮集體智慧的一種手段，領導也不是神，也有會出錯的時候，這時若是可以有及時的質疑，就能避免一些錯誤的發生。

追求卓越，而不是減小錯誤

在平時的工做中，由於有各類考覈手段，每一個人都懼怕出錯，寫程序時懼怕出 Bug，那有沒有不出 Bug 的程序呢？答案是：有，具體能夠看看 Github 上的這個項目：https://github.com/kelseyhightower/nocode 。

固然，那個項目只是個玩笑，只要有代碼輸出就可能會有 Bug，若是是一個追求卓越的程序員，會想辦法去作重構，讓代碼變得更易讀、擴展性更好，在這個過程當中可能會出現新的問題，咱們應該多思考怎樣來解決問題，而不是規避問題的方式來減小錯誤。

以不斷減小錯誤的方式行事，最後結果就是金玉其外敗絮其中，後果終究仍是要本身來承擔，至今尚未誰能打破墨菲定律。

總結

馬凱特經過「領導者-領導者」的管理模式使將聖塔菲號有翻天覆地的變化，更厲害的是在馬凱特離開聖塔菲號十年內，這裏仍然人才濟濟，領導力獲得了傳承，這纔是最高境界。

若是領導者老是試圖「事事親力親爲」並依靠自身「人格品性」，他們一旦缺席，將會給組織的表現帶來巨大影響。

推行一種新的方式始終是困難的，但不試試怎麼知道呢？