如何看待提问这件小事？

编辑导语：提问，这件事虽然看起来很简单，但是实际上却暗藏技巧与玄机。会提问的人往往可以很轻松的问到自己想要的答案，而且与被提问者保持轻松的谈话氛围；而不会提问的人往往很难与被提问者深入的进行沟通，使得自己得到的答案浮于表面，深度不足。那么，我们究竟该如何看待提问这件小事呢？

本文主要内容如下：

• 我们为什么想提问？
• 提问的目的是什么？
• 如何让一次提问的价值最大化？

一、提问只是问题的解决方式之一

我们为什么会在某些场合想提问？

有些时候，我们遇到了一些棘手的问题，自己找不到答案，因此我们希望通过提问来找到答案，其他的时候，我们遭遇了一些困惑，希望有人解答困惑指出明路，因此我们通过提问来获得一些建议。

所以，提问是为了解决问题。从解决问题的角度，我们重新看待一下提问这件事，以下是一次解决问题的通用思路：

本着解决问题的目的，很多人潜意识想通过提问来走捷径，从第一步直接跳到第七步的那种，遇到问题只想快速得到答案，所以即使动动手百度就能获得的答案，也习惯于张嘴提问。

的确，找对人提对问题，能够让我们更快的接近真相，对他来说的常识，只要张张嘴就可以低成本解决你的问题，让你走出困惑。

但解决问题的步骤是固定的，你走捷径意味着有人为你负重前行。

一个含糊不清的没有针对性的问题，比如“怎么找工作？”，这个问题问出来之后，如果要帮你找到答案，对方需要帮你逐步明确问题，了解你的喜好、专业、背景，了解你目前所处的阶段。

现阶段找工作最大的卡点，再基于自己的经验和了解给到一些帮助和建议作为回答。

被答疑解惑的快乐是你的，脏活累活是人家的，这个过程一定是不可持续的。因为你在获得输入，他人在持续输出，价值的流动是单向的。

所以，我们需要先摆正对提问的预期，什么时候适合使用提问这个工具来协助我们解决问题。

我的答案是，当且仅当你做了足够充分的功课和思考，明确问题的现状，以及你当前无法独立通过除提问以外的其他渠道获取到这部分关键信息/依赖自己当前的决策模型无法破局的时候，可以考虑场外求助，即提问。

也就是说，你需要先独立完成234，再在第5步的时候考虑人作为你的信息来源，这是对彼此时间和精力的尊重。

因此，不要对提问有过高的不切实际的预期，希望对方帮你分析问题，帮你梳理现状，帮你做决策，帮你担风险，否则，你很难通过提问来满足预期。

举个例子：你拿到了百度的产品offer和新浪的产培offer。

然后你恰好认识一个比较信任的已经在职的一位产品经理，如果恰巧有机会向其咨询的话，你应该做的是，先想清楚自己在两份工作中无法决策的关键原因，一定是有一些考虑在的，否则你为什么不掷骰子，而是要找人问。

想清楚你为什么无法决策，是因为你觉得A哪里不好，或者B哪里不匹配，还是因为你既舍不得A的薪资，又舍不得B的食堂，你需要对方给你提供什么信息，明确的告诉对方你的诉求。

比如：我拿到了百度的产品offer和新浪的产培offer，对于找工作的主要考虑是薪资和发展机会以及工作氛围。目前根据我获取到的信息，两边的薪资相差不大，无法决策的主要原因在于无法衡量发展机会和工作氛围。

学姐之前在其中一家公司待过，因此不知道方不方便请教一下关于部门的工作氛围，当然我理解每个部门肯定也不太一样，因此学姐以你之前待过的部门举例即可，我主要想了解一下部门的工作节奏和协作模式

而不是直接上来就问：学姐，我拿到了百度的产品offer和新浪的产培offer，你觉得选哪个好？

总之，问题越具体，越有可能获取你想要的信息，越有可能基于这个信息推进问题的解决。

二、提问不是目的，目的是解决问题

既然核心目的是为了解决问题，那么仅仅明确自己是否需要提问是不够的，提出问题是为了得到相应的信息，问题存在的意义是被回答，所以围绕被回答，我们至少需要思考这么几件事。

• 我究竟想知道什么
• 谁有可能知道答案？
• 他为什么愿意回答我？

多少答案，苦等一个好问题。某些时候，对方的存量信息和经验等待被一个好问题激发和活跃。

比如说：基于柠檬后台的部分提问，帮助我对过去的知识和经验进行各种维度的总结整理，这本质上也帮助我建立了信息的链接，使整个知识体系更加趋于完善。

所以，一个好问题的提出不仅仅能提高匹配效率，使问题更快被解答，好问题本身也在某种程度上有机会对提问者提供价值，补偿其时间成本（前提是这不是同质性的问题）。

在这个环节中，你的主要任务是让问题和回答问题的人尽可能匹配。那么从自己的已知信息出发，拆分问题，找到核心卡点，即明确你的需求。

“跨专业没有实习，八月份还没开始找工作，我是不是没救了？”

这个不能称之为一个问题，只能称之为一次情绪宣泄，通过情绪宣泄和卖惨示弱企图获得关心和同情，来平复自己的情绪。这个提问的背后不是为了解决问题，而是为了让自己好受一点点，对解决问题毫无帮助，所以不在今天讨论的范围之内。

