靈活是一種實踐，隻有在落地才能取得真正的價值。而實踐中每一步的進展都是通過解決問題而得到的。但是源源不斷的問題，也會讓靈活團隊内部産生危機。
以軟體開發為例子，常見的内部危機，包括因與重要關系人溝通不暢導緻發生沖突、研發節奏出現問題，技術團隊内部對方案的了解偏差較大、靈活實施對研發團隊成長促進慢等等導緻成員對靈活導入的懷疑等等。對于靈活教練介入項目後，應先與成員進行溝通，收集到核心問題，然後按優先級等級進行逐個擊破，用一句話說就是“先救命再治病，恢複常态後進行日常保健”。在筆者掌握到的靈活案例中，一般有三大難題是每個靈活團隊leader必須去破解的。
一、靈活實施的三大問題
問題一：如何解決與重要關系人溝通不暢導緻的沖突問題？
重要關系人對靈活團隊的影響深遠，根據pmp的關系人矩陣的描述，業務上司是最重要的關系人，但是往往沖突與這位最重要的關系人身上，如業務上司不滿功能上線的時間為什麼拖着這麼差，因為商機是有時間視窗的，錯過了上線也沒有意義，而且還有很多bug。而靈活研發團隊人員則認為需求經曆需求澄清、系統設計、研發以及測試，在這麼多時間内上上去已經非常給力了。
造成雙方的看法沖突，主要在溝通不透明的情況下，各方的判斷前提有差異導緻結論不同。業務上司這個idea也許是通過一個月的市場調研得到的，其了解的是這個過程是一個月+疊代周期（一般是兩周），一共6周時間。而技術團隊，了解的過程就是疊代周期裡面這兩周，而且這兩周裡面還包括了對需求的确認，有時需求價值也沒有明确傳遞到團隊中，其實總感覺到好像這需求是拍腦袋的事情，經常又急又沒有價值，純粹試錯而已。歸納起來就是溝通缺乏透明。
破解方法就是找到最核心的問題，透明出來，并促進互信和了解一緻。案例中提供兩個方法：業務看闆以及每周業務站會。
- 業務看闆主要是對需求
進行粗粒度的整理，分為需求落地狀态、上線計劃期望以及需求清晰度。
需求落地狀态辨別各個需求（未分解成使用者故事）處于idea、構思、待拆WIS、設計研發以及已上線，這個子看闆，讓業務上司的需求從閃現到上線的過程，全體成員都能及時識别到。
上線計劃期望子看闆，則明确在近2-3個月份中各個沖刺sprint的重點内容。
需求清晰度子看闆，則對PO的需求準入進行了限制，讓需求更明确得到研發團隊的了解。
這個業務看闆，建議放在業務上司和PO必經之處，讓業務上司随時可以了解項目的進展，減少了資訊的不對稱。
2、每周業務站會
每周業務站會為技術負責人與業務上司創造直接溝通和澄清問題的機會，之前靠PO中轉資訊，現在增加了一條直接溝通的管道，讓問題透明出來，促進互信和了解。一般建議會議不涉及太多細節，流程中PO先簡述業務和需求的情況，業務上司或者營運可以進行補充和提新需求，然後技術負責人進行研發進度通報。
解決了與重要關系人沖突問題，讓項目團隊得到了生存下來的機會。也進行就是把命救下來。
問題二：如何減少浪費和衰減，提升品質？
這個問題，很多時候表現在團隊頻繁加班導緻效率衰減，研發團隊内部對技術方案的了解差異導緻技術方案變更，測試時間被壓縮等。其奧中原因主要是并行工作出現在跨疊代周期裡面，導緻缺乏專注。
很多時候，我們會把上述情況歸因為業務方要求快速上線，導緻需求還不夠清晰的情況下倉促開始設計研發。沒錯，業務方肯定希望快速上線，來取得市場的回報，進而驗證需求。但是經過對問題一的解決後，業務方更希望項目能以穩定的節奏推進，能得到預期的功能，而且功能的品質是有保證的。
既然明确了業務方的核心訴求，那麼們的解決方法就建平穩的timebox以及組織回顧會。
1、平穩的timebox
如果現有的疊代周期無法消除跨周期的并行工作，那麼我們就改變研發工作安排，幹掉所有跨疊代的并行工作，進而建立平穩的研發節奏。也就是我們把timebox給定出來了。Timebox是靈活團隊提升的基礎，并為團隊争取到提高品質争取到時間。
（調整前）
（調整後）
2、回顧會
真實有效的組織回顧會，檢視出真正的問題，建立有效的标準，統一認知，解決好協同問題。案例介紹回顧會可以讓團隊投票把最需要解決的問題選出來，确定責任人、解決時間，以及方案，并通過告示闆公示出來。
問題三：如何讓成員擁抱靈活，走行自管理？
團隊成員自我管理是靈活的一個目标，但是如果才能讓經曆、性格和能力各異的成員去主動擁抱靈活，走向自管理呢？這個問題作為靈活教練也必須深思。
對于團隊leader來說，内容傳遞、團隊成長、個人成長等三方面的共赢是靈活實踐的目标。很多時候，我們無法在金錢上進行激勵的時候，我們可以通過激勵個人成長去完成這點。主要方法：1、輪值疊代牽頭人，2、路線圖優化
- 輪值疊代牽頭人
這個是對骨幹進行培養的方法，重在發揮他們主觀能動性。可以選擇有一定經驗的骨幹，輪流疊代中擔任牽頭人，進行需求對接、任務拆分、結對設計，然後技術負責人組織評審，這樣讓骨幹去感受高于他們崗位之能的工作，體驗一把充當團隊leader。經過這樣一個過程，骨幹得到了成長，更容易了解作為leader的艱辛之處，也對靈活的優點有了深入的了解，在工作中發揮更大的主觀能動性。
1、路線圖優化
在開始的靈活開發流程中（經常是小瀑布的流程），産品在構思下一個疊代的需求，研發在開發本疊代的功能，而測試則在測試上一疊代的代碼。一般需要上個疊代周期才能上線功能。 好一點的，則是産品在探索新需求，而上個版本需求正在本疊代中開發和測試。
但是這裡就存在一個問題，那就是開發和測試對需求探索的價值沒時間掌握，也在新需求價值的傳入上大打折扣。如果研發和測試同時進行，實作自動化測試，那麼就縮短了回歸測試的壓力，整個團隊對新需求探索過程投入大，對傳遞的品質就更有保證。
誠然，需求探索、功能研發和測試三者如果能同時進行，那麼則最吻合靈活的要求，但是一般條件下，達到第三步已經非常不易。
二、三大難題的通用解決流程
經過對上述三大難題的逐一破解，我們得到了對應的解決之道。接着我們把這些難題解決流程串聯起來，為大家提供一個通用的解決方案
- 先解決生存問題。一般是與重要關系人有關，其中最重要的是業務上司。
- 推動透明。關鍵人員建立直接溝通的通道
- 形成Timebox。在Timebox實作專注。
- 發動大家解決問題。在回顧會中讓團隊自己發現問題和解決問題。
- 激發團隊。激發團隊自管理，并看到需求的價值。
- 問題不斷湧現，做好心理準備。
三、結語
對抗層出不同的問題，最好的應對方法就是建立自己的靈活思考系統。作為leader，首先要從組織實施的目的入手，因為靈活實踐是建立在特定的組織文化中oqi的，脫離了這土壤因素，實施的價值則喪失。而組織導入靈活的目的，主要是更好地傳遞、提升能力、更有價值的傳遞、帶領團隊成長以及提升個人能力。
到達技術團隊leader層面，應該是基于組織的目的，實踐的目标就是更有價值的傳遞、帶領團隊成長以及提升自身的能力。其中人因素的部分，最為複雜。更需要我們通過内驅因素，如職場進階、自我實作等方面進行思考和引導，方可讓團隊和個人在靈活的實施中持續地得到收益。
最後，文中除了腦圖外 ，其他圖檔素材來自楊大鵬老師，在此深表感謝。