[討論] 2周高速開發App的秘訣,CMoney從技術與

軟工

37207

2周高速開發App的秘訣,CMoney從技術與組織同時翻轉開發流程

在投資理財圈,有一家軟體科技公司2周就能推出一款新App,短短幾年推出超過80款App
,服務超過730萬會員,如何辦到?不只將核心數據引擎模組化和API化,以敏捷思維翻轉
瀑布式開發流程,更展開組織變革,改用矩陣組織和OKR目標管理,奠下快速開發的基礎

文/翁芊儒 | 2022-03-22發表

你能想像,只要2周,就能上線一支App?在投資理財圈,有一家軟體科技公司,透過超快
的開發流程,短短幾年內就推出了超過80支App,服務超過730萬會員,從每周活躍人數破
百萬的投資社群平臺、或是百萬人次下載的股市工具,甚至是學校愛用的操盤模擬軟體,
都出自他們之手,可說是臺灣最大規模的投資工具群。

雖然這些App大多是財經數據分析服務,但要在短時間內快速上線,又能大受歡迎,不是
一件容易的事。尤其十年前,這家軟體商服務對象是企業,還是透過傳統瀑布式開發流程
,來更版軟體服務,很難想像現在只要2周,就能推出新產品,不只技術或人力,更重要
的是根本開發思維的改變。

這家快20歲的財經軟體公司,就是CMoney,早年在企業端市場上,推出一款驗證投資策略
的軟體工具,在法人市場的採用率超過了9成,近年來瞄準一般大眾推出的多款投資理財
工具,更有超過400萬股民用過。

「我們很早就知道,投資不能靠直覺,每一種投資策略,都需要靠數據佐證。」CMoney數
據應用部總監陳建文指出,根據主觀的想法來投資,或是僅參考小樣本資訊來擬定投資策
略,在缺乏足量數據的支持下,容易面對投資失利的風險。

影響股票的變因過多,很難預測一支股票的未來走勢,但許多法人改採組合投資策略,來
分散單一支股票漲跌的風險,進一步借重大量歷史數據分析,更能驗證不同組合策略的有
效性。

然而,靠手動撈取數據來分析的速度太慢,跟不上快速波動的股市,等到算出結果,市場
局勢又改變了。「能不能把運算過程變成一個工具,來快速告訴用戶,該策略過去某一段
時間的表現如何?」陳建文點出開發驗證工具的初衷。
如何加速投資策略驗證?把驗證邏輯變成一套軟體工具

這套CMoney開發的驗證工具,將股市數據分析邏輯模組化,提供彈性設定分析邏輯、自訂
計算公式與篩選邏輯的自助式介面設定。同時,也彙整第一線需求,提供常用投資策略的
功能模組,直接將數據和演算邏輯結合,來提供特定投資策略的快速分析功能,後續更提
供像是視覺化BI報表的功能,讓股市分析工具變得簡單好用,連不諳技術的分析人員,也
能透過介面設定的方式直觀點擊操作。

這套軟體推出後的幾年, 陸續取得了超過400家法人機構的採用,搶下了企業端法人市場
的9成市占。
分別從IT與開發面改造基礎架構,轉型邁向2C市場

不過,2010年前後,臺灣股票數據公開,加上投資理財風氣逐漸興起,CMoney開始思考,
如何將服務企業的模組化軟體設計與系統架構,轉而符合一般民眾的投資需求。

「投資用戶投資方法百百種,我們當然心很大,希望每一種都要滿足,這個策略體現在我
們的產品上。」CMoney行銷暨內容專案總監李湘婷指出,不像企業端需求是All-in-one功
能的軟體,對一般民眾來說,每個人的投資方法都不同,一款App若提供過多用戶不需要
的資訊,就不易獲得青睞。因此,CMoney開發團隊開始思考如何企業級軟體功能拆解、細
化,來發展只有特定功能的投資型App。

除了軟體功能拆解是一大挑戰,陳建文指出:「從2B到2C,是很大的轉型,從服務對象、
用戶需求、程式設計與數據拆解,都不一樣。」過去服務法人,只有400多家,但去年臺
股累積開戶數逼近1,200萬,潛在的服務對象更多了。