不过我们需要明白的是，极少数情况下，你提的问题有标准答案，你问别人，别人直接告诉你答案，选C。大多数情况下，答案因人而异，或者说，问题的本身没有答案，根据不同的标准有不同的回答，而你的标准未必和其他人一样。

第二，在明确需求的基础上，需要思考，谁有可能知道答案，即去哪里提需求。我能理解大家在困境中都会比较迷茫，比较着急，但也不能病急乱投医。

你不可能对着一个后端开发提前端需求，这对彼此来说都是浪费时间。很多时候，我们陷在问题中不知所措，进入僵局，那么就需要新的外部信息的输入打破僵局，给到解决问题的灵感和思路。

有些信息可以被公开检索，可能在互联网上，各种论坛上，也可能在某本书里，某段文字里。

但有些信息和经验是不可见的，它尚未被沉淀为文字广泛的传播，这些信息储存在每个人的大脑里，每个人都像是一个检索系统，如果你上一步明确了关键词，这一步就是要找到一个收录了该词条的检索系统。

最后也是很关键的一个问题，他为什么愿意回答我。这是问题被回答的最关键步骤，也是无法绕开的一个关卡。

如果没有想明白这个问题，那么得到回答的几率只能由天决定，有可能你一开口就得到了非常理想的回答，也有可能你问了好几个人都没能得到理想的回答，大家都没能理解你的诉求，还有可能你连问十几个人，都没有得到回答。

我们需要明确在这个提问市场中，到底是谁需要谁，谁能从这次提问中获得最大的收益。答案当然是，你需要对方。

虽然开始提到了一个好问题或许能够给被提问者带来些许价值，但这未必能补偿其回答你的问题的时间成本和精力成本。此外，一天面对十个同质化的好问题的时候，好问题就不再是好问题了。

所以，这个世界上没有什么事情是理所应当发生的，为了make things happen，你就需要推动事情的发生，至少给对方一个愿意回答你的理由。如果你自己都想不出一个理由让对方回答你，那么对方不予回复也就在情理之中了。

对方愿意回答你可能有以下几个理由：

对方为什么要回答你（截图来自公众号：凌空落雪）

此外，我们也可以尝试换个思路，即使我们无法明确怎样做才能让对方有可能回答，但我们能明确的是，怎么做对方大概率不会回答？通过避雷来提高问题被回答的概率。

• 比如带着情绪化提问，既想要解决方案，又想要情绪价值（被安慰）；
• 比如不尊重对方时间，一上来就堆十个问题；
• 比如没摆正预期和心态，半夜提问还质问别人为什么不回答。
• ……

三、如何让提问的价值最大化

提问就是一次淘金的过程。

《学会提问》中提到过，我们有两种思维方式，一种叫做海绵式思维，一种叫做淘金式思维。

• 海绵式思维不涉及过多的信息处理和判断，强调大量吸收外部信息；
• 而淘金式思维强调主动性和参与度，在获取信息的过程中保持主动性，一方面明确自己所需要的内容，对信息作出筛选另一方面主动参与到问题的探寻过程，接近事物的本质。

海绵式思维是比较被动的学习方式，适用于学习的初期，在提问中适用于我们收集和整理信息的阶段。

当我们对某个领域毫无了解的时候，很难在一开始就能对信息的有效性作出筛选和辨别，所以更多的时候是像一块海绵一样，一股脑的全吸收。

当我们无法判定真假的时候，先暂定为真，在之后的学习过程中，碰到类似的观点或者相关的论点论据时，随时拿出来比较和探讨，从而一步步建立认知。

因此，海绵式思维不是一无是处，而是知识的原始积累，毕竟你想淘金的话，至少你的淘金盘里得有几块金子，至少你得慢慢识别出什么是金子。

所以，为了让提问的价值最大化，我们需要前置这个海绵式思维的过程，即对被提问者有充足的了解，对被提问者所专供的领域内公开可查询的知识做足够的了解。

否则，在整个提问过程中，我们对信息的质量无法判断。

我们倾听他人的回答，不是为了将他人的回答奉为圣旨立刻执行，而是为了通过他人提供的信息构建出自己针对当前遇到问题的回答。否则这次提问只是获得了一个参考答案，抄个作业，下次还是不会做。

吸纳了足够的营养后，我们就可以开始淘金，淘金强调的是和知识的主动互动。

在提问前，我们想明白了自己的问题卡点，并且经过深思熟虑找到对面这个人，向他提出问题，并对我们想要的答案有所预期的话，当对方给出答案的时候，我们就可以第一时间将这个结果和预期做比对。

如果不符合预期的话，需要及时的思考，为什么自己的预期出现了失误，是因为预期过高，还是因为自己对问题的描述不够清晰导致了对方的回答不完全符合预期，并且及时的作出调整。

我相信，如果对方愿意回答你的问题的话，自然也是希望能够给予你帮助的，在合理的范围内展开讨论于你，于他都是一次思维的碰撞，在这个过程中，充分展现双方的思考，让这次提问更有价值。

#专栏作家#

李涛，微信公众号：柠檬two，人人都是产品经理专栏作家。新人产品经理，专注于产品求职分享和社交/社区赛道产品思考。

本文原创发布于人人都是产品经理，未经许可，禁止转载。

题图来自 Unsplash ，基于 CC0 协议