@rdmind/rdmind 0.0.9-alpha.1 → 0.0.9

package/.knowledge/.ext/.bmad-core/checklists/pm-checklist.md

@@ -0,0 +1,372 @@
+<!-- Powered by BMAD™ Core -->
+
+# 产品经理（PM）需求 Checklist
+
+这份 checklist 是一个完整的框架，用来确保产品需求文档（PRD）和 Epic 定义完整、结构清晰，并且适合 MVP 开发。产品经理在产品定义阶段需要逐项完成。
+
+[[LLM: 初始化说明 - PM CHECKLIST
+
+使用这份 checklist 前，请确保你已经拿到这些材料：
+
+1. prd.md - 产品需求文档（检查 docs/prd.md）
+2. 用户研究、市场分析或竞品分析文档
+3. 业务目标和策略文档
+4. 现有的 epic 定义或用户故事
+
+注意：如果找不到 PRD，请先问用户要文档位置或内容。
+
+验证思路：
+
+1. 以用户为中心 - 每个需求都要能体现用户价值
+2. 聚焦 MVP - 确保范围真的最小化且可行
+3. 清晰明确 - 需求要明确且可测试
+4. 完整全面 - 产品愿景的各个方面都要覆盖
+5. 技术可行 - 需求在技术上能实现
+
+执行方式：
+问用户想怎么执行 checklist：
+
+- 逐章节（交互模式）- 逐个章节审查，展示发现，确认后再继续
+- 一次性完成（全面模式）- 完成全部分析后给出综合报告]]
+
+## 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 核心功能
+
+- [ ] 核心功能和锦上添花功能分清楚
+- [ ] 功能直接解决定义好的问题
+- [ ] 每个 Epic 都对应特定用户需求
+- [ ] 功能和故事从用户角度写
+- [ ] 明确成功的最低要求
+
+### 2.2 范围边界
+
+- [ ] 清楚说明哪些不做
+- [ ] 包含未来功能规划
+- [ ] 记录为什么做/不做的理由
+- [ ] MVP 功能最小化，学习最大化
+- [ ] 范围经过多次讨论和调整
+
+### 2.3 MVP 验证方法
+
+- [ ] 明确怎么验证 MVP 成功
+- [ ] 规划用户反馈收集方式
+- [ ] 设定超越 MVP 的标准
+- [ ] 明确 MVP 要学到什么
+- [ ] 设定时间预期
+
+## 3. 用户体验需求
+
+[[LLM: UX 需求是用户需求和技术实现的桥梁。要验证：
+
+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 用户故事与验收标准
+
+- [ ] 故事格式要统一
+- [ ] 验收标准要能测试
+- [ ] 故事大小要合适（不能太大）
+- [ ] 故事要尽量独立
+- [ ] 故事要包含必要的背景
+- [ ] 后端/数据故事的 AC 要定义本地测试方法（比如通过 CLI）
+
+## 5. 非功能需求
+
+### 5.1 性能需求
+
+- [ ] 明确响应时间要求
+- [ ] 设定吞吐量/容量要求
+- [ ] 规划可扩展性需求
+- [ ] 明确资源使用限制
+- [ ] 设定负载处理要求
+
+### 5.2 安全与合规
+
+- [ ] 明确数据保护要求
+- [ ] 定义认证/授权需求
+- [ ] 明确合规要求
+- [ ] 规划安全测试要求
+- [ ] 考虑隐私保护
+
+### 5.3 可靠性与弹性
+
+- [ ] 明确可用性要求
+- [ ] 规划备份和恢复方案
+- [ ] 设定容错要求
+- [ ] 明确错误处理方式
+- [ ] 考虑维护和支持
+
+### 5.4 技术约束
+
+- [ ] 明确平台/技术限制
+- [ ] 规划集成要求
+- [ ] 明确第三方服务依赖
+- [ ] 明确基础设施要求
+- [ ] 明确开发环境需求
+
+## 6. Epic 与故事结构
+
+### 6.1 Epic 定义
+
+- [ ] Epic 要代表完整的功能单元
+- [ ] Epic 要专注用户/业务价值
+- [ ] Epic 目标要写清楚
+- [ ] Epic 大小要适合分步交付
+- [ ] 理清 Epic 的顺序和依赖关系
+
+### 6.2 故事分解
+
+- [ ] 故事要拆分成合适大小
+- [ ] 故事要有清晰、独立的价值
+- [ ] 故事要包含验收标准
+- [ ] 理清故事依赖关系和顺序
+- [ ] 故事要和 Epic 目标对齐
+
+### 6.3 第一个 Epic 完整性
+
+- [ ] 第一个 Epic 要包含所有必要的准备工作
+- [ ] 要解决项目脚手架和初始化
+- [ ] 要包含核心基础设施搭建
+- [ ] 要解决开发环境配置
+- [ ] 要尽早建立本地测试能力
+
+## 7. 技术指导
+
+### 7.1 架构指导
+
+- [ ] 给出初始架构方向
+- [ ] 明确技术约束
+- [ ] 识别集成点
+- [ ] 突出性能考虑
+- [ ] 明确安全要求
+- [ ] 标出已知的高复杂度或技术风险点，让架构师重点分析
+
+### 7.2 技术决策框架
+
+- [ ] 给出技术选择的决策标准
+- [ ] 说明关键决策的权衡
+- [ ] 记录为什么选这个方案而不是其他方案（针对关键设计/功能选择）
+- [ ] 明确不可妥协的技术要求
+- [ ] 识别需要技术调研的领域
+- [ ] 给出技术债务的处理方法
+
+### 7.3 实现考虑
+
+- [ ] 给出开发方法指导
+- [ ] 明确测试要求
+- [ ] 设定部署期望
+- [ ] 明确监控需求
+- [ ] 明确文档要求
+
+## 8. 跨功能需求
+
+### 8.1 数据需求
+
+- [ ] 明确数据实体和关系
+- [ ] 明确数据存储需求
+- [ ] 明确数据质量要求
+- [ ] 明确数据保留策略
+- [ ] 规划数据迁移需求（如果需要）
+- [ ] 迭代规划数据模型变更，和需要的故事关联
+
+### 8.2 集成需求
+
+- [ ] 明确外部系统集成
+- [ ] 明确 API 需求
+- [ ] 明确集成的认证方式
+- [ ] 明确数据交换格式
+- [ ] 规划集成测试要求
+
+### 8.3 运营需求
+
+- [ ] 设定部署频率期望
+- [ ] 明确环境要求
+- [ ] 明确监控和告警需求
+- [ ] 明确支持要求
+- [ ] 明确性能监控方法
+
+## 9. 清晰度与沟通
+
+### 9.1 文档质量
+
+- [ ] 文档语言要清晰、统一
+- [ ] 文档结构要清晰、有条理
+- [ ] 技术术语要解释清楚
+- [ ] 适当的地方要加图表/视觉元素
+- [ ] 文档要版本化管理
+
+### 9.2 利益相关者对齐
+
+- [ ] 明确关键利益相关者
+- [ ] 收集利益相关者意见
+- [ ] 解决潜在分歧点
+- [ ] 建立更新沟通机制
+- [ ] 明确审批流程
+
+## PRD 与 Epic 验证总结
+
+[[LLM: 最终 PM CHECKLIST 报告生成
+
+生成包含以下内容的综合验证报告：
+
+1. 执行摘要
+   - 整体 PRD 完整性（百分比）
+   - MVP 范围是否合适（过大/刚好/过小）
+   - 是否准备好进入架构阶段（就绪/接近就绪/未就绪）
+   - 最关键的问题或关注点
+
+2. 类别分析表
+   填写实际表格：
+   - 状态：通过（90%+ 完成）、部分（60-89%）、失败（<60%）
+   - 关键问题：阻碍进展的具体问题
+
+3. 按优先级排序的问题
+   - 阻塞项：架构师继续前必须解决
+   - 高优先级：应该解决以提高质量
+   - 中优先级：会提高清晰度
+   - 低优先级：锦上添花
+
+4. MVP 范围评估
+   - 可能为真正 MVP 而砍掉的功能
+   - 缺失的必需功能
+   - 复杂度担忧
+   - 时间线是否现实
+
+5. 技术准备情况
+   - 技术约束是否清晰
+   - 识别的技术风险
+   - 需要架构师重点调研的领域
+
+6. 建议
+   - 解决每个阻塞项的具体行动
+   - 改进建议
+   - 下一步行动
+
+展示报告后，问用户是否需要：
+
+- 对失败部分的详细分析
+- 改进特定领域的建议
+- 帮助完善 MVP 范围]]
+
+### 类别状态
+
+| 类别               | 状态   | 关键问题 |
+| ------------------ | ------ | -------- |
+| 1. 问题定义与背景  | _待定_ |          |
+| 2. MVP 范围定义    | _待定_ |          |
+| 3. 用户体验需求    | _待定_ |          |
+| 4. 功能需求        | _待定_ |          |
+| 5. 非功能需求      | _待定_ |          |
+| 6. Epic 与故事结构 | _待定_ |          |
+| 7. 技术指导        | _待定_ |          |
+| 8. 跨功能需求      | _待定_ |          |
+| 9. 清晰度与沟通    | _待定_ |          |
+
+### 关键缺陷
+
+（验证期间填写）
+
+### 建议
+
+（验证期间填写）
+
+### 最终决定
+
+- **可以交给架构师**：PRD 和 epic 完整、结构清晰，可以开始架构设计。
+- **还需要完善**：需求文档还需要补充，解决发现的问题。