第四章 设计样例需求清单：从产品功能列表中筛选待评估需求
1. 适用场景
本章SOP适用于以下三类典型场景：
- KANO问卷筹备期：产品团队已收集到大量功能提议，需要从中筛选出适合放入KANO问卷的待评估需求。
- 功能列表瘦身：原始功能列表超过50项，需压缩至可评估的合理数量（15～25条），同时保证关键功能不被遗漏。
- 需求描述标准化：原始功能描述存在模糊、歧义或技术化表达，需要转换为用户可理解的清晰语言。
💡 提示：本流程适用于任何需要进行KANO调研的产品阶段，不限于全新产品设计，也适用于成熟产品的版本迭代。
2. 前置条件
| 序号 | 条件项 | 验收标准 |
|---|---|---|
| 1 | 原始功能列表已归档 | 列表包含功能名称、简要描述、提出来源，条目≥20项 |
| 2 | 产品目标与评估范围已确认 | 已明确本次KANO调研覆盖的产品模块/版本边界 |
| 3 | 筛选团队已组建 | 至少包含1名产品经理、1名技术代表、1名用研人员 |
| 4 | KANO问卷设计模板已准备 | 掌握正反向问题结构，了解条目数量上限（通常≤25条） |
⚠️ 注意：前置条件不满足时，切勿跳过筛选直接进入问卷设计，否则可能导致KANO分类结果失真。
3. 操作步骤
本章SOP共包含5个步骤，请按顺序执行，每一步完成后标记「✔」方可进入下一步。
步骤1｜原始功能列表清洗与去重
- 动作：合并完全相同的功能项；删除已废弃或明确不进入本次评估范围的功能。
- 产出：清洗后的原始功能列表（去重后）。
- 耗时参考：30～60分钟。
步骤2｜建立筛选标准并逐条评估
使用以下四维筛选矩阵对每一条功能进行评估：
| 维度 | 说明 | 评分（1～5） | 保留阈值 |
|---|---|---|---|
| KANO相关度 | 该功能是否可能归为魅力/期望/必备属性 | 1（低）～5（高） | ≥3 |
| 用户可感知度 | 用户能否在无引导情况下独立理解该功能 | 1（难）～5（易） | ≥3 |
| 与技术可行性 | 当前技术储备是否支持实现 | 1（不可行）～5（可行） | ≥2 |
| 商业价值 | 与产品战略/营收目标的匹配程度 | 1（低）～5（高） | ≥2 |
保留规则：四项评分均不低于对应阈值，且总分≥12分，则进入候选清单。
📌 关键判据：如果一条功能的「KANO相关度」评分为1或2，无论其他维度得分多高，都建议剔除，因为它不适合用KANO模型评估。
步骤3｜需求描述规范化（消除歧义）
- 原则：使用用户语言，避免技术术语；一条需求只描述一个核心功能点。
- 操作：对照原始描述，逐条重写为「谁 + 在什么场景下 + 能做什么 + 达到什么效果」的句式。
正反例对比：
| 类型 | 原始描述（❌） | 规范化描述（✔） |
|---|---|---|
| 技术化 | 支持WebSocket长连接实时推送 | 当订单状态变化时，我能立即收到页面上的实时更新提示 |
| 歧义 | 优化首页加载速度 | 打开App首页后，核心内容在3秒内完全显示 |
| 多重功能 | 增加搜索与筛选功能 | 在商品列表页，我能通过输入关键词搜索商品 |
步骤4｜条目数量控制与优先级排序
- 数量红线：最终需求清单条目数控制在15～25条，超过25条必须再次筛选。
- 排序依据：按步骤2的总分从高到低排列，优先保留高分项。
- 兜底规则：如果高分项不足15条，可从KANO相关度≥4的低分项中补充，但须标注「补充项」。
步骤5｜团队评审与终版确认
- 评审参与人：产品经理、技术代表、用研人员（与前置条件团队一致）。
- 评审内容：逐条朗读规范化描述，确认无歧义；检查数量是否在15～25条区间。
- 终版确认：三人均签字（或会议纪要确认）后，清单冻结。
4. 流程结构图：需求筛选与清单设计全流程
5. 输入输出物
| 类型 | 名称 | 格式/载体 | 责任人 |
|---|---|---|---|
| ↗ 输入 | 原始产品功能列表 | Excel / 飞书表格 / Confluence | 产品经理 |
| ↗ 输入 | 产品评估范围文档 | PRD / 版本规划文档 | 产品经理 |
| ↙ 输出 | 待评估需求清单（终版） | Excel（含评分、规范化描述、排序） | 产品经理 |
| ↙ 输出 | 筛选过程记录表 | Excel（含四维评分明细） | 产品经理 |
📎 输出物模板示例：终版清单表头建议包含「序号｜需求ID｜规范化描述｜KANO相关度｜用户可感知度｜技术可行性｜商业价值｜总分｜是否补充项」。
6. 责任边界
| 角色 | 职责 | 决定权 | 否决权 |
|---|---|---|---|
| 产品经理 | 主导筛选、描述规范化、清单整理 | 评分执行、排序 | — |
| 技术代表 | 评估技术可行性维度 | 技术可行性评分 | 对不可行功能可一票否决 |
| 用研人员 | 评估用户可感知度，检查描述语义清晰性 | 可感知度评分 | 对歧义描述可要求重写 |
⚠️ 边界说明：产品经理无权在未经评审的情况下单方面增加超过25条的条目；任何条目的删除均需记录原因。
7. 记录材料
本章执行过程中需归档以下材料，作为后续KANO问卷设计的追溯依据：
- 材料A｜筛选过程记录表：包含每条功能的四维评分、总分、筛选结论（保留/剔除）及剔除原因。
- 材料B｜描述规范化对照表：原始描述与规范化描述一一对应，方便评审时核对语义是否偏差。
- 材料C｜终版需求清单：经三方签字或会议纪要确认的最终清单，注明版本号和冻结日期。
📌 记录规范：所有材料统一命名格式为「【KANO需求筛选】产品名_版本号_日期_材料类型」，例如：
【KANO需求筛选】心选商城_v2.3_2025-06-15_终版清单.xlsx。
8. 异常处理
| 异常场景 | 触发条件 | 处理方案 |
|---|---|---|
| 条目数量严重超标 | 筛选后仍超过30条 | 按总分排序，强制截断至25条，截断条目移入「备选池」并记录 |
| 描述歧义无法消除 | 团队对某条描述的理解不一致 | 暂停该条评审，由用研人员补充用户用语调研后再评审 |
| KANO相关度评分普遍偏低 | 超过50%的条目相关度≤2 | 重新检视原始功能列表是否适合KANO评估，必要时调整评估范围 |
| 团队评审无法达成一致 | 某条目的保留/删除争议超过15分钟 | 暂时标记为「待定」，收集更多用户反馈后二次评审 |
⚠️ 异常升级路径：若上述处理方案仍无法解决，升级至产品负责人做最终裁定，并记录裁定理由。
9. 验收标准
本章交付物须同时满足以下所有条件，方可视为通过验收：
- 完整性：终版需求清单包含15～25条需求，每条均有规范化描述、四维评分及总分。
- 清晰性：随机抽取3条需求，由一名未参与筛选的团队成员阅读后，能准确复述功能要点。
- 可追溯性：从终版清单的任一条目，均可反向追溯到原始功能列表中的来源项。
- 签字确认：产品经理、技术代表、用研人员三方均已签字或会议纪要确认。
- 文档归档：材料A/B/C均已按命名规范上传至指定知识库，链接可访问。
✅ 验收通过标志：完成上述5项检查并填写《第四章验收检查表》后，由产品负责人签字确认，方可进入第五章「KANO问卷结构设计」。