数据产品需求分析：用户调研方法、需求优先级排序、数据需求文档撰写
需求分析这件事，说白了就是搞清楚「谁要什么数据，用来干什么，怎么才算好用」。我在做数据产品的头两年，踩过最大的坑就是——产品上线了，用户说「这不是我要的」。嗯，后来我学乖了，需求分析不能靠猜。
这一章我们聚焦三个核心动作：用户调研、需求优先级排序、数据需求文档撰写。这三步走扎实了，后面的设计、开发、交付才不会翻车。
3.1 用户调研方法：别只盯着「用户说什么」
用户调研不是发问卷、记笔记那么简单。数据产品的用户往往有两类：业务用户（看报表、做决策）和技术用户（调接口、做分析）。他们的诉求完全不同。
我个人习惯把调研方法分成三层：
| 调研层次 | 适用场景 | 常用方法 | 产出物 |
|---|---|---|---|
| 第一层：背景理解 | 项目启动、新领域 | 二手资料分析、行业报告 | 领域知识图谱 |
| 第二层：行为洞察 | 已有产品优化 | 用户访谈、场景跟访 | 用户旅程地图 |
| 第三层：量化验证 | 需求确认、优先级 | 问卷、日志分析、A/B测试 | 需求频次/价值矩阵 |
举个例子。我之前做电商供应链的数据产品，一开始直接找运营总监聊需求。他张口就要「全链路库存看板」。我追问了一句：「您每天几点看？看多久？看完之后做什么动作？」他愣了一下，说「其实我就是想知道哪个仓库快断货了。」
你看，他真正需要的不是一个大而全的看板，而是一个预警推送。所以调研时一定要追问场景细节。
3.2 需求优先级排序：别被「紧急」牵着走
需求收集上来之后，你会发现——每个需求都有人拍桌子说「必须做」。但资源就那么多，怎么排？
我见过很多团队用「老板说先做这个」来排序。短期看没问题，长期看产品会变成一堆补丁。我个人比较推崇价值-成本-风险三维模型。
3.2.1 三维评估模型
- 价值维度：覆盖多少用户？能提升多少决策效率？能带来多少业务收益？
- 成本维度：开发周期多长？数据源是否就绪？需要多少跨团队协作？
- 风险维度：数据质量是否可靠？合规风险有多大？技术方案是否成熟？
每个维度打分（1-5分），然后算综合得分。我习惯用这个公式：
优先级得分 = 价值 × 2 - 成本 × 1.5 - 风险 × 1为什么价值权重高？因为数据产品本质是「用数据换效率」，价值不明确的需求，做得再好也是浪费。
避坑指南：我曾经把一个「数据导出Excel」的需求排得很高，因为提需求的VP说「很急」。结果做出来后，用户根本不用——他们真正需要的是自动推送报表。所以优先级排序前，一定要先做调研验证。
3.2.2 需求优先级矩阵
除了打分，我还常用一个四象限矩阵来可视化排序：
| 象限 | 价值 | 成本 | 策略 |
|---|---|---|---|
| 第一象限 | 高 | 低 | 立即做 |
| 第二象限 | 高 | 高 | 分阶段做 |
| 第三象限 | 低 | 低 | 有空再做 |
| 第四象限 | 低 | 高 | 不做 |
你想想看，很多团队把大量资源砸在第四象限——低价值高成本的需求上，结果核心功能反而没时间打磨。这个矩阵能帮你快速对齐团队认知。
3.3 数据需求文档撰写：把「模糊」变成「可执行」
需求文档是产品经理和开发团队之间的「契约」。数据产品的需求文档和普通功能需求文档不太一样——它必须说清楚数据从哪里来、怎么算、给谁看。
我一般把数据需求文档拆成五个部分：
- 需求背景：一句话说清楚为什么做这个需求
- 用户场景：谁在什么情况下使用
- 数据定义：指标口径、维度、粒度
- 交互原型：页面布局、筛选条件、默认展示
- 验收标准：什么样的数据算「正确」
3.3.1 数据定义示例
拿「用户活跃度」这个指标举例，文档里应该这样写：
指标名称：日活跃用户数（DAU）
口径定义：当天有至少1次有效操作的去重用户数
有效操作定义：点击、滑动、提交表单（排除后台自动刷新）
数据源：user_action_log 表
计算逻辑：
SELECT COUNT(DISTINCT user_id)
FROM user_action_log
WHERE dt = '目标日期'
AND action_type IN ('click', 'swipe', 'submit')
AND is_auto = 0
更新频率：T+1 每日凌晨2点你看，这样写出来，开发、测试、业务方都能看懂，而且不会产生歧义。
3.4 知识体系总览
下面这张图把本章的核心逻辑串起来了。你可以把它当作需求分析的「操作手册」：
这张图从左到右展示了需求分析的完整链路。你想想看，如果跳过调研直接写文档，或者跳过排序直接开发，最后大概率要返工。三个环节环环相扣，一个都不能少。
3.5 本章小结
需求分析是数据产品最容易被低估的环节。很多人觉得「不就是问用户要什么吗」，但真正做过的人都知道——用户说的和用户要的，中间差着十万八千里。
我个人总结了三句话，每次做需求分析前都会默念一遍：
- 调研要深：别只听用户说，要看他怎么做
- 排序要狠：敢于砍掉低价值需求，哪怕提需求的人职位很高
- 文档要细：数据口径写不清楚，后面全是坑
嗯，这一章的内容就到这里。记住，需求分析做得越扎实，后面的设计、开发、交付就越顺畅。别急着动手写代码，先把需求搞清楚。