第4章 收集候选功能清单：来源渠道、去重规则、初始描述模板

适用场景

• 团队已完成目标用户画像与核心场景定义（第3章），需要从多个渠道系统收集功能候选。
• 产品经理希望确保功能清单完整、无重复、描述一致，避免在 RICE 评分阶段因功能定义模糊导致评分偏差或团队争议。
• 产品处于 0→1 的 MVP 规划窗口，或进入 1→N 的迭代规划周期，需要建立可复用的功能候选池。

前置条件

• 已完成目标用户画像与核心场景定义，并形成书面文档。
• 已确定 MVP 的时间窗口与资源约束（如：3个月 / 5人团队）。
• 已准备功能来源所需的原始数据：用户访谈记录、竞品分析报告、内部脑暴纪要、客服工单汇总等。
• 已指定功能收集的负责人（通常为产品经理），并明确团队各角色的输入职责。

操作步骤

步骤1：从来源渠道收集功能诉求

团队需要从以下四个核心渠道系统化地收集原始功能诉求，确保覆盖用户侧、市场侧、内部侧与反馈侧。每个渠道的产出物应汇总为一份独立的功能诉求列表。

步骤2：应用去重规则合并相同功能

来自不同渠道的功能诉求可能存在名称不同但实际相同、描述详略不一、粒度粗细不均等问题。通过以下三条规则进行系统去重：

步骤3：按初始描述模板格式化每个功能

去重后的每一条功能候选，都必须按照统一的初始描述模板进行格式化，确保信息结构一致，为 RICE 评分提供无歧义的输入。模板字段如下：

以下是一个完整的模板填写示例：

{
  "功能名称": "微信登录",
  "用户故事": "作为新用户，我想通过微信授权快速登录，避免繁琐的注册流程",
  "验收标准": "1. 点击「微信登录」按钮\n2. 跳转至微信授权页面\n3. 授权成功后服务端回传 code\n4. 后端验证并返回 token\n5. 登录成功进入首页",
  "来源编号": "S1-2024-003",
  "优先级标记": "P1"
}

输入输出物

责任边界

记录材料

材料1：候选功能来源追踪表（推荐使用共享表格或数据库）

材料2：功能描述模板（JSON Schema）

{
  "功能名称": "string（必填，简洁唯一）",
  "用户故事": "string（必填，格式：作为…，我想…，以便…）",
  "验收标准": "string（必填，可验证条件，换行分隔）",
  "来源编号": "string（必填，格式：渠道-年月日-序号）",
  "优先级标记": "string（可选，P0/P1/P2）"
}

异常处理

验收标准

• 完整性：候选功能清单中的每条功能都填写了必填字段（功能名称、用户故事、验收标准、来源编号），无遗漏。
• 无重复：经团队交叉审核，清单中不存在名称不同但实际相同的重复功能。
• 来源可追溯：每条功能均可通过来源编号追溯到原始渠道与具体出处（如访谈记录ID、竞品报告页码）。
• 粒度一致：清单中所有功能的颗粒度大致对齐，没有出现功能 A 覆盖整个模块而功能 B 只覆盖一个按钮的极端差异。
• 格式统一：所有功能均按模板格式化，用户故事遵循「作为…，我想…，以便…」结构，验收标准使用编号列表或明确的可验证条件。