30 天的挑戰來到了尾聲，回想這次系列文的副標題『Data Engineer 與合作夥伴如何譜出協奏曲』，心裡冒出兩個疑問：
最後一天就從提供軟體即服務 (Software as a Service, SaaS) 的公司發展脈絡，來談談小型到中型公司軟體團隊組織變化及相關職務的特化衍生，也作為我職涯體驗的梳理。
身處 2024 的現代人，應該對於「一站式提供 XX 服務」這類的行銷號召不陌生。在資訊高度發展的時代，每個人的注意力被高度地瓜分。在一天只有 24 小時的限制之下，適度地利用這種一站式服務，幫助我們解決生活所需是相對划算的。假設我想要開間服飾店並經營網路通路，以前我可能要找網站工程師來架設品牌網站，現在則可以選擇開店平台的服務模組 (如我現職公司 SHOPLINE) 來滿足需求。
從 SaaS 產品的角度切入，可以先由全端工程師 (Full Stack Engineer) 來打造網站服務，尋求業務發展空間。
投入市場後，愈來愈多用戶喜歡並訂閱這個服務。全端工程師開始無法負荷，於是有了前後端分離的概念，後端工程師更多心力放在伺服器 (server) 與資料庫上。
隨著用戶的數量累積，人流帶來金流也帶來資料，企業有了資料就會開始想要運用多樣化的巨量資料探索更多契機。而 OLTP 資料庫不再能夠負荷運用需求，於是有了從特別關注資料本身的後端工程師，也就是資料工程師。
圖／Data Analyst, Data Engineer 與 Back Engineer 的職能文氏圖。簡書廷製。
雖然後端工程師和資料工程師都需要建構資料庫，但資料工程師針對分析與加值運用需求特別打造了 OLAP。至此，算是兩個職能的關鍵分化點。
在 Day 09 的資料庫設計總回顧裡，我們從正規化與反正規化的取捨，到 OLTP 與 OLAP 的差異，再到資料倉儲的三層架構與不同資料模型結構的選擇，一一講述了資料工程師與後端工程師的思維差異。
具備資料思維，並搭配上 Day 16 的軟體工程以及 Day 23 的基礎建設技術，讓資料從組織內部 (in-house) 及第三方 (third-party) 開始定時甚至即時地流入資料系統裡。這樣的衍生資料系統讓資料分析師或是機器學習工程師開始能夠探索業務發展的更多可能。
當然，有的團隊可能先招聘了資料分析師，希望建構 Dashboard 或是指標體系 (metrics map)，作為共同語言以幫助團隊達成共識，但如 Day 24 所提，只要是資料團隊的開拓者，終究無法迴避資料工程。
隨著市場的競爭，除了穩固好既有業務外，產品前進的腳步也不能停歇。例如從資料系統創造額外使用契機，提供更多便利的服務模組，讓用戶願意多付出使用費，讓一站式服務的影響力更全面。
這階段的重點是從衍生資料系統尋求衍生價值，讓用戶在平台的足跡更密集，進而創造更多衍生價值的機會。
上述五個階段的進展是以 SaaS 產品為案例，不代表所有軟體應用產品的發展脈絡。有時資料系統不一定源自 in-house 資料，可能是直接來自第三方接口，端看公司尋求的市場突破口為何。
先求有資料，再求好資料，最後用上資料
這句話不論在談論團隊建構或是資料本身，都是一針見血地存在。
只要團隊大方向是往『資料衍生價值，價值吸引用戶，用戶創造資料』的循環去建構，巨量資料對企業的持續挑戰就會存在。
雖然職能間的界限往往是模糊的，但對開發團隊而言，在巨量資料的挑戰下仍維持協作順利源自於不同職能間的傾聽與諒解，最大的原則是在部門間的溝通上『不把需求當索求』。舉例而言，例如資料團隊和上游微服務團隊協商，引入 Schema 變更的檢驗，雖然新功能的開發可能因此多了一些步驟，但能夠確保資料流的前後相容性。或是從確立指標體系開始，逐步收斂分歧的資料定義，不但提升資料品質，也減少對資料一致性的不信任感。
隨著企業規模成長，巨量資料只會越來越巨，衍生資料系統的穩定性需要更多時間與心力來建構，且有賴上下游團隊的共同配合。因此，系列文的最後一篇就定名為『未完的挑戰』。
歡迎您來到我的小天地和我一起探索這些生命片段！
iThome鐵人賽
看影片追技術