4. 业务问题拆解：问题树构建、问题分层、问题与RICE的映射、问题边界界定

4.1 为什么需要系统化问题拆解

面对模糊、宽泛的业务需求，直接进入原型设计会导致频繁返工、边界模糊和评分失真。系统化拆解将宏观问题逐层分解为可评估的原子单元，使RICE评分建立在统一的问题粒度之上。四个步骤构成完整链路：问题树构建（结构化分解）→ 问题分层（确定评估层级）→ 问题与RICE映射（量化对齐）→ 问题边界界定（划定评分范围）。

4.2 问题树构建：从模糊到结构

问题树是将一个宽泛的业务问题逐层分解为相互独立、完全穷尽的子问题集合。构建时以原始问题为根，按MECE原则展开第一层（通常为3~5个维度），再对每个子节点继续拆解，直到每个叶子节点可以直接评估RICE为止。

4.3 问题分层：从战略到执行

问题分层将问题树中的节点按决策层级归类：战略层（做什么/为什么做）、策略层（怎么做/用什么方式）、执行层（具体操作细节）。同一问题在不同层级下RICE评分的权重和评判标准截然不同。

• 战略层问题：影响产品方向、商业模式、核心价值。例如"是否要支持跨平台作业提交" → RICE中Impact权重最高。
• 策略层问题：影响实现路径、交互模式、功能组合。例如"采用拖拽上传还是选择文件对话框" → RICE中Effort和Reach权重居中。
• 执行层问题：影响开发细节、UI样式、文案措辞。例如"上传进度条是圆形还是线性" → RICE中Confidence权重最高，Impact较低。

4.4 问题与RICE的映射

将分层后的每个叶子问题分别映射到RICE四维：Reach（影响用户数/频率）、Impact（对核心指标的影响程度）、Confidence（数据/经验支撑强度）、Effort（开发/设计/测试人天）。映射结果填入标准化矩阵。

4.5 问题边界界定

边界界定决定"哪些问题进入本轮原型设计"，避免RICE评分后仍无法聚焦。三类边界状态：

• 边界内：问题与当前迭代目标直接相关，RICE总分 ≥ 阈值（如20分），必须进入原型设计。
• 边界模糊：问题可能影响当前迭代但证据不足，需要先进行验证性原型（低保真/概念验证），RICE总分在阈值区间波动。
• 边界外：问题与当前迭代无关，或RICE总分明显低于阈值，标记为"待定/未来版本"，不投入原型资源。

4.6 综合案例：作业提交系统问题拆解全流程

以"学生无法在移动端提交作业"为例，走通四阶段：

1. 问题树构建：根问题 → 用户问题（移动端缺失/流程复杂/反馈延迟）→ 叶子节点"移动端提交入口不明确"
2. 问题分层：归属战略层（影响产品覆盖率和用户留存）
3. RICE映射：Reach=5, Impact=5, Confidence=4, Effort=3 → RICE=33.3
4. 边界界定：33.3 ≥ 20 → 边界内，进入原型设计

最终输出清晰的问题卡片，直接作为原型设计输入。

4.7 交付物模板

以下模板可直接用于团队协作，建议嵌入产品需求文档（PRD）或原型评审看板。

// 问题树构建示例（JSON 格式，可直接导入项目管理工具）
{
  "root": "提升作业提交系统效率",
  "children": [
    {
      "dimension": "用户问题",
      "nodes": [
        {"id": "U-01", "label": "移动端提交入口不明确", "layer": "战略"},
        {"id": "U-02", "label": "上传后无成功反馈", "layer": "执行"}
      ]
    },
    {
      "dimension": "业务问题",
      "nodes": [
        {"id": "B-01", "label": "截止时间后仍可提交", "layer": "策略"},
        {"id": "B-02", "label": "抄袭检测覆盖率低", "layer": "战略"}
      ]
    },
    {
      "dimension": "技术问题",
      "nodes": [
        {"id": "T-01", "label": "大文件上传超时", "layer": "策略"},
        {"id": "T-02", "label": "格式转换失败无提示", "layer": "执行"}
      ]
    }
  ]
}