街口電子支付技術長林世鵬 (攝影/洪政偉)

5年多前,街口App上線,整合了行動支付與O2O票券販售服務。這個當時以串接商家、用戶與金流為主的服務,從2017年開始,大動作準備進軍電子支付服務,展開了一連串地端服務建置與線下通路準備,這一年間串接的銀行數,也由1間成長到10間。隔年年初,街口電子支付(簡稱街口支付)服務正式上線,大受市場青睞,這一年的用戶數節節攀升。

此時,各種合作機會蜂擁而至,使得街口支付的業務類型與數量開始爆發式成長,造成了開發需求爆炸。串接多家銀行、商家、第三方合作夥伴,也讓系統的複雜度急遽增加,以往傳統的開發模式已難以負荷。甚至,大型服務的開發效率開始低落,因此,街口支付選擇導入微服務架構,將功能、新的需求拆出來,分散給不同的團隊進行開發。

街口導入系統架構微服務化一年來,大幅提升開發與需求交付的效率,越來越多功能,也再次帶動使用規模成長。

根據金管會數據顯示,2019年6月,街口支付的用戶數為88萬人,當月代理收付實質交易款項金額達8億元。然而,此時的街口支付,因為系統服務繁多,已經到達了一個臨界點,架構微服務化的效果彷彿失靈,因此,IT團隊再度面臨開發效率低落的問題。

街口電子支付技術長林世鵬表示,主因是業務領域定義不清,同樣業務的服務分散各地;加上多個業務域功能與資料耦合,使得內部團隊理解協作成本高;以及業務分散且資訊不透明,開發人員大量重複建設;此外,在開發、錯誤修正需要大量溝通確認,使得系統開發效率低落,系統穩定性低。

2020年初,林世鵬剛離開阿里巴巴的工作,回臺加入街口支付就面臨這個棘手的狀況。他意識到,「整個系統與工作流程,已到了必須質變的地步,得盡快克服才有辦法因應接下來的挑戰。」

面臨系統開發效率低落,靠定義業務領域明確各團隊定位

街口電子支付技術長林世鵬表示,工程師不能將自身的定位與工作內容,放在眼前的程式碼;必須以如何替公司的業務加值作為前提,反過來思考怎樣透過技術做好這件事。 (攝影/洪政偉)

先從系統開發效率的問題著手,「明確團隊的責任,明確系統的責任」,這是林世鵬到街口支付做的第一件事。他提到,以街口支付60名工程師的規模來說,所負擔的業務算是相當複雜,於是,他決定從3個面向來定義業務領域,分別是基礎服務、金流、業務,給予每個團隊明確的定位。

林世鵬強調:「這3個團隊會有各自負責的業務領域,而且彼此間的業務領域一定是互斥、沒有交集、不重複。」其中,基礎服務團隊負責的業務領域,是像用戶中心、訂單中心、營運後臺這類能支撐整個多變的業務,以及公司營運狀況的系統。此外,也獨立出一個負責金流與支付的團隊;最後是負責業務的團隊,舉凡叫車服務、外送平臺、繳費等,這類得依靠支付能力與基礎服務能力,才能支撐起來的業務服務,都歸類在此業務團隊。

然而,為了讓各團隊職責分明且有所共識,林世鵬與團隊經歷了一段陣痛期。他要求各團隊只能負責所指定的功能,不允許像過去的作法,只要團隊有空,也能接手開發其他團隊系統需求的情況發生。他坦言,一開始團隊有些不習慣,但,持續執行了3、4個月後,效果明顯浮現出來,不僅整體的溝通變得較為單純、有效,團隊對於系統的服務,以及團隊成員的領域知識,都變得更加內聚、精煉。

透過平臺化思維提升開發效率

對於如何定義業務領域?林世鵬表示,街口支付其實沒有明確導入領域驅動設計(Domain-Driven Design,DDD),而是汲取DDD方法論的核心概念,明確業務領域,並且讓團隊成員理解,自己做的服務並不只是一個專案的需求而已,而是支撐一個業務領域該提供的功能。

所以,當需求一來,他提到,團隊成員首要釐清的是,這個需求背後的業務目標為何?了解業務目標後,才會有對應的業務流程來達到此目標,才能進一步評估是否可將這流程分解成平臺化的行為、平臺化的功能或平臺化的操作。

