Capture捕获层——识别和定义问题 ​

80%的问题出在问题定义 ​

一个程序员朋友跟我说："我花了三天优化首页性能，结果产品经理说不是这个意思。"

我问他："产品经理一开始怎么说的？"

他说："产品说'首页太慢了，优化一下'。"

这就是典型的问题：问题没定义清楚就开始做。

"首页太慢"不是一个好的问题定义。什么叫"慢"？加载慢？交互慢？慢到什么程度？和谁比慢？

如果他一开始花10分钟问清楚，可能就不会浪费三天。

什么是好的问题定义 ​

在逻辑学中，一个好的问题定义必须是一个命题。

什么是命题？一个可以判断真假的陈述。

看这两个表述：

表述A："性能不好"
表述B："首页首屏加载时间超过3秒"

表述A不是命题——你没法判断它是真是假。什么叫"不好"？没有标准。

表述B是命题——你可以测量，可以判断它是真是假。

好的问题定义 = 可验证的命题

定义的三条逻辑规则 ​

逻辑学对"定义"有三条基本要求：

规则一：清晰 ​

定义中的概念必须是明确的，不能有歧义。

❌ "提升用户体验"
—— 什么是用户体验？怎么算提升？

✅ "将注册流程从5步减少到3步"
—— 概念清晰，可以验证

规则二：不循环 ​

不能用要定义的词来定义它自己。

❌ "优化性能就是让性能更好"
—— 循环了，没有增加信息

✅ "优化性能就是将接口响应时间从2秒降到500毫秒"
—— 给出了具体标准

规则三：适当（不过宽不过窄） ​

定义的范围要恰好覆盖要解决的问题。

过宽："解决所有的性能问题"
—— 范围太大，无法执行

过窄："只解决首页图片加载问题"
—— 如果问题不只是图片呢？

适当："解决首页首屏加载超过3秒的问题"
—— 范围明确，可执行

5W2H：问题定义的实操工具 ​

知道了好定义的标准，怎么做到？

用5W2H框架，系统性地定义问题。

实例演示 ​

收到需求："首页太慢了，优化一下"

用5W2H分析：

## What - 具体是什么问题？
首页加载慢。

追问：什么叫"慢"？
→ 首屏加载时间超过3秒

追问：是所有用户都慢，还是部分用户？
→ 主要是弱网环境下的用户

## Why - 为什么要解决？
用户流失率高。

追问：有数据支撑吗？
→ 数据显示首屏加载超过3秒，跳出率增加40%

## Who - 谁受影响？
弱网环境下的用户。

追问：占比多少？
→ 约30%的用户

## Where - 在哪里发生？
首页首屏区域。

追问：其他页面呢？
→ 目前只关注首页

## When - 什么时候解决？
下周五上线。

追问：有优先级吗？
→ P0优先级

## How much - 影响/资源？
目标：首屏加载时间降到2秒以内。
资源：1个前端，1周时间。

经过5W2H，问题从"首页太慢了"变成了：

问题定义：在弱网环境下，首页首屏加载时间超过3秒，导致30%用户流失。需要在一周内将加载时间降到2秒以内。

这才是一个可执行的问题定义。

一句话问题陈述公式 ​

当你用5W2H收集完信息后，可以用这个公式写出问题陈述：

[背景/现状] + [需要达成的目标] + [主要挑战/约束]

示例：

背景：弱网环境下，首页首屏加载时间超过3秒
目标：将加载时间降到2秒以内
约束：一周时间，一个前端资源

→ 问题陈述：
"在弱网环境下首页首屏加载超过3秒，
需要在一周内将其降到2秒以内，
约束是只有一个前端资源。"

如果你能用一句话说清楚问题，说明你真的理解了这个问题。

检查点：问题定义的逻辑检验 ​

定义完问题，用这个检查清单验证：

□ 概念清晰：问题中的关键词有明确定义吗？
  - "慢"→ 超过3秒
  - "优化"→ 降到2秒以内

□ 不循环：定义是否提供了新信息？
  - 不是"解决性能问题就是让性能更好"

□ 范围适当：不过宽不过窄？
  - 不是"解决所有性能问题"
  - 不是"只解决某一个图片"

□ 可验证：能判断问题是否解决了吗？
  - "加载时间是否降到2秒以内"可以测量

□ 一句话：能用一句话说清楚吗？
  - 如果不能，说明还没真正理解

全部通过，才能进入下一步。

有未通过的，继续追问和澄清。

常见的问题定义错误 ​

错误一：把方案当问题 ​

❌ "我们需要用Redis缓存"
—— 这是方案，不是问题

✅ "接口响应时间过长，需要优化"
—— 这才是问题

先定义问题，再讨论方案。

错误二：把表象当问题 ​

❌ "用户投诉说页面白屏"
—— 这是表象

✅ "某些情况下JS报错导致页面渲染失败"
—— 这才是问题

需要追问"为什么"，找到真正的问题。

错误三：问题太大无法执行 ​

❌ "提升整体用户体验"
—— 无法执行

✅ "将核心流程的步骤从5步减少到3步"
—— 可以执行

大问题需要拆成小问题。

本章小结 ​

核心观点：

• 80%的问题出在问题定义不清
• 好的问题定义必须是可验证的命题
• 定义要满足三条规则：清晰、不循环、适当

实操工具：

• 5W2H：系统性收集问题信息
• 一句话公式：背景 + 目标 + 约束

检查点：

□ 概念清晰
□ 不循环
□ 范围适当
□ 可验证
□ 能用一句话说清楚

下一章，我们讲信息收集——定义清楚问题后，如何收集充足的信息。