如果搜索一下“大数据”关键字，可以找到无数的趋势、概念文章，然而切合实际工作的内容极少，本文聊一下两点日常困难和思考：敏捷流程，持续改进。
1、敏捷流程：从单打独斗到团队
最早的电商，我们以开网店来说，选品、进货、仓储、拍照、修图、上下架管理、活动策划、买关键字、客服、配送、维护老客，夫妻老婆店2个人足够。现在呢？我刚才说的每个词都是一个部门，都有成套的培训体系和岗位流程。
数据工作也是一样，伴随电商兴起，就有了互联网概念的数据，流量订单转化率，耳熟能详。在想当长的时间里，这都是一个“兰博”式的个人英雄主义工种：
注册一个工具比如ga，加埋点代码，验证数据，设计漏斗，定制流程事件，产生报表，提出建议--都是一个人。
然而，这种情况已经不适应现在的实际工作：
要埋点的平台、设备数量极大增长；埋点内容紧密结合业务，复杂多元；埋点验证和开发测试流程紧密耦合；最直观的，团队规模也远非昔日可比--因此就算有老手能够一个人全部解决（是完全有可能的），也会面临新人带不起，团队表现不稳定的问题。
以上都是切身之痛，不再多吐槽，however笔者是属于相信“一切事情都能改善，而且试一下也不会死”的那种（待过创业团队的都这样傻），打算借鉴流行的增长黑客理念，用kanban敏捷方式来做做改善。
希望达到的目的很简单：增加流程透明度，记录工时，自动提醒周期任务；
工具的要求是学习门槛低（因为是非技术应用），手边就有朋友推荐的teambition或tower（广告费请打到瑞士银行的户头里谢谢）；
过程很简单，首先用kanban敏捷开发模板建一个项目，将代码专用的push、merge等过程微调，改成所在数据组习惯的说法；
然后是困难的部分（实践中还会改进），即抽象现有工作类型；
比如针对日常工作的不同维度数据，有实时报警、T+1的监控、T+7的监控、乃至月报、季报；再比如，对应某个事件的，节假日分析，重大改版分析；再再比如，月度季度的用户留存分析，不同地区差异分析等综合数据挖掘。
如图所示（白板是网络还是实体的无所谓了，很多人觉得站着开会就是敏捷，我可能建议组员葛优躺着开会），每个需求一张贴纸，不同颜色对应日常、事件、综合的大类。
最初所有贴纸都在左侧的backlog（待办）区域，在每周内部会上确认优先级，然后将优先级最高的放在下一个列表，经过概念（确认具体库表、字段、逻辑、sql），执行（包括和其他组的依赖），报告（日常任务每天要拉到这里）三个阶段，直到完成关闭。
再后续，就看花多久能带动其他人融入流程了。
2、持续改进：从记录历史，到预测未来
有时候回头想想，为什么现在的数据团队，明明是以前人数的十倍甚至几十倍，仍然觉得完全忙不过来呢？（官方吐槽：是因为弱。。。对，但不完全是）
可能相关的变化，是“期望”被大大提升了。
现在，大家不仅仅希望数据组出一个“上个月销售量xxx”，而是更进一步希望数据组给出“下个月建议主打yyy”。
也就是说不仅仅要求“记录”确认的部分（也就是十八世纪古典统计的水平），还要求有“刻画”PDF概率分布的预测（也就是计算机发明以来的水平），这对于数据质量、置信度CI定义和数据视觉隐喻的要求，一下子跃升了很大的台阶。
基于如此之高的期望，我对敏捷流程的所谓“收益预测”，不仅仅在于有个方便统计工时和自动提醒的工具（当然了可能hr和行政管理就需要这些就够了），更在乎的是，敏捷思想会引导人“归类/抽象/透明化团队工作过程”，进而反过来，进一步提高整个工作的品质。
举例来说，当一个app用户留存报告需求，陷入僵局的时候，如果是通常的工作模式，细节散落在上百封邮件和聊天记录（甚至线下聊天）里，接受任务的数据运营执行人员要承受的沟通压力是可想而知的，因为不知道要推动哪里，向哪里推，推了以后怎么证明价值等等。
而如果是类似敏捷工具这样，透明化整个过程（要技术人员接受敏捷比非技术人员要容易些，因为码农都是天生工具癖），视乎融合的程度来说，有一定的可能可以更容易看到症结。
常见的有：业务需求不明确，业务到产品需求转化不具体，埋点方案的开发架构问题、工时预估问题，测试阶段工时问题、用例问题（遗漏了某个事件抓包验证，几乎每个玩数据的都体验过），等等等等，或许几次下来，就可以定位到优化点（大白话就是南郭先生）。
一句话概括：敏捷的价值，在于之后的反哺效应。
本篇只是个开头，知易行难，后续有了一些实践积累以后可能会继续更新，谢谢阅读，欢迎讨论。
