[英語流利說]管理資料採集需求～在英語流利說，我們這樣管理資料採集需求...

在英語流利說，我們這樣管理資料採集需求
http://mp.weixin.qq.com/s?__biz=MzI0NjIzNDkwOA==&mid=2247483770&idx=1&sn=b083e38a7d089fc635a187728bd58d21&scene=21#wechat_redirect

你們公司是如何管理資料採集（俗稱“埋點”）需求的？ Word？ Google Doc？ Excel？ 是不是遇到如下問題？
需求描述模糊

歷史版本需求過段時間就沒人找得到了

資料質量堪憂，出現錯誤或者遺漏現象

我們知道，處理結構化資料程式最擅長。那麼思考：
如果我們把資料採集需求定義結構化，是不是就可以依靠程式協助管理資料採集需求，甚至自動化驗證資料格式呢？

在英語流利說，我們是這麼幹的：

1. 結構化資料採集需求
   將資料採集需求抽象，發現資料需求包含幾個方面：
   通用資料，user_id
   等用於識別使用者。一般僅僅需要統一定義一次，不需要再在每個採集需求中重複定義。

event_id ， 採集需求唯一名稱，在後續資料分析中會經常用到。跟程式碼中的變數命名一樣，越清晰越好。

採集需求描述，這個最抽象，基本上是告訴開發人員在哪種情況下點選某個按鈕時觸發資料採集。這裡經常是資料採集需求模糊的地方。

事件引數。在事件發生時，事件所關聯的資源的 ID 等。例如：使用者點選了某個商品詳情頁面，事件引數中需要攜帶商品 ID 。

需求定義模糊，重點發生在第3點：採集需求描述。在哪裡哪裡使用者點選了什麼什麼的情況下采集x事件，寫的人費勁，看的人模糊。怎麼破？
截圖！從產品的互動設計中截圖，使用類似 Skitch 之類的工具標記，一目瞭然。

資料採集需求中剩下的部分是不是就可以結構化了？類似這樣：
{ "event_id": "test_event", "curent_app_version": "當期需求定義時的產品版本號", "params": [ { "name": "product_id", "desc": "商品 ID" }, { "name": "type_id", "desc": "型別ID" ], "desc": "事件的詳細描述"}

然後，我們資料採集需求變成了一個JSON檔案和一個圖片，如何管理？Git啊。那PM怎麼會用Git？ 抽象一層，做一個工具隱藏Git的複雜性不就好了？

2. 通過 Git 管理需求文件,提供視覺化介面隱藏 Git 複雜性
   JSON 檔案和圖片都放到 Git 中

一個 app 版本一個 branch, 新版本需求直接 clone 上一個 branch 然後 push 到最新版本的 remote branch 即可
git checkout 1.0 -b 1.1 && git push -u origin 1.1 && echo "新版本1.1 需求分支初始化完成"

新版本自然繼承上一個版本的所有資料採集需求

多個版本併發開發時，需求也是多個版本，最後通過Git merge在版本釋出後將需求合併

通過 WEB 介面，隱藏 Git 複雜性

PM 僅僅感覺是在一個 Web 介面中定義資料採集需求

每個需求定義做格式校驗，成功後直接 commit 到 Git 中

通過 commit log 追溯需求定義修改記錄

提供唯一 URL， PM 跟開發人員討論需求細節，直接帖 URL， 避免歧義

通過上述措施，開發人員可以通過版本號篩選到當前版本的所有資料採集需求，測試人可以獲得新版本所有資料採集需求，方便做迴歸驗證。

上圖為某需求修改日誌截圖，這位寫6666666
commit log 的同學，咳咳，不專業啊。
做到這裡就結束了？顯然沒有。

3. 資料收集系統根據需求自動做格式驗證
   為何需求要結構化？因為程式可以幫忙做資料驗證。
   通過識別公司測試裝置，在資料採集伺服器上通過白名單方式將測試裝置傳送的資料統一傳送到資料驗證工具系統中，測試工程師可以實時而且快速的檢視測試裝置傳送的資料，資料驗證工具通過 API 從資料需求工具中獲取當前客戶端版本的資料需求定義，識別以下異常：
   資料格式錯誤

資料引數不匹配

未知資料，指過期或者程式設計師小哥的 typo 導致的資料無法識別，或者已經刪除的資料採集需求

通過資料驗證工具，減少資料驗證的工作。每條測試資料都有唯一 URL，測試工程師提交 Bug 時附帶資料 URL, 方便開發工程師還原現場，定位 Bug。
總結
折騰到最後，系統結構變成了這個樣子，涵蓋了需求定義、資料收集、資料驗證。

最後，摘抄一句特別實用的話：
If you're not thinking about how to keep your data clean from the very beginning, you're fucked. I guarantee it.

-- EOF --