第2章：需求获取方法选择——适用场景与决策模型

需求获取是项目实战的起点。选错方法会导致信息失真、进度延误，甚至验收阶段频繁返工。本章提供一套基于项目环境和信息类型的决策框架，帮助你在用户访谈、问卷、观察、文档分析之间做出精准选择。

2.1 用户访谈

适用场景

• 需要探索用户深层动机、痛点和未表达的需求
• 项目初期的需求发现阶段，信息缺口大
• 目标用户群体较小（少于30人），且可获取高价值反馈
• 需求复杂、上下文依赖性强，需要追问与澄清

前置条件

• 已识别关键利益相关者和用户代表
• 准备好访谈提纲（非结构化或半结构化）
• 预约时间并确保单人/小组环境不受干扰

操作步骤

1. 编制访谈指南：列出开放性问题（5W1H），每个问题附带2~3个追踪提示。
2. 预演校准：内部角色扮演，调整提问语气与时长。
3. 执行访谈：记录、录音（需知情同意），保持中立，避免引导性提问。
4. 整理与编码：24小时内转录，标记关键引述和潜在需求点。

输入输出物

角色	输入物	输出物
需求分析师	利益相关者清单、访谈指南	访谈记录（逐字稿）、需求初步清单
产品经理	业务背景文档	确认后的用户故事地图（初步）

责任边界

• 需求分析师：掌控访谈节奏，确保不偏离主题；记录客观事实，不带入自身假设。
• 用户/客户：提供真实业务视角，不承诺不现实的功能。

记录材料

【用户访谈日志示例】
日期：2025-03-12
受访者角色：销售主管
核心发现：手动填写报销单导致每月浪费6个工作小时
引用原文：“我最烦的就是月底加班填单子，系统如果能自动匹配差旅记录就好很多”
初步需求编号：FR-INT-007

异常处理

• 受访者回避关键问题：换一种情景假设提问，或多次追问。
• 访谈偏离主题：温和回拉，例如“刚才您提到的这一点很有意思，我们回到核心流程再确认一下。”
• 记录缺失：24小时内补记，或安排第二人旁听备份。

验收标准

• 每场访谈产出至少3条明确的需求陈述（以“用户需要/希望/必须……”开头）。
• 访谈记录中矛盾点不超过2处，且已标记待澄清。
• 所有关键用户角色至少覆盖80%。

2.2 问卷

适用场景

• 需要量化验证假设，或收集大量标准化反馈
• 用户群体分布广、地理分散（如不同分公司）
• 需求已初步定义，需要排序或优先级的定量依据

前置条件

• 已通过访谈或文档分析获得初步需求维度
• 设计好量表和封闭/半开放问题
• 确定采样方法和样本量（至少30份有效回收）

操作步骤

1. 问题设计：每个问题聚焦一个变量，避免双管问题（例如“系统是否稳定且易用？”应拆解为两个问题）。
2. 预测试：5~8人试答，检查逻辑跳转、歧义和完成时长。
3. 投放与回收：利用企业邮件、内部平台集中投放，跟踪回收率。
4. 数据清洗与分布分析：剔除无效答卷，计算均值和分布，识别异常值。

输入输出物

角色	输入物	输出物
需求分析师	需求维度清单、问卷草稿	数据汇总表、频次分布图
数据分析师	回收数据	相关性分析和优先级排序

责任边界

• 需求分析师：确保问卷不暗示特定答案，选项互斥且穷尽。
• 项目发起人：提供分发渠道，确保样本覆盖关键部门。

记录材料

【问卷题项示例（未格式化）】
Q3: 当前报销流程中，最大的痛点是什么？（单选）
1. 手动填写耗时
2. 审批环节过多
3. 与财务系统数据不对接
4. 其他__________

异常处理

• 回收率低于30%：发送两轮邮件提醒，或增加抽样奖励。
• 大量异常值：回访样本，确认是否因理解偏差导致。
• 逻辑跳转错位：在预测试阶段拦截，重新编写题之间依赖关系。

验收标准