要轉而服務如此龐大的用戶群,背後面臨的技術挑戰極其不易,首當其衝的是,原先部署
在法人機構內的軟體與伺服器,服務範圍與人數有限,要支援一般用戶每天動輒上百萬人
的使用,原有運算資源完全不夠。因此,CMoney重新設計了本地端的系統架構,建立了自
己的私有雲,以彈性開關的虛擬機,來因應暴增的用戶連線需求。後期為了穩定性和可擴
充性,更將機房遷移至標準IDC機房及可擴充的Google雲端機房來提高可靠性。

除了IT架構大轉變,「我們最早就有一個概念,開發產品時,總不能每開發一支App、就
做一個底層,這樣永遠沒完沒了,」陳建文指出,軟體開發的特性,要避免成本大幅提升
的前提下,能夠支援大量用戶,才能有效發揮影響力,所以CMoney的目標,「用較低的成
本、更有效率的方法,達成開發目的。」

為此,CMoney從2010年開始,延續開發企業端軟體工具的作法,整合不同的數據模組與運
算邏輯,打造了一個叢集式的數據分析引擎,並以API提供數據存取服務。

「引擎提供最底層的資料邏輯,上面可以建置不同的應用。」陳建文指出,內部開發財經
相關軟體時,不必重複開發底層的資料與運算邏輯,只要透過API呼叫模組,即可執行運
算,這是快速開發App的關鍵基礎架構。

甚至,負責不同產品的開發團隊,還能大量設定各自獨立的API來串接資料,依據數據組
合需求重開一隻API,比如殖利率和3年平均殖利率可以分別建立不同的API,還能拆解API
來加速運算。陳建文形容,「CMoney的API,多到數不清!」透過高度彈性的API設計,讓
不同產品的開發不必互相等候,API維運也互不影響,是軟體開發效率再提升的另一關鍵

簡化API設定讓App開發再加速

有了API化的數據引擎,CMoney更運用了Low-code精神,來簡化API的設定介面。比如一支
產品某一頁若需要串接三項資料,專案負責人可以直接在數據引擎中設定能提供這些資料
的API,取得API編號後提供給工程師,呼叫這些編號的API,就能在App頁面中提供這3項
資料內容。若遇到需要特殊數據運算的處理,無法靠介面設定完成,也可搭配簡單的程式
碼,來完成API的設置。

不只簡化後端API作業來縮短時程,CMoney在前端介面設計上,也設計了常用圖表的模板
工具,比如K線模板、走勢圖模板、長條圖模板等,開發團隊可自行選用不同模板,再串
接所需的API,就能完成一款App的核心功能設定。

「要讓越多人參與開發,不是要所有人來寫程式,而是打造Low-code工具,讓行銷、業務
、PM都能夠參與。」陳建文點出,讓非工程師人員參與開發,降低工程師的工作負擔,也
是加速軟體開發的作法。

陳建文指出,透過快速打造出多種App服務,再搭配用戶分群的商業模式,精準找出目標
受眾,才能領先對手搶進市場。
靠技術力解決業務難題,關鍵是引擎內運算邏輯與資料傳輸速度

「API數量不是瓶頸,成本也相對低,反而是引擎運算效能與承載,需要維持穩定。」陳
建文指出,數據分析引擎上線至今,為了滿足更複雜的用戶需求與爆增的流量,歷經了數
次改版。

「數據引擎要容納各式各樣的數據,讓用戶能查得快、又不能錯,速度更要穩定,背後的
細節並不容易。」陳建文說。

技術細節上有多複雜?陳建文指出,為了提供盤中即時選股的參考資訊,得先搜集臺股上
市櫃股票的所有訊號,從證交所取得每一筆即時撮合資訊,再搭配自行累積的盤後資料來
提供。而且,為了提供用戶更即時的資訊,力求5秒更新一次資訊,後端資料運算幾乎得
在1秒內完成。主要技術挑戰是,得確保對外提供的盤中即時訊息或數據分析結果,能對
應到即時股價,對運算準度、運算速度到送達速度都是挑戰。

不僅如此,由於每個會員關注的個股不同,為了支援上千檔個股的龐大運算查詢需求,
CMoney也自行開發資料傳輸技術,來優化引擎內部模組間的資料拋送,也取得資料封包傳
輸協定的專利設計,能在有限頻寬下穩定傳輸。同樣的技術,也用於後端系統與用戶App
之間的傳輸。

為了提升用戶體驗,CMoney也設計了斷線後的資料補回機制,讓用戶端App遇到網路斷線
時能繼續使用,等到網路恢復時後自動回補盤中即時資訊,「用戶不希望回補時,手機畫
面一直轉圈圈,我們運用資料壓縮方法來加快傳輸速度。」陳建文說。
靠每日6,000萬筆用戶數據處理的挑戰,奠下AI開發基礎

