11 KiB

Raw Blame History

产品经理 (PM) 需求清单

本清单作为一个全面的框架，旨在确保产品需求文档 (PRD) 和史诗 (Epic) 定义是完整的、结构良好的，并且为 MVP 开发进行了适当的范围界定。产品经理应在产品定义过程中系统地审阅每个项目。

[[LLM: 初始化说明 - PM 清单

在开始使用此清单之前，请确保您能访问以下内容：

prd.md - 产品需求文档 (检查 docs/prd.md)
任何用户研究、市场分析或竞争分析文档
业务目标和战略文档
任何现有的史诗定义或用户故事

重要提示：如果 PRD 缺失，请在继续之前立即向用户询问其位置或内容。

验证方法：

以用户为中心 - 每个需求都应回归到用户价值
聚焦 MVP - 确保范围在可行的同时真正最小化
清晰性 - 需求应明确且可测试
完整性 - 覆盖产品愿景的所有方面
可行性 - 需求在技术上是可实现的

执行模式：询问用户是否希望通过以下方式审阅清单：

逐节进行（互动模式） - 审阅每个部分，提出发现，在继续前获得确认
一次性完成（全面模式） - 完成全部分析并在最后提交综合报告]]

1. 问题定义与背景

[[LLM: 任何产品的基石都是一个清晰的问题陈述。在审阅本节时：

验证问题是真实且值得解决的
检查目标受众是具体的，而不是“所有人”
确保成功指标是可衡量的，而不是模糊的愿望
寻找用户研究的证据，而不仅仅是假设
确认问题-解决方案的匹配是合乎逻辑的]]

1.1 问题陈述

清晰阐述正在解决的问题
确定谁遇到了这个问题
解释为什么解决这个问题很重要
量化问题的影响（如果可能）
与现有解决方案的差异化

1.2 业务目标与成功指标

定义了具体的、可衡量的业务目标
建立了清晰的成功指标和 KPI
指标与用户和业务价值挂钩
确定了基线测量（如果适用）
指定了实现目标的时间框架

1.3 用户研究与洞察

清晰定义了目标用户画像
记录了用户需求和痛点
总结了用户研究发现（如果可用）
包括了竞争分析
提供了市场背景

2. MVP 范围定义

[[LLM: MVP 范围至关重要——范围太大浪费资源，太小则无法验证。检查：

这真的是最小化的吗？挑战每一个功能
每个功能是否都直接解决了核心问题？
“锦上添花”的功能是否与“必须拥有”的功能明确分开？
包含/排除的理由是否已记录？
你能在目标时间框架内交付吗？]]

2.1 核心功能

基本功能与锦上添花的功能明确区分
功能直接解决了定义的问题陈述
每个史诗都与特定的用户需求相关联
从用户角度描述功能和故事
定义了成功的最低要求

2.2 范围边界

清晰阐明什么不在范围之内
包括了未来的增强功能部分
记录了范围决策的理由
MVP 在最小化功能的同时最大化学习
范围已经过多次审查和完善

2.3 MVP 验证方法

定义了测试 MVP 成功的方法
计划了初始用户反馈机制
指定了超越 MVP 的标准
阐明了 MVP 的学习目标
设定了时间线预期

3. 用户体验需求

[[LLM: 用户体验需求是连接用户需求和技术实现的桥梁。验证：

用户流程完全覆盖了主要用例
识别了边缘情况（即使已推迟）
可访问性不是事后才考虑的
性能预期是现实的
计划了错误状态和恢复]]

3.1 用户旅程与流程

记录了主要用户流程
确定了每个流程的入口和出口点
映射了决策点和分支
突出了关键路径
考虑了边缘情况

3.2 可用性需求

记录了可访问性考虑因素
指定了平台/设备兼容性
定义了从用户角度出发的性能期望
概述了错误处理和恢复方法
确定了用户反馈机制

3.3 UI 需求

概述了信息架构
确定了关键 UI 组件
引用了视觉设计指南（如果适用）
指定了内容要求
定义了高层导航结构

4. 功能性需求

[[LLM: 功能性需求必须足够清晰以供实施。检查：

需求关注的是“什么”而不是“如何”（没有实现细节）
每个需求都是可测试的（QA 将如何验证它？）
依赖关系是明确的（什么需要先构建？）
需求使用一致的术语
复杂的功能被分解成可管理的部分]]

4.1 功能完整性

记录了 MVP 所需的所有功能
功能有清晰的、以用户为中心的描述
指明了功能的优先级/重要性
需求是可测试和可验证的
确定了功能之间的依赖关系

4.2 需求质量

需求是具体且明确的
需求关注“什么”而不是“如何”
需求使用一致的术语
复杂的需求被分解成更简单的部分
技术术语被最小化或解释

4.3 用户故事与验收标准

