本篇開始，嘗試與業內同仁探討銀行產品設計相關內容。筆者從業經歷主要在IT，但曾長期為銀行產品團隊提供開發服務，并曾有幸跟隨非常優秀的業務領導和產品同事下業務一線拜訪客戶，直接參與了多類產品的方案設計，期間所受教益匪淺。后又曾在騰訊有過一段產品工作經歷，并深受騰訊8分鐘產品課和騰訊產品法的啟發，騰訊對產品的理解，及形成的各種理念、方法論、案例等等，對指導商業銀行產品體系構建、產品設計，也都很有參考意義。相關經歷，值得進行一些總結，不妥之處，請讀者置之莞爾即可。

產品為王

銀行產品的內涵與外延

雖然在系統建設中，我們總是想辦法去建構“產品工廠”或“產品中心”，但實際上，即使是對銀行產品下定義都是非常困難的。與手機、電腦等顯而易見的有物質實體承載的產品不同，商業銀行的“產品”，多數時候實際上是一攬子為客戶提供的服務的組合，而服務通常極其復雜。《設計心理學》一書中，作者諾曼不無吐槽地指出，“我們最常見的服務，駕照、護照簽發、繳納所得稅…都有龐大的官僚主義規章制度，一大批機構內部的人，經常還有公司里面都會有的很多個部門，聲稱負責所有非常規性問題。….所有那些在幕后的東西–那些神秘地運作著，形成順利、高效或者令人困惑的運作效果的東西，被稱為’后臺’….”

循著諾曼對服務的解釋，銀行產品的定義從狹義上可以做如下概括：“銀行產品，是銀行基于特定金融需求，面向特定客戶群體（個人或企業），設計并提供的、具有明確功能、使用規則、定價機制和服務流程的金融服務方案。它本質上是銀行與客戶之間圍繞資金流動、風險管理、價值增值等核心金融活動所建立的契約化服務載體”。在這一定義中覆蓋的產品包括兩類，一種是面向規模化長尾客戶提供的標準化產品（比如微粒貸、余額寶）；另一種是面向特定行業，甚至個別客戶定制的，但又具備可復制、推廣的金融服務解決方案/產品，比如面向特定行業，甚至特定核心企業的定制化現金管理、分級賬簿、供應鏈金融解決方案等。

面向客戶的銀行產品可以做以上定義，但因前、中、后臺的存在，銀行產品常常在內部管理及部門協同過程中造成困擾，一款產品，你是站在客戶視角，還是中臺業務，或是后臺運營、財務視角，看到的情況是不一樣的。銀行中對客戶來說是后臺的部分對業務管理部門來說就是前臺，而對業務管理部門來說是后臺的部分，對運營或者財務來說，又是前臺，每個角色都有自己的前臺和后臺。舉個例子，以最近國內新能源汽車供應商應收賬款賬期問題為例，在此案例中，供應商可以向商業銀行轉讓對整車廠的應收賬款債權而獲得現金流。在這個業務中，供應商，即銀行的企業客戶感受到的產品是“應收賬款債權轉讓融資”，而在銀行中臺–一般是負責貿易融資管理的中臺部門（如交易銀行部或貿易金融部、企業金融部之類的），這個產品一般被定義成“保理融資”（并細化成有追索權、無追索權、需要進行債權轉讓確權的明保理，或者無需確權的按保理等等），而到了財務部門編制會計科目時，這個產品可能就變成了“前收息模式的預支價金”，最后在IT系統中，這本質上與一筆預收息的貸款沒有任何區別…

從上述例子中不難看出，正如諾曼所言，“成功的產品必須合并內部和外部成分的所有不同層面，協調地支持所有可見和隱藏的服務和操作。產品存在于一個復雜的交互網絡中….”

為什么需要重視產品

其一，做好產品論證與分析，有利于資源的有效投入，獲得正向回報。有過銀行系統的開發經驗的工程師們或許都有過這樣的經歷：一個被催的十萬火急，必須限期完成的項目或者需求，在項目組人員加班加點、蓬頭垢面地忙活一圈，上完線后過幾個月一統計：新增客戶數0，新增收入0，業務價值0。隨之而來的解釋通常是這樣：業務效果未達預期，是因為這是一次“快速試錯”，潛臺詞則是“因為是試錯，所以沒有業務效果是正常的”。只不過，如此試錯的代價是銀行的寶貴預算，以及其他更有價值的項目或產品被影響，還有倒霉的程序猿們的加班加點。

當然，這里面，有一部分的確是面對不確定的市場，不得不付出的試錯成本（畢竟成功很大程度上是概率事件），又或者是為了營銷客戶，必須付出的成本，即某個產品或解決方案，你有，客戶不一定選擇你，但如果你沒有，客戶連機會都不會給你。有問題的是不經研究和論證，拍腦袋決策、倉促開干的項目和產品，提出者將開發壓力交給IT，將客戶經營壓給分支行，將業務效果交給天意。

其二，銀行產品不僅僅是功能工具，更是銀行定位戰略的載體和品牌形象的關鍵塑造者，通過產品建立的印象有利于建立正面的客戶心智。特勞特在《定位》一書中，提出企業成功的關鍵，就是“如何在潛在顧客的心智中占據一個有利位置”，而在“信息傳播過度的社會里，傳播簡化的信息是唯一有效的方法。” 產品便是那個能夠簡化信息傳播的關鍵抓手。“微粒貸”的成功，不僅僅是為webank的資產規模、利潤規模作出重要貢獻，其形成的客戶對微眾銀行提供的服務便捷、科技、專業、普惠的印象，也被投射到微業貸、微眾銀行智能存款等產品中，奠定了微眾銀行在客戶心智中的整體印象。

其三，銀行產品不僅是滿足需求的工具，更是低成本、高效率獲客的核心引擎。原因有三：1）、一款具有強吸引力的“鉤子”產品，本身就是最低成本的獲客廣告。2）、產品體驗（流暢度、功能滿足度、收益/利率競爭力）是用戶是否留下的關鍵。糟糕的產品體驗會讓辛苦營銷來的客戶瞬間流失。3）、產品內設計交叉銷售路徑（如理財用戶看到專屬貸款優惠、貸款客戶引導開通關聯還款賬戶/信用卡）和用戶分層運營機制（如VIP等級體系對應專屬產品/服務），可以提高客單價，讓存量用戶產生更多價值。

產品設計需要關注的高階問題

大多數機構的沒有華為那種可以建立IPD（集成產品管理）的能力，也沒有騰訊那種刻在基因里的產品文化。有什么辦法能夠一定程度上做到“謀定而后動”呢。這便是通過一定的流程和機制設計（比如產品審批、產品委員會審核），確保在一個需求或一款產品開始建設前，一定要將如下問題回答清楚，即經典的5W1H分析法：

WHO：產品為誰設計？目標客戶是誰？目標客群有什么特點？購買者和使用者是同一個嗎？目標客群有多大規模？最樂觀與最悲觀的情況下，分別的轉化率與留存率預計有多少？

WHY：我們的產品有什么差異化競爭優勢？客戶為什么選擇我們？產品有哪些競品？有可替代產品嗎？（比如信用卡與花唄）

WHEN：用戶什么時候使用我們的產品？多久用一次？產品有政策窗口期嗎？（商業銀行產品必須非常關注的，比如票據市場、外匯市場、債券市場的階段性機會）產品有市場窗口期嗎？（比如ETC扣費的短暫窗口期）

WHERE：產品有可能完全線上化？用手機用方便還是電腦用方便？（這在企業銀行業務中，尤其是中大型企業中特別需要關注，因為企業員工坐班原因，網銀比手機銀行更受青睞，再大的企業，則需要銀企直連，因為企業員工只想在自己的ERP等內部系統上操作）可以使用H5進行場景投放嗎？

