prd-writing

文档架构

围绕以下核心章节组织每份 PRD。根据项目的复杂程度调整各章节的详细程度。

问题界定

以清晰阐述的问题为整份文档奠定基础：

• 用具体、可观察的方式指出用户面临的痛点
• 量化受此问题影响的人群及问题发生的频率
• 阐明不采取行动的后果：收入损失、用户流失、运营负担或竞争劣势
• 以支持工单、用户访谈、行为数据或市场信号中的证据作为论据依据

预期成果

将问题转化为 3-5 项可衡量的目标：

• 围绕可观察的变化来制定每项成果：行为转变、效率提升、错误减少
• 将面向用户的成果（客户获得哪些改善）与组织层面的成果（业务获得哪些收益）区分开
• 将成果表述为结果，而非交付物：写成“将新手引导时长缩短一半”，而非“重新设计新手引导流程”
• 每项成果都必须回答：“哪些证据能证明我们实现了这一目标？”

范围边界与排除项

记录 3-5 项明确排除的内容，防止范围不断扩大：

• 指明本次迭代不会涉及的相关功能
• 简要说明每项排除内容的理由：数据不足、杠杆作用有限、更适合后续阶段，或属于独立工作流
• 明确排除项有助于在实施期间保护团队，并让利益相关者对预期保持合理认知

用户叙述

按照以下模式记录用户需求：“作为一名[具体角色]，我需要[能力]，因为[根本动机]”

有效叙述指南：

• 角色应足够具体，以便指导设计取舍（例如“账单管理员”，而非“用户”）
• 描述期望的结果，而非界面操作方式
• 动机部分必须说明用户能获得什么价值
• 考虑错误场景、空状态和边界情况
• 涵盖该功能涉及的每一种不同角色
• 按优先级从高到低排列叙述

示例叙述：

• “作为一名账单管理员，我需要按日期范围导出发票历史记录，因为我们的财务团队需要季度对账报告”
• “作为一名新团队成员，我需要查看近期项目活动摘要，因为在项目进行中途加入却不了解背景，会拖慢我的工作进度”

有效用户叙述的特征

使用 INVEST 清单进行检查：

• 独立（Independent）：无需依赖其他叙述即可交付
• 可协商（Negotiable）：实现细节保持灵活
• 有价值（Valuable）：为最终用户带来切实益处
• 可估算（Estimable）：工程团队能够估算大致工作量
• 小型（Small）：可在单次迭代内完成
• 可测试（Testable）：验证标准明确无歧义

用户叙述中应避免的问题

• 含糊不清：“作为一名用户，我希望性能更好”——应指出具体操作和性能阈值
• 指定实现方式：“作为一名用户，我希望有一个模态对话框”——描述需求，而非界面控件
• 缺少动机：“作为一名用户，我希望点击保存”——说明执行此操作的目的
• 范围过大：“作为一名用户，我希望全面管理团队”——将其拆分为具体能力
• 以内部联系为出发点：“作为后端团队，我们希望迁移数据库”——这是技术任务，而非用户叙述

需求层级

优先级分类

关键（P0）：没有这些内容，该计划就不完整。它们是解决所述问题的最低门槛。试金石问题：“如果移除这项内容，核心问题是否仍未解决？”如果是，就应保留为 P0。

重要（P1）：显著提升体验，但没有它们，基本用例仍可正常运行。这些内容很适合作为初始发布后的快速跟进事项。

延期（P2）：有意排除在首个版本之外，但架构应能支持它们。记录这些内容可避免设计决策造成未来障碍。

优先级管理原则

• 严格把控 P0。精简的关键事项集有助于加快学习和交付。
• 如果每项都标为关键，就没有任何一项真正关键。逐项审视 P0：“我们真的会因此推迟发布吗？”
• P1 应代表几乎确定会跟进的事项，而非推测性的愿望。
• P2 作为架构护栏，在不消耗实现精力的情况下影响设计方向。