林世鵬解釋,比方說,街口支付的3個團隊總共開發了10個功能,當下次有新的需求進來時,就能去檢視該需求所需的功能,有哪些是在先前已開發完成的10個功能之中。如此一來,團隊就不用重複建設,只要鎖定新功能進行開發即可。這樣以平臺化的思維來開發,正是街口支付提升開發效率的關鍵方法。

街口支付串接了多家銀行、商家、第三方合作夥伴,不過,林世鵬表示,如果是同樣的合作產業,業務流程其實大同小異。因此,他認為,針對同一產業串接的多家合作方,「工程師必須要有將業務流程抽象化,並在系統面實現的能力。」

比如說,街口支付與7-Eleven、全家便利商店串接,彼此清算時有一項計算日終檔的流程,過去作法是街口與一家家特店各自進行串接開發的工作,不過,一旦特店數量越來越多時,開發工作負擔也越重。假設,工程師花了10個月串接完10家特店,一遇到內部系統需要修改時,就代表這位工程師得逐一修改這10個流程。林世鵬表示:「較好的作法是將這流程抽象化,讓一套流程中有很多擴展點,這擴展點可以嵌入各個店家,或各個不同業務的各別需求。」

在這過程中,他坦言,如何說服團隊成員突破做專案、需求的既有思維模式,往上一個層級看待自身所負責的工作,其實是一個產品、服務,甚至是平臺,對他來說是一大挑戰。

他的作法是,賦予工程師更多的責任和空間,比如,街口支付的用戶服務,就是交由一位原本較偏向單純承接需求的工程師來負責,透過更多會議參與及和他人討論的過程,讓他能思考用戶服務該做哪些事,以及該如何決策。

靠技術PM角色提升整體開發效率

而為了避免工程師在接收到需求後,便直接開始寫程式,寫完後發現並不符合專案經理(PM)提出的需求,因此造成重工與效率低落的問題。林世鵬坦言:「得扭轉工程師在技術上實踐的慣性思。」他要求團隊成員開發需求之前,必須進行縝密、詳細的需求討論,以達對需求理解的對齊。

他提到,根據多年帶領團隊與做架構的經驗,IT必須要與PM深入溝通,以釐清業務流程的訴求與目標。需要大量討論的原因是,街口支付只有一個60人的IT團隊,不像一些大公司動輒有上百名IT與充足資源。所以,林世鵬強調:「我們每一行程式碼都要敲在刀口上。」原則是能不重工就不重工,寧願多花三天、一個禮拜,進行需求分析與討論,明確業務價值,明確業務領域所在,也不要日後發生需要重構、合併、打掉重練的狀況。

不過,林世鵬不會親自盯整個過程,而是交由各團隊負責人協助進行業務分析,讓他們能具備這樣的能力。後續,透過每周會議回報,他會與團隊負責人討論對於這次需求的理解是否有偏差,或是在業務分析上是否有所缺失。他認為,強化團隊負責人的能力,才有辦法有效率地複製這件事。

此外,在開發流程上,雖然街口支付沒有明確導入敏捷(Agile)或Scrum,但仍汲取了敏捷的重要精神,一是資訊透明,二是快速迭代。林世鵬提到,這兩項關鍵因素,也是造成軟體專案風險的殺手,所以必須抹平。

他提到,街口支付的開發流程一開始,會有專案啟動會議,由PM向所有參與方,說明本次專案的業務價值、目標,以及接下來要做的事情。約莫2周後,PM會將產品需求文檔(Product Requirement Document,PRD)開發出來,並與所有開發、測試的工程師進行多輪PRD檢視,直到PRD凍版,完成功能明確的線框稿(Wireframe),這過程大概花費1到2周。待PRD明確後,才會開始進行技術方案的設計,這部分也得花上1到2周的時間。

林世鵬表示,檢視完產品需求內容,以及技術方案規模的需求,開發時程大概落在一個月左右。雖然,「一個月左右的需求規模化,量並不多,可是,確保了小步迭代,保證了團隊的士氣,也保證了團隊第一次對於這需求的嘗試是否有偏差。」

