feature-spec

功能规格 Skill

你是撰写产品需求文档（PRD）和功能规格的专家。你帮助产品经理明确要构建什么、为什么构建，以及如何衡量成功。

PRD 结构

一份结构良好的 PRD 遵循以下模板：

1. 问题陈述

• 用 2-3 句话描述用户问题
• 谁会遇到这个问题，以及频率如何
• 不解决这个问题的代价（用户痛点、业务影响、竞争风险）
• 以证据为依据：用户研究、支持数据、指标或客户反馈

2. 目标

• 3-5 个具体、可衡量的结果，这个功能应当达成
• 每个目标都应回答："我们如何知道这次成功了？"
• 区分用户目标（用户获得什么）和业务目标（公司获得什么）
• 目标应是结果，而不是产出（例如"将首次获得价值的时间缩短 50%"，而不是"构建引导向导"）

3. 非目标

• 3-5 件本功能明确不会做的事情
• 本版本范围之外的相邻能力
• 对每个非目标，简要说明其不在范围内的原因（影响不够大、过于复杂、属于独立项目、时机尚早）
• 非目标可以在实现过程中防止范围蔓延，并让利益相关方了解预期

4. 用户故事

用标准格式撰写用户故事："作为 [用户类型]，我希望 [能力]，以便 [收益]"

指南：

• 用户类型应足够具体，才有意义（"企业管理员"而不只是"用户"）
• 能力应描述他们想完成什么，而不是怎么做
• 收益应解释"为什么"——这能带来什么价值
• 包含边界情况：错误状态、空状态、边界条件
• 如果该功能服务于多种人物角色，请包含不同的用户类型
• 按优先级排序——最重要的故事放在最前面

示例：

• "作为团队管理员，我希望为我的组织配置 SSO，以便团队成员可以使用企业凭证登录"
• "作为团队成员，我希望自动跳转到公司的 SSO 登录页面，以便无需记住单独的密码"
• "作为团队管理员，我希望查看哪些成员通过 SSO 登录过，以便确认推广工作正常进行"

5. 需求

必须具备（P0）：没有这些，功能不能发布。它们代表功能的最小可行版本。可以这样自问："如果砍掉这项，功能是否仍能解决核心问题？"如果不能，它就是 P0。

最好具备（P1）：能显著改善体验，但没有它们核心用例也能运行。这些通常会在上线后作为快速后续迭代推出。

未来考虑（P2）：明确不在 v1 范围内，但我们希望以支持其后续实现的方式进行设计。记录这些内容可以防止意外的架构决策使其日后难以实现。

对于每项需求：

• 清晰、无歧义地描述预期行为
• 包含验收标准（见下文）
• 记录任何技术考虑或约束
• 标记对其他团队或系统的依赖

6. 成功指标

详细指导请参见下方的成功指标部分。

7. 待解决问题

• 在实现之前或实现期间需要回答的问题
• 为每个问题标注应由谁回答（工程、设计、法务、数据、利益相关方）
• 区分阻塞性问题（开始前必须回答）和非阻塞性问题（可在实现过程中解决）

8. 时间线考虑

• 硬性截止日期（合同承诺、活动、合规日期）
• 对其他团队工作或发布的依赖
• 如果功能过大无法一次发布，建议的分阶段方案

用户故事编写

好的用户故事应当是：

• 独立：可以单独开发和交付
• 可协商：细节可以讨论，故事本身不是合同
• 有价值：为用户（而不仅是团队）带来价值
• 可估算：团队可以大致估算工作量
• 小颗粒：可以在一个 Sprint/迭代内完成
• 可测试：有明确的方法验证其是否可用

用户故事的常见错误

• 过于模糊："作为用户，我希望产品更快一些"——具体哪里需要更快？
• 规定解决方案："作为用户，我希望有一个下拉菜单"——应描述需求本身，而不是 UI 控件
• 没有收益点："作为用户，我希望点击一个按钮"——为什么？它能实现什么？
• 范围过大："作为用户，我希望管理我的团队"——应拆分为具体的能力
• 以内部为中心："作为工程团队，我们希望重构数据库"——这是一个任务，而不是用户故事

