关于提问与回答

在「如何请求到他人的帮助来解决问题」上已经有许多优秀的指导文章,但在如何有效的帮助他人上似乎还是少了那么点东西。

授人予鱼不如…?

「帮助他人」自然算不上是什么难事,至少相比如何高效的提问来说是非常简单的了。但能够并不就代表着高效,很多时间我试着去帮助其他人解答他们的问题——无论难易或是问题给予的信息有多少,我总是将答案说的尽可能详细,想着以这样的方式来解决问题。

不得不承认这种方法有时相当有效,只需要告诉对方「啊,先这样,然后那样」他们的问题就被解决掉了。但是随着时间推移,我在社区里解答过的问题越来越多,渐渐的我感到疲倦。这种手把手的解答方式当然非常有效,但对方能得到什么,我们持续的输出知识又能得到什么?带着这样的想法,我开始不把话说的那么详细

举个例子。

原问题

我的回答

结果

以下是在另一个群内发生的,相同的问题不同的答案:

我觉得我成功让对方思考了一番,而不只是我在唱独角戏。
所以说,有时候解决问题应当是引导提问的人寻找思考的方向,而不只是告诉他答案。正所谓 授人以魚不如授人以漁

问句应使用问号而不是句号

如果提问者的态度令人发指,自然应该拒绝它。
就我所在的圈子里而言,我经常能见到一些人是这样问问题的:

遇到这样的提问者,我通常会猜测两种人。

  1. 语音输入用户
  2. 日常聊天说什么话末尾都要用个句号,连问句和感叹句都不放过的人

当然,语音输入用户没有做错任何事情。我无法理解的是第二种人,为什么日常聊天什么都得带个句号呢?对句号的执念是如此的深…

当然,以上是我的个人吐槽,若有冒犯请多见谅。本段的重点不在于用问号还是句号,而是提问的态度。没有任何人有义务在社区里为了各自的问题来逐一解答,大家的时间都很有限,所以正确的提问方式(而不只是态度)尤其重要。试想一下如果遇到了这样的问题:

反面教材

那么如何解决?一不知道用的是什么权限组插件,二不知道他是要干什么,这样的问题必须要有人来进一步引导才能解决,然而他甚至可能已经在群发这种问题,根本看不到你的反问。

由此,纠正错误的提问方式尤其重要,每个人都应该学会如何正确的提一个问题来尽可能快的得到帮助,对你好也对我好。

正如上文所说,*在「如何请求到他人的帮助来解决问题」上已经有许多优秀的指导文章*,但直接把这玩意扔出去多半也没有什么人会看。

但我们有别的做法。

Ex.1

Ex.2

还有一种是“问题类型收费表”,把最差的问法放最贵,最好的问法放免费,这也不失为一种巧妙的做法。

唯有问问题的人学着去问问题,解决问题的人才能把时间花在真正有用的地方上。

不要太多厨师

这句话其实出自英语里的 too many cooks in the kitchen,意思是这里有太多的人工作在同一件事情上,而这样会导致不好的结果。

正如上文的一个反例:

反例

各抒己见自然有利于自由讨论,但不适用于解决问题上,其实也很可能会演化成情绪倾泻的垃圾桶,每个人都在坚持自己的意见,甚至可能还会出现人身攻击。

当然,这种极端情况是后话而且并不多见。但一个问题确实不应该有太多的人上去解答,尤其是比较泛的问题。如果你已经看到有别的”厨师”正在解决这个问题,那么你只要纠正他的说法就好,而不是他说一套你也要跟着说一套,那样只会让提问的人更加混乱

「我 TM 到底听谁的」

找出真正的问题

有一种问题,我们管它叫做 Y 问题,为什么呢?
因为 Y 问题是 X 问题的一个分支,解决了 Y 问题自然可以解决 X 问题,但不代表必须解决 Y 问题才能解决 X 问题。

这就是 XY-Problem ,大家都经常犯的错误。如果你遇到了一些比较不合理的需求,不妨问一问提问者「你的原始需求是啥啊」,或许你会得到一个新的看问题的视野。

举个例子:

「Q:有没有什么插件可以替换任意 GUI 里面的文本啊,我只找到替换聊天信息的」
「A: 你要替换什么文本?」
「Q:XX 插件的菜单里面都是英文的,我想通过替换来翻译一下」
「A: 直接在 plugins\XXX\gui.yml 里面改就好了,用不着找那种插件,况且也没有。」

除了 X-Y 问题,也可能是提问者表述不清,适当引导即可。


说了这么多,其实核心只有两件事情:

  1. 引导——有时我们要引导提问者而不只是给他答案,但不代表所有的问题都需要引导。
  2. 态度——如果提问者的态度令人发指,你应该恰当的指出他的错误。

就此抛砖引玉,欢迎在评论区留下评论。

作者

iceBear67

发布于

2022-02-10

更新于

2022-02-10

许可协议

评论