隨著開發了更多用戶端的投資工具,CMoney也面臨更多資料儲存與運算需求,這些與使用
者有關的記錄,包含用戶討論區貼文與留言,或像是新增頁籤、匯入庫存資料等行為,也
包括了App推播訊息等,每日資料總量達到6,000萬筆的規模。對此,團隊也逐步改變了資
料庫的架構,除了原有SQL類資料庫之外,又加入了Hadoop、MongoDB、ElasticSearch等
資料計算與查詢技術,來因應不同量級的資料處理需求。

比如說,CMoney的App每日自動推送的訊息量超過3,000萬則,為了分析這些訊息的推播效
果,並能依據用戶對訊息的反應,來調整推送頻率,團隊得將累積數月的訊息推播與用戶
點擊行為資料用於數據分析,由於這個數據量體過大,團隊因而將資料從SQL搬到大數據
運算平臺Hadoop,來進一步執行分析運算。

又比如官方站上股市爆料同學會討論區,每周活躍人次破百萬,則改用NoSQL資料庫
MongoDB,來提升發文、點讚、留言等互動性內容的處理,提高回應速度。而系統事件記
錄,則是用大數據搜尋引擎ElasticSearch來儲存,同時也會拋一份資料到Hadoop,來執
行Log的分析運算。

奠定資料分析的基礎架構後,CMoney也試圖透過更多用戶數據分析,來提供個人化功能。
比如在App中增加用戶行為追蹤的埋點,以便能搜集更多用戶跨平臺累積的行為資料,包
括點擊的文章、影音與常看股票資訊,並將資料彙整到數據平臺進行分析,就能推測用戶
的投資行為與偏好,來提供個人化推薦與訊息推播。

不只如此,CMoney今年更計畫要大力發展AI,將App做到「千人千面」,由AI決定每一支
App的長相,讓每一位用戶打開的App介面資訊,都不一樣。「這對AI來講,就是一個非常
適用的場景。」陳建文指出,現有App的介面資訊固定,只提供少數客製化功能,如用戶
自訂選股,未來,將以AI自動推薦符合個人選股喜好的內容。另一項目標,則計畫在股市
爆料同學會中增加文章自動推薦。
2周上線App第二關鍵,靠矩陣組織徹底翻轉開發流程

CMoney凡事求快的軟體開發哲學,也反映在組織管理上。「2019年初,我們發現,雖然技
術持續演進,但是產品更新的速度還是太慢了。」CMoney人資長簡麗晴點出,隨著組織不
斷成長,溝通成本不斷提升,產品迭代的速度也慢了下來,甚至出現跟不上市場變化的現
象。為此,高層決定汰換瀑布式開發方法,轉而導入新創常見的敏捷式專案開發流程。

萌生這個想法後,2019年初,先挑出一支20人隊伍來驗證敏捷開發的可行性,團隊包含了
工程師、PM、UI/UX、行銷等角色,在緊密的協作之下,不同角色間的溝通更順暢,不用
像過去得跨部門呈報再層層分派任務,產品開發可達每兩周迭代一次的速度。執行半年之
後,簡麗晴感悟:「這才是我們要的節奏跟感覺。」

因此,CMoney在2019年底,決定將按部門別的組織編制,改為敏捷思維的專案型編制,但
這時的公司規模成長到上百人,「要怎麼翻?」成了下一個問題。

簡麗晴指出,儘管部門型編制的分工模式,影響了產品開發速度,但部門仍有其不可取代
的功能,因此,組織轉變的理想做法,是採取「矩陣組織」,以原組織的部門為基礎,額
外根據不同的產品成立專案小組,並將各部門中可以獨當一面的成員,分散到不同的小組
中,形成緊密分工的團隊來加速產品開發。

在這項作法中,CMoney要求第一線的專案小組,落實敏捷開發與兩個披薩原則,維持利於
溝通的扁平組織,同時賦予團隊領導人足夠權限,能主導產品的發展與決策,再直接向執
行長匯報,來加速產品開發迭代;原先負責彙整需求再向下分派任務的部門單位,則退居
二線,扮演類似後勤的角色,主要負責培育新人、開發共用模組、進行整合與橫向溝通等
任務,在後端負責打穩地基,來支援前線的實戰需求。