MoSCoW 视角

另一种分类方式，可自然用于与利益相关方协商：

• 必须具备：没有这些内容，发布就毫无价值。不可妥协。
• 应该具备：用户会期待且十分重要，但没有这些内容，发布仍然可行。
• 可以具备：资源允许时值得添加的内容。省略它们不会延误时间表。
• 本周期不会具备：明确延期的内容。记录下来可消除歧义。

衡量成功

早期信号（发布后数天至数周）

变化迅速、能够反映即时反馈的指标：

• 采用率：符合条件的用户中使用这项新功能的比例
• 激活率：完成预期主要操作的用户比例
• 完成率：实现端到端目标的用户比例
• 耗时：核心工作流所用的时间
• 失败率：错误、流程中断或尝试放弃的发生频率
• 回访频率：用户重新使用该功能的频率

持续信号（发布后数周至数月）

随时间逐渐成熟、反映持久影响的指标：

• 留存率提升：可归因于该功能的用户留存率改善
• 营收贡献：由该功能带来的升级、扩容或新订单
• 满意度变化：NPS、CSAT 或定性反馈的变化
• 支持负担降低：相关支持咨询数量减少
• 赢单率影响：竞争性交易结果的改善

设定目标

• 目标必须精确：应为“前 14 天内采用率达到 60%”，而非“强劲采用”
• 根据类似发布、行业标准或明确提出的假设制定目标
• 同时定义基准预期和进取目标
• 指明测量工具：使用哪个工具、哪条查询、哪个时间范围
• 安排评估检查点：发布后一周、一个月、一个季度

验证标准

使用结构化条件或检查清单来表述验收标准。

结构化条件：

• 假设 [起始状态或前置条件]
• 当 [用户操作]
• 则 [预期系统行为]

示例：

• 假设组织已启用单点登录
• 当员工进入登录页面时
• 则系统将其重定向到组织的身份提供方

检查清单方式：

• 管理员可以在工作区设置中配置身份提供方 URL
• 团队成员会在登录页面看到带有品牌标识的登录选项
• 首次通过 SSO 身份验证时会自动创建新账户
• 如果电子邮件地址匹配，SSO 身份验证会关联到现有账户
• 身份验证失败时会显示明确的错误消息

编写有效的验证标准

• 涵盖主要路径、错误条件和边界场景
• 描述可观察到的行为，而非内部实现
• 包含否定情形：明确说明哪些情况不应发生
• 每项标准都应可独立验证
• 将主观措辞（“响应迅速”“直观”“无缝”）替换为具体阈值

范围治理

范围扩大的迹象

留意以下警示信号：

• 规格定稿后才出现需求
• 增量式添加逐渐累积，导致工作量大幅增加
• 团队构建了没有用户提出过的功能（“反正我们已经在处理了……”）
• 未经过审慎的范围调整讨论，目标日期就发生了变动
• 利益相关方不断追加需求，却没有相应删减内容

控制策略

• 在每份规格中明确列出排除项
• 执行权衡规则：新增范围必须对应删减内容或调整时间线
• 明确划分当前迭代与后续阶段的界限
• 定期核实每项需求是否都能追溯到所述问题
• 为探索性工作设定时间上限：“如果两天内无法解决 X，就延期处理”
• 为值得考虑但超出当前范围的建议维护“未来创意”待办列表

未解决的问题

每份 PRD 都应跟踪待解决事项：

• 记录需要在实施前或实施过程中解决的问题
• 为每个问题指定负责人：工程、设计、法务、数据科学或具体利益相关方
• 将问题分类为阻塞项（开始工作前必须解决）或非阻塞项（可与实施并行解决）

时间安排与顺序

• 记录硬性截止日期：合同义务、外部事件、监管里程碑
• 确定跨团队依赖关系及其预期交付日期
• 如果计划超出单个发布周期，建议分阶段实施