一份数据分析需求沟通模板，避免来回更改需求

小提示：您能找到这篇{一份数据分析需求沟通模板，避免来回更改需求}绝对不是偶然，我们能帮您找到潜在客户，解决您的困扰。如果您对本页介绍的一份数据分析需求沟通模板，避免来回更改需求内容感兴趣，有相关需求意向欢迎拨打我们的服务热线，或留言咨询，我们将第一时间联系您！

确认的需求，做好之后来回更改，搞得数据分析师心力交瘁，白白做无用功。为了避免需求来回变更的情况，有什么办法呢？作者总结了一份数据分析需求沟通模板，帮助你与业务同学更好地沟通需求。

作为数据分析师最怕什么？莫过于下午5:55分，自己正准备收拾包包走人，一个电话飞进来：“歪！帮忙跑个数，我们总监要，今天无论多晚都得给！”听完这通话，心情直接跌入谷底。

如果有比这还可怕的，就是晚上11:00，你累死累活跑出来数了，对方一句：“哦，好像不是这个数，你换另一个跑法试试，还是今天无论多晚都得给哦……”

如何避免这种问题呢？

一、数据分析的需求沟通

这个问题显然是出在需求沟通上。没有沟通清楚需求就动手，自然会来来回回返工。不但自己做得辛苦，业务部门也不满意。所以沟通需求很重要。而数据分析是有标准的需求模板的。

如果是取一张数据表，标准的需求，至少由以下三部分组成（如下图）网络公关公司是什么：

1. 取数指标
2. 取数时间段
3. 分类维度

如果取数的指标/分类维度，在数据字典里没有标准定义，则还需要说清楚计算公式。比如市场部有三个活动同时在举行，想看看用户在多个活动间与情况。

此时需要新建一个分类维度：活动参与情况电商运营怎样做，包括：

• 三个活动全部参与
• 三个活动参与任意2个
• 三个活动参与任意1个
• 三个活动全部未参与

如果是一个分析型需求，则要说清楚：

1. 当前的业务背景是什么
2. 目前是否已经清晰的问题？
3. 是否已有假设/预案

整个逻辑如下展开：

BUT！

上边这么复杂的需求格式，靠业务自己说，根本讲不清楚。

2022年的职场现状是，十个业务里：

• 3个认为数据就是你数据分析的事，我凭什么要讲清楚！
• 3个表示这需求是老板给的我也不清楚你自己问他老人家去……
• 3个可以讲出：“我要分析这个问题”，但具体到字段，啥是字段？？？
• 只有1个能讲清楚，因为他以前干过数据……

所以需求沟通这个事，不能太指望业务自己，自动自觉把这些问题都讲清楚，而是需要数据分析师们掌握沟通技巧，学会主动挖掘。毕竟挖掘不清楚，还是自己倒霉。

二、挖掘需求的技巧

想要在稀里糊涂的情况下梳理清楚需求，需要五个步骤：

第一步：听到需求后，把“收到”改成“等一下！”第二步：明确正在聊的事，是具体哪个业务场景

第三步：明确正在聊的事，有哪些数据记录

第四步：基于数据记录，给几个示例，让业务感受下

第五步：基于数据示例出数，完美交差

总之，就是用一个例子，把虚幻的分析需求具体化，从而明确输出内容，减少后期返工。话不多说，直接上个案例同学们实操一下。

三、实操案例学习

背景：某电商公司，客服找到数据分析师，说分析一下客户联系客服的留言，看看有啥价值，比如退单原因、客户满意度啥的。

问：该咋分析？

第一步：管好嘴

把已经到嘴边的“好的，我去分析分析”咽回去，说出：“等一下”。

第二步：找业务场景

“分析一下客户留言”是一句空话，没有任何具体问题，因此放过去。后边有两个具体场景：

场景1：客户退单

场景2：客户满意度

因此可以从这两个场景切入，具体聊聊啥情况

第三步：确认数据记录

1. 客服口中的“客户退单”，具体定义是啥？是以客户沟通中表达“想退单”为准，还是以客户人工标记：“想退单”为准，还是以客户建立的退货工单为准？
2. “客户退单”的信息，关联了哪些内容，比如退单对应的订单号、产品、退货原因。
3. 如果有退货原因字段，是客户自己填的，还是客服标注的，客服标注的常规操作是什么？

注意：以上问的三个问题，要么是客服自己的理解，要么是客服自己的操作习惯，与数据一毛钱关系都没有，这种问他们自己的认识、习惯的问法，是很容易得到回答的。得到答案以后，再根据实际情况，转化为数据问题。

第四步：做分析示例

根据客服描述的具体场景，做一个示例出来。

比如客服说：“是客户跟我们聊的时候，表示想退单，结果经过我们努力成功保住了订单。”这就是一个具体的客服操作场景，而对应的数据情况也是很清晰的：

• 客服聊天记录里，抓有“退单”“退货”“不要了”等关键字的用户
• 根据用户聊天中提及商品/订单号、关联商品名称、商品金额
• 根据该用户后续订单是否取消，确认客服是否保住成功
危机公关英文书

因此，可以做分析示例如下：

并且，在这个场景里，客服表达的诉求也是很明确的：要向其他部门证明我的价值！我为公司赚钱了。所以这个分析的核心，其实就是算出来上图中挽留金额。这个才是人家真正在乎的，别的都是点缀。

比如客服说：“每次上大促销，Q&A指引都不清不楚，搞得一堆退货工单，烦死了”。这也是一个具体场景，对应的数据情况：

• 以客服实际建立的退货工单，客服标注退货理由为准
• 重点关注退货工单里“促销”有关问题。
• 清理其他促销同时段的，可能关联的标注，比如“促销产品质量差”是否被客服标记为了：“产品问题”而非“促销问题”。

因此，可以做分析示例如下：

并且，在这个场景里，客服表达的诉求也是很明确的：要倒逼运营做好促销Q&A。因此这里不需要深入的分析，而是需要把情况说清楚：到底有多少退货和促销有关。

这里的第三步很重要，因为工单是人工标注的，所以很可能有标漏、标错、标注不合理等问题。而在这个场景里，客服怼人的意愿是非常强烈的。因此很有可能会刨根问底的，想把所有情况都弄清楚。

因此“清理其他情况”这句话最好由数据分析师主动说，这样帮助客服打消疑虑，后续数据也好过关。不然很有可能出了数，被扣个：“分析不细致，不深入”的帽子，最后还是返工。

当然，也可能有其他场景，总之按照同样的方法，从场景→数据→示例，一个个耐心点做，梳理完毕就好。

很多时候，业务在聊场景的同时，会把他想达到的目标一并说出来。这就是做需求挖掘的终极目标了。当知道业务想干啥，就能顺水推舟，让他们满意。不过有些业务很保守（不信任数据）所以不会主动讲出意图，因此这一点不强求。

第五步：基于数据示例出数

其实前四步做好了，这里根本不会遇到什么阻碍。因为铺垫都已经做好，业务很清楚自己能看到的是什么数据，很清楚数据里已经包含了哪些情况，排除了哪些可能，因此短时间内很难再想出什么更改需求的内容。一般看到数据以后都是：“好的，很清晰”一句话，差不多就安神了。

这么梳理，远远强过一声“好的”然后哼哧哼哧跑数，回头再被人怼回来修改。我个人使用体验是非常好的，当年还没做领导的时候，靠这套方法不但下班按时，而且和很多业务同事交了朋友，体验极好，推荐同学们都试试哦~