必备的8个主要流程 数据分析的流程包括哪些

1 。新要求
数据分析
工作流程的第 1 个状态,就是忠实地记录新的需求,纯粹地站在需求方的角度,不加任何评判地收集原始的需求 。
这种状态借鉴了ORID焦点讨论法的第一步,就是真实记录客观事实 。
关于ORID焦点讨论法,我从网上查了一些相关资料,看到了下面这个例子,觉得比较合适 。假设我昨晚下班路上遇到一只狗(O fact ) 。当时我很害怕(R觉得)想着怎么办(我想) 。为了避免被狗咬,我最终决定绕道而行 。
2 。需求确认
需求确认是分析任务成败的关键,要根据不同的情况采取不同的对策 。
案例一:需求者无法清晰描述问题 。
刘思哲老师说,这类需求者专业技能不合格,会害上下游,“火”就够了,绝不能手软 。
英文单词“fire”的意思是“驱逐”,但我理解刘思哲先生在这里表达的应该是“拒绝” 。
对于一般的数据分析师来说,需求方可能是自己的老板,恐怕也没有勇气去“火” 。在这种情况下,我个人建议加强沟通,主动询问更具体的信息,搞清楚需求者的真实意图 。
情况二:需求方把很多问题混在一起 。
这种情况很常见 。数据分析师需要应用MECE原理,帮助需求者梳理业务,成为独立详尽的问题,了解主要矛盾和次要矛盾 。
【必备的8个主要流程 数据分析的流程包括哪些】情况三:需求方无法用数据映射 。
这种情况也比较常见 。企业一般用“角色前置”来缓解这个问题,比如设置“产品经理”这个岗位角色 。但有时候,前台角色可能会不合格,这就需要数据分析师在“数据验证”环节给出专业意见 。
案例四:需求方提出了错误的数据需求 。
想象一下,数据需求本身不对,而你作为数据分析师,居然执行的很漂亮...结果需求方不满意,又提了,以后可能还有第三次...需求方最后可能很不满意,数据分析师吃了亏 。
当出现这种情况时,建议数据分析师进行合理的沟通,并在实施之前指出数据需求的不足之处 。
情况五:需求方无法预测可能的分析结果 。
这种情况很正常,毕竟很难满足完美的需求方 。我觉得这个时候数据分析师应该多一些宽容和理解,站在对方的角度看问题,先学会自己预测,再帮对方学会预测,为对方解决问题 。
如果需求方既掌握了业务和数据的关系,又懂得如何利用数据分析的结果来指导下一步工作,那么数据分析师就要好好珍惜 。
3 。数据确认
当需求确认清楚后,接下来需要确认数据源,可能会出现三个问题 。
问题1:没有存储预期的数据 。
作为数据分析师,如果你能帮助改善这个问题,让企业的数据更加完整,那么你的影响力就会增强 。
第二个问题:数据分散在不同的位置 。
在传统企业中,这个问题很普遍,可能还没有数据仓库 。对于互联网企业来说,这个问题反映了数据仓库设计的不完整 。
如果不是反复出现的问题,可以暂时解决 。如果是经常出现的问题,建议数据分析师主动了解底层数据逻辑,编写自动化代码,如果可能的话,交付给数据仓库团队 。
第三个问题:数据源错误 。
这个问题很致命 。如果数据来源有误,后期的分析结果可能会产生误导,需求方可能会做出错误的决策,后果不堪设想 。
所以数据分析师提高数据敏感度也是非常重要的 。在做数据分析之前,一定要确定数据来源是正确的 。
4 。正在实施
在需求实现的过程中,数据分析师应该管理自己的分析代码 。
以Python为例,尽量使用成熟的包,如Numpy、Pandas、Matplotlib等 。,用Git做好代码版本控制,特别注意代码注释和提交信息的可读性和完整性,让数据处理的每一步都清晰明了 。
此外,使用Jupyter Lab等工具可以大大提高数据分析的工作效率 。
一方面要把好的经验和方法沉淀到固定的流程步骤中,实现工作的过程化 。比如在一份数据报告中,什么样的格式和规范才能让读者轻松掌握最有价值的信息?
另一方面,我们也需要实现流程的工具化 。因为总会有“懒”,总会有人超越过程,总会有人偷偷绕过过程 。因此,我们应该适应使用工具来辅助流程的执行 。
流程工具不适合用怎么办?
华为早些年引入了集成产品开发(简称IPD)的流程,但大家一开始并不适应 。
任郑飞说过一句话:先僵化,再优化,再固化 。
5 。交付
突出主要分析结论,这是数据分析交付的重要内容 。


推荐阅读