企業敏捷轉型的痛點在哪里？

很多企業已經走在敏捷轉型的路上，首先始于電信和互聯網公司，然后是金融行業，現在連零售這樣的傳統行業都在嘗試轉向敏捷。

從2001年敏捷宣言宣布到現在，已經有將近十五年的歷史。十五年，在我們這個變化迅速的軟件工程行業已經是一個非常悠久的時期了。敏捷并不是什么新玩意，而已經成為我們行業主流的管理運營體系。

如果一個企業還沒開始擁抱敏捷思想并付諸實踐，那它很快要就out了！原因很簡單，為了快速響應市場需求的變化，企業采用和擁抱一些敏捷的方法和思維是必須的。

走向敏捷并不表示完全放棄目前的工作方式。很多企業可能會覺得目前的運營有敏捷所不具備的優勢，但在這個快速變化的時代中，持續改進已經成為必然，敏捷有很多成熟可操作、可落地的改進方法是完全可以被拿來借鑒的。如果一個企業對現有的工作方式太執著，結果必然是逐漸邊緣化，直到被市場淘汰。

十年前，很多企業對敏捷有所懷疑，說敏捷不成熟。但如今形勢恰恰相反，一個還沒有擁抱敏捷的企業會懷疑自己到底出了什么問題，為何不愿意敏捷、為何敏捷不起來。

在2007年，每當我介紹敏捷，都一定會跟瀑布模式做個比較，解釋敏捷的好處。眼下我再給企業介紹敏捷時，已經不談瀑布了，大家都知道敏捷的好處，解釋也變得多余。我遇到的問題大多是如何讓敏捷落地，如何把敏捷帶給整個企業。

企業痛點在哪？

即使敏捷已經是主流了，一個企業也不應該為了敏捷而敏捷。敏捷是要解決具體問題的。企業具體問題在哪？有哪些痛點？涉及哪些方面？這些問題應該從組織結構開始梳理。

圖1展示了一個典型的企業組織結構。上層負責指定方向，規劃、預算、決策、治理和激勵。在執行層面會有業務部門直接與用戶對口。用戶的請求和期望由業務代表來收集。如果組織有復雜的系統應用組合，往往會有一個解決方案部門，負責整理需求傳達給開發和測試。開發測試交付的軟件系統由運維部門來運營和支撐。

我咨詢過的很多企業，從互聯網企業、傳統企業、到嵌入式產品廠商等，他們的組織結構大概就如圖1。

圖1 典型企業組織結構

雖然圖1是一個高度抽象的組織結構展示，但它有益于讓我們在討論企業痛點時找到具體聚焦的主體：是業務側，還是解決方案側；是開發測試側，還是運維側，亦或是決策層的問題？

企業的痛點一般是如何讓各部門端到端的更好協作，那么具體痛點在哪？瓶頸在哪？具體哪些部門必須更加敏捷靈活的運作來響應市場變化？

小范圍的嘗試、小范圍的效果

很多企業在嘗試敏捷的初期往往都會從一個小范圍開啟，大部份會從開發測試小團隊開始。小團隊的敏捷方法和理論非常成熟，比方說Scrum的小團隊迭代運作，極限編程（Extreme Programming）的用戶故事（User Story），持續集成（Continuous Integration），看板（Kanban）等。

圖2 小范圍的嘗試，小范圍的效果

小團隊敏捷運作的方法和理論是很成熟的。有能力讓小團隊敏捷落地的教練和資源也很多。

1. 如果企業的應用都是十人以下小團隊能夠完成的，那么實施Scrum和XP就會獲得一些效果。但如果只停留在小范圍的嘗試，必然只有小范圍的效果。

2. 如果企業有比較復雜的系統，開發團隊上百人的話，那Scrum和XP就遠遠不夠了。

不管企業團隊大小，如果企業敏捷落地只限于開發測試這一側，沒有執行層端到端的考慮，以及和企業上下對齊的思維，就不能發揮敏捷的潛能，就失去了獲取更大效益的可能。

沒有組織層面的支持，小團隊的良好效果也不容易持續，反而很容易倒退。組織一旦想踏上敏捷的道路，就必須要有決心，必須要有長遠的目標，必須考慮企業的整體敏捷轉型。

大型企業的挑戰

除了小團隊必須敏捷之外，一個擁有大型開發團隊的企業還必須解決一系列的問題。我與許多上千人企業的管理者和工作者交流他們面臨的挑戰，做了一個總結（看圖 3）：

圖3 大型企業的挑戰

這些企業面臨的挑戰包括：

1. 端到端的敏捷：如何讓執行層端到端的運作更加順暢穩定？包括前端的需求管理和后端的運維協同。前端的業務代表往往非常希望需求能夠快速上線，而后端運維則希望系統穩定，能不變是最好的。在這樣的矛盾中，大型組織必須思考如何建立一個快速又穩定的開發通道。

2. 跨團隊協作敏捷：團隊之間和項目之間如何協作得更好？每個小團隊都有他們的目標和工作量，團隊之間的工作計劃如何更好的對齊，減少協作的成本和不必要的等待或者沖突？我經常觀察到由于團隊之間沖突導致工作中不必要的拖延，浪費了時間非常可惜。

