軟體中的數據分析 (之一)
在之前的篇幅中，曾經提到過 Office 中使用了遙測的技術。這邊就來近一步聊一下 M 社怎樣規劃遙測的資料蒐集以及做後續的分析。基本上，需要做分析的問題可以分成兩大類 (聽起來好像繞口令):
第一類: 我們知道我們不知道的問題
第二類: 我們不知道我們不知道的問題
第一類是比較容易了解，也是一般常面臨解決的。簡單來說，就是我們對問題本身已經有了一個假設，甚至已經有可以運行的模型，只是對其中的一些參數還不知道，蒐集資料的目的就是要來決定這些參數。大家熟知的 AB test 就是很常用的工具: 對已經存在的兩組 (或多組) 介面設計，想知道哪一種比較受歡迎 (設計參數)，就發給兩組使用者群，藉由蒐集使用的頻率，或是直接進行 survey，就可以決定哪一組設計比較好。這個說明當然是簡化再簡化，只是用來讓大家了解問題的性質。
M 社有一個技術叫 Software Quality Metrics (SQM)，是一個資料傳輸協定，就是整個遙測架構的基礎。以 Office 為例，每個 PM 在對功能撰寫 spec 規格的時候，會有一個章節說明針對這個 feature 打算蒐集甚麼資料點 (data points)。PM 可不是愛蒐集甚麼資料就可以蒐集，必須先說明清楚幾件事:
- 蒐集資料點的基本假設或是模型，就是這些資料點使用來決定甚麼參數?
- 資料點的最少欄位，資料蒐集也是花資源的，能用最少的欄位推論出最多的資訊最好。
- 有了這些參數，後續會做甚麼決策?
工程管理團隊必須全盤看過所有的 SQM 設計 proposals，再決定產品中做哪些關鍵的資料蒐集。
舉一個例子吧。最初台灣的團隊曾經設計從手機的瀏覽器看 Office 的文件功能，其中有一個功能就是將文件的外觀用影像的方式推送到瀏覽器中，這樣用戶可以看到所有的文字格式以及分頁方式；對現在的全功能手機瀏覽器顯然可以偶更好的設計，但是早期的手機這卻是必要的折衷。而其中有個參數要決定的是，一個整頁的影像如果一次推送，使用經驗當然不好，尤其是在之前網路速度還不好的情況下，哪server 要分幾個 band 分個這影像，效果才會最好?
一開始我們當然要有基本的運作模型，所以團隊就在實驗室裏針對幾個固定數目的影像切割做測試，先訂下幾個比較接近預期的數值。不過實際的問題是，手機網路的速度會針對不同的使用情況有許多的變化，我們無法模擬出所有的可能性。而另一方面，我們又希望能固定一個切割的數值，免得架構弄得太複雜，不好維護。這就是一個典型可以用資料分析來決定的 case。
不過這裡還有另一個問題，就是在第一版的功能中，我們無法從 client 中直接回傳數值，因為我們必須假設手機瀏覽器沒有 JavaScript 的功能 (那可是 2005 年時代呢)。所以我們只能用推論的方式，就是以使用者點翻頁命令，server 得到通知的時間差，來和切 band 的數值做相關比對。老實說這個假設的確有點粗糙，其中還會有很多的變因，但是這是我們手邊僅有的資料點，只好將就著用經過一連串的資料蒐集，總算把這個值定下來。以後來持續改進的技術架構，能做的蒐集和分析當然能更細緻了。
第二類問題比較棘手，但能發現並且解決的話卻是能提供很高的價值。下次再聊。