WHAT：產品的具體形式，或載體是什么？產品要做成怎么樣？產品的定價如何？

HOW：用戶怎么交互？交互設計涉及的概念模型、示意符號、功能入口布置等等。（在互聯網想方設法投入巨資僅僅是為了客戶少點一下手機的當下，商業銀行的很多設計還是不憚于打擾客戶，有些交互的設計簡直就是為了刻意給客戶制造麻煩….）

在”5W1H分析法”之外，還要考慮產品建設的“時間成本”、“資金成本”、“風險成本”與“行動成本”等等。一份需求也好，一個產品也罷，事前做好分析論證：判斷要不要做，值不值得做，做完了怎么獲客，怎么演進，比知道產品和需求怎么去做更重要。如果說IT的能力養成是為了能夠“正確的做事”，那么，產品論證分析則指向一個更重要的命題–如何盡可能保證“做正確的事”。一件事不值得做的事，自然就不值得做好。

產品團隊責任重大

在傳統商業銀行的組織架構模式下，以前、中、后臺條塊化組織的一個機構中，要確保“做正確的事”殊非易事，如果組織不能實現有效的協同，就會出現好像個個部門都在認真履職，而最后什么事都做不成的情況。而要做好這些，除了董事會及經營管理層的決策部署外，在執行層面，需要有人來完成“市場分析、用戶研究、收益成本分析”，并對“產品定位、產品設計、產品推出時機、產品營銷方案”等進行說明，最后還要想辦法協同相關部門，取得配合部門的支持。總之，要向前能夠連接起分支行，向后能夠協調好風險、財務、法規、營運、IT，為達成一個共同的目標而努力。這在商業銀行，從來都是一個不易解決的問題。

在商業銀行的機構設置中，處于“中臺”位置的總行業務主管部門，比如零售的消費金融、財富管理、汽車金融、信用卡，對公的交易銀行、貿易融資、國際業務、商業匯票專營等部門，以及具有全線上產品設計、運營職責的網絡金融部門，專注SME經營的小微或普惠金融部門，天然具備深耕本領域業務，知曉領域業務特性，向前可連接并向分支行下達經營指標，橫向可以拉通兄弟部門，實現公私聯動、存貸聯動產品設計，向后可以拉通風險、財務、法規、財務、IT等的能力，作為利潤創造中心的特點，這些部門也最有能力和動力通過整合資源達成業務目的。統籌產品設計與經營，中臺產品部門責任重大、使命光榮。

要完成如此重要的工作，對產品經理的能力要求自然被顯著地放大了。與風險、IT、法律、財務等僅需要專注于某一領域的專業技能不同。一個好的產品經理，除了需要對本領域的銀行業務有深入且獨到的理解外，通常還需要具備一定的法律基礎知識，比如知道《民法典》中關于合同、擔保、物權的法律條款。如果產品經理正好對會計知識有所了解，那么在跟財務部門爭取更優惠的FTP定價，在思考如何通過非融資性保證業務降低RWA占用方面，就會占有優勢；產品經理如果有IT背景，知道一個功能大致的實施難度與實施周期，就能避免“這個需求很簡單、怎么實現我不管”的沖突；如果產品經理對設計有基本的了解，就能在產品設計中很好地完成關于等待、推薦、反饋、提示及概念模型的設計；如果產品經理對宏觀經濟學、貨幣銀行學、監管法規有好的了解，那么就更能敏銳的發現監管政策窗口與市場機會。最后，產品經理還需要有天然的直覺，對人性的洞察，以及卓越的溝通能力。

“With great power comes great responsibility”，這也正是喬布斯、馬斯克、馬化騰、雷軍、余承東、張曉龍等一眾大佬，都被認為是大產品經理的原因。

產品思維

產品設計者面臨的困境

在“傳統”商業銀行中，產品部門、產品經理要做成一件事，需要有效協調前、中、后臺部門的支持，需要識別市場機會，又要面對監管約束，常會面臨三重困境。一是專業深井困境。在商業銀行中，一款產品通常涉及的風險、法規、財務、科技等部門，各有各的專業語言，比如風險中的PD、LGD、EAD、M、RAROC、EVA、FPD、DPD、AUC、KS等；法規中關于要約、承諾、無因性、善意取得、質權、債權、留置權、一般保證、連帶責任等；財務中的各種資產、負債、收入、支出、費用、未分配利潤、表外、FTP定價、利率重定價曲線等等。IT則自不必說，從應用架構到數據模型，知識體系紛繁蕪雜。也因此，產品也成為“翻譯損耗”的重災區。所謂對“跨界復合型人才”需求最高的領域，產品類崗位首當其沖。二是創新悖論困境。商業銀行因為其經營特點的特殊性及對國民經濟的特殊重要性，受到央行、金融管理局等的強監管約束，以巴塞爾協議“資本約束 – 監管干預 – 市場制衡” 為內核的三維監管體系需要商業銀行的“創新”活動必須在規定的框架內進行。而與此同時，一些泛金融機構，如商業保理公司、金融租賃、消費金融公司、網貸公司、第三方支付公司等，其監管約束（從監管主體到監管細則）與商業銀行不可同日而語。部分機構因此得以進行的“擦邊球”創新，對商業銀行構成極大的競爭壓力，此其一；其二，以互聯網，尤其是頭部互聯網公司為代表的，金融產品獲客、交互體驗創新，則對商業銀行形成了降維打擊。因此，對商業銀行而言，一方面需要“守正”，一方面又需要“創新”。三是價值量化困境。財務可以通過利潤表直接記錄收入、支出和利潤，風險可以通過五級資產分類和不良率計量損失，IT可以通過剛性費用衡量投入，而產品價值卻往往與市場、營銷、內部的資源投入及協同等眾多因素相關，因此難以剝離歸因。產品部門的績效計量，在缺乏產品基因的機構，向來都不容易。《人人都是產品經理》一書中提出：“產品是解決問題的載體”。而銀行問題的復雜性在于——它既是數學問題（定價模型、資本計量）、工程問題（系統架構、流程耦合）、行為問題（用戶心理、組織協同），更是哲學問題（風險與效率的永恒博弈）。

五大產品思維

在2015年“互聯網+”時代前后，商業銀行曾掀起一股向互聯網學習的熱潮。彼時，”互聯網的13種思維”，”互聯網獨孤九劍”等曾被商業銀行奉為圭臬。其中的內容魚龍混雜，不少指向的不是踏踏實實的價值創造，而更像某種方式的割韭菜指南。當然，其中也不乏值得學習借鑒的，但那并不僅僅是互聯網特有，而是各行各業的普遍性真理，也即《騰訊產品法》中提到的五項思維模式，分別是：第一性原理思維、系統性思維、相對思維、抽象思維和演進式思維。在“技術可購買、流程可復制、客群需要爭奪”，金融產品同質化加劇的今天，產品設計者這這些方面的思維認知能力，對構建商業銀行全局或局部競爭優勢十分關鍵。第一性原理思維。第一性原理思維要求只采用最基本的事實作為依據，在傳統的產品設計的前提下重點觀察它的前提條件是否發生了變化、是否有優化的空間、是否還有更優的解決辦法。通過不斷追問的方式，剝離所有表象后，識別產品解決的最原始需求是什么。第一性原理最需要挑戰的，是對商業銀行“傳統”做法的挑戰–即“祖宗之法可不可變”的靈魂追問。以筆者曾經歷過的一個項目為例，因為歷史上票據貼現賬務在核心的貸款模塊記錄的原因，即使在投產了商業匯票系統后，這一“傳統”仍然被保留，因而導致客戶每次在申請票據貼現時，運營部門都需要先為客戶開立一個貼現賬號。但實際上，貸款業務首先從本質上就不需要所謂的“賬號”，而只需要編列“借據–IOU”，其次，貼現業務與貼現票據強相關，其明細賬在票據系統分錄，科目賬在總賬系統反映即可。基于這一原理性分析，后來我們在方案實施過程中，就直接取消了貼現賬號，既減少了系統間交互（信貸、票據與核心之間的多次交互），又簡化了作業流程。

