打造敏捷的自組織團隊

　　敏捷思想的出現讓我們看到了新的曙光——以更低的風險、更高的效率開發出更具質量的軟體產品。正因如此，敏捷方法得到了業內足夠的重視並使各路團隊相擁實踐。然而，即便我們對於各種敏捷原則、正規化、方法和流程瞭如指掌，仍會發現其所給組織帶來的改善遠達不到我們的預期。這究竟是為什麼？造成這種困境的根源並非我們學得不精，而是實踐不到位。

　　在我看來，敏捷宣言過於簡單（好吧，是宣言總得簡單一點！），以至於足以讓人對之產生誤解。比如：“可以工作的軟體勝過面面俱到的文件”容易讓人忽視對必要文件的重視；“個體和互動勝過過程和工具”容易讓人誤以為有了面對面的溝通就可以忽視適宜的過程和易用的工具所帶來的巨大正面作用。就我的觀察，只要軟體開發活動中忽視了必要（言簡意賅）的文件、適宜的過程及易用的工具就一定“敏捷不起來”，因為它們是塑造訓練有素的個體所需的重要素材，而個體正是敏捷原則中所提到的自組織（開發）團隊的組成單位。團隊是否做到自組織是檢驗敏捷思想是否真正落地的重要判定依據。然而，團隊要真正做到自組織卻面臨很大的挑戰，讓我們分別從幾個方面加以探討。

　　首先，從專案管理層面加以審視。最近面試了一個專案經理，他在華為和騰訊兩家公司都幹過，從與之的交談中很明顯地看出他對於敏捷軟體開發有著良好的實戰經驗，也對實踐中所碰到的困境有著自己獨特的思考。然而，當我問他“實施敏捷軟體開發的最大挑戰是什麼”時，他的回答卻是“專案難以如期完成”。得知他的這一回答後，我立即告訴他“儘管你談起敏捷時頭頭是道，但你內心深處並沒有真正擁抱和理解敏捷”。在告知他我為何得出該結論後，他抱以微笑並對我的觀點加以認可。我估計與他有同樣想法的專案專案管理者大有人在！

　　“響應變化勝過遵循計劃”這條宣言告訴我們，軟體專案的評估是為了適應變化而非為了遵循計劃。更深一層的含義是，專案計劃應當保持一定的彈性（指計劃時間可以經常適時地調整，專案管理也得敏捷！），即如期完成專案計劃並非是敏捷所倡導的，她所倡導的應是持續地以更高的效率完成高質的軟體開發工作。然而，受傳統專案管理思想的影響，我們大部分管理者仍然以專案是否如期完成作為一個重要的考核指標。其實，對專案計劃要求越是精確（這裡的“精確”是指計劃一旦制定就得嚴格如期執行，或者我們說專案計劃很具“鋼性”），實現自組織團隊的困難就越大。為什麼？

　　事實上，不論軟體開發工程師的經驗多麼豐富，要真正精確評估實現一個軟體功能的時間在很多情形下幾乎沒有可能。當然，現實中存在另一種“精確”，即透過更大的時間冗餘使評估顯得“精確”。這所導致的直觀結果就是，最終單從專案計劃上就能一眼看出“根本不敏捷”。專案計劃一旦不具一定的彈性，所產生的另一個問題是開發工程師在實現功能時根本無法將一個功能做到讓自己滿意，因為將時間評估得偏少這類事總在發生。原因在於很多工程師迫於管理層的壓力，不會將時間評估得保守，而是報著“我加加班應當可以搞定”的心態。最終的結果就是，工程師為了按計劃完成工作只能“缺斤少兩”地做事。

　　讓專案計劃保持一定的彈性會讓很多管理者（包括專案經理自己）提出一個問題，即“那我如何知道專案是否進展順利呢？”事實上，專案是否真正進展順利並不能簡單地從計劃的執行情況看出，因為軟體的真正質量和開發效率並非體現在專案計劃的鋼性上，管理者在這種情形下能做的除了信任團隊外，去了解更多的團隊狀況、技術細節或許有助於平復自己的焦慮情緒。千萬別忘記，沒有信任就沒有敏捷！也千萬別忘記，敏捷意味著更高的開發效率和軟體質量，而專案計劃是否如期執行根本沒有完全代表這兩個訴求！

　　值得一提的是，我並非主張管理層該盲目、簡單地信任團隊，在之前一定要確保開發團隊中存在合適的人可能讓團隊自組織起來。但管理層一定需要意識到的是，即使團隊中存在那樣的人，也要配合適當的管理方法才能讓那些人真正將團隊帶向自組織。

　　其次，從基層技術管理的角度加以剖析。技術管理的核心內容是提高團隊技能（參見《技術管理的核心內容——提高團隊技能》），但不少基層技術管理者從技術走向技術管理崗位後，將（絕）大部分精力投入到專案管理事務中，忽視自己所應承擔的團隊管理責任。更為可怕的是，這類人很容易將團隊的自組織能力放在一邊，既聽不進團隊發出的聲音，也不會去刻意培養，這種管理模式造成我們永遠得不到真正自組織的團隊。

