摘要
於軟件開發領域而言，敏捷已經被廣泛認可為一個行之有效的應對快速交付和不確定性的指導方法，並有一系列相對成熟的模型和框架。而企業更為需要的企業敏捷和業務敏捷則仍在探索階段。敏捷吸引軟件開發工作者的原因，是它打破傳統開發常規，用不同的思維找到更好的方法，取得更好的結果。同樣的，如果要業務敏捷，就要探尋業務部門所需要突破的常規。本文將與諸君分享三類業務部門突破常規的故事。
在這個技術突飛猛進、環境瞬息萬變的時代，能夠快速響應變化並做出適當的調整，是關係到企業生死的基本能力。企業（enterprise）需要敏捷，業務（business）必須敏捷。但很不幸的是，現行的商業和管理理論和實踐普遍相對落後，連彼得·德魯克都曾感嘆：“我們稱之為管理的東西反而使人們做事更困難”，更不用說支持快速響應變化。請問各位，您所在組織的管理和運作模式是否支持快速實現客戶需求，是否支持快速響應變化？有哪些規則妨礙你們的工作？要邁向更好的運作模式，首先必須打破那些不必要的常規。
探尋更有效的運作模式並非容易的事。幸運的是，軟件群體已迎來新希望。交付週期縮短的壓力下，軟件團隊已經成功的實踐新的工作方式，我們將之統稱為“敏捷軟件開發”。敏捷團隊能夠高效有效地協作，產出客戶滿意的軟件產品。敏捷團隊驚人的效率和激情，對業務工作者是一種鼓舞。組織領導希望業務人員有同樣的敏捷能力和效果。
但是，業務敏捷（business agility）並沒有明確的定義。敏捷聯盟（Agile Alliance）將業務敏捷定義為“業務能感知內部、外部的變化，並及時回應以便於為客戶提供價值。業務敏捷不是一種具體方法，甚至不是一個整體框架，它是形容一個組織怎樣在成長思維下運作，而這種思維很類似於敏捷軟件開發群體形容的敏捷思維。”敏捷聯盟進一步表示，沒有固定的敏捷實踐、角色、或者週期。因此，業務敏捷的組成可說是還處於探索階段。因此，業務敏捷是什麼，它的目標是什麼，它的廣度和深度是什麼，還需要每一個組織自己去定義。目前，沒有任何參考的模型，各組織需要自行探索，自己檢驗。
在敏捷軟件開發方法體系，業界有不少通用的模型，比如Scrum、XP等，來指導敏捷開發的實施。以上模型以軟件團隊作為出發點。業務敏捷的出發點呢？它從哪裡開始？業務部門的領域不同，需要的敏捷模式則不同。比方說：銷售部門的敏捷可能就跟財務部的敏捷完全不同，採購部的敏捷和人力資源部的敏捷也應該不同。同樣的，敏捷對於高層管理者和業務部門領導來說也有不同的意義和側重點。
我們或許可以考慮讓這些業務部門嘗試成熟的Scrum框架，讓這些部門有迭代運作的概念。這或許有用，但我覺得不能解決業務的根本問題。原因很簡單，業務部門都有他們慣用的例行工作分配和跟蹤機制。在這些例行會議當中，他們會討論與跟蹤問題，並商定改進措施。所以，如果跟業務人員只是談論“一般”的敏捷迭代做法，持續改進，他們就可能會感覺“我們都知道，已經在做了，沒什麼新鮮的”。
敏捷吸引軟件開發工作者的原因，是它打破傳統開發常規，用不同的思維找到更好的方法，取得更好的結果。敏捷宣言中的四個價值觀：
個體和互動 高於 流程和工具
工作的軟件 高於 詳盡的文檔
客戶合作 高於 合同談判
響應變化 高於 遵循計劃
右邊就是常規，左邊就是嶄新的思維模式。同樣的，如果要業務敏捷，就要探尋業務部門所需要突破的常規。
敏捷宣言也提出“我們一直在實踐中探尋更好的軟件開發方法，身體力行的同時也幫助他人。由此我們建立了如下價值觀。”同樣的，我將分享我的一些個人在業務敏捷經驗和體會，供大家討論，我把這些經歷分為三類：
- 業務與IT的敏捷（Business and IT Agility）
- 客戶參與的敏捷（Customer Engagement Agility）
- 業務自身的敏捷（Business Agility in Itself）
這三類經歷都在說明，業務人員如何跳出他們存在的心態和思維，找到突破。
業務與IT的敏捷
談到業務敏捷，很自然的就談到業務部門和IT部門的合作。下面的場景相信大家都不陌生：業務和IT雙方並不和諧，各自維護自己的利益，互相對抗。業務壓需求，IT抵抗需求。其實，從企業整體目標的角度考慮，他們應該是相互合作的合作伙伴關係，沒有高下之分。
這是很多企業裡常見的做法：業務方希望以最低價格完成目標，所以跟許多供應商合作，讓他們之間互相競爭價格。這些供應商，有些做開發，有些做所謂的“獨立測試”，他們互相競爭報價。在極端情況下，一個業務部門有十幾個供應商，分別負責開發、測試、用戶體驗等等不同的工作。在這種討價還價，隨時停止供應商服務的情況下，供應商怎麼可能有熱情和忠誠？有些業務部門不僅僅對供應商這樣，甚至對公司內部IT的同事也一樣。IT服務質量難免受損。
業務與IT的敏捷協作基礎是互相尊重，互惠互利。我分享兩段個人經歷：
第一個經歷是我2014年的一個大型敏捷轉型項目，包括供應商大概有好幾千員工，該業務在一年後擴張至約萬人。當時我們提供IT組織敏捷轉型方案，並且輔導團隊落地實施。正好我輔導的某個團隊，業務代表和IT代表水火不容，一開口就吵，幾乎不說話，關係很尷尬。業務代表希望將70個左右的需求都要現實，但是IT方面抱怨說需求不明確，做不到。IT代表問我，到底他們哪一方合理，這讓我左右為難，傾向哪一方都有損失。這時，我便問業務代表是否真的希望每一個想法（Idea）都實現，以及每一個想法當前的進展情況。如我所料，那些想法的進度並不相同，有些想法就是想法，業務代表只是想與IT代表共同討論。說到這裡，IT代表才平下心情。我們便建立一個想法看板（Idea Kanban），附有清晰的標準定義和具體的排序規則。這形成業務方和IT雙方的合作基礎。這個運作方式受組織的認可，並且變成了其他業務團隊的參考模型。
第二個經歷更是難以忘記。業務代表想創造一個B2B電子商務平臺，向歐洲和香港市場發展，有大量的業務需求。IT方面正手忙腳亂地實施落地，工作量特別大，不少加班情況。為了滿足業務需求，IT部門有並行的版本開發。這意味著業務方必須參與驗收測試（UAT），而同時也需要投入準備德國和香港的演示和銷售工作，所以工作量也很繁重。總而言之，業務和IT雙方都被壓得喘不過氣。其實，對我來說，解決辦法很明顯：就是要聚焦，不要把精力分散。為了讓香港客戶演示的成功，應該把大部分精力集中在這裡，不必要並行版本開發，反而應該捨棄一些已經計劃發佈的工作。我參加他們業務和IT的協作會議，並指出我的想法。業務方很果斷的捨棄一個版本，並同意專注於演示的準備。取消一個並行版本之後，業務和IT突然感覺輕鬆多了，特別開心。為了紀念這次的決定，業務代表還提議在敏捷宣言前合影留念！
客戶參與的敏捷
說到客戶參與，我想把本文的重點放在線上和線下的“人為渠道”（human channel）方面。在目前提倡數字化背景下，組織提倡自動化和智能化，希望通過技術手段，更好的為客戶服務。客戶通過這些自動化智能化的渠道辦理業務，不需要業務人員的參與，減少業務人員和客戶通過移動或其他方式進行溝通。雖然，這將讓客戶更方便，但是在某種情況下，會失去跟客戶人與人之間的接觸機會。數字化和業務敏捷存在的意義就是讓業務給客戶更人性化的服務，如果要人性化，怎麼能夠完全沒有人為的參與呢？所以，在本文當中，我分享兩個相關經歷。
在某家金融科技公司，客服人員每人每天有350次通話指標。其實，通話次數和通話質量是兩回事。我便問他們是否有建立一些有意義的關係，解決他們的問題。這些一線客服人員便滔滔不絕的講述他們與客戶接觸的感人故事：一名客戶問客服夜間上哪裡買藥，另一名客戶詢問哪裡能找到托兒服務、等等。很明顯，這些都是超出客服的工作範圍。在他們分享經驗時，我能感覺到他們的熱情，他們助人為快樂之本的心態。我相信他們的客戶也會特別感激。在這分享中，客服人員理解他們的意義不是為了達到冷冰冰的通話次數目標，而是有同理心的幫助客戶。客服人員不是接電話或撥電話的機器，他們是一群具有影響力的大使，幫助組織建立人脈，建立口碑。當業務意識到這一點，就會有更強大、更有創新力的服務。如果你想要客服更人性化，你必須關注他們，鼓勵他們呈現人性化的一面。這是敏捷的基礎——以客戶為中心，以人為本。
這個故事是我在某家銀行的經歷。作為一個每月領取人民幣薪資的新加坡人，還要把工資匯到新加坡，這手續其實很麻煩。在銀行風險政策的要求下，每次境外匯款都要親自跑支行兩趟去辦理手續，對我這樣一個差旅頻繁的人來說，這是個很大的問題。不過與支行經理商量之後，商定一個稍微簡單的辦法，將兩次親自現場辦理手續減為一次。支行的王經理不僅滿足我作為客戶時間上的要求，在自己的工作上取得成就，更交了新朋友。這是個體現出一線人員尋找流程創新和突破的很好例子。
一線員工不是推銷產品、提供信息的渠道。他們是真正能夠與客戶立建關係的大使，所以他們應該賦予更多權利。但是，不少企業往往對他們就像對待機器一般，完全沒有決策權，完全百分百的遵循過時和不完備的流程制度。以上兩個案例體現了一線的突破。這就是所需要的業務敏捷。
業務自身的敏捷
業務敏捷的第三方面是業務自身的質量和管理方式。這跟客戶、合作伙伴和IT沒直接關係。這是業務自身的核心，通常與領導層有關。業務的決策和經營體現了領導者的意願。領導做事的方式對業務敏捷有很大的影響，通常表現在細節上。
我在知識共享領域有一段有趣的經歷。客戶所在的業務有不同產品線，規模很大。領導層希望不同產品線分享知識，讓員工互相學習，找到更好的解決方案。但是，業務的安全部門有責任保護機密。因此，兩個部門產生了衝突——知識管理部希望分享，安全部門需要維護保密性。討論之後，最終沒有將知識分享的項目交給知識管理部，而交給安全部門負責，這樣他們就需要改變保密政策。這顯然了創造共同視野的好方法。
在另一個組織中，不同額度的採購需要不同的級別的審批權限，這在某種程度上是有道理的，但卻給帶來巨大的問題。一個項目當中所需採購工作，就需要獲得不同級別的批准。較小的採購交給較低管理層的批准，而較大的採購則交給更高管理層的批准。結果，經理們看到的是完全不同的採購，而不是一個項目的所有主要採購。經過一次改善活動之後，讓每個項目都由一個單獨的人來批准重大的採購，而採購業務的合作使他可以批准指定項目相關的所有其他採購。這大大簡化了審批過程，將審批週期從最多21天縮短到最多3天。
最後一個例子是一家有很多個不同子公司的業務，每一個子公司經營的業務都不同，成熟度也不同。於是，我們合作設計了一個共同的績效框架，用於管理不同子公司。這個框架基於麥肯錫的三維度、基於業務驅動變量，它們適用於B2B、B2C和混合商業模型。過去，他們集中於金融指標，經過共同的努力，他們得到了更好的領先指標，能夠追蹤客戶和商業夥伴的成長。為總公司和子公司之間提高了急需的可見性，優於以往不透明的方式。
敏捷即打破常規
如果你已經嘗試過敏捷，你可能會在開始的幾星期或者幾個月內感到很新穎。但是，如果在這期間沒有任何突破，沒有任何思維的創新，沒有打破常規，團隊就很容易回到老樣子。團隊們可能說他們有Scrum活動，有一系列的“敏捷”儀式，但是，我的經驗告訴我，如果只有表面上行動，沒有根本上的改變，這是很難持續的。若要真正的敏捷，就必須更上一層樓，就必須有思維的突破和創新。敏捷軟件開發如此，業務敏捷也如此。
各位業務敏捷實施者，你們有哪些最關鍵限制因素?這些因素背後的原則和政策是什麼？你可以做出哪些改變？你可以克服這個限制嗎？要付出什麼代價？如果你袖手旁觀，後果會怎樣？ 我們追求的是管理層面的突破。這些突破，往往就是一個簡單的決定，就向打開一扇門那麼簡單。但是打開門後，海闊天空。
今天，你有沒有嘗試打破常規？歡迎分享。
文／ThoughtWorks黃邦偉 博士
原文：https://insights.thoughtworks.cn/key-point-of-enterprise-agile-is-break-the-routine/
閱讀更多 ThoughtWorks 的文章