系統性思維。銀行產品的本質是多重復雜系統的耦合體，其跨度涉及用戶行為系統（心理學、社會行為學范疇）、金融基礎設施系統（如支付清算體系）、監管政策系統（動態變化的合規邊界）與商業價值系統（FTP定價、RWA占用、客戶LTV等）。以一款高利率存款產品的發行為例，在系統工程視角下，除了存款部門的考慮外，還需要如下的考慮：從資產負債角度，會否在未來導致資產負債期限錯配？從流動性角度，會否在產品到期后因贖回導致流動性風險？會否導致全行FTP定價失效？對全行利潤的侵蝕度如何？是否會引致監管處罰？總而言之，傳統的線性思維模式–要攬存就提高利率，已經越來越需要讓位于系統性的思維，即將產品置于生態網絡中做整體性思考。相對思維。相對性思維是摒棄掉非黑即白的二元對立思想，不輕易貼標簽，不輕易下論斷，看到事物之間的內在關系和動態變化，以此來指導產品設計。相對性思維在銀行產品設計中的核心運用，是需要把握銀行產品的”最優解”只存在于具體約束條件下，在約束條件下需求“整體收益、風險成本、監管合規”的有機統一。監管約束下的相對思維運用，反而會成為機構獲得差異化競爭優勢的突破口。比如，“寶”類產品在表面上會導致商業銀行存款搬家，但如果能夠獲得貨幣基金的代付資格，則通過基金公司的托管，活期存款的“流失”則可以得到超額補充，產品競爭力帶來的流動資金池（當日購買與贖回的差額），事實上對活期存款的損失可能會非常小，而商業銀行則能獲得資金托管帶來的存款、客戶粘性、費用收入等一攬子收益。
抽象思維。抽象思維通常與系統性思維相輔相成，是指在產品設計及實施過程中，需要提取不同事物性質相同的內核;通過功能與能力要素的抽象，支持產品的快速組裝。這一思維，不僅是產品經理的契約，更應是IT架構師們的圣經，在分布式微服務架構中經常提及的共享服務抽象，以及前些年被推崇備至的“中臺”，本質上都是在產品或者系統實現過程中，需要進行充分抽象，在不同產品、不同功能間尋求最大公約數，將公約數沉淀為穩定的，后續可復用的產品功能。比如在融資業務中，對押品管理、額度管理、核算賬務的共性抽象和服務共享，可以實現對消費信貸、汽車金融、小微信貸、對公信貸的普遍支持，避免重復造輪子。
演進思維。演進思維是商業銀行在面對不確定的宏觀經濟環境、快速進步的技術條件、不斷變化的產業環境等情況下，結合用戶認知和競爭對手情況，依靠快速試錯、快速選代、用最小可行性驗證產品假設的一種產品思維。這種思維模式下，要求產品經理對產品核心功能有高度的提煉能力，技術能力上能夠支持AB測試與灰度流量驗證等。以互聯網貸款為例，在演進思維指導下，對風險控制指標的預測、驗證、反饋、調整需要反復不斷地進行，通過A/B測試，選擇最優解。

局中人的破壁之道

銀行產品創新的最大障礙，往往不是技術瓶頸或資源限制，而是對問題本身的錯誤錨定。愛因斯坦說，“我們不能用制造問題的同一思維水平來解決問題”。當我們能夠新的思維模式重新審視產品，那些曾經的困境，就可能顯露出隱藏的破局點。但“you can’t be what you can’t see”，思維模式的建立依賴于認知，而認知的建立需要大量的訓練，對身處局中的我們（產品經理、架構師、開發工程師）而言，或者可以在如下方面進行努力：一是盡可能建立跨學科的知識體系。除自身崗位的專業技能外，通過在金融工程、法律法規（比如民法典、人民銀行發布的各項法規）、用戶體驗（交互設計）、技術架構等方面，盡可能地進行積累，形成跨學科的知識體系。突破性創新通常來自跨學科的靈感啟發，一專多能不但有利于跨越專業深井，還有可能為產品創新提供火花。二是基于“壓力測試”的思維訓練。在產品設計或需求分析過程中，通過“三問”不斷強化思維練習。包括：本質之問–今天我們討論的“賬戶分級”需求，用戶想解決的原始問題是什么？系統之問–這個功能上線，關聯到哪些系統，有更簡單的設計方案嗎？抽象之問–這個功能有現成的功能可以復用嗎？新建功能能否沉淀為標準組件？三是對成功經驗和失敗教訓進行復盤與解剖。“案例教學”是最直觀、最有體感的認知體驗。通過問題復盤過程中的五步法：問題定位–根因分析–思維盲區–制度改進–能力沉淀，建立制度化的事后學習機制，讓成功的經驗得到推廣，失敗的教訓不再重演。

洞見需求

要做成一個項目，或一個產品，通常需要做3段式的準備，即：需求定義–“define what you want”，清楚地知道要解決的問題、痛點是什么； “know how” –有能力進行可行性評估、知道怎么做任務分解、以及有能力完成總體設計和子系統的設計；“enable”–執行、完成實施、達成目標。三項工作可以簡單地分別對應為產品經理的工作、架構師的工作與程序員的工作（畫外音：要讓一家銀行的產品/系統好用，服務體驗如沐春風，你需要同時擁有優秀的產品經理、架構師、以及程序員）。其中，需求定義是任何復雜工程或產品項目的基石，它直接決定了項目/產品能否成功、做的工作是否具有價值、付出的成本是否值得，以及問題是否真的得到了解決。需求是所有產品設計的起點，“修煉對需求的認知，是所有產品設計者的終身課題”。

需求通識

《人人都是產品經理》一書中，將需求定義為“用戶的問題”，產品經理的使命是“發現問題、定義問題”，通過產品“解決問題”，最后為用戶“創造價值”。

如雷貫耳的馬斯洛需求層次理論，是大家最耳熟能詳的“需求”定義，馬斯洛將人的需求分為5個層次：生理需求、安全需求、社交需求、尊重需求以及自我實現的需求。漢語中有于此對應的另一句話，“倉廩實而知禮節”。馬斯洛定義的需求，是從心理學角度描述的需求。而在經濟學意義上，《騰訊產品法》一書對需求做過非常簡單精煉的概括：需求，是想要，且要的起的產品或服務。“想要”是需求的起點，“要得起”才構成真正的有效需求。對身處商業組織中的管理者、產品經理、架構師、程序員來說，更重要的是，是“借我一雙慧眼”，能夠在紛繁蕪雜的用戶訴求中，判斷哪些是“顯性需求”，哪些是“隱性需求”，哪些是“剛性需求”，哪些是“彈性需求”，總而言之，在商業機構中，需要產品經理能夠“去偽存真”，通過表層用戶直接表達的需求，挖掘用戶行為背后的真實目標或痛點，最終回歸人性的底層動機–本質需求。
那么，在一般性方法論的層面，可以這么做呢？通常涉及到4個步驟，分別是挖掘和識別需求，定義需求，方案設計，以及持續驗證。