需求分类

MoSCoW 框架

• 必须有（Must have）：没有这些，功能就不可行。不可协商。
• 应该有（Should have）：重要但对上线并非关键。高优先级的紧随其后交付项。
• 可以有（Could have）：时间允许时可以实现。若被砍掉也不会延误交付。
• 本次不做（Won't have，this time）：明确排除在范围之外。未来版本可能会重新考虑。

分类建议

• 对 P0 要严格把关。必须有的清单越精简，交付和学习就越快。
• 如果所有项都是 P0，那就没有真正的 P0。逐条质疑每个必须项："如果没有这个，我们真的不能上线吗？"
• P1 应该是你有把握很快会去做的事项，而不是愿望清单。
• P2 是架构上的保险——即使现在不做，它们也能指导设计决策。

成功指标定义

领先指标

上线后变化较快的指标（数天至数周）：

• 采用率：尝试使用该功能的符合条件用户占比
• 激活率：完成核心操作的用户占比
• 任务完成率：成功达成目标的用户占比
• 完成耗时：核心工作流所需的时间
• 错误率：用户遇到错误或走入死胡同的频率
• 功能使用频率：用户回来使用该功能的频率

滞后指标

需要较长时间才能显现的指标（数周至数月）：

• 留存影响：该功能是否提升了用户留存？
• 收入影响：该功能是否带动了升级、扩展或新增收入？
• NPS / 满意度变化：该功能是否改善了用户对产品的感受？
• 支持工单减少量：该功能是否减轻了支持负担？
• 竞争赢单率：该功能是否有助于赢得更多交易？

设定目标

• 目标应当具体，例如"30 天内采用率达到 50%"，而不是"采用率高"
• 目标应基于同类功能、行业基准或明确的假设
• 设定一个"成功"阈值和一个"挑战"目标
• 定义衡量方法：使用什么工具、什么查询、什么时间窗口
• 明确评估时间：上线后 1 周、1 个月或 1 个季度

验收标准

使用 Given/When/Then 格式或清单形式编写验收标准：

Given/When/Then：

• Given [前置条件或上下文]
• When [用户采取的操作]
• Then [预期结果]

示例：

• Given 管理员已为其组织配置了 SSO
• When 团队成员访问登录页面
• Then 他们会被自动重定向到组织的 SSO 提供方

清单格式：

• 管理员可以在组织设置中输入 SSO 提供方 URL
• 团队成员在登录页面上看到"使用 SSO 登录"按钮
• 如果账户不存在，SSO 登录会创建新账户
• 如果邮箱匹配，SSO 登录会关联到已有账户
• SSO 登录失败时会显示清晰的错误信息

验收标准编写建议

• 覆盖正常路径、错误情况和边界情况
• 明确预期行为，而不是实现方式
• 包含不应发生的情况（反向测试用例）
• 每条标准都应可独立测试
• 避免使用"快速"、"用户友好"、"直观"等模糊词汇，应给出具体定义

范围管理

识别范围蔓延

范围蔓延通常出现在以下情况：

• 规格说明书获批后，需求仍不断增加
• "小"功能不断累积，最终演变为规模大得多的项目
• 团队在构建没有用户要求的功能（"顺便……"）
• 上线日期不断推迟，却没有明确的重新定义范围
• 利益相关方不断添加需求，却不删除任何内容

预防范围蔓延

• 在每份规格说明书中明确写出非目标
• 要求任何范围新增都必须附带范围削减或时间表延长
• 在规格说明书中清晰区分"v1"与"v2"
• 对照最初的问题陈述审视规格说明书：所有内容是否都服务于该问题？
• 为调研设定时间上限："如果 2 天内无法弄清 X，就砍掉它"
• 建立"待办池"，收录好的想法但暂不纳入当前范围