数据需求有多野？“三连问”帮你处理得明明白白

需求类型是需要判断的。尤其是由业务人员主动发起的需求，通过你的需求判断， 也许会从一个临时需求变成一个报表需求，也可能会从一个需求拆解成多个需求，为的是更高效地帮助业务人员使用数据。

▊ 识别需求背后需要解决的问题

 场景1：当你坐在办公室“燃烧”脑细胞写着文档时，一个业务分析师打电话来说： “我需要在一个报表中加一个指标，比较着急。数据我验证过了，需求文档马上发给你。”

你迅速地看了一眼那张报表，数据归属的业务和高频使用者确实是这位同事。打开他的需求文档，定义非常清晰，而且符合逻辑，甚至提供了现成的查询语句。你暂停了手里的工作，开始和这位同事争论这个指标应该加在哪儿， 能不能按照他的要求很快上线。

 场景2：负责商品运营的业务部门同事说：“我们需要一个单个商品销量的预测值，放在采购管理后台，我们什么时候聊一下怎么实现？”听到“预测”两个字你头都大了，开始和业务同事讨论怎么预测能更合理。

 场景3：你路过一位一线运营人员的工位，发现他的Excel 出现了令人绝望的无响应提示，他一脸沮丧。看到你路过，他叫住你：“来，兄弟，帮我看一下是不是我的处理方式不对？”你走过去仔细一看，他正在从两个系统里分别下载两张表格，在本地用VLOOKUP 函数拼起来做后续计算，数据量有十几万行。你觉得既然这个动作每天都要完成，直接将它产品化好了。

 场景4：业务主管在会议室门口碰到你，说：“我组里的数据分析师有一个每个月都要做的数据PPT，每个月内容都差不多，能不能做成可视化页面？”你回答：“什么PPT ？发给我看一下吧。”他说：“好的，我让他找你对接。”看到PPT 你发现， 它本来的意义在于每个月对关键指标的波动进行多维度拆分归因，理论上业务侧每个月发生的事情都不一样，几乎不可常规化。

之所以那位主管觉得每个月内容差不多，看起来是他把这个PPT 当作报表来用了，实际上这些指标和维度已有的线上报表都是覆盖的。最头疼的是，你和这位数据分析师聊过之后发现，这是一位新人，这个PPT只是他的一个工作任务，数据使用方式和背后的业务逻辑并不能从这位对接人身上获取。这可怎么办呢？ 

▼

数据无处不在，数据需求无处不在，有时候是以它们本来的面目出现 ，有时候伪装成别的样子需要你去发现，最可气的是有些不是数据需求的内容以数据的面目出现。这些要如何识别？

原始需求描述的通常只是一种现象，这种现象被各种你没有参与过的讨论“变形”。那么我们工作的一项重要内容，就是识别这些以各种各样面目出现的需求背后的本质问题。

这就像讨论所有数学问题的第一步一样：先讨论假设前提。所以无论数据需求以什么面目出现，数据产品经理都要问自己（“三连问”）：

• 业务究竟遇到了什么问题需要解决？
• 数据怎么定义和描述这个问题？
• 这个问题是通过数据能直接解决的，还是数据能够提供一些佐证？

之所以要问自己这3个问题，而不是直接问需求方，是因为并不是每一个需求方都能把问题直接对应到数据模型。在沟通过程中，通过一系列的提问和需求文档的填写（复杂场景可能还需要多方信息的补充），来逐步回答这3个问题。

回答了这3个问题，再考虑执行：是否实现？怎么实现？在哪儿实现？

问题识别难度大致可以分为以下3个层级。

◆1 原始需求完全描述了业务问题和业务目标，而且有明确的可实现的指标定义和维度定义。

碰到这样的需求方当然很开心。但是千万不要忽略“三连问”。比如在场景1里， 至少要先问一下这位数据分析师：“能先介绍一下背景吗？”或者“到底发生过什么事导致突然出现了这么紧急的需求？”这样的合作者意味着他除了足够了解业务，还足够了解数据，你可以从他那里得到的信息就会更多。

另外，非常重要的一点，在执行过程中，对方提供的定义一定是基于某些假设前提的，也需要在进一步沟通中确认，并提示数据技术人员——在开发过程中从数据层面校验这些假设。

例如：如果定义“单个商品的转化率”为“商品销量 / 商品详情页UV”，且操作定义里没有加入任何限制条件，那么就必须符合“该商品的购买必须经过浏览详情页”这个假设前提。

如果数据分析师或数据运营校验过的SQL 中，使用了某两个不同名称的字段做连接（Join）的关联关键字，那就必须先验证这两个ID 在数据表中的实际关系，避免数据被这个关联放大或缩小。

◆2 原始需求讲明白了业务问题和业务目标，但是数据定义缺失或者有偏差。

这可能是多数情况。毕竟术业有专攻，一个非数据角色无法明确数据定义是很正常的事情。将业务的问题和目标进行准确的量化，并给出明确定义，便是数据产品经理在需求沟通中需要做的。