3. 用戶互動敏捷：如何更好得貼近用戶聆聽他們的需求？業界調查顯示，大部份開發后的功能都沒人關注，甚至沒人用。用戶對這些功能覺得無所謂，沒太大的感覺。如何更有效的理解“用戶真正想要什么”是一個挑戰，企業要考慮如何讓整個組織具備這樣的共情能力。

4. 人力敏捷：個人能力是非常重要的。在一個大的企業里，人員能力參差不齊，如何提高各個層面人員的能力，讓他們學會自我管理，是企業必須解決的問題。如果能夠達到這一點，就會減少很多的管理成本。

5. 戰略治理敏捷：執行層面運作如何有效的與決策層面結合？決策層的舉措如何有效的落地到執行層面？執行層面遇到市場機會時如何有效反饋到規劃層面從而指導方向調整？

6. 文化敏捷：敏捷以人為本。一個大型企業由于人數眾多，很容易忽略個人特別是基層的戰士。我們這個行業有“屌絲”和“碼農”這種說法，說明對基層不夠重視的情況長期存在。事實上他們也很有想法，有改進的意愿。如何激勵他們，發揮他們的價值和協助他們成長是企業文化建設中必須考慮的。

當企業在考慮以上的挑戰時，會發現小團隊敏捷運作的實踐，已經不是企業敏捷轉型所關注的重點了。小團隊有效的運作僅僅是個基礎，企業需要的是整個組織的戰略和布局。就像一名將軍或總司令，看的是整個戰場，不只是一兵一卒，看問題需要更加宏觀。

大型企業敏捷實踐

要解決一個大型組織面臨的挑戰，辦法不是沒有的。敏捷方法也在持續的演進中，從開始僅僅解決開發側的問題，到如今已經延伸到整個組織的運營體系中。目前，業界所強調的已經不是團隊的敏捷（Team Agility），而是產品端到端的敏捷（Product Agility），以及整個企業的敏捷（Enterprise Agility）。

圖4 大型組織的敏捷實踐

敏捷方法和理論有豐富的實踐（Practice）和經驗總結。這幾年來，我花了不少時間總結這實踐。在企業內，除了小團隊敏捷Scrum和XP之外，還必須引入許多方法和實踐（見圖 4）。

1. Super Scrum：不僅小團隊需要Scrum，Super Scrum拔高了一個層次，指導跨團隊和項目的運作。

2. 前端協同和后端協同：當然也必須有前端和后端的敏捷。前端敏捷包括敏捷的需求管理，有效的概念過濾，需求的ROI排序，尊重開發側的能力和容量而不強壓需求。后端除了穩定上線之外，避免上線的風險，提供運營的反饋。

3. 一個產品的演進是經過很多市場需求積累的。如果需求的實現沒有標準化，代碼和架構很快就會腐爛。標準化不僅僅能夠提高軟件本身的質量，也能夠提高開發的效率。有了標準，各職責都知道要做什么，實現起來簡單，評估也簡單。

4. 貼近客戶包括與客戶進行有效的接觸和快速反饋，還借鑒用戶行為分析，構建用戶的同理心，有效挖掘客戶和用戶的痛點，形成明確的產品定位。

5. 質量不僅僅需要后端的測試和驗證，更重要的是如何進行更有效的設計。這包括產品設計、業務設計、系統設計和不可缺少的代碼設計。這些設計能力，必須融入到各成員的習慣中。

6. 大型企業必須要有針對每個個體的回顧和反饋體系。這不是一件容易的事，企業不僅僅需要時刻聆聽用戶，也必須有效地聆聽每個成員的心聲。一個團隊開心就會積極，一個團隊積極，什么問題都能解決。

7. 以上的實踐必須有一個改進工作組來落地。這個工作組必須具備分析、說服、探索、嘗試、總結等能力，改進也必須有章法。

每個實踐是解決企業運營上某個問題的一種方案。每個實踐（Practice）有具體的操作指導，還有交付對象、交付物、職責、活動、模式等定義，這樣能夠方便學習和落地。建立實踐的架構也應該有方法。

大型企業敏捷轉型路標

一個大型企業不是說變就變的，需要一步一步來，首先選擇一些基礎的實踐來落地，然后逐漸延伸到整個企業的運營。圖 5顯示了一個可參考的大型企業的敏捷轉型路標。

圖5 大型企業敏捷轉型路標（共參考）

圖5的橫軸代表時間。從企業當前的運營來看，可以首先讓開發測試團隊內部運作，通過Scrum或XP的實踐，讓團隊先養成敏捷運作的習慣，然后是整個執行層端到端的敏捷運作，再延伸到上層的戰略治理和基層的大規模回顧與激勵，確保改進能夠持續。

有一個敏捷轉型路標非常重要，這是企業踏上敏捷轉型的關鍵步驟！在這條走向敏捷的道路上，企業必須一開始就明確改進工作組，來協商制定這個路標。有了路標，就能給各參與者一個統一的方針，管理他們的期望，從而推動企業敏捷實踐落地的方向和計劃，進而有助于衡量進展和效果。 敏捷就是響應變化。敏捷的落地也必須敏捷，也必須按照實際情況而演進，所以企業必須明確自己的步伐和節奏。經過以上的實踐積木化，就能夠有一個相對靈活的路標。希望通過以上的積木識別，協助你的企業走向敏捷。