從搞笑到高效，構建敏捷團隊的基礎原則

翁雲峯 --稿定科技敏捷教練，廈門敏捷社區組織者

在印度有這麼一個神奇的團隊，他們有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敏捷博客

歡迎訪問交流更多關於技術及協做的問題。

文章轉載請註明出處。