Requirements Elicitation

需求访谈技能

目的

此技能可帮助 AI 助手开展专业的需求访谈，运用行业标准技术，从各种项目类型（Web、移动端、ERP、CRM、CDP、电商）的利益相关方处收集全面的业务需求。

何时使用此技能

• 启动新项目或功能开发
• 开展需求探索或项目启动阶段的工作
• 收集系统增强需求
• 了解业务问题和机遇
• 准备 BRD/FRS 文档

核心需求访谈技术

1. 利益相关方访谈

最适合：深入了解个人观点、敏感话题和高管意见

方法：

• 准备：研究利益相关方的背景、角色和痛点
• 结构：采用半结构化形式（准备问题，同时保持灵活）
• 时长：每次访谈 45-60 分钟
• 提问框架：使用 5W1H（Who、What、When、Where、Why、How）

问题类型：

• 开放式：“能否为我讲解一下你们目前处理……的流程？”
• 探究式：“这对你的团队为什么很重要？”
• 澄清式：“你说的‘实时’具体是指多长时间？”
• 假设式：“如果你可以改变当前系统中的一件事，你会改什么？”

STAR 技巧（用于了解流程）：

• 情境：“请描述一下你……时的典型情境。”
• 任务：“你想要完成什么？”
• 行动：“你会采取哪些步骤？”
• 结果：“结果如何？有哪些可以改进的地方？”

2. 需求研讨会

最适合：跨职能协同、头脑风暴和达成共识

方法：

• 参与者：来自不同部门的 6-12 位利益相关方
• 时长：2-4 小时
• 引导方式：使用可视化辅助工具（白板、Figma、Miro）
• 技术：
  • 头脑风暴会议
  • 亲和图整理（将相似想法分组）
  • 点投票（确定优先级）
  • 流程演练

研讨会议程模板：

1. 介绍与目标（10 分钟）
2. 回顾现状（30 分钟）
3. 识别痛点（30 分钟）
4. 描绘未来状态愿景（45 分钟）
5. 需求头脑风暴（45 分钟）
6. 优先级排序练习（30 分钟）
7. 后续步骤与行动项（10 分钟）

3. 文档分析

最适合：了解现有系统、合规要求和历史背景

要审阅的文档：

• 现有系统文档
• 业务流程手册
• 用户指南和培训材料
• 合规与监管文档
• 分析报告和仪表板
• 支持工单和 Bug 报告
• 竞争分析报告

分析方法：

• 找出文档记录的流程与实际流程之间的差距
• 提取业务规则和约束
• 了解数据结构和关系
• 记录假设和依赖关系

4. 观察与跟岗

最适合：了解实际工作流，识别未记录的流程

方法：

• 在用户的工作环境中跟岗观察
• 观察时不要打断工作（做好笔记）
• 记录变通方法和痛点
• 随后提出澄清问题
• 记录“现状”流程

关注领域：

• 任务频率
• 各项活动所花费的时间
• 使用的工具和系统
• 团队之间的交接
• 容易出错的步骤

5. 调查与问卷

最适合：收集大量用户的意见和定量数据

最佳实践：

• 问卷要简短（最多 10-15 个问题）
• 混合使用不同类型的问题（单选题、评分量表、开放式问题）
• 适当时确保匿名
• 明确回复截止日期
• 分析并分享结果

问题示例：

• 评分：“请按 1-5 分打分，你对当前结账流程有多满意？”
• 单选：“你最常使用哪些付款方式？”
• 开放式：“处理订单时，你面临的最大挑战是什么？”

6. 原型设计与模拟稿

最适合：验证 UI/UX 需求、视觉需求

方法：

• 创建低保真线框图（Figma、草图）
• 展示给利益相关者以收集反馈
• 根据反馈进行迭代
• 使用可点击原型进行用户测试
• 记录反馈和需求

需求分类

功能需求

定义：系统应该执行的操作

按领域划分的示例：

• 电子商务：“系统应允许用户将商品添加到购物车”，“系统应根据目的地计算运费”
• ERP：“系统应根据已批准的请购单生成采购订单”，“系统应支持多币种交易”
• CRM：“系统应跟踪潜在客户来源和转化率”，“系统应自动发送后续跟进邮件”
• CDP：“系统应整合来自 Web、移动端和 CRM 的客户数据”，“系统应根据行为创建受众细分”
• 移动端/Web：“应用应支持离线使用，并在联网后同步”，“网站加载时间应少于 3 秒”

非功能需求

类别：

• 性能：响应时间、吞吐量、可扩展性
• 安全性：身份验证、授权、数据加密
• 易用性：用户体验、无障碍访问（符合 WCAG）
• 可靠性：正常运行时间、错误处理、灾难恢复
• 兼容性：浏览器支持、设备支持、集成
• 合规性：GDPR、CCPA、SOX、行业法规

示例：

• “系统应支持 10,000 个并发用户”
• “所有敏感数据在静态存储和传输过程中都应加密”
• “系统应达到 99.9% 的正常运行时间”
• “移动应用应支持 iOS 15+ 和 Android 12+”

约束

类型：

• 技术约束：必须使用现有基础设施、特定技术栈
• 业务约束：预算限制、时间安排限制
• 监管约束：必须遵守特定法规
• 组织约束：必须与现有系统集成

领域特定考量

电子商务项目

需要探索的关键领域：

