靠60人IT團隊衝刺業務擴張，電子支付龍頭揭平臺化秘訣

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萬名用戶