銀行組織的敏捷落地
年初在一篇文章 ofollow,noindex">《銀行IT的敏捷轉身》 中談了銀行IT普遍面臨的敏捷轉型問題，主要聚焦於這個數字化時代，銀行IT從過去的成本中心，走向科技能力中心的困惑和挑戰，文中我指出了敏捷轉型絕對不是IT一個部門的事情。可喜的是在這半年的時間裡，我們看到越來越多的銀行從數字化戰略的角度開始整體規劃敏捷轉型，把敏捷作為邁向數字化的一個堅實基礎來抓。
在經歷了幾家銀行大刀闊斧的改革後，我希望能夠把敏捷落地這個話題放到銀行整個組織下來跟大家分享幾點心得，藉機提醒正在高歌猛進的組織不要忘了初心，也為正在規劃轉型的組織提供一些前車之鑑。 利用敏捷宣言的模式，我總結了四個方面：
- 敏捷文化 over 敏捷開發
- 實驗探索 over 創新專案
- 平臺思維 over 微服務架構
- 員工體驗 over 開放辦公
我們應該都意識到了排比句的右手邊是這個數字化時代敏捷落地的一些核心領域，但我希望通過這樣的對比，強調組織級敏捷落地中左手邊領域的重要性。在下文中我將逐一展開這四個對比，幫助大家理解轉型過程中的一些核心關注點。（ 點選此處 或掃描二維碼觀看視訊回放）
敏捷文化 over 敏捷開發
金融是一個強監管和強合規的行業，在中美貿易戰和P2P暴雷遺患未除的當下，監管肯定是不會鬆綁的。某種意義上這是合理的，有多少客戶能夠接受自己在四大行買的現金理財產品出現了本金虧損（即使購買時風險已經告知）？如果這種情況出現在我父母身上，他們有可能就報警了。
這樣的行業管理模式下必然驅動出統一、標準化的服務（產品）開發過程及方法，以及隨之配套的企業文化。在面對不確定性市場時，這樣的方法和文化的弊端被放大了，沒有辦法快速響應變化，更無法激發創新。這是大多數銀行開始走向敏捷的原罪。
經過最近20年的演進，敏捷（軟體）開發實際上已經有了一套比較體系化的方法。Scrum、Kanban及XP的實踐都得到了廣泛應用，在 《ThoughtWorks的敏捷開發》 一文中我也總結了這10多年來ThoughtWorks全球形成的敏捷開發方法的體系構建及關鍵實踐。
那麼銀行作為一個組織的敏捷轉型，是否就是要把過去的開發過程和方法，轉變成上面提到的敏捷方法，並形成自己組織內部的統一實踐呢？答案自然不是。我們要解決的原始問題是如何建立對市場變化的快速響應，並能夠激發組織內部的創新。我們的目標並不是要用一套大一統的“敏捷方法”來取代過去的傳統方法，我們需要的是組織文化上的敏捷性，能夠持續學習和改善。
就中國的大多數銀行來講，這意味著可能有多種軟體開發過程和方法，甚至於在一些傳統核心應用裡仍然使用瀑布過程作為流程主幹。當然這裡並不是預定解決方案就是“雙模”，從銀行自身業務發展出發，誰說不可以“三模”、“四模”呢？
經過四年多的實踐，某大型國有銀行軟體開發中心就形成了三種敏捷開發模式（開發敏捷、全流程敏捷和端到端敏捷），為中後臺團隊、網路金融和網際網路創新分別提供了實踐的牽引。如果從教條主義出發這是值得批判的，為啥不全都是端到端敏捷？但從現實的行業和企業生存環境出發，這樣的敏捷落地是務實的。四年時間裡我見證了該組織員工敏捷認知上的持續進步，在強監管的約束下，通過多種模式創造了時代需要的組織靈活性。從這一點出發，這樣的做法和大刀闊斧的組織變革同樣值得尊敬。
我們需要擁抱變化和持續改進的敏捷文化，而不是所有產品整齊劃一的“敏捷”開發模式。
實驗探索 over 創新專案
由於FinTech的衝擊，各大銀行紛紛啟動了創新機制，有的甚至成立了單獨的創新中心。科技創新在銀行業成了最為重要的企業戰略話題，各家銀行的網點裡目前都已經擺滿了全自助的櫃員服務機，有的大堂裡已經開始有服務機器人在主動迎賓。
創新同樣是敏捷落地過程中一個不可避免的問題，甚至在不少銀行成為發起敏捷轉型的原動力。在一家致力於金融科技引領的大型股份制銀行的轉型過程中，敏捷開發模式成為了FinTech創新專案的必選項。但除了更“快”，大家似乎都沒有找到創新和敏捷的必然聯絡，只是因為希望創新產品快速上市，所以認為必然是敏捷的。
在這家股份制銀行的一次FinTech創新專案提案評審會議上，CIO的一個問題觸動了我的思考。在各個創新團隊爭相彙報自己的創新產品取得的成果後，CIO停頓了幾秒鐘，說到：“我希望大家以後不要每次都出來講自己的創新如何成功，取得了如何的成績。我希望大家都講講自己在創新的過程中遇到了什麼問題，通過使用者實驗驗證了哪些錯誤的假設，並談談怎麼改進的。”
是啊，既然是創新，那就是在實驗，而實驗失敗應該是十之八九的事情吧。如果永遠都是成功，可能如這位CIO接下來點評的：“大家都沒有創新，只是在延續已有業務而已。”而接受實驗失敗，並把失敗作為一次重要的學習機會，在目前銀行業裡仍然十分少見。沒有這樣的試錯文化，可能下一個“支付寶”仍然不會出現在現有的銀行體系裡。
我們需要通過科學實驗來驗證業務想法，而不是製造一堆只能成功的“創新”專案。
平臺思維 over 微服務架構
金融服務已經完全依賴於數字化渠道了，各家銀行都意識到了IT系統的重要性，拼命加大科技方面的投入。由於很多網際網路企業的示範作用，微服務化架構也進入了銀行科技的願景裡，期待著雲時代能夠通過微服務構建靈活的系統架構，從而能夠支撐新服務和產品的高效敏捷開發。
於是很多銀行都開始拿出不同的應用進行微服務改造，希望通過試點建立自身微服務架構的能力，逐步讓更多的應用“微服務化”。國內銀行顯然沒有時間等著一個一個應用的試點，於是往往會挑選不同業務領域（如零售和對公）的應用同時進行改造。然而，完成微服務拆分後，根本沒有人會跨業務的審視大家在服務層面是否有共性需求，我們希望的複用性自然也就不會發生。這些服務未來可能也僅僅是一個應用改造後的“模組”，而不是真正為多項業務持續使用的“活著”的服務。
在此基礎上，不可避免的需要構建一套微服務開發框架，直接採用開源框架對於銀行來說還是很難滿足其監管要求的。在設計和開發這個框架的過程中，我們最常聽到的就是如何能夠把各種服務管理述求（從註冊到安全）都植入到框架裡。這是一個似曾相識的故事，結局可能是一個複雜難懂的框架，看似開發工作量（程式碼行數）少了，但卻給開發人員帶來了痛苦的體驗，以至於一有機會大家都會想辦法繞過框架。
這些問題的解決必須依賴於我們思想觀念的轉變，新的平臺思維是我們需要去擁抱的。我們這談的並非是阿里提出的中臺，而是從過去軟體應用框架平臺到數字化能力平臺的轉變，這個轉變帶來了三個方面的顯著變化：
平臺的“客戶”是我們的開發人員。這裡的開發人員是廣義的，比如在資料分析領域，未來的銀行業務人員也是開發人員。這個能力平臺必須要關注開發人員，即客戶的體驗！
平臺是持續演進的“活體”。平臺上每種能力都為不同的業務應用提供著支撐，並且是持續完善的。我們不會像過去應用框架開發一樣集各種述求於一身，設計就需要大半年。
平臺是自服務的。開發人員不需要讀上百頁的技術文件，或demo專案來理解怎麼使用平臺能力。感謝網際網路，已經為我們做出了這樣的表率。
我們需要一個能夠持續積澱的數字化能力平臺，而不是一堆各自為戰的微服務。
員工體驗 over 開放辦公
我經常玩笑說組織轉型有兩個非常好的破舊立新的契機：一是組織結構的調整，二是辦公室重新裝修。後者毫無意外已經成為了銀行組織敏捷轉型過程中的常規武器，通過打造不一樣的工作環境，來促進員工之間更多的溝通和交流。
在敏捷倡導的協作和信任模式下，大部分重新裝修都會選擇開放式辦公環境，即每個員工不再有自己的小格子間，甚至不會有自己的固定工位。這樣的好處自然是我們可以更方便地讓一個團隊的員工們坐到一起，形成更緊密的團隊協作氛圍。
多年的顧問工作讓我習慣了“居無定所”，每次走到客戶的開放辦公環境自然感覺非常適應。但也有那麼幾次走入新裝修的彩色環境時感覺莫名的不快，所謂的開放辦公桌比之前的格子間更為擁擠了，桌上一個顯示器挨著一個顯示器。整個場地沒有幾個會議室，都擺滿了長條桌，團隊站會都顯得非常侷促。這讓我想起了多年前一家創業企業負責人在參觀了ThoughtWorks北京辦公室後跟我說的一句玩笑話：“這樣的開放佈局不錯，單位面積裡能多坐不少人，還能時刻監視每個人！”搞得我忙解釋，其實我們的人均員工空間是行業普遍水平的一倍多，並且也沒有人會去監視別人。
（你聽說的開放辦公 vs 你經歷的開放辦公）
這樣假借開放之名來“提高”場地利用率的情況現在也正在發生著。值得提醒有類似考慮的管理者，別忘了選擇開放環境的初心。我們在給團隊提供更緊密協作空間的同時，也需要考慮團隊的私密空間，這要求不同團隊之間有一定的空間隔離，也要求足夠的會議室來支撐時常需要進行的小範圍協作會議。開放空間的設計不是在大平桌上整齊地排列一臺挨著一臺的電腦和顯示器，而是更加全面的思考團隊溝通協作的需求，更多的視覺化空間及移動辦公設施。
而這一切都是為了更好的團隊和員工體驗，讓大家能夠在安全放鬆的環境下去思考和碰撞，從而能夠啟用整個組織，建立生機型文化。借用西方管理哲學裡常用的一句話：只有愉快的員工，才會有愉快的客戶！
我們需要一個能夠讓員工感到安全和放鬆的團隊工作環境，而不是一個為了提升利用率而擁擠不堪的“開放”場地。
銀行組織的敏捷落地正在發生著，文中四點顯然無法涵蓋轉型工作的方方面面。如開篇講到的，我希望在幫助銀行數字化轉型的過程中，持續把自己的經歷和觀察總結分享出來，促進我們的銀行業在數字化的程序中變得更加開放，從而能夠碰撞出真正的創新。