傳統金融機構們的App——尤其以手機銀行、手機證券爲最，發展到今天，已經產生一系列的問題：從用戶角度看，體驗普遍不好、高度同質化；從業務運營角度看，幾乎沒有什麼“運營”的抓手；從IT角度看，投入產出比低、難以真正敏捷迭代持續交付。並且這些App普遍違背移動互聯網的基本要素。
金融類App真的以客戶爲中心？
先說用戶體驗。從用戶視角來看，我們恐怕無法認同現在市場上的大部分這類App是以客戶爲中心的。很多App的產品其實談不上設計，只是堆疊功能，要麼是根據業務部門的需求增加一些菜單、入口，要麼是基於合規監管的要求改造一些操作流程（例如配合KYC、適當性管理增刪一些界面），要麼是“借鑑”友商的一些做法進行一點改良，要麼是基於“臆想”進行一點“創新”；行業總體相互因循沿襲，唯獨缺乏對客戶核心訴求的關注和理解。
收集用戶在App端側的交互行爲數據，結合其雲側的交易歷史，再匹配每天交易市場的行情變化，完全可以構建出模型對用戶的操作習慣、投資偏好、對市場變化的反應、所關注的功能等等進行描繪，或者說把客戶給“數字化”了。這些海量的客戶畫像，對App的優化產生關鍵影響，決定下一個版本的設計。
但是，估計這個“閉環”對於目前市場上大部分傳統金融機構的App並沒有實際形成（雖然很多App產品經理和大數據團隊會大談App“數據埋點”，但是團隊能夠常態性的哪怕用Excel進行手工統計分析並迅速反饋到研發中已經很不錯了），所以大部分的App在很長時間內看上去都是“千人一面”、一成不變的，直到某一天也許出於下一任App產品經理的靈光一現進行大改版。
再說說同質化。以券商的手機證券類App爲例，同質化程度是非常高的，雖然業內的這些App水平也有高下之分，可是對於大部分的用戶而言，App的差異恐怕不足以讓用戶決定成爲哪家券商的粉絲乃至客戶吧。
換句話說，客戶更有可能是因爲你的App做的特別爛而拋棄你，卻不見得能僅僅因爲你的App做的稍微好而投奔你，況且一家金融機構的App哪裏是那麼容易把自己在消費者中的口碑做起來？
同質化的原因之一，是券商們的業務形態總體相似，業務層面就已經高度同質化，在手機屏幕的彈丸之地，界面佈局、交互設計還能玩出花來？行業相互“借鑑”、“沿襲”的習慣也非常嚴重。原因之二，是業內絕大部分App的“內核”，都來自有限的廠商，外觀看上去大同小異，券商的科技團隊自己嘗試把這些傳統封閉技術換張皮估計也得自己先掉層皮吧。
活躍度低。移動互聯網時代，用戶手機裏充斥數以百計的App，但大部分都處於“長期無用”狀態。銀行、證券類的應用，是典型的效用工具，隨需隨用。某些銀行嘗試讓自己的App增加各種與客戶的觸點，從而提升用戶活躍度、黏着度、使用時長，但即便銀行具備無比豐富的生活應用場景，在這方面努力收效甚微。
對於券商來說，其App啓動的頻次也許會高一些，畢竟股民每天還是需要看一下行情。可是我們看到股民一邊用某互聯網公司的股票行情App看行情、一邊用某第三方財經App看資訊、最後才用自己賬戶所在券商的App做交易的情況不在少數。
正如銀行雖然掌握着巨型的資產負債表卻被第三方支付平臺、技術平臺攔截、割裂了與客戶的直接聯繫一樣，大部分中小券商也可能逐漸淪爲可被隨意切換的交易通道，議價能力越來越低。
金融類App普遍沒有運營抓手
傳統泛金融機構的App也好網站也好，總體來說缺乏“可運營”的設計考慮，這方面和互聯網公司的差距不是一星半點，畢竟互聯網公司們的謀生之道就是全靠網上，在線運營推廣套路多多。依靠線下營業網點做零售的銀行、券商們，在線上運營確實無論經驗、人才都非常缺乏。有在線運營意識的員工只能在互聯網公共平臺上營銷展業，可是又面臨巨大的合規監管問題。
銀行、券商們自身的App，確實沒有多少可以與客戶進行互動的抓手，除了在App的首頁展現一個理財產品的廣告條，能做的事情不多。此外，由總部統一運營的內容，也往往和全國各地區域性網點的本地化訴求沒關係。或者說，沒有哪家機構的App可以允許自己的區域人員參與到運營中，所以網點的員工往往自己都不關注自家App的內容，去某個銀行網點諮詢App裏推廣的某些產品，也許當地的服務人員會“措手不及”，給你一個“一臉懵圈”的表情。
金融類App版本難以敏捷迭代
大家都在講敏捷迭代，但對於傳統金融機構IT而言，“敏捷”在更多時候只是一種良好願望而已。
首先行業特點決定了安全、穩定、合規、健壯的App的基本屬性，“維穩”是技術團隊要遵循的第一原則，對於能引起生產事故導致監管問責的任何缺陷絕對是零容忍，更多的創新抵不過一張問責函。
其次，大部分金融IT缺乏互聯網公司通常具備的藍綠測試、灰度發佈的全閉環（包括支持滾動發佈技術產品的基礎設施、運營配合的方法論、發佈與回滾的管理制度），所以試錯成本非常高。隨着App功能的不斷堆疊豐富，每次需要回歸的測試場景越來越多。一直以來高度緊耦合的技術架構，導致任何功能的改動增加，都是牽一髮動全身，只有維持非常高的測試覆蓋率才能真正保障舊有的功能沒有被新的改動破壞。
結果測試周期越來越長，尤其是在做不到自動化迴歸測試的情況下，手工測試團隊永遠疲於奔命：當業務功能從30個堆疊成300個的時候，我們完全可以理解IT運維團隊以極其保守的態度對待App新功能的發佈、希望以延長測試時間來保障上線質量的心態。所以快速響應業務、市場需要的“敏捷迭代”，哪怕在開發階段可以維持，到了測試、發佈階段也不得不終止。
歷史包袱越來越多，App逐漸變成一個“脆弱系統”（隨着時間的遷移、人員的變動，整個系統裏總是有些沒有人願意觸碰的關鍵部分，唯恐修改不慎導致巨大生產問題），開發步伐越來越慢，投入產出比則越來越低。
傳統金融機構的App中的功能，用2/8法則來看，很有可能其中80%的功能只有20%（甚至更低）的用戶在使用，換句話說絕大部分的功能都是使用價值很低的。但是金融機構無法像互聯網企業那樣擁有自主選擇權去決定放棄某些功能。
以券商App的“銷戶”功能爲例，這是一個監管要求在一定截止日期前提供的App功能，哪怕券商多不願意提供、或無論其客戶多麼忠誠而不需要這個功能，實現它是一個剛性要求。但是即便開發上架這樣一個不算複雜、不算常用的功能，對於某些券商的App也是一個大挑戰 ——可以耗費數週、能夠引起故障。
當前App典型問題的根源
導致上述三類問題的根本原因有兩個，一個是技術架構的掣肘，一個是產品設計對移動互聯網的認知偏差。
當前主流銀行、券商App的技術架構，完全是“緊耦合”的，以證券類App爲例，代碼框架不清晰、模塊化缺失、功能耦合度高，開發團隊在軟件工程的專業程度較低，例如面向對象設計及領域建模的最佳實踐缺位、在設計階段對技術架構沒有能力預先考慮“可測試性”（Testability）、對組件化理解偏差、版本管理及依賴關係管理的工具鏈沒有正確領會使用等等，技術功底離科技公司的標準有一定差距。
在App的設計方面，很多設計者並沒有理解透徹移動互聯網、手機設備“外形因素”（form factor）的幾個基本要素：點對點連接、社交屬性強、用戶總是“在線”、更加場景化、普適性極強 （一些看似“地球人都明白”可是大部分人沒有仔細斟酌深刻理解的東西）。
當前的很多金融App是如何無視上述要素的呢？首先是功能繁複堆砌，違背了手機彈丸之地裏應用需要簡單易用的“普適性”原則。什麼是“普適性”（pervasive）？微信就是一個最好的例子 ： PC時代完全無法上網、使用瀏覽器的祖父祖母們，現在都是微信的重度用戶，這就是普適。
其次是該App明明運行在一個移動電話裏，可是卻沒有與他人互聯互通的能力，客戶有疑問無法就當前操作的上下文在App裏找到實時響應自己的服務人員、而客戶經理則眼睜睜看着客戶在App上而無法觸達她，最終雙方的溝通還需要藉助其他渠道。
例如：理財師只能通過電話致電VIP客戶，費勁的告訴她打開App進入哪個菜單入口打開哪個界面、對哪個合適的理財產品進行交易操作；而客戶則同樣詞不達意、費盡脣舌向客戶經理描述自己在App裏的操作問題，而對方無法清晰瞭解，迫不得已只好對App截個屏通過社交平臺分享一下來把事情說明白。
傳統金融機構的App，對於用戶而言往往是典型的信息孤島：App的所有用戶只是和服務器端一堆冷冰冰、僵硬的接口連接，雖然人人都以同一個App接入，彼此卻無法聯通（哪怕移動互聯網確實是任何手機可以對接任何其他手機的點對點網絡）。
在用戶的同一臺手機裏，金融機構的App往往與同一部手機上的其他應用形成孤立、隔絕的信息孤島，例如無法分享內容至社交平臺或反之（合規方面的考慮固然是決定能否這麼做的因素，但我們更相信這是App產品經理在這方面意識的欠缺），作爲信息孤島的App是沒有生命力的，因爲它無視用戶在端側所要求的便利，也失去自身向其他應用渠道傳播的能力效應。
上述兩個問題根源，導致到目前爲止大部分的App開發還是被按作一種“信息化”的方式在進行，也就是把移動端當作小屏幕的PC，採用的技術架構與PC時代無異。
我們認爲移動互聯網是“數字化”的開端，它的應用形態與“信息化”時代的應用形態是不一樣的，前者強調雙向、連接而後者只是由內而外的單向的信息傳播與服務輸出（本文受篇幅所限，不就“數字化”與“信息化”的區別進行討論）。移動端按傳統“信息化”思路實現的直接後果，就是割裂金融機構與客戶的關係：一方面客戶因爲移動互聯網帶來的便利而無需造訪金融機構營業網點，另一方面金融機構與客戶失去線下面對面的觸點但是又無法建立起線上的連接互動。同質化的業務、同質化的App，最終導致的就是客戶的忠誠度、黏着度爲零。
現階段把App當作一個手機軟件來看待是過時的，認爲改良一下App的用戶界面、調整增刪一下功能就能提升“用戶體驗”，也是一種錯誤的認知。
App並不是用戶體驗的全部，例如App裏有沒有服務人員隨需隨應？一個真實例子是某甲作爲某大銀行十多年的七鑽用戶，可是從來沒有在該行的App裏聯繫自己的客戶經理獲得過成功迴應 - 恐怕App本身做配備1000項功能，對該用戶也無“體驗”可言。
提升活躍度和建立運營的抓手是”社交“
把金融類App當作一個“掌上型門戶”、集成各種中後臺應用功能向用戶提供服務的架構思路，已經走到盡頭。如上所述，這種思路導致的產物，實際上無異於一個單向的、把金融機構的業務信息化輸出給用戶自行使用的Web 1.0時代的“網站”。這種App與客戶毫無“關係”可言。客戶甚至都懶得銷戶、換個App就成了別家銀行、別家券商的客戶。這種風格的App，就不要談用戶“活躍度”和“使用頻次”了。用戶一定是“無事不登三寶殿”，牛市時使用頻次也許高一些，其他時候讓用戶多使用App的企圖則基本上是徒勞。
套一句俗一點的說法，在“移動互聯網的下半場”，銀行們券商們的App需要認真考慮移動互聯網本身的最重要特點，讓本身就運行在手機通訊工具裏的App迴歸通訊協同的本源 ——社交化。也就是說，讓用戶在你的App裏能夠彼此進行交流互動、與你的員工和團隊進行交流互動。
當用戶（無論個人還是機構客戶）打開一個銀行App的時候，他在這個App裏不僅能自助服務或者聯繫一下呼叫中心，還能找到一個客戶經理、一個能實時解決他此刻問題的理財顧問、一個提供一站式服務的專業團隊、甚至一整個營業網點（該客戶所屬的物理網點在線上“數字孿生”），這就是所謂的“Bank in a pocket” ——讓用戶帶上他的銀行/證券公司出行，任何需要的時候打開App，虛擬化的銀行、券商就在App裏。
這樣做的好處有三：
（1）客戶能通過App與理財師、工作室建立關係——這纔是真正的“關係”，沒有交流能有關係嗎？
（2）銀行、券商的員工終於有主動觸及客戶的途徑、出口，可以通過向客戶提供有價值的信息來展業、獲客、鞏固關係。券商App裏採購回來的第三方資訊都是同質化的、並且往往也無法成爲客戶最信任的信息源（很有可能客戶寧願去看專業財經App）。但是券商的明星分析師分享的專業見解、投資顧問向客戶個人定向提供的建議，卻是App裏真正有價值、能產生差異化的資訊，是真正屬於券商自己生產的信息。
（3）運營終於有了途徑與抓手——雙向交流互動，是在線運營的基本條件，如果結合市場化的激勵機制，完全可以讓區域性營業網點、線上虛擬團隊或工作室自主負責O2O運營，擴大本地網點的服務半徑，主動出擊發展客羣，而不是受制於“千人一面”的總部無差異統一運營（也就是找些互聯網公司統一引流、在App裏推廣一些產品等等）。
簡單總結：一個運行在手機裏的App本身沒有交流互動能力，算不算是“忘記了初心“？是時候把這種能力認真構建到App裏，重建客戶與金融機構的遠程卻可信賴的數字化關係。
敏捷迭代快速創新的訣竅是“化整爲零”
作爲追求代碼潔癖的軟件工程師，我們對“緊耦合”的技術實現可以說是深惡痛絕。要解決當前金融機構移動端App日益沉重、難以真正迭代、投入產出比低的問題，首先在技術架構上要實現真正的“鬆散耦合”。
鬆散到什麼程度呢？我們知道你可以通過面向對象設計來解耦代碼級的依賴關係，你也可以通過組件化以及包管理工具來更進一步解耦二進制模塊，但是這些技巧都不足以讓一個同時遭受合規監管壓力和市場變化壓力的傳統金融機構App提升敏捷度、降低試錯成本。更何況大部分團隊並不見得掌握這些技巧。
更徹底的解耦，是在一個相對穩定的App“內核”基礎上，讓絕大部分的應用功能（不管是因爲創新需要、業務部門訴求、合規監管要求等等而產生）必須可以（1）獨立開發，（2）獨立部署，（3）獨立運維，（4）獨立管理生命週期——隨時上下架而不影響App主體。
解決方案就是對現有的App做瘦身，化整爲零，把功能高度“碎片化”。
”碎片化“ 現在已經是一個潮流。首先，在移動互聯網時代，用戶的閱讀時間、應用使用時間都是高度碎片化的。與之相對應的，就是前端用戶體驗的碎片化。全中國的手機用戶都已經被微信小程序充分教育，各種場景下“隨需隨用”、“用完即扔”，是非常典型的“效用計算”。
而在雲端，過去幾年來“微服務”大行其道，本質上也是把傳統“單體應用”碎片化。碎片化當然帶來管理它們（小程序、微服務）的耗損，但是現在這些問題早就被越來越成熟的開發運維平臺、工具鏈解決了。例如：Docker容器化生態、Kubernetes容器編排管理技術、FaaS函數即服務工具鏈等等讓雲側的小粒度服務開發運維更便利、穩定、彈性可擴。而微信本身則實際上在端側充當了小程序的“運行時”及管理工具。
微信本身與運行在它上面的數以百萬計的小程序，就是一個“鬆散耦合”的最佳例子 ：微信自身的版本迭代，從來與任何第三方小程序無關；每天互聯網上各種小程序的迭代升級、上架下架，也不會影響到微信運行的穩定性。
如果銀行、券商們能把自己的App做成像微信一樣穩定，把App中的業務功能拆分出去以類似小程序的技術載體進行碎片化、單一職責、獨立生命週期的開發部署，是不是金融行業特有的既需要維穩又需要敏捷迭代的矛盾就有希望得到解決？
這種程度的鬆散耦合，讓業務功能可以獨立於App進行開發、測試與上下架，有這樣一些顯而易見的好處：
（1）新業務功能單獨測試單獨發佈，不影響基礎App的穩定性，也無需對App進行全迴歸測試。
（2）業務功能開發可以高度並行 – 只要有人手，人多好辦事（想想微信讓全互聯網的開發者都可以同時互不影響爲它提供海量應用場景），而在傳統原生App的技術體系下，這是不可能的。
（3）容易藍綠測試、灰度發佈 – 粒度細到碎片級（例如一個微信小程序是可以僅在測試白名單的範圍內試點）。
（4）形成技術生態 。一家金融機構如果掌握了微信這樣的技術，它也可以成爲一個技術生態中心，讓外部開發者、合作伙伴們遵循一定的標準開發碎片功能並申請上架到該金融機構的“應用商店”，在合規的前提下這些碎片即可類似微信小程序被該金融機構的App用戶使用。
簡單總結：要滿足金融行業既穩妥又敏捷的App迭代訴求，銀行、券商們需要採用一種新的技術架構，解耦其通用、穩定、基礎的核心功能與場景化、變更性強、業務和運營相關的應用功能，一方面使前者健壯穩固，另一方面支持後者靈活多變。
解決方案：金融“物”聯網
凡泰極客認爲解決本文所討論的所有問題的出路，是幫助每家金融機構打造自己的金融“物”聯網（Internet of Everything For Financial Services）。它應該回歸移動互聯網的社交化（social）、場景化嵌入（embedded）、普適（pervasive）、隨時在線連接（always-on/connective）、開放（open）的特點，轉化傳統重型App爲輕量化的金融物聯網入口，讓客戶與其他客戶、客戶與金融專業服務人員、金融機構員工與其他崗位、金融機構與合作伙伴、人與非人（機器人、算法、數據、應用）互相連接，實現在線、協同、強交互、遠程信任關係下的連接。
爲此，凡泰極客的工程師們經過兩年的研發，面向金融業（不限於銀行、證券、基金、保險和其他泛金融領域）構建了一個 FinChat金融社交技術生態，包括以下生態成員：
FinChat金融級合規通訊與協同平臺。支持豐富、強大的通訊協同能力，包括文字聊天、羣聊（普通羣、保密羣）、語音、視頻、網盤、信息已讀回執、文件傳輸、頻道（類似Slack）、通訊錄、URL預覽等等功能。任何金融機構可以私有化部署，並把FinChat SDK（支持iOS、Android、Mac、Windows、純JS）嵌入到自己的App中，輕易實現自身App的社交協同能力。這是以社交技術連接一切的基礎技術平臺，幫助金融機構解決數字化服務“最後一公里”問題。
FinChat Federation（多站點“聯邦”互通）。上述合規通訊與協同平臺，可以被部署多套 —— 例如不同部門各自部署、不同子公司各自部署、內外網面向客戶與員工分別部署等等，但是“站點”之間可以互相聯通同時又維持獨立安全的隔離空間。金融機構內部特別需要的“動態業務防火牆”、“內外網隔離”場景均可得到滿足。
FinChat小程序運行時。我們提供這個技術幫助金融機構打造自己擁有的小程序生態。有了這個技術，金融機構們可以對自己的App進行瘦身，把新舊功能剝離，以獨立生命週期、獨立開發測試團隊的方式進行開發。讓基礎App保持穩定、讓頻繁增刪變更業務功能成爲可能，同時最大程度降低開發門檻、減少試錯成本、實現敏捷迭代。（注：我們的“小程序”技術並非“微信小程序”，但是技術原理類似，任何懂得開發微信小程序的工程師都能輕易掌握FinChat小程序。對於金融機構而言，掌控這個技術的意義是，擁有了一個開放的技術生態，讓更多的社會資源爲自己所用）。
FinChat應用商店。應用商店裏上架與統一管理各種業務功能“碎片”的技術載體，包括但不限於“小程序”、“Progressive Web App（PWA）”、“聊天機器人”等“物”，它們由金融企業內部開發人員或者外部合作伙伴開發，經IT與合規審覈上架，被投放到該金融企業的FinChat社交網絡中，與用戶產生連接，形成一個金融“物”聯網。應用商店裏的每一“物”，都體現了一個單一職責的業務場景。FinChat社交網絡裏的一切交流溝通，均與場景、上下文關聯。
FinChat 會話即平臺（Conversation Platform as a Service - CPaaS)。FinChat本身絕不僅是一個簡單的聊天工具或者“即時通訊企業版”，它本身是一個二次開發的平臺，支持容器化微服務、函數即服務（FaaS）、機器人開發框（Botkit Framework），配備DevOps所需要的運維監控工具。FinChat服務器端的API接口近300個完全開放，讓業務場景可以無縫整合到平臺中。
FinChat數字化身份管理。金融機構可以利用FinChat的賬戶系統、統一認證、分佈授權、單點登錄能力作爲基礎，基於開放標準實現企業內外（包括員工、客戶、合作伙伴）的數字身份管理。在互聯網上很多應用或網站，接受以Google、Facebook、Twitter、微博、微信作爲登錄認證源。我們相信金融企業需要一個類似的內部社交平臺充當認證授信服務的提供者，讓企業數以百計的新舊應用避免重新發明車輪 – 每套系統一個獨立賬戶系統的做法對於金融機構來說已經成爲另一個巨大的問題。
FinChat 數字關係鏈管理（Digital Relationship Management - DRM）。FinChat覆蓋了數字化服務的最後一公里 – 只要客戶通過App裏的FinChat入口進入金融機構的社交網絡與任何人員發生過交流，社交關係就自動生成。和傳統CRM的簡單一維關係不同，FinChat充當金融企業內外一切數字關係的統一管理中心，無論關係鏈是在客戶與員工之間、員工與同業外部夥伴之間、內部崗位之間、還是人與機器人之間。所形成的社交圖譜，能幫助金融機構挖掘很多有趣的應用場景。
FinChat合規存儲（Compliance Store）。作爲一個可選項模塊，合規存儲對整個“物”聯網的一切消息內容進行合規留痕的存儲，實現不可篡改（WORM – Write Once Read Many）。這對一些事件（例如服務過程中的糾紛、違規行爲等），可以進行索引、舉證，以提供法律依據。
FinChat搜索引擎。作爲一個企業用於構建自己內外部生態的社交網絡工具，交流內容留存於金融機構私有云上，用戶對其歷史內容的授權的在線搜索，也發生在雲側。這符合金融企業的場景與需求，有別於微信等端側的內容搜索（對於用戶而言）。
全新交付模式：社區版免費、源代碼開放
作爲一支一切日常研發活動發生在Git技術生態裏的技術團隊，我們覺得是時候把互聯網界的開放技術文化引入到金融行業。FinChat技術體系裏的部分基礎模塊，我們對金融機構提供社區版供體驗。
FinChat企業版的採用者，則自動獲得凡泰極客開發者社區賬戶，將能訪問到我們的容器鏡像倉庫、iPhone/Android/Node.js的模塊倉庫，通過容器技術工具鏈、前端模塊的包管理工具鏈，獲得最新的技術模塊，以部署、整合到自己本地的環境中進行二次開發。
授權的企業開發者，獲得權限訪問我們日常研發更新的部分源代碼庫 。目前對金融機構開源的主要包括iPhone、Android以及JS版本的SDK（一系列鬆散耦合、可深度訂製的端側組件），未來我們將授權機構客戶獲得更多的技術產權共享。我們也歡迎業內開發者通過Git Pull-Request把缺陷修復、代碼優化貢獻回來與主線代碼合併，從而與主幹保持一致。
我們深信這是能促進行業科技水平提升的技術交付、共享模式。業內需要專注於技術平臺、底層硬核技術的科技團隊，通過極其開放的SDK、API、PaaS、CICD Pipeline（持續交付管道）、源代碼，向金融機構的IT團隊提供可自行深度訂製的技術工具，讓其專注於真正應該做的事情：業務層面的代碼開發。而金融機構IT則“有所爲、有所不爲”，聚焦金融業務但對基礎設施提出需求，讓通用底層場景被抽象出來，讓專門團隊更專業更開放的回饋、服務行業。相信這樣的行業生態能促進金融行業的科技發展，避免基礎設施的重複建設，同時讓基礎設施做專做精。
我們將這樣向行業交付FinChat技術，助力金融業的手機App走向移動“物”聯網時代。
本文來源：凡泰極客（微信公衆號：finogeeks）