　　我在《如何做好基層技術管理工作？》一文中談及了動機與方法兩大方面，在本文討論的主題下需做一些補充。當團隊還不具備自組織能力時，基層技術管理者起到至關重要的作用。第一，重視工作安排策略。大多情況下，由於專案的時間壓力，基層技術管理者很容易採取根據工程師的技能安排他做最能獲得效率的工作這一策略。然而，長期採用這一策略將導致工程師所熟悉的模組趨於單一化，結果導致工作安排缺乏彈性，變成“每個蘿蔔都挪不了坑”。這種境況很不利於團隊技能的發展，也使得團隊很難進入自組織的狀態。更為合適的做法是，在每次迭代中安排少數幾個工程師做他們不擅長的。多次迭代下來，工程師所涉功能面將更廣，這就為專案計劃時的人員安排帶來了更大的彈性，也使得各功能模組的程式碼能在多個工程師的視線範圍內，從而更容易落實質量。第二，如果不能營造一種讓工程師暢所欲言的團隊文化，則同樣沒有將團隊帶入自組織狀態的可能。在我看來，只要是一名管理者，如果你的下屬不願向你吐露工作中的心聲，那證明你已失敗！第三，在制定開發計劃時，基層技術管理者一定要持續地將一隻眼睛盯住改善部分，而不能只關注新功能開發。不斷改善的目的，是為了防止技術債高築而使得程式變更缺乏彈性。第四，團隊在走向自組織的道路上，一定存在不少對既定目標做適當變更的情形，此時基層技術管理者一定要做好上下間的溝通工作，讓團隊的工作狀態對高層管理者更加透明。資訊的透明化有助於管理高層真實瞭解團隊的現狀，為信任提供良好的支撐，讓他們不至於過於關注專案計劃的鋼性。第五，確保軟體設計質量與編碼質量落實到位。換句話說，確保在團隊中落實概要設計評審和程式碼審查等工作流程。

　　我相信很多基層技術管理者想將團隊帶好，但不少人受能力、惰性和胸襟所限，根本不理解什麼是自組織團隊，也不願意學習與自我改善，還放不下自己是“領導”的架子。然而，這類人正是自組織團隊要“消滅”的。於是，我們面臨這樣一個悖論——“為了自己不被‘消滅’，這類人一定帶不出自組織的團隊”。不難發現，合適的基層技術管理者是打造自組織團隊關鍵中的關鍵！

　　再次，我們從工程師的角度給予考量。自組織團隊對於工程師來說究竟意味著什麼？第一，技能多樣化。技能過於單一往往會造成專案計劃的實施瓶頸在於某個人無可替代地處於專案的關鍵路徑上，這使得專案的人員安排缺乏彈性。要實現技能的多樣化首先要從管理著手，即需要基層技術管理者有意識地透過工作安排加以培養，這一點我們前面已談及。另一方面，工程師也得有意識自我培養，千萬不要將自己的工作錨定在很窄的範圍。為了避免出現這種境況，工程師對自己的工作內容應透過編寫言簡意賅的文件（比如概要設計、指南等）的方式讓他人可以方便地接手。顯然，文件的編寫能力也涵蓋於技能多樣化之中。第二，律己和律他。“自組織”這個詞從表面就向我們傳達了“紀律”，紀律意味著質量與效率。工程師個體首先需有良好的自律能力，對於團隊所達成的各種共識（規範、流程等）努力實施到位，對於已存在的好方法、好習慣積極地模仿並跟隨，而不是簡單地打破並自立門戶。除了良好地律己我們還得關注律他，透過指出他人不足並給予幫助的方式讓整個團隊維持良好的工作紀律。第三，良好的方向感。這種方向感源於清楚地知道產品的定位與戰略，並基於此而形成的、清晰的軟體開發策略。良好的方向感使得工程師清楚地知道技術的真正價值在於為產品的核心競爭力提供強有力的支援，並努力在產品與技術之間獲得平衡。在我看來，簡單地偏向產品或技術，從長遠來看對於整個團隊都會是一種災難。第四，主動承擔責任。面對責任，與“主動承擔”相反的方式是“防禦”或“逃避”。自組織團隊一定不會害怕責任，當出現問題時工程師會主動承擔責任或幫助他人解決，呈現的是一種互幫互助的良好協作氛圍。第五，自發地持續改善。在具有良好方向感的自組織團隊中，工程師會時刻關注開發工作中的點滴改善，透過持續改善的方式從技術層面不斷地將產品推向更高的品質。

　　從專案管理、技術管理和工程師三個緯度的分析可以看出，真正的敏捷自組織團隊需要從上到下、各工種的理解與配合才有可能打造出來。“敏捷”所強調的更多的是“彈性”，因為具有良好彈性的團隊在面對各種壓力時才具韌性。試想想，如果個體被桎梏於只能容下身體的空間中，那麼我們有可能做到（伸手）“敏捷”嗎？

　　真正的敏捷不是形式，而是團隊的文化與能力。如果不注重從文化與能力上去塑造，無論我們對於敏捷之形多麼在意和刻意臨摹，我們永遠只能遊離於表面。