在需求挖掘和定義階段，需要回歸第一性原理，通過追問“為什么”，挖掘表象背后的真正問題，弄清楚用戶真正想要的是什么。當拿到一份需求，通常可以做如下發問：用戶為什么會有這樣的需求？提出這樣的改造，是基于什么樣的前提條件？這些條件至今沒有變化嗎？有其他替代方法嗎？隨著技術、經濟、文化潮流的發展，有引入新的變量嗎？….《騰訊產品法》一書中，用微信群的案例舉過一個經典的案例：我們知道，在微信群之前，騰訊其實是有QQ群的，QQ群需要由發起人在群功能中創建一個群，讓后將群ID分享給需要入群的人，經過群主審核后，才能入群。如果是一般的產品經理，在設計微信群的時候，將不可避免地受到QQ群設計的影響，但是。運用第一性原理的追問：QQ群設計時的目的與微信群一樣嗎？不一樣，QQ群更像是滿足某種特定功能或提供特定服務而存在的，微信群則與大家聚在一塊聊天沒區別；QQ群設計時的情景與微信一樣嗎？不一樣，QQ是“虛擬社交”，微信則是“實名社交”；使用環境變了嗎？當然，QQ群時代以PC為主，微信時代則是手機入口為主。于是，情況一目了然，微信群是為了滿足熟人社群互動而存在的，他的特點與線下社交一樣，需要支持可以隨時隨地，幾個人聚在一塊就可以聊天，也不需要有所謂的群ID，于是，微信群的形態就是我們今天見到的這樣。

商業銀行的“需求”

商業銀行的需求，在具備需求的一般通識性特征外，回到第一性原理視角，還帶有大量的行業特征。本文試僅就銀行零售與對公業務作少許討論：

零售銀行。零售銀行中的產品需求，追根溯源后，金融需求是第二位的，其第一推動來自人的需求，即“生、老、病、養”，“衣、食、住、行”，與社交、娛樂等的需求，由這些需求衍生出個人客戶需要的資產增值需求、資產保障需求、交易需求、消費信貸需求、信用卡需求、汽車金融需求、住房信貸需求，最后以存款、匯兌、基金、保險、理財、消費貸、汽車貸、信用卡、房貸等產品的形態體現。

這些需求的特點，對商業銀行的產品設計和業務拓展而言，最終被歸納為業內常見的一個詞–“場景金融”。在零售業務中，需要追求讓金融服務無感地嵌入到場景之中。而場景資源通常是寶貴的，在互聯網時代，優質的場景入口，幾乎都被互聯網巨頭或垂類的公司所占據，而場景拓展的難度，常被商業銀行簡化為“開放銀行”的建設，甚至是進一步簡化為“openAPI”建設。“開放銀行”從第一性原理視角，是毫無疑問的本末倒置，是銀行中心論在今時今日仍不能放下身段的表現。openAPI在產品設計上，從銀行的視角，試圖通過封裝銀行內部的金融服務接口，提供標準化的對外服務暴露來支持任意第三方按需適配。問題在于，是銀行需要場景，而不是場景需要某家發布了openAPI的銀行，所謂的ApiBanK，在邏輯上并不成立。不信的話，去看看微信、支付寶的綁卡，是按銀行的標準來，還是按兩個巨頭的標準來，聯合貸的話語權是在銀行還是發起方。因此，在零售銀行領域，面向個人客戶的場景拓展，以及開發適配具體場景的產品，比搞開放銀行重要。而在技術準備上，不要去試圖制定標準，而應該通過適配層的抽象，通過sdk / h5等，考慮如何敏捷、快速、低成本地接入場景。

企業金融。與零售金融的需求圍繞個人的需求展開不同，企業金融業務的第一驅動來自于企業經營過程中的金融服務需求，它包括企業的“生產制造”、“貿易結算”，以及企業運營過程中的企業并購、補充資本、稅費繳交、招投標、采購、銷售、發薪、福利報銷等等。企業金融服務的需求，根據企業類型、企業規模的不同，體現出明顯的產業、行業甚至個性化特點。

也因此，企業金融業務中的需求提煉、挖掘，其實更考驗產品經理的能力。以廣義的貸款業務為例，假設某個企業提出需要一筆“流動資金貸款”，對客戶經理而言，站在客戶角度，則需要了解，這筆“流動資金貸款”的用途是什么，如果是用于向上游付款，該產業鏈上可以接受商票嗎？如果可以接受商票，是否可以改為簽發銀行承兌匯票？對應地，融資品種一換，企業就可以將需要付息的貸款，轉變為無需付息的銀承，減少有息負債，對優化企業的資產負債表，顯然更有價值。又比如，在為客戶辦理信用證開證時，要求繳納的保證金，銀行是否有能力分戶核算到企業自己的賬戶上，而不是都繳納到內部戶中，不同的繳交方式，雖然對銀行都是一樣的存款，但對企業而言，保證金存款將仍然體現在企業的流動性中，這顯然對企業資產負債表、現金流量表都更有價值。
不同于零售業務，在企業金融業務中，光融資工具就有貸款（可進一步根據具體的場景細分為一般性貸款、貼現、預支價金、押匯）、票（商票、銀票）、信用證、保函，以及由此衍生的各種擔保承諾類產品。在支付工具中，在普通賬戶之外，則有票據、信用證；在公私聯動中，有代發、代扣的專門解決方案；在存貸聯動解決方案中，有法人賬戶透支等等…也因此，企業金融業務尤其需要回歸企業的需求本心，真正深入企業，針對性地提供金融解決方案（內容太多，未來專題討論）。

需求分析的若干案例

商業銀行中，除了上述面向客戶的產品化需求外，還有一類面向內部作業的需求，這一類需求提出時，通常從提出者的視角出發，基于其崗位痛點提出需求，是最需要回歸第一性原理，進行全局性考慮的一類需求。看幾個具體案例：

CASE1：保證金開戶同屏授權改異步。

需求背景：在銀行承兌匯票業務中，保證金開票時需要開立保證金賬戶，保證金賬戶的開立需要同屏授權，由于業務量大，主管需要頻繁離開座位，進行同屏授權。因此提出需求：請將保證金授權由同屏授權改為異步授權。根因分析：銀承匯票業務保證金開戶過程中，因為保證金賬戶業務業務合同一一對應的關系，當銀承合同多的情況下，需要頻繁開立保證金分賬戶，每次分賬戶開立，不只是需要授權，還需要填寫申請表，并經支行行長簽字，開立時不僅是需要主管授權，操作人員還需要錄入一系列開戶信息，并驗證支行行長簽字。所以，這個需求的根本痛點其實是，在銀票業務中“開立保證金賬戶的操作十分復雜，影響作業效率，最終影響銀票的簽發效率”。方案設計：完成根因分析后，我們繼續追問，保證金賬戶的開立只是銀行承兌匯票簽發的其中一個環節，在開戶申請前，還做了什么？了解后發現，在開戶前，客戶經理已經錄入了銀承業務合同、為客戶開立了結算賬號，保證金開戶的所有要素都已經具備了，銀承業務合同在業務審批過程中，本身就需要支行行長及放款中心線上審批。這也即意味著，保證金開戶的要素已經全部具備，保證金開戶可以隨業務合同一起審批。于是，這個需求被調整為“銀行承兌匯票簽發的流程優化”，將保證金開戶、應解匯款戶開戶，與銀承業務合同的審批進行了自動關聯。改造完成后，不僅僅是保證金開戶不需要同屏授權，是保證金開戶的所有操作直接變成了線上化，客戶經理不需要再去柜面，運營同事也不需要再操作開戶，對應的簽字、驗簽，線下資料存檔等所有內容，也都被撤銷，銀票簽發效率大幅提升。

