📚 课程目录第3章第一步

第一步：识别并列出所有候选功能特性：需求来源汇总、功能描述规范、去重与合并规则

适用场景

产品团队在启动新版本或全新产品时，需要系统化收集初始功能需求。
作为后续RICE评分的输入，确保候选列表完整、无冗余、颗粒度一致。
适用于从0到1的MVP定义阶段，以及存量产品新增模块的需求梳理。

前置条件

已确认产品愿景、目标用户群和核心问题域。
已完成至少一轮用户访谈或竞品研究（可为本步骤的输入）。
确定一位需求汇总负责人（通常由产品经理担任）。

操作步骤

步骤	操作内容	关键输出
1	需求来源汇总：收集来自用户访谈记录、竞品功能列表、客服反馈、内部脑暴、数据分析报告等渠道的所有原始需求。	原始需求清单（非结构化）
2	功能描述规范：将每条原始需求转换为统一格式，包含： • 功能标题（动宾短语） • 用户角色 & 用户目标 • 触发条件 & 操作流程 • 预期结果 & 价值说明	规范化功能描述卡片
3	去重与合并： • 完全重复 → 直接保留一条，标注来源类型 • 描述相近但侧重点不同 → 合并为“大类功能”，拆分原子功能点 • 上下游依赖 → 按流程合并为功能组，保留依赖关系	去重合并后的候选列表
4	输出候选功能特性列表：每项包含功能标题、描述、来源、负责人初步评估（可选：已知依赖、实现成本苗头）	结构化的候选功能登记表

输入输出物

输入物：
• 用户访谈记录 / 录音摘要
• 竞品功能矩阵（至少Top 3竞品）
• 客服工单 / 产品反馈汇总
• 内部创意收集表

输出物：
• 候选功能特性列表（电子表格或文档），字段：序号、功能标题、功能描述、来源、去重状态、初步优先级（可选）。

责任边界

角色	职责	不负责
产品经理	汇总所有需求来源，统一描述，执行去重合并	不做可行性评估，不做RICE评分
交互设计师	在功能描述阶段提供用户目标与流程合理性建议	不决定功能去留
技术代表	识别明显的技术重复或不可行功能，提供早期反馈	不参与描述规范制定

记录材料

候选功能登记表（模板示例）

序号 | 功能标题         | 功能描述                       | 来源     | 去重状态 | 备注
1    | 游客快速注册     | 用户无需手机号，输入昵称和密码即可创建账号 | 用户访谈 | 唯一     | 
2    | 手机号注册       | 输入手机号、验证码、密码完成注册          | 竞品分析 | 唯一     | 
3    | 忘记密码重置     | 通过手机验证码重置登录密码             | 内部创意 | 唯一     | 依赖手机号注册
4    | 第三方登录(微信)  | 使用微信账号一键登录               | 用户访谈 | 合并微信/QQ | 统一归入“第三方登录”

异常处理

需求来源冲突（同一功能不同描述）：以用户访谈或数据验证过的描述为准。
描述粒度不统一：将过细的原子功能合并为“最小可测试功能”，将过粗的宏功能拆分为当前版本能独立交付的子项。
来源过多难以审核：设置来源权重（用户访谈 > 数据分析 > 竞品 > 内部），优先处理高权重来源。

验收标准

候选列表中的每一条功能都具备完整的描述（标题 + 目标 + 触发 + 预期结果）。
列表中不存在两条完全重复的功能（同一描述不同来源视为重复，已合并）。
同一用户场景下的上下游功能已标注依赖关系。
所有已知需求来源（至少列出的来源类别）均已覆盖，无明显遗漏。
列表呈现形式满足下一章RICE评分的读取要求（有唯一标识、描述可评分）。

流程全景图

提示：下图展示了从原始需求到候选特性列表的完整识别与清洗路径，请在执行本章步骤时对照此图确认关键节点。

常见坑点：
• 忽略数据来源的一致性，导致同一功能在不同来源描述差异极大，后续RICE评分无法对齐。
• 颗粒度不匹配：将“用户登录”拆出10个子需求，而“订单退款”只写一条，导致评分失衡。
• 漏掉隐性依赖（如支付功能依赖第三方接口开通），应在描述中明确前置条件。