資料分析的核心挑戰
概念型定義與操作型定義的重要性
最近我有讀到一個有趣的文章，它是 AI 應用於軟體開發相關的報告與 redmonk 提出的詮釋。
首先是 DORA 2024 的報告，它的結果充滿了矛盾：
75% 的受訪者表示使用人工智慧提高了工作效率。
如果人工智慧採用率增加 25%，預計用於「有價值工作」的時間將減少 2.6%
如果人工智慧採用率增加 25%，預計「交付吞吐量」將減少 1.5%
如果人工智慧採用率增加 25%，預計「交付穩定性」將下降 7.2%
仔細來看，結果 1 與結果 2, 3, 4 像是矛盾又像是不矛盾。像是矛盾的點在於，人工智慧到底是提高了產出還是降低了產出？不像矛盾的點在於：結果 1 是量測個體、結果 2, 3, 4 則是量測團隊。
接下來是解釋的部分，Redmonk 提出的解釋是引用 theory of constraints ，它說：「除了做在瓶頸之外的任何改進都只是幻想。」這個解釋算是合理地解釋了 1, 2, 3, 4 的結果：很有可能，對於個體來講，感覺到 『AI 帶來的改善』，但是實質上，因為該改善並非發生在系統的瓶頸 (系統是指 software development life cycle) ，就系統來講，不僅沒有改善，甚至還效能下降。
啟發
我從該文章得到的啟發有兩個。一個是直接與 AI 應用相關的，另一個是資料分析方法論相關的。
儘管現在主流媒體的聲音一面倒地主張 AI 帶來的生產力提昇，這些媒體報導多數是受訪者的經驗之談，也因此，過度樂觀的效能改進主張很有可能經不起研究的檢驗。
換言之，儘管我個人也常常用 LLM 來翻譯、學英文、寫作時潤飾文字，甚至也主動推薦親戚朋友多多應用 AI ，當別人問我，善用 AI 可以改進多少 % 的生產力，多數的時候，我還是會評估一個很保守的數字：5~10% 這類的。
第二個重要的啟發，則是重新思考，什麼是資料分析的核心挑戰？
如果有人問我，資料分析是什麼？我可能會簡單地回答：
對問題領域 (domain) 有一定的認識。
透過結構化的思考與分析方式，先將想要了解的事物或改善的目標，設計定義、模型與量測方式。
透過量測，來進一步地改善模型與定義，進而得到可用的洞察或是改進 (improvement)。
拿我上述的說法去對照 DORA 的報告，方法論其實沒有明顯的暇疪。那為什麼還是做出看似矛盾的結果呢？
我的答案是：
資料分析的核心挑戰，不只是資料的處理與建模，而是針對一個待解決的問題或待理解的現象，建立清楚的概念性定義與可操作定義，並在具體情境中反覆驗證與修正。
也就是說，當我們想分析「AI 是否提高了開發效率」時，首先就要問：
「開發效率」的概念性定義是什麼？這個詞在團隊層面與個人層面，意義是否相同？
接著還要問：「我們要如何觀察它？」——這就進入可操作定義的設計，也就是：我們打算用什麼指標來量測效率的變化？
DORA 的報告中，其實正是採用了不同層次的可操作定義——受訪者主觀的感受作為個人層次的指標，交付吞吐量與穩定性等指標則代表團隊層次的觀察。而這些定義之間沒有明確對應時，就可能導致結果看似矛盾，實則是定義的差異所致。
總結
資料分析的真正難處，不在於套用哪一套分析技術、是否使用了 AI、或模型夠不夠複雜，而在於我們是否對所處的問題情境建立了適當的概念架構與量測機制。也就是說，概念型定義與可操作定義的建構能力，才是資料分析工作的基礎建設。
因此，在面對日益龐雜且資料還有日新月異的分析方法與工具，我們更需要培養一種分析素養：不是立刻著手建模，而是先反覆釐清「我們要問的問題是什麼？」「我們的定義站得住腳嗎？」
這樣的分析態度，也許不能立刻帶來驚人的效率提升，但卻是避免誤解、積累洞察、真正讓資料發揮價值的必要條件。