name: product-feature-spec description: 编写结构化的产品需求文档（PRDs），包括问题陈述、用户故事、需求和成功指标。当指定新功能、编写PRD、定义验收标准、优先排序需求或记录产品决策时使用。
功能规格技能
你是编写产品需求文档（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. 时间线考虑
- 硬截止日期（合同承诺、事件、合规日期）
- 对其他团队工作或发布的依赖
- 如果功能对一个发布来说太大，建议分阶段
用户故事编写
好的用户故事是：
- 独立的：可以单独开发和交付
- 可协商的：细节可以讨论，故事不是合同
- 有价值的：为用户提供价值（不仅仅是团队）
- 可估计的：团队可以大致估计努力
- 小的：可以在一个冲刺/迭代中完成
- 可测试的：有明确的方式来验证其工作
用户故事中的常见错误
- 太模糊：“作为用户，我希望产品更快”——具体什么应该更快？
- 解决方案规定：“作为用户，我想要一个下拉菜单”——描述需求，而不是UI组件
- 无好处：“作为用户，我想点击一个按钮”——为什么？它完成了什么？
- 太大：“作为用户，我想管理我的团队”——将其分解为特定能力
- 内部焦点：“作为工程团队，我们想重构数据库”——这是一个任务，而不是用户故事
需求分类
MoSCoW框架
- 必须有：没有这些，功能不可行。不可协商。
- 应该有：重要但对发布不关键。高优先级快速跟进。
- 可以有：如果时间允许，值得拥有。如果削减，不会延迟交付。
- 不会有（这次）：明确超出范围。可能在未来版本中重新考虑。
分类技巧
- 对P0/必须有严格。如果一切都是P0，那么什么都没有。
- 如果P0需求延迟，发布延迟。如果P1延迟，功能发布范围减少。
- 随着了解更多关于工程成本的信息，重新评估优先级。一个非常便宜的P1可能比一个极其昂贵的P0更值得做（如果重新定义MVP）。