然而,這次組織編制大翻轉,並非一聲令下就全部到位,簡麗晴點出箇中挑戰,前期投入
成本中,溝通成本尤其巨大,「我以為統一講一次,大家就懂了,」但事實不然,員工平
時專注忙於工作,通常要等到閒暇時,才會來了解制度的改變,「得一而再、再而三的講
。」

改為矩陣組織架構後,另一個轉變是,公司內的每一位員工,不再隱身於部門之下,分派
到專案後,就得扛起一支支產品功能的成敗責任,CMoney也同時導入了OKR制度,讓團隊
與個人學習設定目標、定期檢視。

李湘婷指出,在成立十多個專案團隊後,加上原有部門主管,一口氣增加了三十多位直接
向執行長報告的小主管,「這是培養新進主管們領導能力的機會。」而對於進入專案團隊
的員工來說,也不再只是處理來自所屬部門交付的任務,得更積極了解主責的產品功能,
透過各自的專業技能,主動貢獻想法。

「2021年底時,這套制度逐漸完整,我們開發App的速度也大幅提升。」以App實際開發時
間為例,2015年時,以部門主導的瀑布式開發,大約需花上3個月才能實作出一款App的初
版,但落實矩陣組織之後,一個6人專案團隊只花了2周時間,就能上線一款App。除了技
術力之外,組織變革也是CMoney提升開發效率的另一關鍵。「雖然歷經陣痛,但是很值得
。」李湘婷強調。文⊙翁芊儒

https://www.ithome.com.tw/people/150043

好厲害,二週就可以做出一個APP O_O!


--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 220.132.136.216 (臺灣) ※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1648091472.A.FD4.html
acgotaku1樓公司流量夠 可惜低薪 03/24 11:31
now992樓高速開發App,我笑了 03/24 11:52
s0015820003樓我看彼得潘也是一分鐘的時間拉出一個app 03/24 12:08
s0015820004樓*一首歌的時間 03/24 12:08
DrTech5樓難怪股市爆料同學會bug與一星評價那麼多… 03/24 12:19
kissmickey6樓所以平均年薪有百萬嗎 03/24 12:19
DrTech7樓存股價值K線,股市籌碼K線,…下載了才發現,內容都一樣。 03/24 12:21
DrTech8樓浪費大家時間。 03/24 12:21
DrTech9樓之前下載這些App都有bug後來還無法登入,直接刪掉了。 03/24 12:25
t1996080410樓高速產出垃圾。嗯 真棒 03/24 13:04
whitecut11樓大內宣廣告文大可不必 有錢打廣告不如加薪 03/24 13:04
Gaogaigar12樓看到是同樣的內容 狂做不同的app就end了 這是部門 03/24 13:09
Gaogaigar13樓主管在騙kpi吧 03/24 13:09
Gaogaigar14樓 03/24 13:09
bill199215樓面試流程很麻煩 還要花時間寫作業 後來就放棄了 03/24 13:31
lovdkkkk16樓求面試時間跟作業與同時期上架 app 之關聯性的分析 XD 03/24 13:44
lovdkkkk17樓不過內部資料 api 都有,app 只是串一兩個功能上架的話 03/24 13:45
jj032118樓寫過面試作業,提交後只回不是他們想要的,然後就感謝了 03/24 13:46
lovdkkkk19樓不是從設計到前後端由零開始的話,兩週也蠻正常的? 03/24 13:46
alihue20樓兩週一個APP,這樣確定還有工程師敢去嗎XD 03/24 13:56
ckp413102521樓自有產品兩週一個就是沒有要深耕維護的意思 03/24 14:22
ckp413102522樓又不是像91/shopline做代工代管 03/24 14:22
vencil23樓bug一堆,不是很相信裡面的開發品質 03/24 14:33
darkMood24樓app每小時生1個也沒有問題啊,重點是功能是啥啊...... 03/24 14:34
bheegrl25樓"讓非工程師人員參與開發"通常只會增加工程師的負擔 03/24 14:57
ctrlbreak26樓封包資料傳輸也能有專利 XD 03/24 16:12
starburs27樓時間根本不是重點 產一個只有hello world 的app也只要一 03/24 16:54
starburs28樓分鐘 03/24 16:54
wsa2829樓沒有擴編人力的話 就是兜出來一隻app後 接著就放生的意思 03/24 16:55
leolarrel30樓在這罵沒用,CMoney看不到,繼續朝一周產出一個app邁進.. 03/24 18:38