关于 problem-framing
problem-framing 是供项目或分析启动阶段使用的探索技能,面向需要先明确问题的团队。它通过收集背景、追查根因、重新构建问题并审核问题陈述,再进入解决方案工作。
主要功能
- 01以人为中心的背景收集
- 02五个为什么根因分析
- 03重新构建问题与设计提问
- 04定义获胜愿景
- 05问题陈述审批门控
适用场景
- 01分析前界定新项目问题
- 02调查陷入停滞的项目
- 03协调利益相关者对成功的定义
- 04区分用户需求与既定方案
安装
复制下面的命令,在终端中运行。
$
npx skills add https:/ / github.com/ joellewis/ skill-library --skill problem-framing安装后在 Claude Code 中输入/problem-framing确认已加载。
详细介绍
概述
问题界定是“发现关卡”,确保在投入资源寻找解决方案之前,你解决的是正确的问题。它运用以人为本的设计原则和战略级联,将关注点从表象转向根本原因。
铁律
未经批准的问题界定,不得进行分析
过早分析会导致解决错误的问题,将资源浪费在针对低价值或不存在问题的精巧方案上。
状态机
digraph problem_framing_flow {
"Start" [shape=doublecircle];
"Step 1: Observe & Gather Context" [shape=box];
"Step 2: Root Cause Analysis (5 Whys)" [shape=box];
"Step 3: Reframing & Questioning" [shape=box];
"Gate: User Approval of Problem Statement" [shape=diamond];
"Step 4: Define Winning Aspiration" [shape=box];
"Done: Discovery Gate Passed" [shape=doublecircle];
"Start" -> "Step 1: Observe & Gather Context";
"Step 1: Observe & Gather Context" -> "Step 2: Root Cause Analysis (5 Whys)";
"Step 2: Root Cause Analysis (5 Whys)" -> "Step 3: Reframing & Questioning";
"Step 3: Reframing & Questioning" -> "Gate: User Approval of Problem Statement";
"Gate: User Approval of Problem Statement" -> "Step 4: Define Winning Aspiration" [label="approved"];
"Gate: User Approval of Problem Statement" -> "Step 1: Observe & Gather Context" [label="rejected"];
"Step 4: Define Winning Aspiration" -> "Done: Discovery Gate Passed";
}
何时使用此技能
- 开始任何新项目、战略或分析任务时。
- 项目陷入“停滞”或方向不明时。
- 利益相关者对成功的定义相互冲突时。
- 发现自己还未充分理解“是什么”或“为什么”,就直接跳到“怎么做”时。
何时不使用此技能
- 对于有既定且经过验证的流程、熟悉且常规的任务。
- 对于界定成本超过潜在价值的琐碎任务(例如,修正拼写错误)。
- 问题已在之前的步骤中经过严格界定并获批时。
核心流程
第 1 步:观察并收集背景信息
- 运用应用民族志: 在用户的自然环境中观察他们,了解其动机、兴趣和真实需求。重点关注他们进行的活动,而不仅仅是人口统计特征。(来源:Norman,《设计心理学》)
- 描述问题: 力求比任何人都更清楚地描述问题。“最善于描述问题的人,最有可能解决问题。”(来源:Kaufman,《个人 MBA》)
- 收集 SPIN 背景信息: (1) 了解当前情况;(2) 找出人们感知到的问题;(3) 明确短期和长期影响。(来源:Kaufman,《个人 MBA》)
第 2 步:根本原因分析(5 个为什么)
- 执行五个为什么分析: 至少问五次“为什么?”,越过表象,找到最终的根本原因。(来源:Norman,《设计心理学》)
- 避免陷入“人为错误”陷阱: 不要在“人为错误”处停止分析。调查导致错误发生的系统、设计或环境。(来源:Norman,《设计心理学》)
第 3 步:重新界定并提出问题
- 质疑阻碍进展的信念: 找出阻碍进展的信念(例如,“我们一直都是这么做的”或“这不可能”),并将其重新界定为设计挑战。(来源:Burnett,《设计你的人生》)
- 提出恰当的问题: 避免提出问题时就预设了解决方案(例如,“我们如何造一架更好的梯子?”与“我们如何才能到达高处?”)。(来源:Burnett,《设计你的人生》)
- 识别锚定问题: 认识到有些问题以当前形式无法解决,并将其重新界定为可付诸行动的挑战。(来源:Burnett,《设计你的人生》)
- 对比感知: 运用界定方式突出至关重要的细节,同时淡化无关信息,从而聚焦注意力。(来源:Kaufman,《个人 MBA》)
第 4 步:定义制胜目标
- 设定制胜目标: 明确成功的样子。这将为战略级联中的所有后续战略选择(选择战场、如何制胜)设定背景。(来源:Lafley,《制胜》)
- 量化需求收益: 阐明问题解决后客户/用户将获得的财务和情感收益。(来源:Kaufman,《个人 MBA》)
跨技能调用
必需的子技能:using-skills — 确保遵循规范的技能调用纪律。
推荐的子技能:stakeholder-discovery — 梳理哪些人需要批准问题界定。
理性化借口表
| 想法 | 现实 |
|---|---|
| “问题显而易见,我们直接开始吧。” | 显而易见的问题通常只是更深层根本原因的表象。 |
| “我们没时间开展问题界定工作坊。” | 解决错误的问题,耗时远超正确地界定问题。 |
| “客户已经告诉我们问题是什么了。” | 客户往往描述的是他们认为自己需要的解决方案,而非实际问题。 |
| “我会边分析边界定问题。” | 没有问题界定的分析漫无目的,而且容易产生确认偏误。 |
危险信号
出现以下想法就意味着该停下来了——你正要走捷径:
- “我以前见过一模一样的问题,我知道答案。” → 你正在未经验证就陷入模式匹配。
- “我们需要构建 [Specific Solution]。” → 你界定的是解决方案,而不是问题。
- “为什么?因为 [Name] 这么说。” → 你止步于权威,而没有追查根本原因。
诊断清单
- 问题是否从人的需求或目标出发,而非技术要求?
- 你是否至少问过五次“为什么?”,以找到根本原因?
- 问题陈述是否避免提及任何具体解决方案?
- 是否有明确的“制胜愿景”来定义成功的样子?
- 是否通过观察用户在自然环境中的表现,验证了问题陈述?
来源
- Kaufman,《The Personal MBA》,第 3 章(价值创造),第 6 章(销售/SPIN)
- Lafley,《Playing to Win》,第 2 章(制胜愿景),第 5 章(战略级联)
- Norman,《The Design of Everyday Things》,第 1 章(可供性/指示符),第 6 章(设计思维/以人为本的设计)
- Burnett,《Designing Your Life》,第 1 章(重新界定/功能失调的信念)
- Kuang,《User Friendly》,第 5 章(观察与创造)
- Berkun,《Making Things Happen》,第 5 章(问题定义)
评论
支持 Markdown