在一些场景里，业务目标需要在需求沟通中通过一系列提问来确认。

例如在场景2中，第一次沟通，没有任何信息，第一句话就定位到了执行方式， 显然是不妥的。这个“预测值”承担的作用是什么，为的是给什么样的角色做出什么样的决策给出的“预测值”？实际上，经过沟通发现，这位同事只是想要一个商品是否有资格采购并上架的依据，而这一依据显然不应该只有销量这一个指标，而且还使用所谓“预测值”这样的概率结果。

这件事背后的数据使用诉求，需要对商品所处的品类、价格、历史销售情况等一系列的综合因素进行综合考量，是否采购？采购量多少？在哪些城市上架？也应该分别独立决策。于是你建议业务方先做一个简单的数据分析，并提供临时取数的服务。同时联系了商业分析部门的同事来帮忙做一个专项分析。相信对方会愉快地接受。

在场景3中，你看到的是一个执行者日常的烦琐工作。那么这个过程的目标结果是为了描述什么而存在的？这时，除了和这个执行者了解清楚具体的工作流程，还需要了解这种本地操作计算结果最终会如何被使用？解决什么问题？

因为本地处理的方式很有可能会将一些原本更精细的计算简化了。如果将这个操作产品化，则可能会选择更精确的定义。问题他也会回答得直截了当，很少需要进一步追问。

◆3 原始需求中业务目标缺失。

这种情况不多见，但是偶尔也会出现，比如你可能听过的一句话：我不知道为什么，我老板就要这个。但是请相信，所有数据需求的背后，永远有一个需要用这个数据去解决的业务问题。遇到这种情况，方法也很简单，去找数据的最终使用者聊聊。

在场景4中，在看到这个PPT 之前，我们大概可以预判，一个承担月度数据报告角色的PPT，通常会包含几个常规部分：

• 关键指标波动
• 关键维度拆解
• 波动归因分析
• 少量深度分析

这里我们就可以做进一步分解，看哪些是可沉淀的， 哪些是不可沉淀的。其中，关键指标和关键维度的监控，是报表层应该做的事情。而波动归因、对应的结论和观点输出，需要在分析层面解决。

产品化要做的部分，是将分析逻辑尽量融入看数逻辑中，例如让关键指标的关键维度下钻更方便，让业务的关键事件记录更便捷等。那么我们就可以和业务的数据使用者、PPT 的提供者一起讨论， 来明确以上这些观点——讨论中重要的一部分，就是通过这种讨论，来明确业务目标和业务问题。

▊ 工作笔记：一个需求沟通框架

这个框架主要用于需求方发起一个需求后，双方需要沟通的情况下。这里需要注意区分“需求沟通”和 “会议”之间的差异。会议的目标是就某一件事有决议，而需求沟通——尤其是初次沟通的目标，是充分挖掘并记录业务人员关于这个需求的信息，将你本人非常明确的内容做出反馈，盘点待确认信息并告知对方。

在沟通前，需要准备的内容如下表。

在沟通中要仔细记录，如下表。

上表可能会在多次沟通中才能填写完成：前8 项填写完成，最后一个“待确认信息”，才叫作需求确认。

在沟通中，请务必确保业务人员明确的内容为需求流程和涉及的审批流程。

在沟通后，我们要完成“待确认信息”的确认和反馈。经过充分沟通后，“待确认信息”中没有了业务逻辑的部分，只剩下技术方案相关的问题，即认为是可以输出PRD 的状态。而上表的蓝色部分，就是PRD 主体部分的主要依据。

以上内容节选自新书《写给数据产品经理新人的工作笔记》

《写给数据产品经理新人的工作笔记》是资深数据产品经理10余年工作经验的精华提炼，为数据产品从业新人或准备转行做数据产品的读者提供了一个本领域的通解通法，并对即将面临的问题做出预判，并找到解决方案。行文简洁、幽默、富有逻辑，不仅可以成为数据产品经理的工作手册，而且适合业务层面的管理者、决策者阅读，可以帮助读者理解如何让数据更好地为业务服务。

（扫码获取本书详情）

作者简介 

陈文思 （Viola Chen），数据圈非著名“大表姐”，应用统计学及应用心理学双向专业背景。以网站分析师入行，从业十年间从数据采集到指标体系，从数据集市到数据分析、数据运营等方向均有涉及，一直企图以一己之力完成数据应用链路的完整串联，结果变成了一个填“坑”小能手（或者叫：数据产品经理）。 曾就职于凡客诚品、汽车之家、理想汽车、美团点评。

如果喜欢本文欢迎 在看丨留言丨分享至朋友圈 三连
 热文推荐  
书单丨无惧停机故障，数据库异常不可怕
干货丨Kotlin在Spring Boot中的应用算数or算卦，和业务人谈“预测”到底在谈啥？Python之父加入微软，一开口就知道是老“凡学家”了

▼点击阅读原文，了解本书详情~