CASE2：幫我做個RPA，支持開戶信息錄入。
需求背景：某銀行開戶，采取線上預約機制，客戶預約填寫的開戶信息及開戶資料，在完成審核后，需要通過手工重新錄入到交易系統，十分繁瑣。
根因分析：這看起來是個開發RPA的需求，但RPA是否能夠徹底解決問題，是值得懷疑的。問題的根本在于，預約開戶信息及資料，為什么不能直接傳遞給客戶信息系統與賬戶系統，需要反復多步操作的客戶信息錄入與賬戶開立，綜合簽約等，可以通過服務調度，完成自動化處理嗎？
方案設計：答案顯然是可以的。于是，需求轉變為“實現預約開戶的全流程線上化”。負責實現的系統，從RPA，改為預約開戶系統，通過打通預約開戶系統與后臺交易系統，實現信息傳遞的線上化，并通過預約開戶系統實現服務接口的編排，將開戶變成客戶申請、運營檢查、自動開立的自動解決方案，大幅提高了開戶效率。

復雜系統

簡約崇拜天文學家開普勒說，“大自然喜歡簡約和統一”，哈代也宣稱，“美是首要的試金石，丑陋的數學不可能永存”。數學和物理學中那些充滿美感，而又蘊含宇宙普遍真理的方程–如愛因斯坦質能方程、麥克斯韋方程組、歐拉恒等式等等，常常被用來證明–簡單的才是美的。（下圖為歐拉恒等式，它將數學里最重要的幾個數字聯系到了一起：兩個超越數：自然對數的底e，圓周率π；兩個單位：虛數單位i和自然數的單位1；以及被稱為人類偉大發現之一的0。在數學分析領域，以及復變函數論中都占有非常重要的地位，被稱為“上帝創造的公式”）

“奧卡姆剃刀原理”同樣強調“若無必要，勿增實體”，主張剔除冗余，直擊事物本質，避免引入不必要的復雜性。在產品設計哲學中，“簡約”也經常被作為衡量產品設計成功與否的標準之一，尤其在消費者業務（to C）中，以蘋果、騰訊等為代表的產品設計，充滿了簡約的美感。有如此多的珠玉在前，于是在產品設計中，“簡約”常常被作為“產品經理”的追求之一，只是這種“簡約”經常被有意或無意的曲解：其一，數學與物理學中的簡約，是對本質和原理的解釋，其推導、論證過程充滿了復雜性，混沌系統的復雜性研究，甚至發展出了一門專門的學科–混沌工程；其二，產品中的簡約是對用戶而言的，要達到對客戶簡約呈現的目的，產品設計者需要有效管理和整合后臺的復雜；其三，并不所有的產品都可以做到“簡約”，比如下圖這個：

管理復雜

事實上，工程領域，以及我們生活中的大部分場景，復雜才是常態，無論是操作一臺汽車，還是理解一款金融產品，或是管理一個大型項目。唐納德·諾曼曾一針見血地指出：問題不在于復雜本身——復雜是客觀存在的常態——而在于我們如何理解、溝通和駕馭這種復雜。對產品設計而言，復雜并不是問題，令用戶困惑，甚至導致用戶不會使用，才是問題。關于復雜的一個例子，是男士們的書桌或房間，在一堆亂七八糟中，主人總是可以很容易地找到需要的物品，但經過太太的精心收拾后，很多東西通常神秘地不知所蹤。

糟糕的設計，無論是物理產品、數字界面、流程還是組織架構，會將本源的復雜放大成令人望而生畏的困惑，而優秀的設計則能化繁為簡，讓復雜變得馴服、透明，甚至富有力量感。管理復雜，并非追求絕對的簡單，那往往不切實際，而是追求“可理解的復雜”和“可管理的復雜”。諾曼為我們提供了幾個至關重要的手段：

建立有效的心智模型。?這是管理復雜性的基石。用戶需要一個關于系統如何運作的“模型”。這個模型需要能預測操作的結果。優秀的設計通過界面、反饋、文檔甚至隱喻主動提供并強化這種模型。這個最佳的例子是最近華為推出的尊界S800，通過手勢可以開關車門，控制車窗的亮度，將操作與大腦的自然反應進行了映射，當然前提是有黑科技支撐。

合理的分層。分層簡直是解決復雜問題的不二法門，面對龐大的復雜性，人類認知的天然策略就是分解。比如，以JAVA編程為例，可以分層為：JAVA源碼、.class字節碼、JVM、操作系統、計算硬件資源；銀行應用架構中，我們將系統分層為渠道層、產品層、風控層、賬務層及數據層；管理大型項目時，WBS也是典型的層級化應用，將大目標拆解為可執行的小任務。模塊化降低了認知負擔，使聚焦和掌控成為可能。

設計及時且明確的反饋。在復雜系統中操作，用戶需要清晰地知道“發生了什么”以及“我做得對不對”。反饋是建立和修正心智模型的關鍵。?優秀的反饋是即時的–操作后馬上有反應，在銀行應用系統的異步響應模式中，通常以“請求已受理作為即時ack的反應”、明確的–清晰地指示狀態變化或結果，銀行系統如果報錯，得給出明確的報錯提示、匹配的–反饋的形式和強度與操作本身相稱。下載文件時的進度條、提交表單后的成功提示或錯誤信息框，都是反饋的體現。缺乏反饋（點擊后沒反應）或反饋模糊（提示不清晰）會極大增加不確定性。讓用戶感到失控，是導致問題的常見源頭。

利用約束引導行為。復雜系統中存在無數可能的操作路徑，但并非所有路徑都是正確或安全的。優秀的設計通過物理約束，比如特定形狀的插頭只能插入對應的插座；邏輯約束，如必須先填寫A才能填寫B，常見于客戶填寫表單信息時進行關聯檢查；文化約束–比如通用的紅色代表停止/危險，以及語義約束（如旋鈕的箭頭方向指示旋轉效果）來限制可能的操作選項，引導用戶走向正確的行為。這些約束像無形的軌道，防止用戶誤入歧途，減少錯誤和認知負擔。例如，轉賬提交后，一定時間內將按鈕置為“灰色不可點擊”，就是運用邏輯約束和文化約束建立心智模型的典型案例，常用于避免重復轉賬。

善用默認值與預設。面對大量可選項時，用戶容易陷入“選擇悖論”的焦慮。優秀的設計提供經過深思熟慮的、適合大多數場景的默認值或預設方案。這并非剝奪用戶的選擇權，而是提供一個安全的、合理的起點。用戶可以在此基礎上輕松地進行個性化調整，而不是一切從零開始。例如，軟件的“推薦安裝選項”、銀行系統各種產品、核算、費用參數的初始化，都大大簡化了初始操作，降低了入門門檻。

標準化與一致性。當不同的系統、不同的界面、不同的流程遵循相似的規則和模式時，學習成本會大大降低。一致性是易用性的核心原則之一。相同的圖標代表相同的功能，相似的操作產生相似的結果，術語的使用保持統一。這使得用戶可以將在一個系統中習得的經驗（心智模型）遷移到另一個系統，形成規模效應，有效管理跨領域的復雜性。想象一下，如果每個網站的“保存”按鈕圖標和位置都不同，那將是多么混亂。

容錯設計。?在復雜環境中，犯錯是常態。優秀的設計能預見到可能的錯誤，并使其可逆或易于糾正。典型的如“撤銷”功能、“冪等”設計銀行應用系統是容錯設計的典范。清晰的錯誤提示、提供簡便的修正方式、以及防止災難性后果（如刪除前的二次確認），都能極大降低用戶面對復雜操作時的恐懼和挫敗感，鼓勵探索和學習。

