10 KiB
如何合理地回答问题
如果你的同事问你一个不太清晰的问题，你会怎么回答？我认为提问题是一种技巧（可以看 如何提出有意义的问题) 同时，合理地回答问题也是一种技巧。他们都是非常实用的。
开始 - 有时向你提问的人不尊重你的时间，这很糟糕。
我假设 - 我们假设问你问题的人是一个合理的人并且正在尽力解决问题而你想帮助他们。和我一起工作的人是这样，我所生活的世界也是这样。
下面是有助于回答问题的一些策略！
如果他们提问不清楚，帮他们澄清
通常初学者不会提出很清晰的问题，或者问一些对回答问题没有必要信息的问题。
-
** 重述为一个更明确的问题 ** 回复他们（”你是想问 X ？“)
-
** 问他们更具体的信息 ** 他们并没有提供（”你使用 IPv6 ?”）
-
** 问是什么导致了他们的问题 ** 例如，有时有些人会进入我的团队频道，询问我们的 service discovery 如何工作的。这通常是因为他们试图设置/重新配置服务。在这种情况下，如果问“你正在使用哪种服务？可以给我看看你正在进行的 pull 请求吗？”是有帮助的。
这些策略很多来自 如何提出有意义的问题中的要点。（尽管我永远不会对某人说“噢，你得先看完文档 “如何提出有意义的问题” 再来问我问题）
明白什么是他们已经知道的
在回答问题之前，知道对方已经知道什么是非常有用的！
Harold Treen 给了我一个很好的例子：
前几天，有人请我解释“ Redux-Sagas ”。与其深入解释不如说“ 他们就像 worker threads 监听行为，让你更新 Redux store 。
我开始搞清楚他们对 Redux 、行为（actions）、store 以及其他基本概念了解多少。将这些概念都联系在一起再来解释会容易得多。
弄清楚问你问题的人已经知道什么是非常重要的。因为有时他们可能会对基础概念感到疑惑（“ Redux 是什么？“），或者他们可是专家但是恰巧遇到了微妙的极端情况（corner case）。如果答案建立在他们不知道的概念上会令他们困惑，但如果重述他们已经知道的的又会是乏味的。
这里有一个很实用的技巧来了解他们已经知道什么 - 比如可以尝试用“你对 X 了解多少？”而不是问“你知道 X 吗？”。
给他们一个文档
“RTFM” （“去读那些他妈的手册”（Read The Fucking Manual））是一个典型的无用的回答，但事实上如果向他们指明一个特定的文档会是非常有用的！当我提问题的时候，我非常乐意被指明那些事实上能够解决我的问题的文档，因为它可能解决了其他我也想问的问题。
我认为明确你所指明的文档确实能够解决问题或者至少经过查阅明确它有用是非常重要的。否则，你可能将以下面这种情形结束对话（非常常见）：
-
Ali：我应该如何处理 X ？
-
Jada：<文档链接>
-
Ali: 这个并有实际解释如何处理 X ，它仅仅解释了如何处理 Y !
如果我所给的文档特别长，我会指明文档中那个我将会谈及的特定部分。bash 手册 有44000个字（真的！），所以如果只说“它在 bash 手册中有说明”是没有帮助的:)
告诉他们一个有用的搜索
在工作中，我经常发现我可以利用我所知道的关键字进行搜索找到能够解决我的问题的答案。对于初学者来说，这些关键字往往不是那么明显。所以说“这是我用来寻找这个答案的搜索”可能有用些。再次说明，回答时请经检查后以确保搜索能够得到他们所需要的答案:)
写新文档
人们经常一次又一次地问我的团队重复的问题。很显然这并不是人们的错（他们怎么能够知道在他们之前已经有10个人问了这个问题，且知道答案是什么呢？）因此，我们尝试写文档，而不是直接回答回答问题。
-
马上写新文档
-
给他们我们刚刚写好的新文档
-
公示
写文档有时往往比回答问题需要花很多时间，但这是值得的。写文档尤其值得如果：
a. 这个问题被问了一遍又一遍
b. 随着时间的推移，这个答案不会变化太大（如果这个答案每一个星期或者一个月就会变化，文档就会过时并且令人受挫）
解释你做了什么
对于一个话题，作为初学者来说，这样的交流会真让人沮丧：
-
新人：“hey 你如何处理 X ？”
-
有经验的人：“我做了，它完成了”
-
新人：”...... 但是你做了什么？！“
如果问你问题的人想知道事情是如何进行的，这样是有帮助的：
-
让他们去完成任务而不是自己做
-
把你是如何得到你给他们的答案的步骤告诉他们。
这可能比你自己做的时间还要长，但对于被问的人来说这是一个学习机会，因为那样做使得他们将来能够更好地解决问题。
这样，你可以进行更好的交流，像这：
-
新人：“这个网站出现了错误，发生了什么？”
-
有经验的人：（2分钟后）”oh 这是因为发生了数据库故障转移“
-
新人： ”你是怎么知道的？？！？！？“
-
有经验的人：“以下是我所做的！“：
-
通常这些错误是因为服务器 Y 被关闭了。我查看了一下
$PLACE但它表明服务器 Y 开着。所以，并不是这个原因导致的。 -
然后我查看仪表 X ，这个仪表的这个部分显示这里发生了数据库故障转移。
-
然后我在日志中找到了相应服务器，并且它显示连接数据库错误，看起来错误就是这里。
-
如果你正在解释你是如何调试一个问题，解释你是如何发现问题，以及如何找出问题是非常有用的当看起来似乎你已经得到正确答案时，感觉是很棒的。这比你帮助他人提高学习和诊断能力以及明白充分利用可用资源的感觉还要好。
解决根本问题
这一点有点狡猾。有时候人们认为他们依旧找到了解决问题的正确途径，且他们只需要一条信息就可以把问题解决。但他们可能并不是走在正确的道路上！比如：
-
George：”我在处理 X 的时候遇到了错误，我该如何修复它？“
-
Jasminda：”你是正在尝试解决 Y 吗？如果是这样，你不应该处理 X ，反而你应该处理 Z 。“
-
George：“噢，你是对的！！！谢谢你！我回反过来处理 Z 的。“
Jasminda 一点都没有回答 George 的问题！反而，她猜测 George 并不想处理 X ，并且她是猜对了。这是非常有用的！
如果你这样做可能会产生居高临下的感觉：
-
George：”我在处理 X 的时候遇到了错误，我该如何修复它？“
-
Jasminda：不要这样做，如果你想处理 Y ，你应该反过来完成 Z 。
-
George：“好吧，我并不是想处理 Y 。实际上我想处理 X 因为某些原因（REASONS）。所以我该如何处理 X 。
所以不要居高临下，且要记住有时有些提问者可能已经偏离根本问题很远了。同时回答提问者提出的问题以及他们本该提出的问题的恰当的：“嗯，如果你想处理 X ，那么你可能需要这么做，但如果你想用这个解决 Y 问题，可能通过处理其他事情你可以更好地解决这个问题，这就是为什么可以做得更好的原因。
询问”那个回答可以解决您的问题吗？”
我总是喜欢在我回答了问题之后核实是否真的已经解决了问题：”那个回答解决了您的问题吗？您还有其他问题吗？“在问完这个之后等待一会是很好的，因为人们通常需要一两分钟来知道他们是否已经找到了答案。
我发现尤其是问“这个回答解决了您的问题吗”这句在写文档时是非常有用的。通常，在写我关于我熟悉的东西的文档时，我会忽略掉重要的东西。
Offer to。。。。
我是远程工作的，所以我的很多对话都是基于文本的。我认为这是默认的沟通方式。
今天，我们生活在一个简单的视频会议和屏幕共享的世界！在工作时候，我可以在任何时间点击一个按钮并快速处在与他人的视频对话或者屏幕共享的对话中！
例如，最近有人问我关于容量规划/自动缩放。。。
不要表现得过于惊讶
这是源自 Recurse Center 的一则法则：不要假装惊讶。这里有一个常见的情景：
-
某人1：“什么是 Linux 内核”
-
某人2：“你竟然不知道什么是 Linux 内核（LINUX KERNEL）？！！！！？！！！？？？？”
某人2表现（无论他们是否真的如此惊讶）是没有帮助的。这大部分只会让某人1感觉不好，因为他们不知道什么的 Linux 内核。
我一直在假装不惊讶即使我事实上确实有点惊讶那个人不知道这种东西但它是令人敬畏的。
回答问题是令人敬畏的
很显然，这些策略并不是一直都是适当的，但希望你能够发现这里有些是有用的！我发现花时间去回答问题并教人们是其实是很有收获的。
特别感谢 Josh Triplett 的一些建议并做了很多有益的补充，以及感谢 Harold Treen、Vaibhav Sagar、Peter Bhat Hatkins、Wesley Aptekar Cassels 和 Paul Gowder的阅读或评论。
via: https://jvns.ca/blog/answer-questions-well/
作者： Julia Evans 译者：HardworkFish 校对：校对者ID