关于敏捷数据运营的思考

如果搜索一下“大数据”关键字,可以找到无数的趋势、概念文章,然而切合实际工作的内容极少,本文聊一下两点日常困难和思考:敏捷流程,持续改进。

1、敏捷流程:从单打独斗到团队

最早的电商,我们以开网店来说,选品、进货、仓储、拍照、修图、上下架管理、活动策划、买关键字、客服、配送、维护老客,夫妻老婆店2个人足够。现在呢?我刚才说的每个词都是一个部门,都有成套的培训体系和岗位流程。

数据工作也是一样,伴随电商兴起,就有了互联网概念的数据,流量订单转化率,耳熟能详。在想当长的时间里,这都是一个“兰博”式的个人英雄主义工种:

注册一个工具比如ga,加埋点代码,验证数据,设计漏斗,定制流程事件,产生报表,提出建议–都是一个人。

然而,这种情况已经不适应现在的实际工作:

要埋点的平台、设备数量极大增长;埋点内容紧密结合业务,复杂多元;埋点验证和开发测试流程紧密耦合;最直观的,团队规模也远非昔日可比–因此就算有老手能够一个人全部解决(是完全有可能的),也会面临新人带不起,团队表现不稳定的问题。

以上都是切身之痛,不再多吐槽,然而笔者是属于相信“一切事情都能改善,而且试一下也不会死”的那种(待过创业团队的都这样傻),打算借鉴流行的增长黑客理念,用kanban敏捷方式来做做改善。

希望达到的目的很简单:增加流程透明度,记录工时,自动提醒周期任务;

工具的要求是学习门槛低(因为是非技术应用),手边就有朋友推荐的teambition或tower(广告费请打到瑞士银行的户头里谢谢);

过程很简单,首先用kanban敏捷开发模板建一个项目,将代码专用的push、merge等过程微调,改成所在数据组习惯的说法;

然后是困难的部分(实践中还会改进),即抽象现有工作类型;

比如针对日常工作的不同维度数据,有实时报警、T+1的监控、T+7的监控、乃至月报、季报;再比如,对应某个事件的,节假日分析,重大改版分析;再再比如,月度季度的用户留存分析,不同地区差异分析等综合数据挖掘。

如图所示(白板是网络还是实体的无所谓了,很多人觉得站着开会就是敏捷,我可能建议组员葛优躺着开会),每个需求一张贴纸,不同颜色对应日常、事件、综合的大类。

最初所有贴纸都在左侧的backlog(待办)区域,在每周内部会上确认优先级,然后将优先级最高的放在下一个列表,经过概念(确认具体库表、字段、逻辑、sql),执行(包括和其他组的依赖),报告(日常任务每天要拉到这里)三个阶段,直到完成关闭。

再后续,就看花多久能带动其他人融入流程了。

2、持续改进:从记录历史,到预测未来

有时候回头想想,为什么现在的数据团队,明明是以前人数的十倍甚至几十倍,仍然觉得完全忙不过来呢?(官方吐槽:是因为弱。。。对,但不完全是)

可能相关的变化,是“期望”被大大提升了。

现在,大家不仅仅希望数据组出一个“上个月销售量xxx”,而是更进一步希望数据组给出“下个月建议主打yyy”。

也就是说不仅仅要求“记录”确认的部分(也就是十八世纪古典统计的水平),还要求有“刻画”PDF概率分布的预测(也就是计算机发明以来的水平),这对于数据质量、置信度CI定义和数据视觉隐喻的要求,一下子跃升了很大的台阶。

基于如此之高的期望,我对敏捷流程的所谓“收益预测”,不仅仅在于有个方便统计工时和自动提醒的工具(当然了可能hr和行政管理就需要这些就够了),更在乎的是,敏捷思想会引导人“归类/抽象/透明化团队工作过程”,进而反过来,进一步提高整个工作的品质。

举例来说,当一个app用户留存报告需求,陷入僵局的时候,如果是通常的工作模式,细节散落在上百封邮件和聊天记录(甚至线下聊天)里,接受任务的数据运营执行人员要承受的沟通压力是可想而知的,因为不知道要推动哪里,向哪里推,推了以后怎么证明价值等等。

而如果是类似敏捷工具这样,透明化整个过程(要技术人员接受敏捷比非技术人员要容易些,因为码农都是天生工具癖),视乎融合的程度来说,有一定的可能可以更容易看到症结。

常见的有:业务需求不明确,业务到产品需求转化不具体,埋点方案的开发架构问题、工时预估问题,测试阶段工时问题、用例问题(遗漏了某个事件抓包验证,几乎每个玩数据的都体验过),等等等等,或许几次下来,就可以定位到优化点(大白话就是南郭先生)。

一句话概括:敏捷的价值,在于之后的反哺效应。

本篇只是个开头,知易行难,后续有了一些实践积累以后可能会继续更新,谢谢阅读,欢迎讨论。

发表评论