30 天挑戰的最後一星期，我們走過了這次系列文的最後階段 - 資料運用篇。這階段我們談的不是資料技術、基礎建設或系統設計面向，而是資料需求、資料使用、資料管理以及資料團隊建構這類與「人員」較相關的議題。
資料團隊的服務方向可以分成提供資料本身 (Data as a Product, DaaP) 或提供資料洞察 (Data as a Service, DaaS) 兩種。Day 25 在談論這兩種服務模式的差別時，點出其與企業發展階段的相關之處：初期需要先收集資料並提供出來，中長期才有談論資料運用的進階可能。
隨著企業推出的產品愈發成熟，其所帶來的衍生資料累積量與多元性，會讓集中式資料團隊面臨巨大的考驗。Day 26 針對這個考驗提出了自助工具與標準協議兩種方式，讓業務團隊開始有了自助取用資料的能力，減緩了集中式團隊的被索求感。
Day 24 所提的資料需求金字塔階層，揭示了資料運用的地基是可用性與新鮮度，有可用的且新鮮的資料，才算是初步地滿足了資料需求。而在金字塔的腰帶處「資料品質」是資料供給方與需求方提升互信的關鍵因子。
資料品質搭配資料權責管理及資料標準化能讓部門團隊間針對資料專案的合作更順暢，彼此信賴感更高。這屬於資料治理的對內面向。在 Day 27 還提到資料治理對外面向——對企業形象的影響。
最後，Day 28 談論的資料血緣正是資料治理的一環，也是提升資料品質的手段。垂直血緣串起了商業端與技術端的相互理解，而水平血緣讓開發人員掌握資料系統的複雜資料流，提升維運效率。
雖然資料領域的技術具備高度專業性，但使用者是直接接觸這些產出資料，而不像程式碼到產出軟體的過程那樣間接。「直接感」反映一般非技術人員對資料品質的敏銳程度，甚至比軟體品質來得高。
在談論技術債議題及爭取系統穩定性提升的時間分配時，其他人不一定能買單，可見「直接感」對於資料人而言是相當不利的。需要用直白的語言讓合作夥伴看見資料系統建構的美麗與哀愁，讓彼此的背景知識更近一些。所以，嘗試打開這專業的資料技術黑盒子吧！
iThome鐵人賽
看影片追技術