故事遵循一致的格式
验收标准是可测试的
故事的大小适当（不要太大）
故事在可能的情况下是独立的
故事包括必要的背景
在相关后端/数据故事的验收标准中定义了本地可测试性要求（例如，通过 CLI）

5. 非功能性需求

5.1 性能需求

定义了响应时间期望
指定了吞吐量/容量要求
记录了可扩展性需求
确定了资源利用率约束
设定了负载处理期望

5.2 安全与合规

指定了数据保护要求
定义了认证/授权需求
记录了合规性要求
概述了安全测试要求
解决了隐私考虑因素

5.3 可靠性与弹性

定义了可用性要求
记录了备份和恢复需求
设定了容错期望
指定了错误处理要求
包括了维护和支持考虑因素

5.4 技术约束

记录了平台/技术约束
概述了集成要求
确定了第三方服务依赖关系
指定了基础设施要求
确定了开发环境需求

6. 史诗与故事结构

6.1 史诗定义

史诗代表了功能内聚的单元
史诗专注于用户/业务价值的交付
清晰阐述了史诗的目标
史诗的大小适合增量交付
确定了史诗的顺序和依赖关系

6.2 故事分解

故事被分解到适当的大小
故事具有清晰、独立的价值
故事包括适当的验收标准
记录了故事的依赖关系和顺序
故事与史诗目标保持一致

6.3 第一个史诗的完整性

第一个史诗包括所有必要的设置步骤
解决了项目脚手架和初始化问题
包括了核心基础设施设置
解决了开发环境设置问题
尽早建立了本地可测试性

7. 技术指导

7.1 架构指导

提供了初步的架构方向
清晰传达了技术约束
确定了集成点
强调了性能考虑因素
阐明了安全要求
标记了已知的高度复杂或技术风险领域以进行架构深度探讨

7.2 技术决策框架

提供了技术选择的决策标准
阐明了关键决策的权衡
记录了选择主要方法而非考虑的备选方案的理由（针对关键设计/功能选择）
强调了不可协商的技术要求
确定了需要技术调查的领域
提供了关于技术债务方法的指导

7.3 实施考虑

提供了开发方法指导
阐明了测试要求
设定了部署期望
确定了监控需求
指定了文档要求

8. 跨功能需求

8.1 数据需求

确定了数据实体和关系
指定了数据存储要求
定义了数据质量要求
确定了数据保留策略
解决了数据迁移需求（如果适用）
计划了迭代式的模式变更，并与需要它们的故事相关联

8.2 集成需求

确定了外部系统集成
记录了 API 要求
指定了集成的认证
定义了数据交换格式
概述了集成测试要求

8.3 运营需求

设定了部署频率期望
定义了环境要求
确定了监控和警报需求
记录了支持要求
指定了性能监控方法

9. 清晰性与沟通

9.1 文档质量

文档使用清晰、一致的语言
文档结构良好、组织有序
在必要时定义了技术术语
在有帮助的地方包含了图表/视觉效果
文档已适当地版本化

9.2 利益相关者对齐

确定了关键利益相关者
采纳了利益相关者的意见
解决了潜在的分歧领域
建立了更新的沟通计划
定义了审批流程

PRD 与史诗验证摘要

[[LLM: 最终 PM 清单报告生成

创建一个全面的验证报告，其中包括：

执行摘要
- 整体 PRD 完整度（百分比）
- MVP 范围的适当性（过大/正好/过小）
- 架构阶段的准备情况（准备就绪/接近就绪/未准备好）
- 最关键的差距或担忧
类别分析表用以下内容填写实际表格：
- 状态：通过 (90%+ 完成), 部分 (60-89%), 失败 (<60%)
- 关键问题：阻碍进展的具体问题
按优先级排列的主要问题
- 阻塞性问题：在架构师可以继续之前必须修复
- 高优先级：为保证质量应修复
- 中优先级：将提高清晰度
- 低优先级：锦上添花
MVP 范围评估
- 为实现真正的 MVP 可能需要削减的功能
- 必不可少的缺失功能
- 复杂性担忧
- 时间线的现实性
技术准备情况
- 技术约束的清晰度
- 已识别的技术风险
- 需要架构师调查的领域
建议
- 解决每个阻塞性问题的具体行动
- 建议的改进
- 下一步

在提交报告后，询问用户是否需要：

任何失败部分的详细分析
关于改进特定领域的建议
帮助完善 MVP 范围]]

类别状态

类别	状态	关键问题
1. 问题定义与背景	待定
2. MVP 范围定义	待定
3. 用户体验需求	待定
4. 功能性需求	待定
5. 非功能性需求	待定
6. 史诗与故事结构	待定
7. 技术指导	待定
8. 跨功能需求	待定
9. 清晰性与沟通	待定

关键缺陷

（在验证过程中填写）

建议