干货｜数据分析sop之需求处理阶段（二）
共 6064字，需浏览 13分钟
·
2022-02-26 09:54
文 / Janie（溜溜）
字数 / 6105
预计阅读时长 / 8分钟
我是一个专分享干货的号主
前言
在《干货｜数据分析之落地sop流程（一）》一文中讲了数据分析0-1的完整流程，本文将针对性的讲讲数据分析中的前期阶段-需求处理阶段（这篇文章中有一张sop图，大家可以参考下），认认真真准备了6000字的干货。
需求处理阶段我分成了三块：发现问题、需求确认、需求处理。不要小看前期阶段，前期阶段的准备工作直接决定了后续工作的方向以及分析内容。
01
发现问题
1.以数据分析思维探索问题
先引入下王大爷的故事。
我去王大爷摊位买烤串，唠嗑中王大爷说现在现在赚的不行了。我甚是同情王大爷，安慰王大爷说赚点钱买买菜，够日常花销就行，人嘛就要过的开心点。
王大爷：买菜肯定...
我：不够？
王大爷：花不完，就是想置换一套内环内的房子了，现在五套不够住。
我......
那问题来了，王大爷口中的“赚的不行了”是通过什么得到的结论？
与过去比？过去日赚1W，现在日赚8000，这么比确实少了；
与目标比？目标希望赚个千万，买套内环内大房子，这么比确实赚的不行；
与行业平均水平比？烤串行业平均日赚5000，王大爷已经是烤串中的佼佼者了；
与其他烤串大爷比？这个“其他”的对比群体怎么划分？选择和王大爷摊位所在商圈类似的烤串摊主？还是选择与王大爷串串产品类似的摊主？还是相同年龄段相同性别的摊主？还是平均客单价同一水平的摊主？（以上王大爷收入金额纯属虚构）
怎么判别王大爷的烤串是赚的多的还是少了？
这个其实就是根据王大爷抛出的问题延伸出来的新的问题。实际工作中，「问题」可以是领导或者业务方直接抛出，也可以是自己主动发现。但不管哪方发起，思考问题均离不开数据分析思维的支撑。
2. 找到有效问题
数据分析的过程其实就是发现问题并解决问题的过程。一个好的问题，时间与人力的付出才不会竹篮打水一场空，分析工作才有价值。发现有效问题，显得尤为重要。
有效问题的5个特点：
①是否有价值
此“价值”是建立在公司利益之上的。有价值的问题并不是说角度新颖、前所未有，而是触及到了公司的重要层面。该“问题”是否与公司、部门的OKR相关，是否有跟着公司的整体方向走。比如某个产品已经流量见顶了，公司整体策略由之前的拉新获客变更为提升活跃留存、维护老客，那么即使产品的用户体量趋势即使逐渐趋于平稳，孛离公司整体策略，也不需要再在这上面过于下功夫研究探索。
②是否涉及核心指标
首先需要熟悉公司有哪些指标，尤其是核心指标具体是哪些。其次，需要继续了解这个问题是否涉及核心指标，且涉及了哪些核心指标。
③是否影响面广
是否关系到公司的整体策略？这个问题如果不解决的话，会产生多大的影响？如果解决了的话，会有多大的利好？
④是否可规避
受宏观影响还是微观影响？无法避免还是本可避免？
若这个问题受宏观政策的影响，比如疫情原因导致的线下门店销售下滑，再比如国家出台政策规定篇p2p年化利率最高36%，这是宏观因素，不可避免；宏观因素下，公司业绩指标变化较大，原因众所周知，且无法规避。此时单纯研究这个问题则意义不大。
若这个问题未受宏观影响，比如，某个产品的最近复购率下降，宏观上并未有任何政策影响，就莫名其妙的复购下降了，此时需要深入探索是不是产品本身存在了问题，还是竞品导致，或是其他。这个问题可以说是本可规避但未规避。
⑤是否有时效
时效性的理解就是，如果这个问题现在不解决，对业务后续发展会产生一定的影响。比如，研究前年10月销售下跌的原因则没必要，要保证数据与时俱进，避免数据过于陈旧；再比如，当前时间节点若是处于市场竞争激烈的态势，则需实时把握产品的数据变化，及时发现问题并解决，当前的问题延期到未来作用性衰减。
⑥是否波动大
波动“大”没有绝对的标准，但有相对的标准。比如，整个行业的波动是1%，你的产品波动5%；再比如，波动一直处于1%上线，但突然有一天波动了5%。只看波动5%可能觉得也就5%而已，影响不大，但相对来看，5%已超出了正常范围。
3. 通过什么方式发现问题
与历史对比：是否符合历史惯例趋势，比如数据一直平稳波动还是突增or突降？
与同期对比：如周同期、月同期，年同期。比如2020年双11期间销售额较去年同期是涨了还是跌了？
与总体对比：比如某个sku盈利情况与所在品类盈利情况的对比，该sku对总体的的贡献率如何？
与竞品对比：与有相同应用场景、相同用户群体、存在竞争关系的产品进行对比，寻找差异点。
与目标对比：与公司目标、部门目标相匹配的可衡量指标进行对比，是否有跟着公司战略方向走？
与经验对比：以经验第一时间迅速洞察问题，比如双11某门店营收不升反降。经验不需要数据支持，但需要敏感的数据思维以及数据分析经验支撑。
与预测对比: 与预测数据的差距是否在正常范围内？
4. 问题归类与拆解
工作中面对的问题大大小小会很多，即使是同一个问题也可能会被不同人的发起。每获取一个问题就记录下来，加以归类再去选择性的攻克。
常见的问题归类方式有：
按照四象限法则进行归类
紧急不重要、紧急且重要、不紧急不重要、不紧急重要
按照问题类型进行归类
交易相关、流量相关、用户体验相关、数据安全相关、财务数据相关......
按照优先级进行归类
P0（重要紧急，当前亟待解决）、P1（非紧急，可适当延后腾出时间优先解决P0）、P2（非紧急，可后续再做）......
有时候我们遇到的问题很棘手，大且复杂。一片迷茫，思维混乱。如何着手去解决？这时候，我们需要将复杂的问题“拆而解之”，而非将焦点浮在问题表面，把大问题围绕核心点拆解成可以行动的小问题，找到切入点。打个比方，某个线上产品营收下降了10%，将10%拆解到各个子产品线、各个地区维度等，拆解出下降由哪方面带来，再针对性的逐个分析。
5. 站在业务角度想问题
做分析，很容易陷入一个圈：为了分析而分析。
看到一个问题，会想可以用xx模型、xx技巧、xx模板来分析了。使用了一圈的技能，复杂的过程，密密麻麻的公式等，感动了自己，迷茫了需求方。不是说不能使用，而是要回归业务本质，先从业务角度出发，思考这个问题的价值。分析方法向业务靠拢，而非业务需求向分析方法靠拢。
了解清楚了问题的业务价值，以后最起码可以站在一个更高的公司策略层面的角度，谈论这个问题的核心意义。
我最初做分析的时候，就陷入了这种圈子。辞职的时候，跟领导说不想做这种只跟业务方打交道的分析，也没涉及任何模型，想去做涉及模型的分析。现在想来，好愚昧的想法。做分析需求不一定需要复杂的模型，反过来，做模型一定需要深入了解业务知识，哪怕数据科学家这种对分析模型深入熟练的角色，也有着深入的业务了解程度。不管怎么说，深入了解业务，不亏。
发现问题之后，有了初步的方向，下一步就是需求确认。
02
需求确认与梳理
1.确认需求背景
了解清楚需求背景，才能明白这个需求的意义，是为了解决什么问题而出发的，不至于迷茫的做分析。需求背景就是需求产生的原因以及想要达成的目标。
需求产生的原因: 当前现状是怎样的？为什么会提此需求？遇到了什么问题？
需求要达到的目标: 此需求期望在什么时间通过什么样的方式达到什么样的目标？（when、how、what）
2.确认指标口径
需要确认清楚这个需求涉及什么指标，哪些是核心指标哪些不是核心指标。每个指标的口径是什么，最近有没有更改口径。比如客单价，即使大家都知道客单价=GMV/用户数，但是不能想当然以为需求方肯定知道，需求方也以为你肯定也知道，双方未核对口径直接开工干活。这样会存在两波客单价口径不一致的风险。分子什么维度、分母什么维度，都需要对清楚。
说白了就是，我以为你知道，你以为我知道，但是，咱们还是要对一下口径。
因为分析角色是干活的一方，需求方是发布需求的一方，所以面对需求，自身需要想的更多些，有些点需求方可能没想到，此时分析师需要具备更多的主动性。引导沟通、多方核对。毕竟，不沟通清楚需求直接干，容易背锅且被投诉，也竹篮打水一场空，浪费了时间。
所以前期不要怕沟通。最好是沉淀成文档，点对点沟通。
3.确认数据维度
数据维度可以理解为研究数据的角度，比如地区、城市、用户名等。
需要向需求方了解清楚:
需要什么维度的数据？
此维度按照什么方式聚合？
去重还是非去重？
直接聚合还是累积聚合？
......
4.确认底层表逻辑
需求方提需求，一般只会讨论需求详情，但是需求怎么做，数据从哪里获取，他们不需要关心。比如，需要看某个商品的七日复购率，数据库表中有七日复购率指标么？若有指标口径是否和需求方的口径一致？若无，需要从哪些数据库表进行关联得到所需数据？自己关联计算的逻辑需要数仓落表还是直接应用？
5.确认资源配置
资源配置包括人力资源与排期资源。比如需要大致评估下需要什么团队安排几位人手做需求，以及安排的人员是否有排期。所以分析师在这里还扮演了一个协调的角色，协调好需求方、数仓、分析师等人员的配合。需求紧急，排期紧张，还需要去协调是否将此需求优先级前调，其他需求暂且延后。
6.确认需求完成时间
需求方大多数只给了一个最终的时间，比如这个需求2月10日需要完成。那么每个环节的详细时间计划，需要分析师去领头协调了。比如：
清晰的排期计划：
便于需求方及时随时查看进度
便于自己有个需求跟进的时间参考
7.确认数据安全性
分析师可以接触到很多底层数据，所以需要有数据安全意识。有的公司划分比较严格，某个模块的需求专门安排某个分析来一一对接。但有的公司没这么严格，所以需要判别下需求方是否可以查看该数据。
需求方是否可查看该数据
即使是同一个公司的人，各自的数据权限也并不一样，一般不允许非必要性情况下获取本职工作以外的数据。比如，两个部门做着类似的产品，有着类似的用户群体，也背负着各自绩效，数据不能相通。但对方都是希望可以获取另一方数据来做对比，这种情况有的公司不被允许。分析师自然也要判别这种情况，该给给，不该给则果断拒绝这个需求。
明细数据是否涉及数据安全
另一方面，需求方有时候需要明细数据，即数据粒度较细的非聚合数据，比如ods层、dwd层的数据，还需要判别下是否能够提供明细数据。有的公司明细数据会受到公司安全部门的监管。毕竟，明细在手，各种角度的分析都能搞。
03
面对不合理需求
工作中会面对各种各样的需求，确认需求是否合理也是一项重要的步骤。合理的需求建立在利益最大化的基础上的，就是以合理的资源做着合乎公司整体规划的需求。
但若是遇到了不合理的需求呢？
分析师虽然作为服务方，服务于需求方，但不需要将“满足一切需求”作为行事标准，这样解决的只是“量”的问题，并不会解决“质”的问题。其实工作中不必一味的迎合用户，当然也不是说直接掷地有声的拒绝，而是扮演好需求的引导角色与管理角色。
1. 引导角色
以前曾经接过一个大领导的需求，涉及一张图表，需要看不同商品在不同地区的趋势表现，比如看办公用品在北京、上海、杭州、苏州、南京等城市的销售额对比，还需要看学习用品在北京、上海、杭州、苏州、南京等城市的销售额对比，等等。我其实做的是筛选器上筛选不同商品来看城市对比即可，但是这位大领导已经习惯了以前的做法，就是相同的图表一直平铺排列下去，需要一直上下滚动来看。我的直属领导说，筛选的方式自然是很便捷的，只是还没习惯，也不必非要按照他以前的方法来做，你可以先尝试着去引导他，讲解下这种方式有什么便捷性。
这是个小例子。
还有个例子是，有需求方需要的是明细数据，数据量上百万，以表格形式展示出来供他们下载即可。用户是这么需求的。但是作为分析，需要进一步考虑，为什么需求方要把BI当作一个下载数据的平台，而不是直接看数据的平台？在需求沟通的阶段，其实就要了解清楚需求方下载下来的目的？是BI看着不方便？还是用着不习惯？
如果说需求方下载下来之后需要进一步在excel上做数透、函数等处理，是不是可以引导需求方直接在BI上实现即可。因为明细数据的量一般不会小，经常跑明细任务给平台自身也带来了很大的压力，需求方的数据处理时间也增加不少。
所以，其实有时候也没必要非要被需求方牵着鼻子走。如果是个双赢的局面，不如加以合理的引导。
2. 协调角色
如果正在按部就班的处理着需求，突然插进来一个需求怎么办？工作中都会有这种情况。需求方会说“我这个需求很简单，你先处理下吧” “我这个需求很紧急，大佬们都在盯着呢，麻烦你优先处理” “我这个需求10分钟之内就要出结果” “别人都能立即搞定，为什么你要明天才可以？”等。
自己协调
如果手中需求的优先级已经跟各需求方确认好，穿插需求先考虑到会不会打乱其他需求。如果好几个需求都喊着紧急，先紧急做影响面广的。其他的直接表明态度需要适当延后即可，但是最好可以给到一个具体的延后排期给需求方，沟通确认延期后的时间需求方可以认可，而不是直接一句“没时间”就完事了哈。
适当求助
优先级如果自己不能做主，或者自己协调的时间需求方不认可，也可以适当求助上级领导，共同商讨下手中需求的优先级。毕竟领导经验更多考虑的因素会多些。
04
沉淀需求文档
其实需求要梳理的内容基本上都在需求确认环节都确认清楚了。需求确认和需求梳理并没有严格的前后关系，可以同步进行。
只需要将口头沟通、会议沟通等全部沉淀成需求文档，一般来说包括以下内容：
需求背景
需求描述
指标口径及数据维度
人员配置及执行计划
需求文档沉淀完毕之后，还需与需求方再过一下。若需求后续有更改，也需要将需求更改时间标明上去，便于回溯。
以前我接需求特别不爱沉淀文档，觉得浪费时间，就直接开干。过了一段时间后，会出现：
①需求方说当初讨论的明明不是这样的；
②有使用方问指标口径为什么这么定呢；
③其他人问这个需求为了解决什么问题
④ ......
我不能保证我能凭空将以前的需求讨论细节完好的讲出来，甚至忘记。所以，沉淀很重要。如果需求确实紧急，也可以先开干，后续再抽空将需求整理出来。
做好需求梳理的沉淀，还有一个好处是，会让你想的更多更细，比起直接开干更可能及时的发现些问题。
结语
本人主要针对数据分析的前期工作展开仔细讲了讲，包含从问题发现到需求确认、需求处理的过程，下篇文章会着重讲讲数据分析中的数据处理阶段。
此系列将针对性的把数据分析0-1完成流程的各个环节全部讲一遍，正好我自己也可以梳理一遍。敬请期待～
随便说说
以上都是基于平时经验写的，如果有写的不对的地方，欢迎后台留言给我指出哈～
因为边上班边带娃边学习边更公众号，所以更新可能慢了点，但每一篇都在超级认真的准备。我的原则是，不能为了赶时间就将就的凑合一篇，要做就认真做。一般情况下宝宝睡了，我才拥有自己的自由时间。
吾生有涯知无涯，希望看到这边文章的你，一起加油～
另外，今日情人节，祝天下有情人终成眷属！
