# Problem Framing Canvas

> 问题框架画布 (Problem Framing Canvas)

- Skill: `dvcrn/problem-framing-canvas` (Agent Skill)
- Install (CLI): `npx skillmds@latest add dvcrn/problem-framing-canvas`
- Raw SKILL.md: https://api.skillmd.com/api/skills/dvcrn/problem-framing-canvas/raw
- Safety review: pending (external: skill-scanner PASS, skillspector PASS)
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: dvcrn (https://skillmd.com/u/dvcrn)
- Updated: 2026-09-21
- Page: https://skillmd.com/skills/dvcrn/problem-framing-canvas

---

# 问题框架画布 (Problem Framing Canvas)

> 版本：v1.0.0  
> 创建：2026-03-09  
> 作者：Elatia 🌀 (基于 Product-Manager-Skills 提炼)  
> 许可：MIT  
> 类型：Interactive Skill

---

## 📋 技能描述

**面向场景**: 复杂问题需要系统分析、团队对问题理解不一致、需要结构化问题拆解  
**目标用户**: 产品经理、战略顾问、项目负责人  
**核心价值**: 使用结构化画布全面分析问题，避免片面理解，建立系统性认知

---

## 🎯 核心能力

### 1. 九宫格问题框架
覆盖问题的 9 个关键维度：
- 问题描述（What）
- 用户/客户（Who）
- 影响范围（Scale）
- 根本原因（Why）
- 现有方案（Current）
- 成功标准（Success）
- 约束条件（Constraints）
- 利益相关者（Stakeholders）
- 风险假设（Risks）

### 2. 交互式填写
引导式问题填写每个象限：
- 逐层深入的问题
- 示例参考
- 质量检查

### 3. 框架完整性检查
自动识别缺失或薄弱的维度：
- 空白警示
- 模糊描述提醒
- 逻辑一致性验证

---

## 🔧 使用方式

### 方式 1: 交互式引导（推荐）

```markdown
/problem-framing-canvas
```

**画布填写流程**:

**1. 问题描述 (What)**
> 用一句话清晰描述问题
> - 问题是什么？
> - 不是什么？（边界）

**2. 用户/客户 (Who)**
> 谁受到这个问题影响？
> - 主要用户：[角色]
> - 次要用户：[角色]
> - 决策者：[角色]

**3. 影响范围 (Scale)**
> 问题的规模和严重程度
> - 影响人数：[量化]
> - 业务影响：[量化]
> - 紧急程度：[高/中/低]

**4. 根本原因 (Why)**
> 使用 5 Why 分析法
> - 表层原因：[直接原因]
> - 深层原因：[根本原因]

**5. 现有方案 (Current)**
> 当前如何应对这个问题
> - 内部方案：[现有做法]
> - 外部方案：[市场竞品]
> - 方案局限：[为什么不够]

**6. 成功标准 (Success)**
> 如何判断问题已解决
> - 定量指标：[可衡量的指标]
> - 定性指标：[可感知的变化]

**7. 约束条件 (Constraints)**
> 解决问题的限制因素
> - 时间约束：[deadline]
> - 资源约束：[预算/人力]
> - 技术约束：[技术限制]
> - 政策约束：[合规要求]

**8. 利益相关者 (Stakeholders)**
> 谁会受影响/谁能影响结果
> - 支持者：[谁会支持]
> - 反对者：[谁会反对]
> - 中立者：[谁需要争取]

**9. 风险假设 (Risks)**
> 需要验证的假设和潜在风险
> - 关键假设：[需要验证的]
> - 潜在风险：[可能出问题的]

---

### 方式 2: 快速模式

```markdown
/problem-framing-canvas quick \
  --problem "销售方案生成效率低" \
  --users "销售人员，销售总监" \
  --impact "每周 20 小时/人，成单率 15%" \
  --goal "30 分钟内完成方案，成单率 25%"
```

---

## 📝 输出模板

```markdown
# Problem Framing Canvas: [问题名称]

## 📋 画布总览

| 维度 | 内容摘要 |
|------|----------|
| What | [一句话问题描述] |
| Who | [主要用户/客户] |
| Scale | [影响范围] |
| Why | [根本原因] |
| Current | [现有方案] |
| Success | [成功标准] |
| Constraints | [约束条件] |
| Stakeholders | [利益相关者] |
| Risks | [风险假设] |

## 详细分析

### 1. 问题描述 (What)
**问题是什么**:
[详细描述]

**问题不是什么** (边界):
- [范围外 1]
- [范围外 2]

### 2. 用户/客户 (Who)
**主要用户**:
- [角色 1]: [描述 + 痛点]
- [角色 2]: [描述 + 痛点]

**决策者**:
- [角色]: [关注点]

### 3. 影响范围 (Scale)
**量化影响**:
- 影响人数：[数据]
- 时间成本：[数据]
- 金钱成本：[数据]

**业务影响**:
- [影响 1]
- [影响 2]

**紧急程度**: [高/中/低]  
**重要程度**: [高/中/低]

### 4. 根本原因 (Why)
**5 Why 分析**:
1. Why: [问题 1] → [答案 1]
2. Why: [问题 2] → [答案 2]
3. Why: [问题 3] → [答案 3]
4. Why: [问题 4] → [答案 4]
5. Why: [问题 5] → [答案 5]

**根本原因**:
[总结]

### 5. 现有方案 (Current)
**内部现有做法**:
- [做法 1]: [效果 + 局限]
- [做法 2]: [效果 + 局限]

**市场现有方案**:
- [竞品 1]: [优势 + 不足]
- [竞品 2]: [优势 + 不足]

**为什么现有方案不够**:
- [原因 1]
- [原因 2]

### 6. 成功标准 (Success)
**定量指标**:
- [指标 1]: [当前值] → [目标值]
- [指标 2]: [当前值] → [目标值]

**定性指标**:
- [指标 1]: [期望状态]
- [指标 2]: [期望状态]

**时间框架**:
- 短期（1 月）: [里程碑]
- 中期（3 月）: [里程碑]
- 长期（6 月+）: [里程碑]

### 7. 约束条件 (Constraints)
**时间约束**:
- [约束描述]

**资源约束**:
- 预算：[金额]
- 人力：[人数/角色]

**技术约束**:
- [技术限制]

**政策/合规约束**:
- [合规要求]

### 8. 利益相关者 (Stakeholders)
**支持者** (Who wants this to succeed):
- [角色 1]: [利益点]
- [角色 2]: [利益点]

**反对者** (Who might resist):
- [角色 1]: [担忧点]
- [角色 2]: [担忧点]

**中立者** (Who needs to be convinced):
- [角色 1]: [关注点]
- [角色 2]: [关注点]

### 9. 风险假设 (Risks)
**关键假设** (需要验证):
- ⚠️ 假设 1: [描述] - 验证方法：[方法]
- ⚠️ 假设 2: [描述] - 验证方法：[方法]

**潜在风险**:
- 🔴 高风险: [风险描述 + 应对]
- 🟡 中风险: [风险描述 + 应对]
- 🟢 低风险: [风险描述 + 应对]

## 框架完整性检查

| 维度 | 完整度 | 质量 |
|------|--------|------|
| What | ✅ 完整 | 🟢 清晰 |
| Who | ✅ 完整 | 🟢 清晰 |
| Scale | ⚠️ 部分 | 🟡 需量化 |
| Why | ✅ 完整 | 🟢 清晰 |
| Current | ✅ 完整 | 🟢 清晰 |
| Success | ✅ 完整 | 🟢 清晰 |
| Constraints | ✅ 完整 | 🟢 清晰 |
| Stakeholders | ⚠️ 部分 | 🟡 需补充 |
| Risks | ✅ 完整 | 🟢 清晰 |

## 下一步行动

### 立即行动 (本周)
- [行动 1]: [负责人]
- [行动 2]: [负责人]

### 验证行动 (本月)
- [验证假设 1]: [方法 + 时间]
- [验证假设 2]: [方法 + 时间]

### 决策点
- [日期]: [需要做的决策]
```

---

## 📚 示例

### 示例：销售方案效率问题

```markdown
# Problem Framing Canvas: 销售方案生成效率低

## 📋 画布总览

| 维度 | 内容摘要 |
|------|----------|
| What | 销售人员每次从零开始写方案，平均耗时 2 小时，效率低质量不稳定 |
| Who | 销售人员（15 人）、销售总监、客户 |
| Scale | 每周 30 小时/团队，成单率 15%，人力成本高 |
| Why | 缺乏模板和知识库，依赖个人经验 |
| Current | 个人经验 + 历史方案复用，效果有限 |
| Success | 30 分钟/方案，成单率 25%，满意度≥4/5 |
| Constraints | 预算 50 万，3 个月上线，不能影响现有业务 |
| Stakeholders | 销售团队支持，IT 部门中立，财务关注 ROI |
| Risks | 假设销售愿意用新工具，风险是 adoption rate 低 |

## 详细分析

### 1. 问题描述 (What)
**问题是什么**:
销售人员每次拜访客户后，需要从零开始撰写解决方案 PPT，平均耗时 2 小时/份，且质量依赖个人经验，导致：
- 新人产出慢且质量差
- 资深销售重复劳动多
- 整体成单率仅 15%

**问题不是什么** (边界):
- 不是 CRM 系统问题（客户管理已有系统）
- 不是销售能力问题（核心是工具支持不足）
- 不是合同/报价问题（那是后续流程）

### 2. 用户/客户 (Who)
**主要用户**:
- 销售人员（15 人）: 需要快速生成高质量方案，减少加班
- 销售新人（5 人）: 需要模板和指导，快速上手

**决策者**:
- 销售总监张经理：关注成单率和团队效率

**间接受益者**:
- 客户：获得更专业、更及时的方案
- 公司：提升整体销售业绩

### 3. 影响范围 (Scale)
**量化影响**:
- 影响人数：15 人销售团队
- 时间成本：2 小时/方案 × 10 方案/周 = 20 小时/人/周
- 团队成本：300 小时/周 ≈ 7.5 人天/周
- 成单率：15%（行业平均 25%）

**业务影响**:
- 人力成本高：大量时间用于重复劳动
- 机会损失：成单率低，年损失约 500 万
- 团队士气：加班严重，流失率高

**紧急程度**: 高  
**重要程度**: 高

### 4. 根本原因 (Why)
**5 Why 分析**:
1. Why: 为什么方案生成慢？ → 每次从零开始
2. Why: 为什么从零开始？ → 没有可复用的模板
3. Why: 为什么没有模板？ → 没有系统沉淀最佳实践
4. Why: 为什么没有沉淀？ → 缺乏知识管理意识和工具
5. Why: 为什么缺乏？ → 过去业务增长快，忽视了效率优化

**根本原因**:
业务快速增长期忽视了知识沉淀和工具建设，导致销售方案能力无法规模化复制。

### 5. 现有方案 (Current)
**内部现有做法**:
- 历史方案复用：找类似客户的方案修改 → 耗时且可能不匹配
- 资深销售带新人：口传心授 → 不可规模化
- 个人模板：每人有自己的模板 → 质量参差不齐

**市场现有方案**:
- PPT 模板网站：通用模板多，行业化不足
- 方案代写服务：质量好但成本高（5000 元/份）
- CRM 内置方案模块：功能简单，不够灵活

**为什么现有方案不够**:
- 不够行业化：通用模板不适合 B2B 销售场景
- 不够智能：不能根据客户需求自动推荐内容
- 不够易用：学习成本高，销售不愿意用

### 6. 成功标准 (Success)
**定量指标**:
- 方案生成时间：2 小时 → 30 分钟
- 成单率：15% → 25%
- 销售满意度：2.5/5 → 4/5
- 新人上手时间：3 月 → 2 周

**定性指标**:
- 销售感到"有支持，不孤单"
- 客户感到"方案专业，懂我需求"
- 管理层感到"可预测，可管理"

**时间框架**:
- 短期（1 月）: MVP 上线，10 个模板
- 中期（3 月）: 全团队使用，覆盖 80% 场景
- 长期（6 月+）: AI 智能推荐，持续优化

### 7. 约束条件 (Constraints)
**时间约束**:
- 3 个月内必须上线（Q2 结束前）

**资源约束**:
- 预算：50 万（含开发 + 运营）
- 人力：2 个开发 +1 个产品 +1 个设计

**技术约束**:
- 必须与现有 CRM 系统集成
- 支持 PPT 导出（.pptx 格式）

**政策/合规约束**:
- 客户数据不能出境
- 符合公司信息安全规范

### 8. 利益相关者 (Stakeholders)
**支持者**:
- 销售团队：直接受益，减少加班
- 销售总监：成单率提升，业绩好

**反对者**:
- 资深销售：担心"被替代"，不愿分享经验
- IT 部门：担心增加维护负担

**中立者**:
- 财务部门：关注 ROI，需要数据说服
- HR 部门：关注培训成本

### 9. 风险假设 (Risks)
**关键假设** (需要验证):
- ⚠️ 假设 1: 销售愿意使用新工具生成方案 → 验证：MVP 测试，跟踪 adoption rate
- ⚠️ 假设 2: 模板化方案不会降低客户感知 → 验证：A/B 测试，对比成单率
- ⚠️ 假设 3: 30 分钟目标是可行的 → 验证：原型测试，计时验证

**潜在风险**:
- 🔴 高风险: 销售 adoption rate 低 (<50%) → 应对：早期深度参与，激励机制
- 🟡 中风险: 模板质量不够 → 应对：资深销售审核，持续迭代
- 🟢 低风险: 技术延期 → 应对：MVP 范围可控，有 buffer

## 框架完整性检查

| 维度 | 完整度 | 质量 |
|------|--------|------|
| What | ✅ 完整 | 🟢 清晰 |
| Who | ✅ 完整 | 🟢 清晰 |
| Scale | ✅ 完整 | 🟢 清晰 |
| Why | ✅ 完整 | 🟢 清晰 |
| Current | ✅ 完整 | 🟢 清晰 |
| Success | ✅ 完整 | 🟢 清晰 |
| Constraints | ✅ 完整 | 🟢 清晰 |
| Stakeholders | ✅ 完整 | 🟢 清晰 |
| Risks | ✅ 完整 | 🟢 清晰 |

## 下一步行动

### 立即行动 (本周)
- 访谈 5 个销售，收集历史方案：产品经理
- 竞品分析（3 家）：产品经理

### 验证行动 (本月)
- 验证假设 1: 制作低保真原型，找 3 个销售试用
- 验证假设 2: 收集 20 个历史方案，分析共性

### 决策点
- 3 月 15 日：是否立项（基于 MVP 测试结果）
```

---

## 🎯 质量标准

### 好的问题框架画布
- ✅ 九个维度完整（没有明显缺失）
- ✅ 描述具体（有数据有细节）
- ✅ 逻辑一致（各维度相互支撑）
- ✅ 假设明确（标注需要验证的）
- ✅ 可执行（有下一步行动）

### 常见陷阱
- ❌ 维度缺失（跳过某些象限）
- ❌ 描述模糊（"提升效率"太抽象）
- ❌ 逻辑矛盾（成功标准与约束冲突）
- ❌ 假设隐藏（把猜测当事实）
- ❌ 没有行动（分析完就结束了）

---

## 🔗 与其他技能的关系

| 技能 | 关系 | 使用时机 |
|------|------|----------|
| problem-statement | 前置/后置 | 简单问题用 problem-statement，复杂问题用 canvas |
| opportunity-solution-tree | 后置 | 问题框架清晰后，展开解决方案 |
| epic-hypothesis | 后置 | 基于画布输出形成史诗假设 |
| company-research | 前置 | B2B 场景先做客户调研填充画布 |

---

## 📈 成功指标

| 指标 | 目标值 | 测量方式 |
|------|--------|----------|
| 框架完整度 | ≥90% | 九个维度都有内容 |
| 团队共识度 | ≥90% | 团队成员认同问题框架 |
| 行动转化率 | ≥80% | 画布输出转化为实际行动 |

---

## 🔖 版本历史

| 版本 | 日期 | 变更 |
|------|------|------|
| v1.0.0 | 2026-03-09 | 初始版本，基于 Product-Manager-Skills 提炼 |

---

## 📄 许可

MIT License

---

*基于 Product-Manager-Skills by Dean Peters · CC BY-NC-SA 4.0*  
*适配 OpenClaw 标准：Elatia 🌀*