4. 访谈证据分类
用户访谈中收集到的原始陈述、观察记录和上下文信息并非同质化的“需求”。资深数据产品经理必须在访谈现场或复盘中，将证据快速归类为四类：直接需求、隐性需求、约束条件、风险信号。分类质量直接影响后续需求拆解、方案设计和验收标准制定的准确度。
核心原则：同一句话可能包含多种分类证据。例如“我希望报表能每天自动发送，但IT说我们数据库只能凌晨3-5点备份”中，“每天自动发送”是直接需求，“数据库备份窗口”是约束条件，“IT反馈权限”可能隐含风险信号。需逐句拆分、逐条标注。
4.1 四类证据的定义与识别指征
| 分类 | 定义 | 典型访谈句式 | 数据产品映射 |
|---|---|---|---|
| 直接需求 | 用户明确、具体、可操作的期望表达 | “我要看每日DAU趋势图”“过滤条件要支持多选” | 转化为功能列表、指标口径、交互原型 |
| 隐性需求 | 用户未直接说出，但通过行为、抱怨、挫败感透露的真实意图 | “每次导出都要等5分钟，太慢了”“这个数据我从来不看，因为看不懂” | 转化为性能优化、体验改进、数据解释性设计 |
| 约束条件 | 限制方案选择的非功能性边界（技术、法规、组织、预算） | “我们数据只能保留90天”“报表必须符合GDPR” | 写入非功能性需求、验收标准、架构假设 |
| 风险信号 | 可能阻碍项目成功的不确定性因素或负面预兆 | “我们部门正在重组，数据源可能会变”“老板可能不批这个预算” | 记录在风险登记册，设置缓解措施或备选方案 |
4.2 四类证据的拆解方法
步骤1：语义拆解
将每段用户回答切分为最小语义单元（通常是一个主谓宾或条件子句）。使用以下标签对每个单元进行初步分类：
用户原始句： “我希望销售日报能在每天早上9点前自动推送到我的邮箱，但是我们的BI工具目前只支持手动导出，而且最近系统总是在8点做全量备份，导致导出很慢。”
拆解结果：
- [直接] 日报早上9点前自动推送邮箱
- [约束] BI工具当前只支持手动导出
- [约束] 系统8点全量备份时段
- [隐性] 当前导出速度不满足期望（“导出很慢”暗示性能需求）
- [风险] 备份与推送时间可能冲突，若未解决可能导致功能不可用步骤2：交叉验证
同一用户在不同时间点的表述，或不同用户的相似表述，可验证某条证据的真实性。对于隐性需求，可通过“五问法”追溯根本动机：
A面：“我只看前10条数据就够了。”
→ 追问：“为什么只看前10条？”
B面：“因为后面都是无效数据，筛选太麻烦了。”
→ 深层需求：增强过滤/排序/分页功能。
→ 证据归类：从直接需求“只看前10条”修正为隐性需求“需要更高效的筛选机制”。步骤3：冲突与优先级标注
在需求列表中标注来源用户ID、证据分类、冲突对。例如：
| ID | 用户 | 证据分类 | 陈述原文 | 冲突人 | 优先级 |
|----|--------|----------|------------------------------------|----------|--------|
| R1 | 销售VP | 直接 | 日报必须每天9点前推送 | 运维主管 | P0 |
| R2 | 运维 | 约束 | 全量备份时段8-9点，不能加负载 | 销售VP | 不可变 |
| R3 | 产品 | 隐性 | 用户说“9点前”其实是“开早会前要用”| - | 理解 |4.3 四类证据在需求分析流程中的位置
讲师提示：直接需求通常最先被记录，但隐性需求才是产品差异化的关键。约束条件是“避坑清单”，风险信号是“刹车片”。将四种证据放入统一的访谈证据矩阵，后续每一章节（方案表达、指标验证、验收标准、交付物模板）都会回到这份矩阵进行校验。
4.4 交付物模板：访谈证据四分类登记表
每一轮用户访谈结束后，需产出此表格作为需求分析的基础输入。表头字段固定，行数根据访谈记录动态扩展。
| 证据ID | 来源用户 | 访谈时间 | 原始陈述摘要 | 直接需求 | 隐性需求 | 约束条件 | 风险信号 | 冲突/备注 |
|--------|----------|----------|------------------------------|----------|----------|----------|----------|-----------------------|
| E001 | 销售总监 | 2025-03-10 | 日报需要9点前自动推送 | Y | N | N | Y | 备份窗口冲突导致风险 |
| E002 | 运维主管 | 2025-03-11 | 全量备份8-9点，不能加负载 | N | N | Y | N | 与E001冲突 |
| E003 | 产品经理 | 2025-03-11 | 用户看日报是为了早会汇报 | N | Y | N | N | 解释E001隐性动机 |
| E004 | 合规负责人| 2025-03-12 | 报告涉客户隐私需脱敏 | N | N | Y | N | 约束条件优先级P0 |
常见陷阱：
- 将约束条件当作直接需求记录（如“数据库只有MySQL”应列为约束而非功能）
- 忽略隐性需求导致方案不满足真实场景（用户说“我要报表”实际是要“自动预警”）
- 风险信号未及时同步给项目干系人造成后期返工
- 同一证据被不同访谈者重复记录，应合并去重后保留最早或最权威来源
4.5 验收标准：如何判断分类是否合格
| 维度 | 验收标准 | 通过样例 | 未通过样例 |
|---|---|---|---|
| 完整性 | 每轮访谈至少产出1个四分类记录 | 某次访谈记录了2条直接、1条隐性、3条约束、1条风险 | 只记录了直接需求，其他三类空白 |
| 无歧义 | 每条证据的原始陈述可溯回到原话 | E001原始陈述带双引号引用 | “用户想要快点” — 无法判断具体指标 |
| 冲突标记 | 互斥证据必须显式标注冲突ID | E001与E002冲突，已在备注栏标记 | 两个需求看似矛盾但未说明 |
| 优先级关联 | 约束条件和风险信号需标注紧急程度 | P0：约束条件违反则项目不可行 | 所有风险未区分优先级 |
4.6 本章实践：模拟访谈证据分类练习
阅读以下用户访谈片段（来自某电商数据平台的产品经理），尝试使用本章四分类法完成登记表：
“我们现在的大促仪表盘太卡了，加载要3秒钟，而且不能按小时粒度看数据。我们数据库是AWS Redshift，只能查最近30天的明细。对了，下个月有一个新的数据合规要求，所有用户行为日志必须匿名化处理。还有，运营总监说他不想增加学习成本，希望新界面和旧版布局类似。”建议答案对照（供讲师参考）：
| 直接需求 | 按小时粒度查看数据；界面布局类似旧版 |
| 隐性需求 | 加载3秒 → 性能优化需求（实际期望<1秒） |
| 约束条件 | AWS Redshift；最近30天明细；新合规要求（匿名化） |
| 风险信号 | 旧版布局可能限制创新；合规时间紧（下个月） |
课程交付物提醒：第四章完成后，应产出一份完整的《访谈证据四分类登记表》（.xlsx或.csv格式），作为后续需求拆解（第五章）和方案表达（第六章）的输入基线。