# 产品经理 (PM) 需求清单 本清单作为一个全面的框架，旨在确保产品需求文档 (PRD) 和史诗 (Epic) 定义是完整的、结构良好的，并且为 MVP 开发进行了适当的范围界定。产品经理应在产品定义过程中系统地审阅每个项目。 [[LLM: 初始化说明 - PM 清单 在开始使用此清单之前，请确保您能访问以下内容： 1. prd.md - 产品需求文档 (检查 docs/prd.md) 2. 任何用户研究、市场分析或竞争分析文档 3. 业务目标和战略文档 4. 任何现有的史诗定义或用户故事 重要提示：如果 PRD 缺失，请在继续之前立即向用户询问其位置或内容。 验证方法： 1. 以用户为中心 - 每个需求都应回归到用户价值 2. 聚焦 MVP - 确保范围在可行的同时真正最小化 3. 清晰性 - 需求应明确且可测试 4. 完整性 - 覆盖产品愿景的所有方面 5. 可行性 - 需求在技术上是可实现的 执行模式： 询问用户是否希望通过以下方式审阅清单： - 逐节进行（互动模式） - 审阅每个部分，提出发现，在继续前获得确认 - 一次性完成（全面模式） - 完成全部分析并在最后提交综合报告]] ## 1. 问题定义与背景 [[LLM: 任何产品的基石都是一个清晰的问题陈述。在审阅本节时： 1. 验证问题是真实且值得解决的 2. 检查目标受众是具体的，而不是“所有人” 3. 确保成功指标是可衡量的，而不是模糊的愿望 4. 寻找用户研究的证据，而不仅仅是假设 5. 确认问题-解决方案的匹配是合乎逻辑的]] ### 1.1 问题陈述 - [ ] 清晰阐述正在解决的问题 - [ ] 确定谁遇到了这个问题 - [ ] 解释为什么解决这个问题很重要 - [ ] 量化问题的影响（如果可能） - [ ] 与现有解决方案的差异化 ### 1.2 业务目标与成功指标 - [ ] 定义了具体的、可衡量的业务目标 - [ ] 建立了清晰的成功指标和 KPI - [ ] 指标与用户和业务价值挂钩 - [ ] 确定了基线测量（如果适用） - [ ] 指定了实现目标的时间框架 ### 1.3 用户研究与洞察 - [ ] 清晰定义了目标用户画像 - [ ] 记录了用户需求和痛点 - [ ] 总结了用户研究发现（如果可用） - [ ] 包括了竞争分析 - [ ] 提供了市场背景 ## 2. MVP 范围定义 [[LLM: MVP 范围至关重要——范围太大浪费资源，太小则无法验证。检查： 1. 这真的是最小化的吗？挑战每一个功能 2. 每个功能是否都直接解决了核心问题？ 3. “锦上添花”的功能是否与“必须拥有”的功能明确分开？ 4. 包含/排除的理由是否已记录？ 5. 你能在目标时间框架内交付吗？]] ### 2.1 核心功能 - [ ] 基本功能与锦上添花的功能明确区分 - [ ] 功能直接解决了定义的问题陈述 - [ ] 每个史诗都与特定的用户需求相关联 - [ ] 从用户角度描述功能和故事 - [ ] 定义了成功的最低要求 ### 2.2 范围边界 - [ ] 清晰阐明什么不在范围之内 - [ ] 包括了未来的增强功能部分 - [ ] 记录了范围决策的理由 - [ ] MVP 在最小化功能的同时最大化学习 - [ ] 范围已经过多次审查和完善 ### 2.3 MVP 验证方法 - [ ] 定义了测试 MVP 成功的方法 - [ ] 计划了初始用户反馈机制 - [ ] 指定了超越 MVP 的标准 - [ ] 阐明了 MVP 的学习目标 - [ ] 设定了时间线预期 ## 3. 用户体验需求 [[LLM: 用户体验需求是连接用户需求和技术实现的桥梁。验证： 1. 用户流程完全覆盖了主要用例 2. 识别了边缘情况（即使已推迟） 3. 可访问性不是事后才考虑的 4. 性能预期是现实的 5. 计划了错误状态和恢复]] ### 3.1 用户旅程与流程 - [ ] 记录了主要用户流程 - [ ] 确定了每个流程的入口和出口点 - [ ] 映射了决策点和分支 - [ ] 突出了关键路径 - [ ] 考虑了边缘情况 ### 3.2 可用性需求 - [ ] 记录了可访问性考虑因素 - [ ] 指定了平台/设备兼容性 - [ ] 定义了从用户角度出发的性能期望 - [ ] 概述了错误处理和恢复方法 - [ ] 确定了用户反馈机制 ### 3.3 UI 需求 - [ ] 概述了信息架构 - [ ] 确定了关键 UI 组件 - [ ] 引用了视觉设计指南（如果适用） - [ ] 指定了内容要求 - [ ] 定义了高层导航结构 ## 4. 功能性需求 [[LLM: 功能性需求必须足够清晰以供实施。检查： 1. 需求关注的是“什么”而不是“如何”（没有实现细节） 2. 每个需求都是可测试的（QA 将如何验证它？） 3. 依赖关系是明确的（什么需要先构建？） 4. 需求使用一致的术语 5. 复杂的功能被分解成可管理的部分]] ### 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 清单报告生成 创建一个全面的验证报告，其中包括： 1. 执行摘要 - 整体 PRD 完整度（百分比） - MVP 范围的适当性（过大/正好/过小） - 架构阶段的准备情况（准备就绪/接近就绪/未准备好） - 最关键的差距或担忧 2. 类别分析表 用以下内容填写实际表格： - 状态：通过 (90%+ 完成), 部分 (60-89%), 失败 (<60%) - 关键问题：阻碍进展的具体问题 3. 按优先级排列的主要问题 - 阻塞性问题：在架构师可以继续之前必须修复 - 高优先级：为保证质量应修复 - 中优先级：将提高清晰度 - 低优先级：锦上添花 4. MVP 范围评估 - 为实现真正的 MVP 可能需要削减的功能 - 必不可少的缺失功能 - 复杂性担忧 - 时间线的现实性 5. 技术准备情况 - 技术约束的清晰度 - 已识别的技术风险 - 需要架构师调查的领域 6. 建议 - 解决每个阻塞性问题的具体行动 - 建议的改进 - 下一步 在提交报告后，询问用户是否需要： - 任何失败部分的详细分析 - 关于改进特定领域的建议 - 帮助完善 MVP 范围]] ### 类别状态 | 类别 | 状态 | 关键问题 | | --- | --- | --- | | 1. 问题定义与背景 | _待定_ | | | 2. MVP 范围定义 | _待定_ | | | 3. 用户体验需求 | _待定_ | | | 4. 功能性需求 | _待定_ | | | 5. 非功能性需求 | _待定_ | | | 6. 史诗与故事结构 | _待定_ | | | 7. 技术指导 | _待定_ | | | 8. 跨功能需求 | _待定_ | | | 9. 清晰性与沟通 | _待定_ | | ### 关键缺陷 （在验证过程中填写） ### 建议 （在验证过程中填写） ### 最终决定 - **准备好进行架构设计**：PRD 和史诗是全面的、结构合理的，并已准备好进行架构设计。 - **需要完善**：需求文档需要额外的工作来解决已识别的缺陷。