如何以有用的方式回答问题

你的同事问你一个稍微不清楚的问题。你怎么回答？我认为提问是一种技能(参见如何问好问题)，以一种有帮助的方式回答问题也是一种技能！他们两个都非常有用。

首先，有时问你问题的人不尊重你的时间，这很糟糕。我在这里自始至终都在假设这不是什么问题-我们将假设问你问题的人是一个合情合理的人，他正在尽最大努力弄清楚一些事情，而且你想帮助他们解决问题。与我共事的每个人都是这样的，这就是我生活的世界：)。

初学者通常不会问清楚的问题，或者问的问题没有必要的信息来回答问题。这里有一些你可以用来帮助他们澄清的策略。

换句话问他们一个更具体的问题(“你在问X吗？”)。

询问他们没有提供的更具体的信息(“您正在使用IPv6吗？”)。

询问是什么促使他们提出问题。例如，有时人们进入我的团队的频道，询问我们的服务发现是如何工作的。通常，这是因为他们正在尝试设置/重新配置服务。在这种情况下，询问“您使用的是哪项服务？我可以看看您正在处理的拉式请求吗？“。

这些策略中的很多都来自于“如何问好问题”这篇帖子。(虽然我永远不会对别人说，“哦，在问我问题之前，你需要阅读这份关于如何问好问题的文档”)。

在回答问题之前，了解对方已经知道的情况是非常有用的！

前几天有人让我解释一下“Redux Sagas”。而不是一头扎进去说“它们就像是监听操作并让您更新存储的工作线程！”我开始弄清楚他们对Redux、Actions、商店和所有其他基本概念的了解程度。从那里可以更容易地解释将这些其他概念联系在一起的概念。

弄清楚你的提问者已经知道了什么很重要，因为他们可能对基本概念感到困惑(“什么是Redux？”)，或者他们可能是一个正在处理微妙问题的专家。建立在他们不知道的概念上的答案是令人困惑的，而概括他们知道的事情的答案是乏味的。

要问人们知道什么，有一个很有用的窍门--不要问“你知道X吗？”，也许可以试试“你对X有多熟悉？”

“RTFM”是对问题的经典无用回答，但是将某人指向某个特定的文档实际上可能真的很有帮助！当我问问题时，老实说，我更愿意被指向实际回答我问题的文档，因为它可能还会回答我的其他问题。

我认为这里重要的是要确保您链接到的文档确实回答了这个问题，或者至少在事后检查以确保它是有帮助的。否则，您可能会出现这种(相当常见的)情况：

如果我链接的文档非常长，我想指出我正在谈论的文档的特定部分。Bash手册页有44,000字(真的！)，所以只说“它在bash手册页”没有太大帮助：)。

我经常通过搜索一些我知道会找到答案的特定关键词来找到工作中的事情。对于初学者来说，这个关键字可能并不明显！所以说“这是我用来找到问题答案的搜索”可能会很有用。再次说明，之后请检查以确保搜索确实得到了他们需要的答案：)。

人们经常来一遍又一遍地问我的团队同样的问题。这显然不是市民的错(他们怎会知道已经有10个人问了，或答案是甚麽呢？)。所以我们试图，而不是直接回答问题，

编写文档有时比回答问题需要更多的时间，但通常是值得的！在以下情况下，编写文档尤其值得：

这是一个不断被问的问题。答案不会随着时间的推移而改变太多(如果答案每周或每个月都会改变，那么文档就会过时，令人沮丧)。

作为一门学科的初学者，有这样的交流真的很令人沮丧：

如果问你的人想要了解事物是如何工作的，那么这样做会很有帮助：

这可能比你自己做要花更长的时间，但对于提出要求的人来说，这是一个学习的机会，这样他们就可以更好地准备在未来解决这样的问题。

新人：“我在网站上看到错误，发生了什么事？”

更有经验的人：(2分钟后)“哦，那是因为发生了数据库故障转移。”

更有经验的人：“这就是我所做的！”：通常这些错误是由于服务Y停机造成的。我看了看$Place，它显示服务Y正在运行。所以不是这样的。

然后我查看仪表板X，该仪表板的这一部分显示发生了数据库故障转移。

然后我查看了该服务的日志，发现连接到数据库时出现错误，下面是这些错误的样子。

如果你在解释你是如何调试问题的，那么无论是解释你是如何发现问题是什么，又是如何发现问题不是问题，都是很有用的。虽然看起来你一下子就知道答案的感觉可能很好，但帮助别人提高学习和诊断能力，了解可用的资源，感觉更好。

这个有点棘手。有时，人们认为他们找到了通往解决方案的正确途径，他们只需要多一条信息来实现该解决方案即可。但他们可能并没有完全走在正确的道路上！例如：

乔治：我在做X，我遇到了这个错误，我该怎么修复它呢。

贾斯敏达：你真的想做Y吗？如果是这样的话，你不应该做X，而应该做Z。

贾斯敏达根本没有回答乔治的问题！相反，她猜测乔治实际上并不想做X，她是对的。那很有帮助！

乔治：我在做X，我得到了这个错误，我该怎么修复它呢？

贾斯敏达：不要那样做，你在试着做Y，而你应该做Z来完成它。

乔治：嗯，我不是想做Y，实际上我想做X是因为原因。我该怎么做X？

因此，不要居高临下，要记住，有些提问者可能会附和到他们到目前为止所采取的步骤！回答他们问的问题和他们应该问的问题可能是合适的：“嗯，如果你想做X，那么你可以试试这个，但是如果你试图用这个来解决问题Y，你可能会更幸运地做另一个事情，这就是为什么这样做会更有效。”

我总是喜欢在我认为我已经回答了问题并问“这回答了你的问题了吗？”你还有什么问题吗？“。

问完这个问题后稍作停顿和等待是很好的，因为人们通常需要一两分钟才能知道他们是否已经找到了答案。我特别发现这个额外的“这回答你的问题了吗？”编写完文档后，这一步很有帮助！通常，在编写我熟悉的文档时，我会遗漏一些非常重要的东西，而没有意识到这一点。

我远程工作，所以我在工作中的很多对话都是基于文本的。我认为这是默认的沟通方式。

今天，我们生活在一个轻松视频会议和屏幕共享的世界里！在工作中，我可以随时点击按钮，立即与某人进行视频通话/屏幕共享会话。有些问题更容易用你的声音来谈论！

例如，最近有人询问他们的服务的容量规划/自动缩放。我看得出有几件事我们需要弄清楚，但我还不能确切地确定是什么。我们进行了一次简短的视频通话，5分钟后，我们回答了他们所有的问题。

我认为，特别是如果有人真的不知道如何开始一项任务，结对编程几分钟真的会有帮助，而且它可能比电子邮件/即时通讯效率高得多。

这是递归中心的一条规则：不要假装惊讶。下面是一个相对常见的场景。

人类2的反应(不管他们是否真的感到惊讶)并不是很有帮助。它主要是为了让人类1感觉不好，因为他们不知道Linux内核是什么。

我一直在努力假装不惊讶，即使我真的有点惊讶，那个人并不知道这件事，这太棒了。

显然不是所有的这些策略都是合适的，但是很有希望你会发现它们中的一些是有帮助的！我发现花时间回答问题和教人真的很有意义。