PRODUCT 阶段 - 产品需求分析
PRODUCT阶段是SOLO工作模式的第一阶段，由Product Manager子代理负责，专注于需求收集、分析和PRD文档编写，为API设计提供清晰的业务基础。
🎯 阶段目标
核心目标
- 需求澄清: 通过结构化对话明确产品需求
- 用户故事: 编写具体可测试的用户故事
- API需求: 将业务需求转化为API功能需求
- PRD输出: 生成标准化的产品需求文档
成功标准
- ✅ 完整的PRD文档 (
.solo/docs/PRD.md) - ✅ 明确的用户故事和验收标准
- ✅ 清晰的API功能边界
- ✅ 可量化的非功能需求
🤖 Product Manager 子代理
触发条件
当以下情况出现时，会自动调用Product Manager子代理：
- 用户执行
/solo命令启动新项目 - 用户执行
/solo__switch product切换到产品模式 - 需要补充或修订产品需求时
核心能力
markdown
## 需求收集和分析
- 引导用户明确产品愿景和核心问题
- 识别目标用户群体和使用场景
- 探索功能需求和非功能需求
- 评估约束条件和假设
## 结构化需求澄清
使用以下问题模板引导用户：
### 1. 愿景澄清
- "这个API要解决什么核心业务问题？"
- "谁是主要用户？他们现在如何处理这些需求？"
- "核心价值主张是什么？"
### 2. 功能探索
- "具体需要哪些API端点？请描述使用场景"
- "每个端点的输入输出是什么？"
- "有哪些业务规则和验证逻辑？"
### 3. 非功能需求
- "预期的用户量和并发量是多少？"
- "对响应时间有什么要求？"
- "有什么安全性和合规性要求？"📋 需求分析流程
第一步：业务背景了解
🤖 Product Manager: 让我们开始需求分析。
首先帮我理解业务背景：
1. 这个API项目的业务背景是什么？
2. 要解决的核心问题是什么？
3. 不解决这个问题会带来什么影响？
请详细描述...用户回答示例：
我们需要构建一个订单管理API，目前各个业务系统都在各自维护订单数据，
导致数据不一致、重复开发、难以统计分析。希望通过统一的API服务，
为所有系统提供标准化的订单管理能力。第二步：用户群体分析
🤖 Product Manager: 明白了，这是一个数据统一和服务标准化的需求。
现在让我们分析用户群体：
1. 谁会调用这个API？（内部系统、外部合作伙伴、移动应用等）
2. 不同用户群体的使用频次如何？
3. 他们对API有什么不同的期望？用户回答示例：
主要用户：
1. 电商前端（Web/App）- 高频调用，需要快速响应
2. 仓储管理系统 - 中频调用，需要准确的库存状态
3. 财务系统 - 低频调用，需要完整的订单明细
4. 数据分析平台 - 批量调用，需要历史数据查询第三步：功能需求挖掘
🤖 Product Manager: 很好，用户群体很明确。
让我们具体定义API功能：
1. 需要哪些核心的订单操作？（创建、查询、更新、取消等）
2. 每种操作对应什么业务场景？
3. 有哪些特殊的业务规则？引导出的功能需求：
核心API端点：
1. POST /orders - 创建订单
- 场景：用户下单、系统批量导入
- 规则：库存检查、价格计算、用户验证
2. GET /orders/{id} - 查询单个订单
- 场景：订单详情查看、状态跟踪
- 规则：权限控制、数据脱敏
3. GET /orders - 查询订单列表
- 场景：订单管理、数据统计
- 规则：分页查询、多维度筛选
4. PUT /orders/{id} - 更新订单
- 场景：修改地址、更改商品
- 规则：状态限制、操作日志
5. DELETE /orders/{id} - 取消订单
- 场景：用户取消、系统自动取消
- 规则：时间限制、退款处理第四步：非功能需求定义
🤖 Product Manager: 功能需求很清晰。现在我们讨论性能和质量要求：
1. 预期的并发量和数据量级别？
2. 对响应时间有什么具体要求？
3. 系统可用性要求？
4. 安全性和合规要求？示例收集结果：
性能需求：
- 并发量：峰值 5000 QPS
- 响应时间：查询 < 100ms，创建 < 500ms
- 数据量：预计年订单量 1000万+
可用性需求：
- 系统可用性：99.9%
- 故障恢复时间：< 5分钟
- 数据备份策略：实时备份
安全需求：
- API认证：OAuth 2.0 + JWT
- 数据加密：传输和存储加密
- 访问控制：基于角色的权限管理
- 合规要求：符合PCI DSS标准第五步：约束条件和假设
🤖 Product Manager: 最后确认一下项目约束：
1. 技术栈有什么限制？
2. 时间和资源约束？
3. 与现有系统的集成要求？
4. 有什么重要假设需要验证？📄 PRD文档生成
基于需求分析结果，Product Manager会生成标准化的PRD文档：
markdown
# 订单管理API - 产品需求文档
## 产品概述
### 产品名称
订单管理API (Order Management API)
### 产品愿景
为企业提供统一、标准化的订单管理服务，消除数据孤岛，提升业务效率
### 目标用户
- 电商前端系统（Web/App）
- 仓储管理系统
- 财务管理系统
- 数据分析平台
### 核心问题
现有订单数据分散在各个业务系统中，导致：
- 数据不一致和重复维护
- 开发成本高，重复建设
- 难以进行统一的数据分析
- 系统间集成复杂
## 功能需求
### 用户故事
#### US001: 订单创建
- **作为** 电商前端系统
- **我想要** 通过API创建新订单
- **以便** 用户完成购买流程
**验收标准**：
1. 支持单个和批量订单创建
2. 自动进行库存检查和价格计算
3. 返回包含订单ID的创建结果
4. 创建失败时返回具体错误信息
5. 创建成功后发送订单确认通知
**优先级**：必须有
#### US002: 订单查询
- **作为** 各业务系统
- **我想要** 查询订单详情和列表
- **以便** 展示订单信息和进行业务处理
**验收标准**：
1. 支持按订单ID查询单个订单
2. 支持多条件组合查询订单列表
3. 支持分页查询，默认20条/页
4. 支持按时间、状态、用户等维度筛选
5. 查询结果包含完整的订单信息
**优先级**：必须有
#### US003: 订单状态管理
- **作为** 仓储管理系统
- **我想要** 更新订单状态
- **以便** 反映订单的实际处理进度
**验收标准**：
1. 支持订单状态的合规性检查
2. 状态变更时记录操作日志
3. 支持批量状态更新
4. 状态变更时触发相关通知
5. 提供状态变更历史查询
**优先级**：必须有
### 功能清单
| ID | 功能名称 | 描述 | 优先级 | 所属故事 |
|----|----------|------|--------|----------|
| F001 | 订单创建 | 支持创建单个或批量订单 | 必须有 | US001 |
| F002 | 订单查询 | 按多种条件查询订单信息 | 必须有 | US002 |
| F003 | 订单更新 | 更新订单信息和状态 | 必须有 | US003 |
| F004 | 订单取消 | 支持订单取消和退款 | 必须有 | US004 |
| F005 | 订单通知 | 订单状态变更通知 | 应该有 | US005 |
| F006 | 订单统计 | 提供订单统计分析接口 | 可以有 | US006 |
## 非功能需求
### 性能要求
- **并发量**: 支持峰值5000 QPS
- **响应时间**: 查询接口 < 100ms，创建接口 < 500ms
- **吞吐量**: 每日处理订单量 > 100万
- **数据量**: 支持千万级订单数据存储和查询
### 安全要求
- **认证方式**: 支持OAuth 2.0和JWT Token
- **访问控制**: 基于角色的权限管理(RBAC)
- **数据加密**: 传输层TLS 1.3，存储层AES-256加密
- **防护措施**: 防止SQL注入、XSS攻击、API滥用
### 可用性要求
- **系统可用性**: 99.9%（年停机时间 < 8.77小时）
- **故障恢复**: 系统故障后5分钟内恢复服务
- **数据备份**: 实时数据备份，支持点在时间恢复
- **监控告警**: 完善的监控体系和告警机制
## 约束和假设
### 技术约束
- 必须基于RESTful API设计原则
- 必须提供完整的OpenAPI 3.0规范文档
- 必须支持JSON数据格式
- 数据库选择：PostgreSQL或MySQL
### 资源约束
- 开发周期：8周
- 开发团队：3名后端工程师 + 1名测试工程师
- 预算限制：服务器和工具成本控制在月均1万元内
### 假设条件
1. 现有用户认证服务可以正常集成
2. 支付系统接口稳定可用
3. 物流系统可以提供必要的接口
4. 数据库性能可以满足并发要求
## 发布计划
### MVP（最小可行产品）
**发布时间**: 开发完成后4周
**包含功能**:
- 基础订单CRUD操作
- 简单的权限控制
- 基础的监控和日志
**成功指标**:
- 核心API功能正常
- 性能达到基本要求
- 至少接入2个业务系统
### 后续版本
#### V1.1 (MVP后2周)
- 高级查询和统计功能
- 订单状态流转管理
- 消息通知系统
#### V1.2 (V1.1后4周)
- 订单导入导出功能
- 高级权限管理
- 性能优化和缓存策略
## 成功指标
### 业务指标
- API日调用量 > 100万次
- 系统响应时间达标率 > 95%
- 业务系统集成数量 ≥ 5个
- 用户满意度评分 ≥ 4.5/5.0
### 技术指标
- API可用性 ≥ 99.9%
- 测试覆盖率 ≥ 80%
- 代码质量评分 ≥ A级
- 安全漏洞数量 = 0🔄 与后续阶段的衔接
向ARCHITECT阶段移交
PRD完成后，会自动触发ARCHITECT阶段：
markdown
## 移交检查清单
- [ ] ✅ PRD文档完整，包含所有必要章节
- [ ] ✅ 用户故事具体且可测试
- [ ] ✅ 非功能需求明确和可量化
- [ ] ✅ API功能边界清晰定义
- [ ] ✅ 约束条件和假设明确列出
## 移交产物
- `.solo/docs/PRD.md` - 完整的产品需求文档
- `.solo/.solo-metadata.json` - 项目元数据更新ARCHITECT阶段会基于PRD进行：
- API架构设计和技术选型
- OpenAPI规范编写
- 项目任务分解和计划制定
- 关键技术决策记录
📊 质量检查
PRD质量标准
Product Manager完成PRD后，会进行自检：
markdown
## PRD质量检查清单
### 完整性检查
- [ ] 产品概述是否完整？
- [ ] 用户故事是否涵盖所有核心功能？
- [ ] 非功能需求是否量化？
- [ ] 约束条件是否明确？
### 可行性检查
- [ ] 需求是否现实可行？
- [ ] 技术约束是否合理？
- [ ] 时间和资源估算是否现实？
- [ ] 假设条件是否需要验证？
### 一致性检查
- [ ] 不同章节描述是否一致？
- [ ] 用户故事与功能清单是否对应？
- [ ] 优先级划分是否合理？
- [ ] 成功指标是否可衡量？💡 最佳实践
需求澄清技巧
- 使用具体场景: 避免抽象描述，要求用户提供具体使用场景
- 数据驱动: 询问具体的数量、频次、时间等量化信息
- 异常处理: 主动询问边界情况和异常场景的处理方式
- 优先级排序: 帮助用户区分"想要"和"需要"
常见问题处理
markdown
## 用户需求模糊时
🤖 Product Manager: "您提到的'用户管理'具体包括哪些操作？
比如是否包括：用户注册、登录验证、权限管理、个人信息修改？
请举几个具体的使用场景。"
## 性能要求不明确时
🤖 Product Manager: "关于性能要求，能否提供一些具体数据？
比如：预期的用户量级、高峰期并发量、可接受的响应时间？
这些信息对架构设计很重要。"
## 技术方案过早讨论时
🤖 Product Manager: "技术实现的细节我们在架构设计阶段会详细考虑。
现在让我们专注于业务需求，比如这个功能要解决什么问题？
用户期待什么样的体验？"团队协作建议
- 产品经理参与: 建议实际的产品经理参与PRODUCT阶段
- 用户代表: 邀请真实用户或用户代表参与需求澄清
- 分步验证: 对于复杂需求，可以分批进行需求确认
- 文档共享: 及时将PRD分享给团队成员收集反馈
🔗 相关资源
文档模板
工具推荐
下一步
🎯 总结: PRODUCT阶段是整个SOLO工作流程的基础，高质量的需求分析是后续架构设计和开发实现成功的关键。通过Product Manager子代理的结构化引导，可以确保需求清晰、完整、可执行。