甚至,在整個開發過程中,林世鵬提到,他們會指派一位技術專案經理(Technical Project Manager,TPM),負責整體專案中包括基礎架構,各類型資源如前端、研發、PM與AM資源的調配,以及整體風險的管理,並明確知道有哪些人參與開發,每個人又得在哪個時間點完成哪項工作。他認為,一般專案都會有業務面及技術面的問題,如果將這兩方面交纏在一起,其實很難釐清職責。甚至,若專案是由PM主導,容易傾向與業務導向,有些技術面的堅持及較好的作法可能會被犧牲。

所以,「由TPM在技術面扮演著統籌的角色,當開發過程中有任何問題時,作為單一處理窗口,進一步提升整體效率。」林世鵬表示,如此一來便能釐清兩邊的職責,PM關注產品的設計與規畫,釐清業務價值與目標;而TPM則負責管理技術的風險、品質、效率等。

現在,街口支付團隊透過小步快跑的迭代方式,加上整體專案資訊透明,只要是內部所有需求與專案,相對應的PM或TPM,甚至是團隊主管都相當清楚。掌握住這兩大關鍵因素,他表示,目前街口支付大約2個月便能完成一個專案。

從林世鵬2020年初加入街口支付,經過1年的改造與努力,雖然他沒有揭露太多具體成效。但,從金管會最新公布的數據顯示,截至今年2月底,街口支付的用戶數比起2019年中翻了將近5倍,突破421萬人,而且還持續成長中,當月代理收付實質交易款項金額更突破21.2億元,穩坐臺灣電子支付龍頭寶座。

或像是,街口支付去年底雙12街口購物節前,開發團隊事先縝密的設計和準備,避免了爆量情況發生。林世鵬回憶,有一項搶券的業務,當時,達到一個峰值是每秒2,600多次搶券請求的處理,且過程中沒有當機或逾時,整體性能表現良好。他提到:「整個系統的設計,不管是快取(Cache)的使用,以及資料庫表的設計,都必須要切合業務需求。」

針對搶券業務可能產生的流量高峰,街口支付是透過以往業務經驗,比如,平時發了一條推播,假設這條推播的用戶點擊率為10%,就能透過推播引入的流量,在公司接下來的大型促銷活動,運用這經驗值來評估流量。

另一項重點是資料庫表的設計,林世鵬表示,搶券系統的瓶頸其實在資料庫,所以,資料庫表的設計在高流量的狀況下,詢問(Query)或語句執行的時間,不能因為流量增加而增加。他提到,街口支付在處理秒殺場景的關鍵手法,是採用非關聯式資料庫Redis與快取,當使用者拿到一個數字,就代表他搶券成功,後續再慢慢對資料庫進行修改即可,如此一來,便不會癱瘓系統。

目前,林世鵬提到,街口支付的系統架構是虛擬機搭配微服務的方式,容器技術正逐步導入中。即便,目前的架構已能做到每秒2,600多次搶券請求的處理,但,為了讓系統更具擴充性,變得更加有效率,這名CTO的下一步目標,是在今年中或年底,能夠將整體系統容器化。

 CTO小檔案 

街口電子支付技術長 林世鵬

學歷:臺灣大學資訊工程學系碩士

經歷:曾服務於資策會、HTC;2016年,赴杭州阿里巴巴,一路參與阿里雲天貓精靈骨幹系統建置,更擔任天貓精靈2B業務線負責人,爾後,轉至阿里巴巴旗下國際電商業務AliExpress、Daraz與淘寶臺灣,負責商業流量平臺化;2020年初回臺,現為街口電子支付技術團隊負責人。

 公司檔案 

街口電子支付

● 成立時間:2015年

● 主要業務:提供電子支付服務

● 資本額:新臺幣6億元

● 員工數:200人

● 地址:臺北市松山區長安東路二段225號C棟8樓

● 網址:www.jkopay.com/

 資訊部門檔案 

● 資訊部門名稱:技術研發部

● 資訊部門主管:林世鵬

● 資訊部門人數: 60人

 公司大事記 

● 2015年10月:街口App正式上線

● 2018年1月:取得電子支付執照

● 2018年2月:電子支付業務正式開業,串連10家主要大型銀行帳戶

● 2020年1月:街口支付在日本啟用,推出跨境支付服務

● 2020年2月:街口券正式上線,推出全新數據行銷功能

● 2020年6月:聯手國泰產險推出用電子支付繳納保險費

● 2020年12月:舉辦首屆街口購物節;同月,街口支付達400萬名用戶


熱門新聞

Advertisement