03 问题陈述：把现象转化为可操作的定义

TL;DR：问题陈述是把模糊现象转化为可操作定义的产物。一份合格的问题陈述包含四个要素：目标状态、当前状态、量化差距、不预设方案。最常见的问题是“把方案藏在问题里”——“我们需要增加 Redis”不是问题陈述，是方案。“如何将读延迟从 200ms 降到 50ms 且不增加超卖风险”才是问题陈述。好的问题陈述让多个方案可以竞争，坏的问题陈述已经预设了唯一答案。

概念解释

问题陈述的定义

问题陈述是一段可被多人一致理解的文字，它描述“要解决的差距是什么”，而非“要做的方案是什么”。它回答：目标在哪里、现状在哪里、差多少、边界在哪。问题陈述是问题定义的核心产物，相当于 ADR 之于决策——它是可被审阅、被质疑、被修正的中间物。

为什么“把方案藏在问题里”是最大陷阱

核心纪律：检查问题陈述时，问自己“除了当前想到的方案，这个问题还有其他解法吗？”如果只有一个解法，很可能问题陈述已经预设了答案。

目录

问题陈述四要素

关键：四要素中最难的是“不含方案”。大多数人写“问题”时已经在想“解法”，需要刻意练习把描述和方案分开。

问题陈述卡

## 问题陈述卡

**问题标题**: {一句话标题}
**日期**: YYYY-MM-DD
**提出者**: {谁}

### 目标状态
{可量化、可验证、不含方案}

### 当前状态
{有数据支撑、不含解释}

### 差距
{量化}

### 边界
**包含**: {在范围内}
**排除**: {明确不管什么}
**关键约束**: {不可妥协的条件}

### 利益相关者
- 受影响: {谁}
- 掌握事实: {谁}
- 有权决策: {谁}

### 可证伪条件
{什么证据出现时，问题定义需要修正}

软件工程示例

从现象到问题陈述的转化：

关键：问题陈述“降到 4h 以下且不降低质量”不预设方案，五个解法可以竞争。如果写成“我们需要增加评审者数量”，就只剩一个答案了。

适用边界与误用

• 不所有问题都需要正式陈述：简单 bug 直接修，不必写问题陈述卡。
• 问题陈述可以被修正：它不是一锤定音，随着因果分析深入，可能需要修正陈述。
• 不预设方案是最难的纪律：需要刻意练习，大多数“问题定义”里藏着方案。
• 问题陈述不等于根因：陈述说“差距在哪”，不说“为什么有差距”——后者交给因果分析。

关联笔记

• 问题定义总览：从现象到问题陈述（问题陈述是问题定义的核心产物）
• 5W2H：检查完整性的工具（用 5W2H 检查现象描述的完整性）
• MECE：互斥穷尽的分解原则（用 MECE 检查分解的完整性）
• 因果分析与根因分析（问题陈述后交给因果分析定位根因）

参考资料

• Are You Solving the Right Problems? — MIT Sloan Management Review
• What is Problem Solving? — ASQ
• The Minto Pyramid Principle — Barbara Minto