在英语流利说，我们这样管理数据采集需求
http://mp.weixin.qq.com/s?__biz=MzI0NjIzNDkwOA==&mid=2247483770&idx=1&sn=b083e38a7d089fc635a187728bd58d21&scene=21#wechat_redirect
你们公司是如何管理数据采集（俗称“埋点”）需求的？ Word？ Google Doc？ Excel？ 是不是遇到如下问题？
需求描述模糊
历史版本需求过段时间就没人找得到了
数据质量堪忧，出现错误或者遗漏现象
我们知道，处理结构化数据程序最擅长。那么思考：
如果我们把数据采集需求定义结构化，是不是就可以依靠程序协助管理数据采集需求，甚至自动化验证数据格式呢？
在英语流利说，我们是这么干的：
- 结构化数据采集需求
将数据采集需求抽象，发现数据需求包含几个方面：
通用数据，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的复杂性不就好了？
- 通过 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 的同学，咳咳，不专业啊。
做到这里就结束了？显然没有。
- 数据收集系统根据需求自动做格式验证
为何需求要结构化？因为程序可以帮忙做数据验证。
通过识别公司测试设备，在数据采集服务器上通过白名单方式将测试设备发送的数据统一发送到数据验证工具系统中，测试工程师可以实时而且快速的查看测试设备发送的数据，数据验证工具通过 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 --
