Day 2 與 Day 3 我們談到了高風險領域真正需要被解決的是支持決策,而不是效率,以及高風險場域的共同挑戰。我想再接下來的 day 8-12 天,做更多運動數據領域實戰經驗的分享。
在接下這個專案的時候,我心裡其實已經有一套現成的劇本。
「國家級運動數據平台」——聽起來規模很大,但對一個做過不少資料產品的人來說,這其實是一個熟悉的題目。收集更多資料、整合不同來源、建立 Dashboard、讓使用者更快速掌握資訊。這幾乎是我做任何資料平台的預設路徑,也是業界最常見的產品邏輯:把原本分散在各處的資訊集中起來,透過視覺化降低使用者取得資訊的成本。
我以為這次也一樣。
專案初期,我花了不少時間研究需求文件、訪談利害關係人、盤點現有的資料來源。表面上看起來,這是一個資料工程問題:感測器數據怎麼整合、不同系統怎麼串接、報表怎麼呈現。
我甚至已經開始在腦中畫架構圖了。
但真正讓我停下來的,是幾場和教練、運動科學人員的訪談。
真正讓劇本失效的,是一連串我原本完全沒有預料到的細節,陸續在好幾場訪談裡冒出來。
第一個徵兆,出現在需求訪談的階段。我拿著寫好的需求書,逐條跟教練與運科人員確認「希望系統呈現哪些圖表」,但對方常常看著那些圖表選項,一時說不出具體要什麼。後來我才懂,這跟專不專業無關——他們的判斷邏輯,靠的本來就是很多沒被寫進規格書的東西,光看一張圖表根本回答不了。一份需求書,其實裝不下他們真正在意的問題。
接著我才慢慢拼湊出,這些「裝不下」的東西,具體是什麼:
知識只存在耳提面命之間。
很多關鍵判斷,是教練帶學弟妹、老將帶新人時,一句一句口頭交代下來的。一旦教練離職或轉隊,這些經驗不一定有人接手,系統裡卻完全看不出這個斷層。
現場的資料,不一定進得了系統。
到訊號不好的場地比賽或移地訓練時,裝置斷線是常態,資料傳不上去,最後只能退回紙本紀錄——而這些紙本,之後不一定會被回補進系統。
情報是有敵意的資產。
對手風格、戰術部署這類資訊,本身就有被競爭對手覬覦、甚至被有心人士取得的風險,這讓「資料要不要集中存放、誰能看到」變成一個必須認真對待的問題,而不只是權限設定的技術細節。
選手離隊、歸隊,資料卻對不上。
理論上選手離開單位後,系統就不該再累積他的新資料;但當他之後回歸,才發現當初的舊紀錄早就被刪除,因為系統從一開始就沒有做 soft delete 的設計,過往的歷程就這樣憑空消失。
還有運動倫理與個資保護的界線。
選手的生理、心理甚至傷病資料,牽涉到個人資料保護法與運動倫理規範,這已經超出「能不能存」的技術範疇,得回頭問「該不該存」這一層的價值判斷。
這些事情,沒有一件會出現在一般資料平台的規格書裡。但它們每一件,都比我原本準備的圖表清單,更早決定了這個系統做不做得起來。
把這些片段拼在一起之後,我重新回頭看自己畫的架構圖,發現一件很尷尬的事:
我設計的每一個模組,都是為了「呈現資料」,卻沒有一個模組,是為了「這份資料進得來、留得住、找得到、信得過」而存在的。
我原本的劇本裡,資料是一個預設條件——好像只要系統做出來,資料自然就會源源不絕地流進來,剩下的只是怎麼呈現的問題。
但現場告訴我的事實是:資料能不能完整地被留下來,本身就不是一件理所當然的事。它會因為訊號不好而斷在半路,會因為沒有 soft delete 而在選手歸隊時憑空消失,也會因為從來沒有被設計成「該被記錄的東西」,而只留在某個教練的記憶裡,隨著他離職一起離開。
這是我在這個專案裡學到的第一堂課,也是最基礎的一堂課:
一個資料平台再會做視覺化,也救不回一筆從一開始就沒被留住的資料。
決策支持真正的起點,得先問資料在不在、完不完整、信不信得過——好不好懂,是後面才輪得到的問題。
這件事在系統剛上線的當下,其實感覺不太出差別。教練還在,記憶還在,紙本紀錄也還找得到人問,日子照樣過得下去。但真正的代價,要到很多年後才會顯現——等到有一天,這個場域也想借助 AI 來輔助訓練與決策判斷時,才會發現資料庫裡其實一片空白:
沒有被留下來的東西,AI 沒有機會學到;就算留下來了,但沒人整理、沒人看得懂,AI 一樣讀不出裡面的意義。
換句話說,沒有資料、或者資料留了但沒人能理解,最後都會變成同一件事——AI 根本沒有辦法從這個場域裡,建立起屬於它的知識庫。
這個認知上的轉折,其實重新定義了我對這個專案的理解。
它不再只是一個「把資料集中起來」的工程任務,而更像是一堂我自己也還在上的決策課:我必須先搞懂教練、運科人員、管理者每天實際上是怎麼記得、怎麼遺漏、怎麼保護、也怎麼爭奪這些資料的,才有可能設計出一個資料真正「留得住」的系統。而這堂課的第一個作業,就是誠實地承認——我原本以為的問題,其實問錯了方向。
但這也帶出一個更棘手的追問:就算我真的把這些散落、易碎、容易消失的資料都留住了——是不是就代表教練、運科人員看得懂它們了?
這個問題,我會留到下一篇繼續拆解。