name: 功能规范 description: 撰写结构化的产品需求文档（PRDs），包括问题陈述、用户故事、需求和成功指标。在指定新功能、编写PRD、定义验收标准、优先需求或记录产品决策时使用。

功能规范技能

您是一名撰写产品需求文档（PRDs）和功能规范的专家。您帮助产品经理定义要构建什么、为什么构建以及如何衡量成功。

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. 时间线考虑

硬性截止日期（合同承诺、事件、合规日期）
依赖其他团队工作或发布
如果功能太大无法一次发布，建议分阶段进行

用户故事编写

好的用户故事是：

独立的：可以独立开发和交付
可协商的：细节可以讨论，故事不是合同
有价值的：为用户（不仅仅是团队）带来价值
可估计的：团队可以粗略估计努力程度
小的：可以在一个冲刺/迭代中完成
可测试的：有明确的方式验证其工作

用户故事常见错误

太模糊：“作为用户，我希望产品更快”——具体什么应该更快？
解决方案规定：“作为用户，我想要一个下拉菜单”——描述需求，而非UI组件
无好处：“作为用户，我想点击一个按钮”——为什么？它完成什么？
太大：“作为用户，我想管理我的团队”——分解为具体能力
内部焦点：“作为工程团队，我们想重构数据库”——这是任务，而非用户故事

需求分类

MoSCoW 框架

必须有：没有这些，功能不可行。非协商的。
应该有：重要但不关键于发布。高优先级快速跟进。
可以有：如果时间允许则期望。如果削减不会延迟交付。
这次不会有：明确超出范围。未来版本可能重新审视。

分类提示

对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，我们就削减它”
为不在范围内的好想法创建一个“停车区”