• 有效样本量≥30，回收率≥40%
• 数据无缺失关键字段，异常值已被标注
• 至少80%的问题信度Cronbach's α ≥ 0.7

2.3 观察

适用场景

• 用户描述的行为与实际操作往往不一致（如“我每天都会备份”实际从未备份）
• 物理环境或操作流程中有隐蔽细节（如噪声、动作次序）
• 需要采集客观数据，不能依赖用户回忆

前置条件

• 获得被观察者同意，并签署知情协议
• 确定观察角色：完全参与者 vs 完全观察者
• 准备非结构化记录表格或录像设备

操作步骤

1. 划定观察边界：明确观察的场所、时段和关键活动。
2. 建立信任期：先花15分钟在场适应，减少霍桑效应。
3. 记录客观事实：只写动作和事件，不写推断。例如“用户点击保存按钮两次，等待10秒后出现错误提示”，而不是“用户不耐烦”。
4. 事后跟进：针对异常动作进行5分钟简短访谈，验证原因。

输入输出物

角色	输入物	输出物
需求分析师	观察角色说明、记录表	全程时序日志
用户体验研究员	用户任务清单	痛点和中断点标记

责任边界

• 观察者：绝不干扰用户操作流程；若用户主动询问，回答“按您平时的方式做就好”。
• 被观察者：无需刻意加速或放慢，保持正常节奏。

记录材料

【观察日志片段】
14:23:15  用户输入订单号，按回车 → 页面加载8秒 → 用户皱眉查看时间
14:23:23  页面显示“无匹配记录” → 用户再次输入，这次加了前缀字母
14:23:35  系统显示正确订单 → 用户长呼一口气，继续操作
——备注：搜索框中没有输入格式提示，用户第一次使用未知格式

异常处理

• 被观察者明显紧张或表演：暂停记录，闲谈放松；或改用远程屏幕录制+事后访谈。
• 观察期间系统故障：记录故障时间和表现，另安排补观察。
• 发现违法或违规操作：现场不干预，只记录；事后按公司规范报告，不披露到需求文档。

验收标准

• 每位用户至少完成3个完整任务流程的观察
• 日志中“推断性描述”占比低于10%
• 发现至少2个用户未主动报告的操作障碍点

2.4 文档分析

适用场景

• 已有系统或旧版系统有大量历史文档（SRS、用户手册、FAQ）
• 需要获取业务规则、流程规范或法律法规约束
• 无法直接接触用户，或用户群体已经消失（如遗留系统升级）

前置条件

• 获取或定位到相关文档仓储（内部Wiki、标书、测试报告）
• 确认文档版本未被废弃或覆盖
• 整理文档索引表，标记优先级

操作步骤

1. 文档分类：按类型：需求文档 / 设计文档 / 测试用例 / 问题报告 / 合同与SLA。
2. 快速扫描与标记：先读目录和摘要，标记关键章节。
3. 逐章节提取需求：每读到一个功能描述或约束条件，记录原文 + 出处。
4. 存量分析：计算需求变更次数、废弃需求占比，评估文档可信度。

输入输出物

角色	输入物	输出物
需求分析师	文档集合、文档索引表	需求提取清单、可信度评分
技术负责人	历史架构说明书	兼容性约束清单

责任边界

• 需求分析师：区分“描述性内容”与“实际需求”，避免把设计细节误作需求。
• 文档提供方：确保提供的文档是最新获批版本，并标注失效章节。

记录材料

【需求提取卡片示例】
来源：SRS-v2.3_财务模块.pdf  第4节
原文：“系统应支持至少10个并发审批节点”
提取需求：FR-DOC-023  并发审批容量≥10  可信度：高（已通过性能测试报告验证）

异常处理

• 文档版本冲突：以最新修订日期为准，并在输出物中注明冲突点和仲裁依据。
• 文档缺失核心部分：标记为“待补充”，转用访谈或观察补全。
• 文档描述与实际系统不符：记录偏差，提示团队在后续测试中重点验证。

验收标准

• 每份核心文档提取需求数≥5条，且与项目目标直接相关
• 可信度为“高”的需求占比≥40%
• 所有异常版本冲突已记录并保留原始出处