商行產品緣何復雜

以上是產品設計的一般通識，是需要在產品或方案設計中遵守的常識性守則。而對商業銀行而言，因為行業的特殊性，使其產品或方案設計，更加不可避免地具備復雜系統的特點。這些特點體現在：

需求的多元性。不同于一般行業直接面向客戶需求，以解決客戶痛點為核心訴求的產品設計原則，商業銀行的產品設計，需要根據產品特性，同時考慮“客戶、合規內控、監管”三方面的需求。其中，客戶需求自然是毫無疑問的，滿足個人客戶在日常生活、工作、學習中面臨的支付結算、保值、資產增值需求，滿足企業客戶在生產經營、貿易結算中的金融需求等等；但在滿足這些需求的過程中，因為銀行業的特殊性–經營和管理風險，對應標的是“資金”，因此，對應的內控合規、營運安全求，同樣非常重要，比如流動性安全、不良率的控制、審貸分離原則等等，均需要在產品需求中得到充分考慮；在內控合規之外，商業銀行還面臨不同于其他行業的強力監管要求，包括巴塞爾協議中對rwa、ifrs9等相關的剛性約束，以及不同國家、地區監管機構要求的諸如窗口指導、貸存比、mpa考核、信貸行業投向、占比等要求。舉個例子，以設計小微企業貸款產品為例，需要統籌考慮3個方面的需求：

• 客戶需求包括：目前客群畫像、申貸方式（H5、APP、小程序…）、核身方式（五要素核身、活體檢測….）、風控批核模型申請評分卡設計（不同指標的權重測算）、選擇何種的還本付息方式、客戶申請到放款的周期和流程設計、還款方式（是否支持快捷代扣等等）；
• 內控合規需求：貸款合同的條款設計是否合規、事前反欺詐方式、行為評分卡的評分模型設計、貸后預警信號的設計，放款是否需要人工審查等內部流程設計；
• 監管需求：信用貸款的報送口徑，企業規模、類型的認定要素，是否符合產業政策等等，相關貸款產品的rwa、ftp、i9的影響以及對應的數據下送等等。

內部流程設計將直接影響客戶體驗。與一般的物理商品不同，商業銀行的產品實際是一攬子服務的集合，在物理產品的世界中，如果一款產品品質極其過硬，后續客戶與商家/廠家發生聯系的概率不大，但銀行產品與此不同，包括開戶、大額匯款、貸款申請等在內的服務，都會涉及到流程設計，部分需要與銀行的營業網點、反洗錢部門、集中作業部門發生聯系，此時，流程設計中，哪些可以由計算機自動化，哪些需要人工進行審核，就不僅僅是銀行內部降本增效的問題，而是會直接影響到客戶的使用體驗，比如一筆開戶申請，A銀行依靠技術手段，可以實現秒開，而B銀行手工操作，需要個幾天，客戶會選擇誰將顯而易見；同樣的例子是貸款（包括開票、開證）申請，如果一家銀行依靠技術手段，可以做到秒批、秒貸（在有效實現風險控制的前提下），其帶來的產品競爭力講師不言而喻的。因此，從客戶與銀行建立聯系開始，針對客戶旅程的全生命周期進行有效的流程設計，將是產品設計面臨的必然命題，而這通常涉及多個節點的跨系統交互。

差異化競爭優勢獲取需要跨域聯動的設計。高維打低維的降維打擊模式從來都是產品創新的靈感來源，微信紅包的社交打金融，余額寶通過將貨幣基金的投資功能疊加支付功能的產品升維，都取得了巨大的成功。這種現象級的產品當然可遇不可求，但是商業銀行中存在大量的存貸聯動、公私聯動的產品卻是不爭的事實，比如代發薪、擔保承諾類業務中，授信業務與保證金存款的聯動，法人賬戶透支產品中負債產品與融資產品的聯動等等，這通常會涉及到跨業務形態、跨業務領域的復雜設計。

銀行業系統架構分層的必然結果。在商業銀行長期的組織架構和IT系統應用架構的演進過程中，逐步形成的“前、中、后”臺模式，天然地需要進行跨部門、跨系統的協作以有效支持一款產品的有效實現。商業銀行常見應用架構的分層分布，如下圖：

從這一分層架構看，負債產品的產品實現，將不可避免地需要統籌考慮渠道層、公共服務層、賬務作業層、數據層的功能需求；而融資產品，則在負債業務的基礎上，還需要考慮風險控制層的功能實現；跨域聯動類產品，則在以上兩者之外，還需要考慮產品層的跨域聯動，如果涉及支付業務，還需要考慮與外部的適配等等。

應對之道

商業銀行的行業特點決定了銀行產品不可避免地需要管理復雜，而在可操作性層面上，有什么可行的辦法來管理這種復雜性呢，分為組織層面與個人層面。

組織層面。首先仍然是人才先行，針對性地建立一支優秀的跨領域復合型人才隊伍（產品經理、體驗設計師、流程設計師、業務架構師、開發經理等等），通過輪崗、深度參與大型項目等方式，培養隊伍成員一專多能的專業素質；其次是有條件的情況下，建立有渠道、產品、風險、財務、運營、IT、合規人員組成的產品委員會，對新建設產品，充分聽取各不同專業委員的意見和建議，對產品差異化競爭優勢、預期回報、合規可行性等進行充分討論和論證，產品建設做到謀定而后動；再次是有效的需求流程設計，比如最簡單的，一份需求在簽批環節，比如按流程經過風險、合規、相關配合的業務單位、營運、財務等的審閱，并充分發表意見，才可以進入到產品實施環節；最后，需要有充分的需求評審，將需求對應的業務背景、增長預測、功能說明、關聯需求等，向相關方進行完整的闡述并取得支持，需求評審時可以要求需求以模版方式呈現，如下圖所示需要覆蓋的內容：

個人層面。無論是產品經理、業務架構師還是開發負責人（一般也是技術方案設計者），首先是需要具備一些關于產品設計的通識性知識，比如知道基本的關于反饋、約束控制、有效心智模型設計的知識，了解基本的交互設計基礎知識；其次是需要養成系統性思維能力，多以全局視角審視和思考問題，強迫自己盡可能“知其然，且知其所以然”；再次是不斷學習，在深化本專業知識的基礎上，盡可能拓展“多能”的跨領域業務能力，在知識的深度和廣度上，都有所精進（畢竟藝多不壓身）；最后是要多實踐，盡量多地主動請纓，參加一些大型項目或產品研發，如果條件允許，可以考慮在一個領域待夠3~5年后，尋求感興趣的領域轉崗鍛煉，“紙上得來終覺淺、絕知此事要躬行”，理論無論寫的多好，都不如動手來得更有體感。

顯性與隱性特征設計

每一個讓用戶感覺“簡單好用”的產品或功能背后，都是產品設計者對產品顯性特征和隱性特征的統籌考慮，并通過一體兩面的兼顧實現和諧統一的最終結果。

產品經理的雙面視角

如何做好用戶體驗設計

怎么抽象復雜系統交互

持續敏捷

演進思維要求在面向不確定的市場與激勵的競爭時，需要快速低成本試錯、快速迭代，即用最小的可行性產品驗證假設，總之，需要進行敏捷。這一源自互聯網行業的方法論，在印象中應該偏穩健、保守的商業銀行，也被越來越多地推廣及運用。

為什么需要敏捷

商業銀行的產品敏捷，最直接的原因大概是“卷”，這大概是中國大陸，或者是帶互聯網基因的商業銀行–比如Shoppee Bank，特有的現象。“卷”是競爭，有競爭才會有進步，物競天擇，面對市場的波動性、不確定性、復雜性和模糊性（VUCA），那些能夠比競爭對手更快學習、決策和行動的機構，將獲得顯著的競爭優勢。除了競爭之外，商業銀行的一些經營特點，也是對敏捷能力的現實要求：

