第二讲:明确目标——在提问前,先问自己三个问题,锁定你的真实需求

很多人问我:「为什么我提的问题,对方总是不耐烦?」

我通常会反问一句:「你确定自己知道想问什么吗?」

对方往往一愣。嗯,这就是问题所在。

我自己带团队这些年,发现一个规律:80%的烂问题,根源都在于提问者自己都没想清楚要什么。你想想看,一个连目标都模糊的问题,别人怎么可能给你精准的答案?

为什么我们总在「瞎问」?

先说说我自己的经历。刚工作那会儿,我遇到一个bug,跑去问组长:「这个程序跑不动了,怎么办?」

组长看了我一眼:「什么程序?什么环境?报什么错?」

我支支吾吾答不上来。他叹了口气:「你先搞清楚问题是什么,再来找我。」

当时觉得委屈,后来才明白——我连自己的需求都没锁定,就急着要答案。这就像去医院跟医生说「我不舒服」,医生也得先问「哪里不舒服」「多久了」「什么感觉」对吧?

核心观点:提问前先花30秒问自己三个问题,能帮你过滤掉至少一半的无效提问。

第一个问题:我到底遇到了什么?

这个问题听起来简单,但很多人栽在这里。

举个例子。有次一个同事跑来问我:「这个API调不通,怎么回事?」

我问他:「调不通是什么意思?超时?报错?返回空数据?」

他想了想:「哦,是返回了500错误。」

你看,「调不通」是一个模糊的感受,「返回500错误」才是一个具体的事实

怎么把模糊变成具体?我建议你用这个框架:

  • 现象是什么?(看到了什么、听到了什么、发生了什么)
  • 环境是什么?(在什么条件下发生的、用了什么工具)
  • 频率是什么?(每次都这样、偶尔这样、还是第一次)

说白了,就是把你脑子里的「一团浆糊」,拆成几个可以描述的「小块」。

小技巧:试着用「主语+谓语+宾语+状语」的句式来描述问题。比如「用户登录接口在并发100个请求时,返回了30%的500错误」。比「登录有问题」强一百倍。

第二个问题:我想要什么结果?

这个问题更关键,但也更容易被忽略。

我见过太多人,描述完问题后,就等着对方给答案。但对方根本不知道你想要什么程度的答案。

举个例子:

  • 「这个bug怎么修?」——你想要的可能是具体代码
  • 「这个bug的根因是什么?」——你想要的可能是分析思路
  • 「这个bug怎么避免?」——你想要的可能是最佳实践

同一个问题,不同的目标,答案天差地别。

我自己有个习惯:在提问前,先想清楚「我拿到答案后要做什么」

  • 如果是为了解决问题,那就问「怎么做」
  • 如果是为了学习原理,那就问「为什么」
  • 如果是为了做决策,那就问「选哪个」

避坑指南:我曾经犯过一个错——问了一个「这个框架好不好」的问题,结果对方讲了半小时优缺点,但我其实只是想确认它能不能支持高并发。目标不明确,浪费双方时间。

第三个问题:我已经知道了什么?

这个问题,是帮你过滤掉那些「百度一下就能知道」的答案

我经常收到这样的提问:「老师,Python怎么安装?」

说实话,这种问题让我很无奈。因为网上有无数教程,你花5分钟搜一下就能解决。

所以,在提问前,先问问自己:

  • 我查过资料了吗?
  • 我试过哪些方法?
  • 我卡在了哪一步?

如果你能说「我查了官方文档,按照步骤装到第三步,报了这个错」,那对方就知道你是认真思考过的,也更愿意帮你。

记住:提问不是把问题甩给别人,而是展示你已经做了哪些努力,然后请求对方帮你突破最后那层窗户纸。

三个问题,一个公式

把上面三个问题串起来,就是一个提问前的自检公式:

我遇到了【具体现象】,
在【具体环境】下,
我想要【具体结果】,
我已经尝试了【具体方法】,
卡在了【具体环节】。

举个例子:

  • ❌ 烂问题:「这个程序跑不动了,怎么办?」
  • ✅ 好问题:「我在Windows 10上用Python 3.9运行数据分析脚本,数据量10万行时,程序运行到第3步就报MemoryError。我已经试过增加虚拟内存,但没用。请问有什么办法能优化内存使用?」

你看,后者是不是让人更愿意回答?

实战练习:改造你的问题

现在,拿出你最近想问的一个问题,用这个公式改造一下:

要素 你的回答
具体现象 (写下来)
具体环境 (写下来)
想要的结果 (写下来)
已尝试的方法 (写下来)
卡住的环节 (写下来)

填完之后,你会发现:原来我的问题可以这么清晰

最后提醒:这三个问题不是让你背下来,而是养成习惯。刚开始可能会觉得麻烦,但用上几次,你就会发现——提问效率翻倍,回答质量也翻倍。

下一讲,我们会聊聊「如何用5W1H法,把模糊的问题拆解成可执行的步骤」。嗯,到时候见。