📚 课程目录第1章需求描述获取

第1章：需求描述获取

本章定位：需求链条的起点。没有可靠的原始输入，后续的RICE评分就是空中楼阁。本章聚焦“如何把散落的用户声音、业务痛点、市场信号转化为结构化需求描述”。

1.1 适用场景

新产品立项、功能模块新增或迭代优化
跨部门协作时需统一需求入口格式
外部客户/用户反馈首次进入内部需求池
任何计划启动RICE评分前的原始信息收集阶段

1.2 前置条件

条件	说明
需求来源通道	已建立至少一种原始需求提交渠道（邮件、工单、系统表单等）
关键干系人列表	初步识别项目发起方、最终用户、技术实现方、业务决策方四类角色
采集工具就绪	访谈提纲、问卷模板、观察记录表（纸质或电子版）
记录模板预置	使用组织统一的需求捕获模板（见本章记录材料）

1.3 操作步骤

接收原始需求：从工单、邮件、会议纪要、竞品报告等渠道归集第一手描述。
利益相关方识别：绘制干系人地图，标记“提出者”“受益者”“受影响者”“决策者”。
选择采集方法：根据需求类型、用户群体、紧急程度决定用访谈、问卷还是观察法。
执行采集：按选定方法实施，记录原话、场景、频次、痛点。
填写记录模板：将原始信息结构化填入统一模板，生成需求描述文档。

1.4 输入输出物

输入	输出
原始需求碎片（口语、邮件、截图等）	结构化需求描述文档（含编号、来源、干系人、场景描述）
干系人通讯录	利益相关方清单及分类矩阵
采集道具（录音笔、问卷链接、观察表）	原始记录文件（访谈笔记/问卷统计/观察日志）

1.5 责任边界

需求分析师/产品经理：主导访谈、问卷设计、观察执行、模板填写。
业务方/客户：原话提供、场景澄清、需求优先级初判。
技术代表：参与早期识别可行性限制，但不过早介入方案讨论。
项目经理：确保需求进入正式流程前已有唯一ID和干系人确认。

1.6 记录材料

需求描述记录模板（标准字段）

需求编号：REQ-YYMMDD-001
来源渠道：客户邮件 / 用户访谈 / 内部提案 / 竞品分析
提出者：【姓名+角色】
利益相关方（按类型）：
  - 提出者/发起人：xxx
  - 最终用户：xxx
  - 决策者：xxx
  - 受影响方：xxx
需求标题：【一句话描述】
场景描述：【用户、环境、目标、行动、结果】
频次与量级：每天N次 / 影响N用户 / 月N单
当前痛点：无绕行方式 / 耗时N分钟 / 错误率N%
期望效果：【可衡量的目标】
附件清单：截屏_xx.png / 访谈录音_xx.mp3 / 原始邮件.eml
状态：待评审 / 采集中 / 已完成采集
采集日期：YYYY-MM-DD
采集人：【姓名】

1.7 异常处理

异常场景	处理措施
利益相关方拒绝受访	升级至项目经理协调，或用匿名问卷替代；如仍不可获取，在模板中标记“干系人缺失”
原始需求描述模糊矛盾	回访提出者，使用5W1H追问法；记录原话分歧点，不得主观篡改
采集工具无响应（问卷系统崩溃）	切换至离线Excel/纸笔采集，事后补登系统
观察法受环境影响无法高频记录	改用屏幕录制+事后回溯，或缩短单次观察时长为15分钟切片

1.8 验收标准

每个需求记录模板必填字段完整率 100%
利益相关方分类至少识别3种角色且可追溯
采集方法选择理由在模板备注中说明
原始记录（访谈笔记/问卷PDF/观察日志）与模板一同归档
无歧义：需求描述可由第三方独立阅读后复述出80%以上核心信息

  关键检查点：在填写模板前，请确认“利益相关方”一栏是否包含决策者。缺少决策者的需求描述在RICE评分时无法获得资源承诺。

常见陷阱：不要将“解决方案”或“技术实现方式”写入需求描述。例如：“增加一个导出按钮”是不合格的，应改为“用户需要将当前页面的筛选结果批量存档，每周约50次操作”。