因應監管政策變化的要求。金融行業的強監管特性、央行的貨幣政策變化，都要求商業銀行的業務開展需要迅速適應政策變化的要求。如2013年至2016年期間狂飆突進的影子銀行業務中的“產業基金”模式、“票據資管”、“黃金租賃”業務等等，都是只在一定時期內被允許的業務，在一定時期內為開展這類業務的商業銀行創造了客觀的利潤。其他的，諸如央行LPR利率的推出、針對小微的再貸款專項計劃、再貼現利率調整對票據市場的調節、國家金融管理局對消金公司杠桿率、同業拆入規模、擔保增信的限制及由此影響商業銀行聯合貸、助貸業務的發展，都需要商業銀行進行快速的反應，在資源投放、政策修訂、產品調整、系統開發等方面，快速作出反應。

市場時機的的快速把握。包括以下幾類，1）、面向特定熱點事件、或者特殊時間窗口的產品設計。比較有代表性的，如AlipayHK為香港地區年底繳稅專門推出的繳費易產品（包括營銷補貼）、銀行當港股行情好時為投資者開發的IPO融資產品及專項孖展授信產品、因應黃金行情而開發的積存金產品等等；2）、以快制勝的市場競爭需要。以對公業務領域為例，高價值頭部對公客戶通常會成為多家商業銀行的潛在競爭客戶，此時，而他們需要的產品通常都需要定制化，誰能以最快的速度滿足從一線客戶經理傳遞上來的客戶需求，誰就可能獲得先發優勢，獲得更多的業務機會。

經營特點的客觀需要。商業銀行生息資產投放的特點及KPI的考核需要，尤其是在信貸投放領域，新產品的建設往往需要在年底前完成，并在來年通過開門紅，甚至在上一年年底就產生足夠的規模，然后在未來一年中的盡可能長的時間內，帶來經營收益。這種情況在貸款產品領域經常發生，常常需要貸款產品的產研團隊能夠對業務作出敏捷響應。其他因諸如適應季末、月末存款規模等考核要求而進行的產品開發，也在此列。
當然，最終還有一點更現實的，就是強KPI考核下的壓力傳導。大致有如下幾種情形：第一自然是自上而下的壓力傳導。來自于行長、分管副行長、各業務部門總經理依據全行經營戰略，分解落地而需要研發產品，在相當一部分機構中，管理者似乎缺乏耐心，大多按“一萬年太久、只爭朝夕”進行要求，一旦提出，就希望盡快看到成品；二是產品團隊本身，在對產品團隊強考核的商業銀行，產品團隊需要要么通過質量（產品完成的營收、利潤數字）、要么通過數量（沒有功勞，總要搶個苦勞），作為KPI的關鍵支撐，由此帶來的所謂“敏捷響應”需要；三是業務一線，分支行、客戶經理發現的市場機會（或誤以為的市場機會），其中一部分除了需要關系營銷外，還需要銀行中后臺以最快的速度為前線提供好的產品、解決方案以滿足前線的需要。
總而言之，”持續敏捷”能力建設，對銀行產研團隊而言，早就不是一個選擇題，而是銀行產研團隊生存與發展的必修課。

敏捷的誤區

然而，在實際工作過程中，“敏捷”卻常常被玩壞了：將違反科學規律、極致壓縮研發周期的蠻干當成敏捷；將缺乏規劃的功能堆砌，以戰術勤奮替代戰略懶惰當成敏捷；將scrum的引入，完成各種敏捷工具的部署，實則不計效果的形式主義當成敏捷；將頻繁的變更、碎片化的優化當成敏捷，勤奮地對客戶進行打擾。幾種在工作過程中常見的敏捷誤區包括：

多加資源就能縮短產品研發周期。這一點常見于很多銀行業機構，當一個產品、項目研發需要8個人，3個月的周期時，業務方、管理者經常會產生的一種迷思是，加到20個人，能不能將研發周期縮短到2個月？這就好比一個媽媽要懷胎10月，才能生出1個孩子，現在給你兩個媽媽，能不能幫忙將生孩子的周期壓縮到6個月？這一誤區不僅見于銀行產品、項目研發，也常見于銀行戰略中的所謂加大對“金融科技戰略”的支持–讓科技部門多招人。事實上，團隊也好、項目也罷，人都不是越多越好（當然更不能人手不足），維持一個“小而精”的團隊，是研發團隊或者項目組織的最佳策略。《人月神話》一書中，弗雷德里克?布魯克斯提出，向進度落后的項目中增加人手，往往會使進度更加落后。這是因為軟件開發是一種復雜的創造性工作，隨著團隊規模的擴大，溝通和協調的復雜性會呈指數增長。團隊成員之間的溝通渠道數量可以用公式n(n?1)/2來計算，其中n為團隊成員數量。例如，當團隊有5名成員時，溝通渠道有5×(5?1)÷2=10條；當團隊擴大到10名成員時，溝通渠道則增加到10×(10?1)÷2=45條。如下圖示意，曲線處于最低點時的人員規模，才是最佳規模，跨過最低點后，隨著人手的增加，效率反而下降：

碎片化需求而非價值交付。敏捷多數時候離不開迭代，迭代最終表現為做了多少次發布，這最終導致很多產研團隊有意或無意地誤入歧途：將需求拆得稀碎，發布的內容能不能給客戶帶來閉環的價值不重要，重要的是完成了多少次需求發布。這種本末倒置的做法，本質上是一種”交付的幻覺”——團隊沉浸在頻繁交付的成就感中，卻忽略了每一次交付是否真正解決了用戶的問題或帶來了業務價值。其典型的癥狀包括：1）、功能肢解。一個完整的用戶旅程被拆分成多個互不關聯的迭代，用戶需要等待數月才能體驗到一個完整可用的功能；2）、指標異化。團隊關注的不再是“是否提升了客戶滿意度”或“是否增加了業務轉化”，而是“本期完成了多少個用戶故事點（需求點）”；3）、偽敏捷。保持著兩周一次的發布節奏，但發布的內容多是 Bug 修復、體驗調優或邊緣功能，核心痛點始終得不到解決。

形式主義敏捷。形式主義敏捷是許多組織在推行敏捷過程中最容易陷入的誤區，通常是在“領導的親切關懷下”，引入所謂的“敏捷教練”，然后將Scrum的幾件套–站會、看板、待辦事項清單一一執行到位。筆者的親身經歷，本來運轉良好的產研團隊，在敏捷教練的一通指導下，搞得怨聲載道，開發效率急劇下降。其問題表現包括：1）、晨會是形式主義的重災區。一群人神經病式的圍成一圈本身就挺有喜感的，每個成員再按順序講一圈“昨天做了什么、今天要做什么、遇到什么問題…”，這簡直是荒謬。第一，這么公開的場合，能聽到多少真話？第二，產品負責人或者研發負責人，如果連團隊成員的工作進度、項目風險都不掌握，還要通過晨會了解的話，那就要趕緊換人了。如果領導者只是想通過晨會搞服從性測試，那請繼續，如果是為了敏捷，趕緊取消才是正道；2）、看板成為額外的負擔。除了給領導表演外，誰會真的通過看板去了解項目進度。真實的項目進度只在釘釘、企微的聊天記錄中，只在實實在在的文檔和代碼中，只在團隊日積月累的相互信任中。所謂看板，不但增加成員的雙重填寫壓力（他們還得在項目管理工具中再填寫一遍），還常常弄成表演者的舞臺–代碼一般是沒有領導看的，看板可不一樣，做的花樣百出指不定哪天就被表揚了。凡此種種，不一而足…敏捷的本質是適應性和快速響應變化，而不是對特定流程的宗教式恪守。當團隊忙于完美執行敏捷儀式而忘記了為什么要這樣做時，敏捷就已經失敗了。