• 商品目录管理（变体、属性、库存）
• 购物车和结账流程
• 支付网关集成与安全
• 订单管理与履约
• 客户账户和个人资料
• 促销和折扣规则
• 搜索和筛选功能
• 商品推荐
• 多渠道销售（Web、移动端、市场平台）

关键问题：

• “如何管理多个仓库的库存？”
• “必须支持哪些支付方式？”
• “应如何处理被遗弃的购物车？”
• “退货和退款流程是什么？”

ERP 项目

需要探索的关键领域：

• 模块范围（财务、人力资源、供应链、制造等）
• 主数据管理策略
• 模块间工作流和集成
• 审批层级和工作流
• 报告和分析需求
• 多公司/多币种需求
• 基于角色的访问控制
• 合规要求

关键问题：

• “采购订单需要哪些审批级别？”
• “如何处理公司间交易？”
• “合规要求哪些财务报表？”
• “员工数据应如何构建？”

CRM 项目

需要探索的关键领域：

• 潜在客户获取和资格认定流程
• 销售管道阶段和标准
• 联系人和账户层级结构
• 营销活动管理
• 客户服务工单
• 与电子邮件、电话和营销工具的集成
• 销售预测方法
• 报告和仪表板

关键问题：

• “什么样的潜在客户才算合格？”
• “从潜在客户到成交的销售流程是什么？”
• “如何衡量客户满意度？”
• “需要与现有工具进行哪些集成？”

CDP 项目

重点探索领域：

• 数据源（Web、移动端、CRM、电商、线下）
• 客户身份解析策略
• 数据治理与隐私合规
• 客户细分与受众构建
• 实时处理与批处理
• 数据激活渠道
• 分析与报告需求
• 与营销工具集成

关键问题：

• “如何识别跨渠道的同一客户？”
• “哪些客户属性最重要？”
• “哪些营销渠道会使用这些数据？”
• “如何处理同意管理？”

移动端/Web 项目

重点探索领域：

• 平台要求（iOS、Android、Web、PWA）
• 响应式设计需求
• 离线功能要求
• 性能预期
• 推送通知策略
• 深度链接与应用导航
• 身份验证与安全
• 应用商店要求
• 分析与跟踪

关键问题：

• “哪些功能必须支持离线使用？”
• “必须支持哪些设备和 OS 版本？”
• “用户将如何进行身份验证？”
• “需要跟踪哪些分析事件？”

需求获取最佳实践

1. 充分准备

• 研究业务领域
• 审阅现有文档
• 提前准备问题
• 确定合适的利益相关者
• 安排充足的时间

2. 积极倾听

• 不要打断对方
• 详细记录
• 提出澄清性问题
• 复述以确认理解
• 留意非语言信号

3. 提出恰当的问题

• 先从宏观问题入手，再逐步深入
• 使用开放式问题
• 避免诱导性问题
• 对假设提出质疑
• 多次追问“为什么”（5 Why 技术）

4. 立即记录

• 实时记录需求
• 使用模板以保持一致
• 记录决策及其理由
• 记录假设和依赖项
• 分享笔记以供确认

5. 验证并确认

• 与利益相关者审阅需求
• 检查需求是否完整、清晰
• 解决冲突和歧义
• 获取正式签字确认
• 保持可追溯性

6. 处理冲突

• 承认不同观点
• 聚焦业务目标
• 用数据支持决策
• 必要时升级处理
• 记录权衡取舍

应避免的常见陷阱

❌ 想当然地认为自己了解该领域 - 始终核实自己的理解
❌ 接受含糊的需求 - 坚持要求明确、可衡量
❌ 跳过非功能性需求 - 这些对成功至关重要
❌ 忽视边缘情况 - 提出“如果……会怎样”的问题
❌ 不记录假设 - 将隐性知识明确记录下来
❌ 说得多、听得少 - 遵循 80/20 规则：倾听占 80%，发言占 20%
❌ 直接跳到解决方案 - 先理解问题
❌ 不验证需求 - 始终确认理解是否正确

混合方法论工具

Lark

• 使用 Docs 记录访谈笔记和需求文档
• 使用 Base 跟踪需求并保持可追溯性
• 使用 Meetings 录制会议
• 使用 Tasks 管理行动项

Notion

• 创建带有属性（优先级、状态、负责人）的需求数据库
• 使用模板以保持一致
• 将需求关联到用户故事和测试用例
• 创建利益相关者目录

Figma

• 在需求获取过程中创建线框图和模型
• 使用 FigJam 进行工作坊协作
• 为用户流程制作原型以便验证
• 分享设计以征求反馈

交付物

完成需求获取后，应产出：

1. 需求登记册：所有需求的完整列表
2. 访谈笔记：利益相关者会议的详细记录
3. 工作坊成果：图表、优先级排序结果和决策
4. 流程图：当前状态和未来状态的流程
5. 假设日志：已记录的假设和约束
6. 利益相关者矩阵：各项需求由谁提出
7. 待解决问题列表：需要后续跟进的事项

后续步骤

完成需求获取后：

1. 整理并分类需求
2. 使用 MoSCoW 或 RICE 确定优先级（参见 requirements-prioritization 技能）
3. 与利益相关者验证需求
4. 创建 BRD（参见 brd-creation 技能）
5. 制定详细的 FRS（参见 frs-creation 技能）

参考资料

• BABOK® Guide（业务分析知识体系）— 需求获取技术
• IIBA Standards — 专业 BA 实践
• Agile Extension to BABOK® Guide — 敏捷环境中的需求获取
• IEEE 29148 — 需求工程标准