《社群耳朵聽聽看》社群交流筆記｜說服其實沒有用？
由於 Data Team 的交付產物有其特殊性：不是軟體本身，而是可用的資料。對於相關合作團隊而言，資料品質 (data quality) 才是最被在意的。但以 Data Engineer 的角度而言，除了資料品質外，包含程式碼品質、伺服器穩定、查詢效能、低延滯等軟體工程師在乎的價值，我們也都同等在乎。
不過，由於 Data Team 的交付產物有其特殊性，對於相關合作團隊而言，資料品質 (data quality) 才是最被在意的。當「我們在意的」和「別人以為我們該在意的」認知出現落差時，就為合作埋下了潛在未爆彈。
來自 Airbnb 的體悟
這次在 dbt 社群活動上有幸聽到來自 Airbnb 的工程師 Robert Chang 分享《Airbnb’s Journey Towards Data Quality》主題，最令人印象的橋段是，他們在 2019 年時面臨了整個資料體系越來越難以維護的困境，包括
- 指標的不一致性：相近指標散落在各處，只差一些篩選條件
- 資料管線的斷點：資料上游出錯時修正有侷限性，下游得自行處理
隨著產品資料量的提升及時間累積下來的各種問題，就像軟體工程常談的技術債一樣，資料工程的技術債堆積久了，就變成資料破產 (data bankrupt)， Data Team 無法確保資料的準確性，問題盤查的速度也越來越緩慢。
這場演講真的非常讓人有共感，於是我也把握了 Q&A 時間提問：
『當 Data Team 希望有更多心力在工程基礎上扎根重構時，如何說服其他人理解我們正在做的事是為長遠計劃而努力，並化解對於過程中成本提升的不諒解？』
Robert 整個回應很精彩，不過這篇就不用逐字稿呈現，而是用我自己的體悟和經驗綜合起來分段講述。但有一句話實在太令人印象深刻，深刻到成為這篇文的標題，而且一定要原汁原味描述給各位讀者聽：
『說服其實沒有用。』
重構是必然的過程
重構真的難以避免，原因是在 Day 0 時我們無法完全確定產品日後的發展，自然也就很難確定要設計地多嚴謹/彈性，過猶不及。一個對於發展初期好上手的程式架構，可能隨著時間漸漸變得不合用或難以維護了。
以 data pipeline 而言，初期或許只需要簡單的 ELT 流程把資料從產品資料庫 (production database) 抓進資料倉儲就行了，開始有了 BI 需求後，各式各樣的 transformation scripts 應運而生。上面提到的資料破產問題在辦公室就演變成這樣的對話：
指標定義混亂
其他人：『finance 和 sales 的 dashboard 上怎麼 revenue 數字不一樣？資料不都來自 data team 嗎？』
Data Engineer：『兩個 team 提供的定義本來就不一樣，數字當然不一樣…』
程式架構混亂
Data Engineer：『pipeline 因為不預期資料 fail 了，我修改好了，有哪些相依部分要重新執行？』
也是 Data Engineer：（打開 VSCode，看到幾百個平攤出來的 transformation scripts）『算了，把出錯的部分改好就好。然後到 Slack 發個訊息通知一下相關 stack-holders 請他們留意並配合自行修改。』
『v1 就是寫來重構成 v2 的。』嗯，此言不虛。
但是，資料工程的重構跟應用程式的重構可不一樣呀，data warehouse 為了新架構所增加的 storage 要花錢，data pipeline 的每個 query 也都是 $$。data 架構的 v1 要重構成 v2 的成本包含人力、儲存費還有查詢費相當可觀，並行期間還要同時維護兩套系統。隨著時間推進，v1 會越來越難用，排解問題的速度也越來越慢，花的心力越來越多，還會壓縮到開發 v2 的量能。
其他人：『Data Team 怎麼都在花錢？開發 v2 對我們有什麼好處嗎？』
聽到這句，資料團隊在提案重構的討論現場直接崩潰，不給我們時間重構，接下來會越來越難維護了。
端出你的牛肉
重構當然有好處，v2 的資料架構讓工程師未來擴充功能或維護時，開發或錯誤修復的速度會加快。各部門取用資料時，定義更清楚一致，資料品質也會提升。
其他人：『重構計畫預計要多久？』
看來資料品質提升對其他人很有感，慢慢消除疑慮，並開始往時程評估的環節進行了！
Data Engineer：『從開始動工到完成驗證及搬遷要一年。』
其他人：『… 那可能不能做了，要再評估看看…』
資料架構重構跟應用程式改版不一樣，不只軟體層要改動，資料還要驗證、搬遷。但一年真的太久了，直接嚇跑大家。
一步一步來
不要太貪心，把一年的工程拆幾個階段 (phase)，一次改動一個部分，分批修改、驗證及搬遷。這種方法的優勢在於，它可以減少大規模改變的風險。透過逐階完成的方式，data team 可以更容易地掌握潛在的問題，並及時進行修復，從而提高整體效率。
成本雖然少不了，每隔一段時間就要其他人對資料架構的效益有感。
如何「談」的順利？
提出明確的改善效益，並制定可行的分階段執行計畫，其實只是說服過程的一環。更重要的是發動者要找對人，事情才能成。
例如工程師發起重構規劃，尋求 PM 站在產品推進的角度認可，或是找有話語權的中高階主管、CTO 從工程職能角度同理。找到本身對資料/資料工程/資料架構具有相應專業經驗或素養的夥伴，能夠理解問題並認同計畫，對計劃的推進相當關鍵且重要。
Next Step
這是我當天的第二個問題：
『Data Team 的產出作為資料使用平台，如何兼容各部門的需求？』
講者的回應很簡要，能夠在 Data Team 的守備範圍（如：data collection/ingestion/transformation）大部分兼容是最好的，我們可以用工程的手法控管，掌握資料歷程 (data lineage) 也確保指標定義的一致性及資料品質。但仍有少部分必須放手，讓取用資料的部門自行處理。掌握 80–20 法則就行了。
結語｜Takeaway
這天在 dbt 的社群活動上和許多資料科學從業者交流地十分暢快！很多經驗真的是需要一些工作歷練才能感同身受。
回到主題「說服其實沒有用？」當然不是說不需要去說服，而是指－應該換位思考，從對方最在意的點切入協調，才能慢慢獲得認同。以下是我的彙整：
- 適時提出終端使用者在意的成果：例如資料品質，不再一個 revenue 各自表述了。錯誤排除效率提升，以後大家自然不會覺得 Data Team 回應問題的速度緩慢了。
- 耐心不躁進，小步小步穩定前進：把大型規劃拆成小階段，每隔一段時間就推出一些成果，持續維持有感程度。
- 找到具有話語權的專業夥伴支持：尋求理解問題本質的夥伴支持，讓專業問題能夠專業解決。
