John Qiu
712063071c
skills/ → skills-dev(9), skills-req(10), skills-ops(4), skills-integration(8), skills-biz(4), skills-workflow(7) generate-marketplace.py 改为自动扫描所有 skills-* 目录。 Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
127 lines
4.2 KiB
Markdown
127 lines
4.2 KiB
Markdown
# PRD 评审方法论
|
||
|
||
> 评审 PRD 是需求流程中的关键质量关卡。
|
||
|
||
## 评审流程
|
||
|
||
1. **结构完整性检查** - 检查 PRD 是否包含所有必要章节
|
||
2. **需求清晰度评估** - 验证需求描述是否明确无歧义
|
||
3. **技术可行性分析** - 评估技术方案是否可实现
|
||
4. **数据模型验证** - 检查数据结构设计是否合理
|
||
5. **API 设计审查** - 验证接口设计是否符合规范
|
||
|
||
## PRD 评审检查清单
|
||
|
||
### 一、结构完整性检查
|
||
|
||
| 检查项 | 必须 | 说明 |
|
||
|--------|------|------|
|
||
| 基本信息 | ✓ | 需求编号、标题、创建日期、作者 |
|
||
| 需求背景 | ✓ | 为什么需要这个功能 |
|
||
| 目标用户 | ✓ | 明确功能面向的用户群体 |
|
||
| 功能描述 | ✓ | 详细的功能需求说明 |
|
||
| 用户故事 | ○ | As a... I want... So that... |
|
||
| 数据模型 | ✓ | 数据库表结构设计 |
|
||
| API 设计 | ✓ | RESTful 接口定义 |
|
||
| 页面原型 | ○ | 界面布局和交互说明 |
|
||
| 非功能需求 | ○ | 性能、安全、可用性要求 |
|
||
| 验收标准 | ✓ | 明确的功能验收条件 |
|
||
|
||
> ✓ = 必须包含, ○ = 建议包含
|
||
|
||
### 二、需求清晰度评估（SMART 原则）
|
||
|
||
| 原则 | 检查点 | 示例 |
|
||
|------|--------|------|
|
||
| **S**pecific | 需求描述是否具体明确 | ❌ "支持搜索" → ✅ "支持按需求编号、标题模糊搜索" |
|
||
| **M**easurable | 是否有量化指标 | ❌ "快速响应" → ✅ "响应时间 < 200ms" |
|
||
| **A**chievable | 技术上是否可行 | 评估现有技术栈能否支持 |
|
||
| **R**elevant | 是否与业务目标相关 | 功能是否解决实际问题 |
|
||
| **T**ime-bound | 是否有明确的时间范围 | 开发周期、上线日期 |
|
||
|
||
### 三、技术可行性分析
|
||
|
||
| 检查维度 | 评估内容 |
|
||
|----------|----------|
|
||
| 技术栈兼容性 | 现有技术栈是否支持所需功能 |
|
||
| 系统架构影响 | 是否需要修改现有架构 |
|
||
| 第三方依赖 | 是否引入新的外部依赖 |
|
||
| 性能影响 | 对系统性能的潜在影响 |
|
||
| 安全考量 | 是否存在安全风险 |
|
||
| 数据迁移 | 是否需要数据迁移方案 |
|
||
|
||
### 四、数据模型验证
|
||
|
||
| 检查项 | 说明 |
|
||
|--------|------|
|
||
| 表结构设计 | 字段类型、约束、索引是否合理 |
|
||
| 关联关系 | 外键、多对多关系是否正确 |
|
||
| 命名规范 | 表名、字段名是否符合项目规范 |
|
||
| 扩展性 | 是否预留扩展字段 |
|
||
| 数据量预估 | 数据增长预估和存储方案 |
|
||
| 查询性能 | 常用查询是否有索引支持 |
|
||
|
||
### 五、API 设计审查
|
||
|
||
| 检查项 | 标准 |
|
||
|--------|------|
|
||
| RESTful 规范 | URL 使用名词、HTTP 方法语义正确 |
|
||
| 响应格式 | 统一的响应结构 `{success, data, message}` |
|
||
| 错误处理 | 明确的错误码和错误信息 |
|
||
| 分页设计 | 列表接口支持分页 `?page=1&page_size=20` |
|
||
| 参数验证 | 必填参数、类型、范围说明 |
|
||
| 版本控制 | API 路径包含版本 `/api/v1/...` |
|
||
|
||
## 评审意见模板
|
||
|
||
### 通过模板
|
||
|
||
```
|
||
✅ PRD 评审通过
|
||
|
||
【评审结论】
|
||
PRD 文档结构完整，需求描述清晰，技术方案可行，建议批准进入开发阶段。
|
||
|
||
【肯定之处】
|
||
- 需求背景阐述清晰
|
||
- 数据模型设计合理
|
||
- API 接口规范
|
||
|
||
【建议改进】（非阻塞）
|
||
- 建议补充性能测试用例
|
||
- 建议增加边界条件说明
|
||
|
||
【评审人】xxx
|
||
【评审时间】2026-01-24 10:00
|
||
```
|
||
|
||
### 驳回模板
|
||
|
||
```
|
||
❌ PRD 评审驳回
|
||
|
||
【驳回原因】
|
||
1. 数据模型缺少索引设计
|
||
2. API 接口缺少错误处理说明
|
||
3. 搜索功能需求描述模糊
|
||
|
||
【修改要求】
|
||
□ 补充数据表索引设计
|
||
□ 明确 API 错误码定义
|
||
□ 细化搜索功能的具体实现方式
|
||
|
||
【驳回人】xxx
|
||
【驳回时间】2026-01-24 10:00
|
||
```
|
||
|
||
## 常见驳回原因
|
||
|
||
| 类别 | 常见问题 | 改进建议 |
|
||
|------|----------|----------|
|
||
| 结构缺失 | 缺少数据模型或 API 设计 | 补充完整的技术设计章节 |
|
||
| 需求模糊 | 功能描述不够具体 | 按 SMART 原则重新描述 |
|
||
| 边界不清 | 缺少边界条件和异常处理 | 补充边界条件和错误场景 |
|
||
| 设计缺陷 | 数据模型或 API 设计不合理 | 重新设计并说明理由 |
|
||
| 范围过大 | 需求范围过大难以实现 | 拆分为多个小需求 |
|
||
| 验收不明 | 缺少验收标准 | 补充可验证的验收条件 |
|