翁雲峰 --稿定科技敏捷教練，廈門敏捷社群組織者
在印度有這麼一個神奇的團隊，他們有5000名左右的員工，每天要運送20多萬份餐，一份盒飯要經過3-4個人的手才能抵達目的地，交通工具只有火車，自行車，板車和雙腿，沒有任何單據，甚至都不需要客戶填寫地址。
在這樣的狀況下，每6百萬次運送中只有1次錯誤，準時正確到達率卻超過99.99999%，這遠超六西格瑪的標準。在業界，如果一個企業能達到 六西格瑪，就說明它能接近完美地達成顧客要求。在這一點上，達巴瓦拉甚至遠遠超過了聯邦快遞等使用現代技術和工具的快遞公司。
大家可能在想，能夠把事情做到這麼好，他們一定很貴吧？他們團隊的管理水平這麼高，是不是成員的基礎素質很高？
答案卻不是如此，這個團隊基本上都是半文盲或者文盲，每個月的收入也很低，平均每人400-500人民幣。
這個神奇的團隊，叫做達巴瓦拉。
大家有沒有注意到，外賣的每一個飯盒上都有編號？沒有英文單詞或者太複雜的詞，只有一串編號而已（因為他們很多人都是半文盲，所以編號資訊也力求簡單）。這些彩色程式碼告訴這些外賣小哥飯盒來自何處，輸送過程中經過了哪些火車站，最終要投遞到哪個建築物的哪一個辦公室。這個程式碼就是他們的通訊協議，可以保證飯盒並準確無誤的送達。如果出錯了，是誰出了錯可以非常精準被定義到。
他們獲得成功的法寶是時間管理，簡單的色彩分類體系和團隊協作。
我們很多的研發團隊，文化程度都很高，我們能不能做到這樣的準時交付率？很難。我們的團隊可以在發生問題的時候，能不能非常精確的定位問題和處理？也很難。
雖然達巴瓦拉是屬於另外一個行業的案例，相信也會對我們軟體研發有重要的參考意義。我想通過這個案例的分析提出一個關於團隊協作的觀點，也是我今天想談的東西。
1-團隊協作的境界
現在我們來看一張圖，大家試著想一想，我們團隊目前經常溝通的頻道是哪一個？
我們大部分的時候，都是在公開象限裡進行協作。而公開象限的大小，反映了團隊協作中的“資訊披露”和協作水平。
假如我們都在一個團隊裡，一般大家都很樂意談隱私象限，因為你需要把你知道的跟別人進行溝通，讓他們配合你。你需要貢獻一些祕密，一些私人的資訊，讓別人更加了解你。
當你不太清楚你自己的時候，比如你不知道有哪些東西需要改善，你需要請求反饋。你不知道你的程式碼寫的如何，這時候有個人跟你說你的程式碼寫得還不錯，他是在給你反饋，接觸你的潛能象限，這樣的人是教練。
教練在鼓勵你做自我揭示，你在不斷請求教練給你反饋，讓你知道你的潛能是什麼。
喜歡天文學的人應該都知道“熵增”這個概念。舉個例子，大家覺得你家是PPT左邊的樣子還是右邊的樣子？如果是左邊，那就特別好。如果你是右邊的狀態，怎麼辦？你需要整理。
大家有沒有意識到，你的團隊也可能是右邊的這種狀態？出了問題不知道原因是什麼，效率很低不知道怎麼改進，流程無法預估，交付總是看天氣。我們需要做的事情是什麼？教練除了幫你揭示自我幫你反饋之外，還需要幫你做整理，把過去無序的東西變得有序。梳理流程，梳理團隊，梳理產出，暴露問題並推動問題的解決，這個過程是“反熵增”，防止協作系統陷入到混亂和無序中。
增強溝通，反熵增之後，我們希望團隊協作達到什麼樣的境界呢？
我想要用八個字來總結，叫做“既定規則，無腦執行”。
規則是什麼？規則就是做事的方法和標準，比如DoR（就緒的標準）, DoD（完成的標準）和很多的working agreement（團隊一起制定的工作公約）。
為什麼是無腦執行？這裡不是真的說在執行的時候，我們只需要找到一堆idiot來按部就班執行就行了。這裡的意思是，當我們有了協作的規則和方法的時候，根本不需要佔用大腦的頻寬，不需要讓團隊在執行過程中耗費寶貴的計算資源，把有限的精力投入到最需要全神貫注的工作事項中去。
無腦執行的另外一個意思是，事情必須非常流暢，減少在執行過程中的摩擦，減少無謂的人力物力投入。
“以神御刀，不以目視刀。”
《莊子》
為了讓協作更加順暢，我建議大家可以參考這個“協作金字塔”。也就是教練，或者團隊管理者，或者有志於改善團隊協作的任何一個人，需要關注的一些要點。
我們需要定義一些規則和方法。
我們需要不斷提高資訊飽和度（提高團隊的公開象限）。
讓資訊流視覺化（提高公開象限；無腦執行）
及時反饋，及時校準。
2-敏捷教練是什麼
這是一個教練在分享會提到的，他說敏捷就是快速迭代，他分享的主題是《敏捷是騙人的》。
這個事情告訴我們什麼？有一些說法認為敏捷是萬能的，或者說敏捷可以做很多事情，但真的是這樣嗎？不一定。
上面我也提到了一些教練需要做的事情，比如需要不斷擴大溝通視窗，制定規則，減少執行摩擦等，我再提出幾個觀點。
敏捷教練應該是好銷售。我們賣什麼？賣“概念”。如果你在團隊推敏捷方法和敏捷流程，你可以參考以下的銷售思路，會讓你的整個過程更容易，大家不妨試試。
敏捷教練應該是防火隊員，更側重於做防火的事情，而不是做救火隊員（在問題發生前，提前感知到，提前準備預案，最好提前解決掉。）
教練應該是演算法工程師，為什麼？概念只是概念，最終落地的效果好不好，是需要在真實環境下，根據實際情況來做“調參”，通過不同管理演算法的引入，通過不同的實踐和結果反饋，不斷迭代優化的過程。
3-管理的演算法
敏捷教練是演算法工程師，那麼，他應該負責什麼樣的演算法？
比如我們應該要確保團隊持續不斷的做正確的事情，如何做？
我們可以把敏捷和精益創業、設計思維做連結，形成一套從問題發現，到問題的分解和試驗，到敏捷交付使用者價值的閉環。
比如我們有各種各樣的模式。
包括瀑布流程，PMBOK流程。
敏捷流程，看板流程。
敏捷界的網紅Scrum流程和精益流程。
這些都是管理的演算法， 都是敏捷教練這個“演算法工程師”的“演算法庫”，或者說“兵器譜”。必須非常熟悉，並且知道在什麼樣的場景下，該如何使用。
4-極簡之道
我們聽過很多道理，依然過不好這一生。
在這麼多方法論的基礎上，我們如何用於團隊？我們如何幫到團隊提升效能？
我們要讓團隊更加高效，而不是讓團隊搞笑。從搞笑到高效方法很多，比如在個人級別的GTD時間管理，清單方法，個人和團隊級別的“番茄工作法”等，都是在你嘗試敏捷方法前的有益嘗試。在切入敏捷實踐後，可以先從kanban方法開始，慢慢轉移到scrum方法（如果適用的話），再根據實際情況，轉換到SoS（Scrum of Scrum），LeSS，SAFe等大規模敏捷實踐上。
在選擇某一個具體方法實施之前，以下幾個問題值得思考。
首先，我們為什麼要提高效率？為什麼效率重要，如果沒有想清楚為什麼，怎麼做可能都不對。比如我們為什麼要兩週交付？如果產品本身的屬性，支援邊開發，邊測試，測試通過後可以直接灰度上線，我們就不一定要選擇兩週的交付週期，比如可以保持在一週的週期來交付。如果團隊的基礎設施還沒有準備好，比如單元測試，自動化測試，持續整合都還做不到，固定兩週交付可能會是一個災難。
其次，我們需要區分什麼行為是高效，什麼是低效，什麼是無效。我們可以通過對整體流程進行分析（比如使用value stream mapping等方法，來統計流程效率），獲得基礎資料，制定效率提升的目標。
再次，區分清楚後，我們可以採取措施和策略，來放棄無效的事情，減少低效的部分，提高有效工作的佔比。
最後這一點是區分於流程之外的，我們需要提升團隊的“溝通頻寬”，需要不斷擴大團隊的社交連線。比如一個小組可能互相都不太認識，或者在平常的工作裡還沒有形成很好的協作模式，在這樣的情況下，應該著力於讓團隊更多的溝通，加深在專案級別，和在非正式形式的溝通和協作（比如團隊建設等），讓團隊加快融合。這是你無論採用哪種方式方法，都應該考慮的基礎的部分。
文章來源：Worktile敏捷部落格
歡迎訪問交流更多關於技術及協作的問題。
文章轉載請註明出處。