在英語流利說，我們這樣管理數(shù)據(jù)采集需求
http://mp.weixin.qq.com/s?__biz=MzI0NjIzNDkwOA==&mid=2247483770&idx=1&sn=b083e38a7d089fc635a187728bd58d21&scene=21#wechat_redirect
你們公司是如何管理數(shù)據(jù)采集（俗稱“埋點”）需求的镶殷？ Word禾酱？ Google Doc？ Excel绘趋？ 是不是遇到如下問題颤陶？
需求描述模糊
歷史版本需求過段時間就沒人找得到了
數(shù)據(jù)質量堪憂，出現(xiàn)錯誤或者遺漏現(xiàn)象
我們知道陷遮，處理結構化數(shù)據(jù)程序最擅長滓走。那么思考：
如果我們把數(shù)據(jù)采集需求定義結構化，是不是就可以依靠程序協(xié)助管理數(shù)據(jù)采集需求帽馋，甚至自動化驗證數(shù)據(jù)格式呢搅方？
在英語流利說，我們是這么干的：
- 結構化數(shù)據(jù)采集需求
將數(shù)據(jù)采集需求抽象绽族，發(fā)現(xiàn)數(shù)據(jù)需求包含幾個方面：
通用數(shù)據(jù)姨涡，user_id
等用于識別用戶。一般僅僅需要統(tǒng)一定義一次吧慢，不需要再在每個采集需求中重復定義涛漂。
event_id ， 采集需求唯一名稱，在后續(xù)數(shù)據(jù)分析中會經(jīng)常用到匈仗。跟代碼中的變量命名一樣瓢剿，越清晰越好。
采集需求描述悠轩，這個最抽象间狂，基本上是告訴開發(fā)人員在哪種情況下點擊某個按鈕時觸發(fā)數(shù)據(jù)采集。這里經(jīng)常是數(shù)據(jù)采集需求模糊的地方哗蜈。
事件參數(shù)前标。在事件發(fā)生時坠韩，事件所關聯(lián)的資源的 ID 等距潘。例如：用戶點擊了某個商品詳情頁面，事件參數(shù)中需要攜帶商品 ID 只搁。
需求定義模糊音比，重點發(fā)生在第3點：采集需求描述。在哪里哪里用戶點擊了什么什么的情況下采集x事件氢惋，寫的人費勁洞翩，看的人模糊。怎么破焰望？
截圖骚亿！從產(chǎn)品的交互設計中截圖，使用類似 Skitch 之類的工具標記熊赖，一目了然来屠。
數(shù)據(jù)采集需求中剩下的部分是不是就可以結構化了？類似這樣：
{ "event_id": "test_event", "curent_app_version": "當期需求定義時的產(chǎn)品版本號", "params": [ { "name": "product_id", "desc": "商品 ID" }, { "name": "type_id", "desc": "類型ID" ], "desc": "事件的詳細描述"}
然后震鹉，我們數(shù)據(jù)采集需求變成了一個JSON文件和一個圖片俱笛，如何管理？Git啊传趾。那PM怎么會用Git？ 抽象一層，做一個工具隱藏Git的復雜性不就好了鞋仍？
- 通過 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 需求分支初始化完成"
新版本自然繼承上一個版本的所有數(shù)據(jù)采集需求
多個版本并發(fā)開發(fā)時家妆，需求也是多個版本，最后通過Git merge在版本發(fā)布后將需求合并
通過 WEB 界面簸呈，隱藏 Git 復雜性
PM 僅僅感覺是在一個 Web 界面中定義數(shù)據(jù)采集需求
每個需求定義做格式校驗榕订，成功后直接 commit 到 Git 中
通過 commit log 追溯需求定義修改記錄
提供唯一 URL， PM 跟開發(fā)人員討論需求細節(jié)蝶棋，直接帖 URL卸亮， 避免歧義
通過上述措施，開發(fā)人員可以通過版本號篩選到當前版本的所有數(shù)據(jù)采集需求玩裙，測試人可以獲得新版本所有數(shù)據(jù)采集需求兼贸，方便做回歸驗證段直。上圖為某需求修改日志截圖，這位寫6666666
commit log 的同學溶诞，咳咳鸯檬，不專業(yè)啊。
做到這里就結束了螺垢？顯然沒有喧务。
- 數(shù)據(jù)收集系統(tǒng)根據(jù)需求自動做格式驗證
為何需求要結構化？因為程序可以幫忙做數(shù)據(jù)驗證枉圃。
通過識別公司測試設備功茴，在數(shù)據(jù)采集服務器上通過白名單方式將測試設備發(fā)送的數(shù)據(jù)統(tǒng)一發(fā)送到數(shù)據(jù)驗證工具系統(tǒng)中，測試工程師可以實時而且快速的查看測試設備發(fā)送的數(shù)據(jù)孽亲，數(shù)據(jù)驗證工具通過 API 從數(shù)據(jù)需求工具中獲取當前客戶端版本的數(shù)據(jù)需求定義坎穿，識別以下異常：
數(shù)據(jù)格式錯誤
數(shù)據(jù)參數(shù)不匹配
未知數(shù)據(jù)，指過期或者程序員小哥的 typo 導致的數(shù)據(jù)無法識別返劲，或者已經(jīng)刪除的數(shù)據(jù)采集需求
通過數(shù)據(jù)驗證工具玲昧，減少數(shù)據(jù)驗證的工作。每條測試數(shù)據(jù)都有唯一 URL篮绿，測試工程師提交 Bug 時附帶數(shù)據(jù) URL, 方便開發(fā)工程師還原現(xiàn)場孵延，定位 Bug。
總結
折騰到最后亲配，系統(tǒng)結構變成了這個樣子尘应，涵蓋了需求定義、數(shù)據(jù)收集弃榨、數(shù)據(jù)驗證菩收。
最后，摘抄一句特別實用的話：
If you're not thinking about how to keep your data clean from the very beginning, you're fucked. I guarantee it.
-- EOF --
