第4章 需求粒度不当问题排查
需求粒度不当是AI产品建模中的高频问题，表现为需求过粗（难以落地）或过细（淹没决策主线）。本章按现象识别 → 数据采集 → 原因定位 → 修复动作 → 复测 → 预防六步法提供系统性排查方案。
4.1 现象识别
典型症状对照表：使用以下特征快速判断需求粒度是否失衡。
| 粒度问题 | 直观表现 | 团队反馈 | 文档特征 |
|---|---|---|---|
| 过粗 | 需求无法直接进入开发，需要反复追问细节 | “这个需求到底要做什么？” | 一句话描述，无功能清单、无验收标准 |
| 过细 | 需求列表冗长，80%是操作步骤而非用户目标 | “改一个字段就要重审全部需求” | 大量“点击XX按钮”类描述，缺少用户故事 |
排查规则：收集最近两个迭代的10条需求条目，计算平均字数。若平均字数 < 50 字且无拆分项 → 过粗；平均字数 > 300 字且半数以上描述UI操作 → 过细。
4.2 数据采集：工作分解结构（WBS）审查
组织需求清单并进行WBS审查，记录每层的分解深度。使用以下模板采集数据。
采集示例（某AI客服知识库项目）
需求ID: REQ-KB-023
标题: 知识库批量导入功能
当前描述: “用户可以通过Excel批量上传FAQ条目。”
分解审查:
层1（主题区）: 知识库管理 -> 导入模块
层2（功能区）: 文件上传、格式校验、重复检测、导入反馈
层3（任务级）: 无（缺失）
结论: 层1→层2存在，层2→层3断裂，属于需求过粗将所有需求条目按以下维度记录，形成粒度偏差清单：
| 条目ID | 现有层级数 | 预期层级数（Epic / Story / Task） | 缺失层级 | 偏差类型 |
|---|---|---|---|---|
| REQ-KB-023 | 2（主题+功能） | 3 | Task | 过粗 |
| REQ-UI-012 | 5（含点击步骤） | 3 | Epic 层缺失 | 过细 |
4.3 原因定位
故障树分析：从根因向下排查，定位核心缺失。
- 没有分层原则 —— 团队未定义需求应当分几层，导致“想到哪写到哪”。
- 缺乏拆解模板 —— 没有标准模板（如Epic卡片、User Story模板、Task拆分规则），需求写手凭感觉发挥。
- 角色混淆 —— 产品经理写Epic，开发人员写Task，但中间User Story层无人负责。
- 评审缺失 —— 融合了粒度检查的评审环节不存在，粗或细都不会被标记。
使用以下判断规则快速定位根因：
判断规则表
IF 需求库中80%条目层级 ≤ 1 → 原因1（无分层原则）
ELSE IF 存在分层但条目内容混杂（Story写成了Task） → 原因2（无模板）
ELSE IF 分层明确但跨角色不一致 → 原因3（角色混淆）
ELSE → 原因4（评审缺失）4.4 修复动作：引入 Epic-User Story-Task 分层
立即执行以下修复步骤：
- 定义三层模型：
- Epic：业务目标级，包含用户价值与交付范围（例如“支持多语言知识库”）。
- User Story：用户功能级，格式为“作为…，我想要…，以便…”。
- Task：开发任务级，可估计人天，具体到实现动作（例如“实现Excel解析引擎”）。
- 重构现有需求：按上述模型重新拆分或合并条目。可使用以下模板卡片。
Epic 卡片
- ID: EPIC-001
- 标题: AI客服知识库导入功能
- 描述: 支持用户通过批量文件导入FAQ，降低知识库初始化门槛。
User Stories:
- US-001: 作为知识库管理员，我想要上传.xlsx文件，以便快速导入FAQ。
- US-002: 作为知识库管理员，我想要在导入前预览冲突，以避免重复。
Tasks for US-001:
- T-001: 设计文件上传接口（Rest API）
- T-002: 实现Excel格式校验模块（列头检查、数据格式检查）
- T-003: 后端批处理插入数据库（支持事务回滚）
- T-004: 前端上传进度条与错误反馈- 强制评审粒度：在需求评审环节增加“分层合规性检查点”，不符合者打回重写。
4.5 复测
修复后运行以下复测清单，验证粒度是否回归正轨：
| 检查项 | 合格标准 | 通过/失败 |
|---|---|---|
| 每个Story是否可以独立估算并完成？ | 是，且不对其他Story产生强依赖 | ☐ |
| Epic是否覆盖完整业务场景？ | 是，包含所有相关User Story | ☐ |
| Task是否可被单个开发者在1-3天内完成？ | 是，且不包含用户行为描述 | ☐ |
| 是否存在仍用纯UI操作描述的任务？ | 否，已替换为功能实现描述 | ☐ |
让两名产品经理独立检查同一批需求，交叉核对分层一致性。若不一致条目数 < 10% 则通过复测。
4.6 预防
长期预防措施
- 模板驱动：将Epic/Story/Task模板固化到需求管理工具中，创建新需求时强制选择层级。
- 工时校验：设定Task工时上限（3人天），若超出则自动提醒拆分。
- 定期审计：每双周随机抽检10条需求，计算粒度偏差率，纳入团队质量指标。
- 分层培训：组织30分钟工作坊，用正反案例对比加深理解。
下图为Epic-User Story-Task三层分解关系的可视化模型，帮助团队在预防阶段对照使用。