勤奮的懶惰。在騰訊的產品哲學中，有一條非常令人印象深刻，即“避免勤奮地打擾客戶”。我們看到，騰訊系的產品很少會發生那種交互習慣被改的面目全非的情況，這后面一定包含著對產品迭代的嚴謹論證和產品功能上新、體驗改變的充分論證。但與此相對，銀行業機構似乎并不如此，筆者自己用過的手機銀行app，都經常出現過段時間就改頭換面一次的騷操作，一個手機銀行app，居然一路從1.0，發布到1x.0…事實上，在產品進入成熟期后，更多的精力應用用在功能細節、交互體驗的反復雕琢，對特別成熟、用戶早就已經習慣的產品而言，什么都不做，也比瞎折騰要好。在”敏捷”的旗幟下，產品很容易陷入功能主義的誤區，堆砌功能（甚至是堆砌產品）本質上是用“戰術的勤奮掩蓋戰略的懶惰”，不僅浪費大量寶貴的開發資源，還會讓產品變得臃腫不堪，給用戶帶來困擾。

實現持續敏捷

事實上，真正的敏捷必須是以價值交付和用戶體驗優化為中心的。每一次迭代都應回答一個問題：”這次發布為客戶或業務帶來了什么新價值？”如果答案不明確，那么這次迭代可能就是不必要的。
實現持續敏捷，不能僅僅停留在引入Scrum儀式或部署管理工具上。這些形式若沒有內在能力的支撐，終將流于表面。真正的敏捷源于以下核心要素：

建立良性的敏捷評價機制，始終堅持價值驅動下的敏捷。1）、迭代評審機制。每次迭代，都需要向管理者及敏捷小組成員說明這個迭代“可驗證的用戶價值”是什么，而不僅僅是以提出需求，完成開發任務為目標。哪怕這個價值很小，它也應該是一個完整的、可用的功能切片。2）、建立清晰的價值評估框架。在迭代開始前，要明確“如何驗證這個功能成功？”–是通過用戶反饋、業務指標還是A/B測試？3）、敢于說不。對那些不能帶來明顯用戶價值或業務價值的需求（如一味的領導偏好、盲目的競品跟隨），產品經理、研發經理要勇于拒絕，保持團隊的專注力。4）、用成果而非產出衡量敏捷的成功：團隊追求的不應是發布了多少功能，而是通過這些發布獲取了多少用戶增長、提升了多少客戶滿意度或降低了多少運營成本。

充分的組織準備，跨職能團隊與授權機制建設。傳統銀行科層制組織結構是敏捷的最大障礙。組建跨職能的特性團隊(feature team），將產品經理、體驗設計師、運營經理、開發工程師、測試工程師（在融資業務中，通常還會加入風險人員）等凝聚成一個目標明確、被充分授權的小型作戰單元，是進行能力閉環，形成團隊默契，通向敏捷的重要保證。互聯網企業中，除了按矩陣模式進行臨時的團隊編組外，還常常將一個個跑出來的產品線固化下來，形成有福同享、有難同當的利益共同體。這種”產品+研發+運營”的鐵三角團隊，在被賦予明確的業務目標和對實現路徑的決策權后，需求決策周期、需求澄清周期、研發周期、發布周期都將得到大幅壓縮。

服務抽象與架構支撐。后端架構的靈活性是前端業務敏捷的基石。以信貸業務為例，通過共享服務抽象，可以將指標模型、決策引擎、賬務記賬、額度計算、押品管理、客戶評級，分別抽象成獨立的共享服務，在零售信貸、小微融資及一般企業級授信業務中，共享這些能力，支持信貸類產品在推陳出新時，只需要改變準入模型、變化還款周期或還款方式、變更擔保模式等等，極大壓縮產品研發周期，實現有效敏捷。

需求分析與分解。Scrum從來都不是敏捷的核心，需求的分析與拆解，按冰糖葫蘆式組織一個一個交付閉環的功能點，才是敏捷的核心與關鍵。它要求產品經理能夠精準捕捉用戶和業務痛點，確保解決真正有價值的問題按MVP（最小可行產品）思維，優先被交付；它還要求產品和交付團隊，能夠將大型需求拆解為獨立的、可交付的小用戶故事。以下是騰訊8分鐘產品課中分享的產品迭代原則，以支付業務為例：

他將產品需求分為“安全可用”、“使用體驗”、“擴展兼容”、“生態體系”四級，與馬斯洛需求層次理論類似，因為支付涉及到資金安全，支付資金的安全、避免陷入反洗錢的麻煩，就成為支付產品的最基礎需求，這個都做不好的話，遑論其他；之后是使用體驗，而使用體驗的核心便是支付成功率，Lucy（彭蕾）在帶支付寶團隊的時候，其重要貢獻之一，就是大幅提升了支付寶的支付成功率；再之后是能力的擴展，對多類型支付工具的兼容；最后是構建龐大的生態，形成產品的深度護城河，在支付業務中，這包括線上、線下收單場景、商戶的推廣，用戶使用習慣的培養等等。

Devops體系的構建。如果說服務抽象為敏捷提供了可復用的能力積木，那么DevOps體系則是確保這些積木能夠被快速、可靠、高質量組裝和交付的流水線。如果一次需求上線需要經歷冗長的部署文檔編寫、人工申請、多環境手動部署與測試，那么敏捷必然就會以IT人員的加班、人肉運維為代價。Devops體系的構建需要在至少3個方面完成能力建設：1）、自動化工具鏈貫穿全過程。從開發人員提交代碼開始，通過版本控制工具(如Git）、持續集成（CI）工具自動觸發編譯、單元測試與代碼質量掃描；通過持續交付（CD）工具自動完成測試環境、預生產環境乃至生產環境的自動化部署與回歸測試；最終通過自動化監控工具持續觀察應用性能。這條工具鏈將人工從重復、易錯的流程中解放出來，使數小時內完成一次高質量發布成為可能。2）、實現基礎設施即代碼。通過代碼來定義和管理基礎設施，使得服務器、數據庫、負載均衡器等資源的申請、配置與銷毀均可通過自動化腳本完成，實現基礎環境的版本化、可追溯和快速重建，為業務的快速彈性擴縮容奠定基石；3）、構建完備的可觀測性體系。構建包括日志、指標核對與鏈路追蹤的全方位可觀測能力。實現從敏捷開發態下，生產運維由“被動救火”到“主動預警”乃至“故障自愈”的演進。

結語

在組織架構設計、文化特點、支撐體系迥異于互聯網的傳統商業銀行，持續敏捷對身處前線的產品經理和開發人員而言，多數時候是一種無奈的奉命行事。但在局部的微觀生態中，它仍然應該是產品經理、開發經理、運維經理應該努力追求的目標。因為要達成真正的持續敏捷，它要求我們能夠練就一雙慧眼，能夠洞悉用戶真正的問題和關鍵痛點，對最小可驗證需求進行提煉；它還要求我們不斷掌握更多的業務知識，在專業能力的牽引下，去規劃產品的迭代方向；它還要求我們去理解和駕馭復雜，養成“系統化”、“結構化”思考問題的習慣；它更不斷啟迪我們不斷去思考如何構建能夠快速響應的團隊、架構與文化。而所有這些方面的歷練，終將會千磨百煉出一個更好的自己。

作者：高爾斯基