如果你的同事问你一个不太清晰的问题，你会怎么回答？我认为提问题是一种技巧（可以看 如何提出有意义的问题) ，同时，合理地回答问题也是一种技巧，它们都是非常实用的。
一开始 —— 有时向你提问的人不尊重你的时间，这很糟糕。理想情况下，我们假设问你问题的人是一个理性的人并且正在尽力解决问题，而你想帮助他们。和我一起工作的人是这样，我所生活的世界也是这样。当然，现实生活并不是这样。
下面是有助于回答问题的一些方法！
如果他们的提问不清楚，帮他们澄清
通常初学者不会提出很清晰的问题，或者问一些对回答问题没有必要信息的问题。你可以尝试以下方法 澄清问题：
- 重述为一个更明确的问题来回复他们（“你是想问 X 吗？”)
- 向他们了解更具体的他们并没有提供的信息 （“你使用 IPv6 ?”）
- 问是什么导致了他们的问题。例如，有时有些人会进入我的团队频道，询问我们的 服务发现 service discovery 如何工作的。这通常是因为他们试图设置/重新配置服务。在这种情况下，如果问“你正在使用哪种服务？可以给我看看你正在处理的‘拉取请求’吗？”是有帮助的。
这些方法很多来自如何提出有意义的问题中的要点。（尽管我永远不会对某人说“噢，你得先看完《如何提出有意义的问题》这篇文章后再来向我提问）
弄清楚他们已经知道了什么
在回答问题之前，知道对方已经知道什么是非常有用的！
Harold Treen 给了我一个很好的例子：
前几天，有人请我解释 “Redux-Sagas”。与其深入解释，不如说 “它们就像监听 action 的工人线程，并可以让你更新 Redux store。
我开始搞清楚他们对 Redux、action、store 以及其他基本概念了解多少。将这些概念都联系在一起再来解释会容易得多。
弄清楚问你问题的人已经知道什么是非常重要的。因为有时他们可能会对基础概念感到疑惑（“Redux 是什么？”），或者他们可能是专家，但是恰巧遇到了微妙的 极端情况 corner case 。如果答案建立在他们不知道的概念上会令他们困惑，但如果重述他们已经知道的的又会是乏味的。
这里有一个很实用的技巧来了解他们已经知道什么 - 比如可以尝试用“你对 X 了解多少？”而不是问“你知道 X 吗？”。
给他们一个文档
“RTFM” （ “去读那些他妈的手册” Read The Fucking Manual ）是一个典型的无用的回答，但事实上如果向他们指明一个特定的文档会是非常有用的！当我提问题的时候，我当然很乐意翻看那些能实际解决我的问题的文档，因为它也可能解决其他我想问的问题。
我认为明确你所给的文档的确能够解决问题是非常重要的，或者至少经过查阅后确认它对解决问题有帮助。否则，你可能将以下面这种情形结束对话（非常常见）：
- Ali：我应该如何处理 X ？
- Jada：
- Ali: 这个没有实际解释如何处理 X ，它仅仅解释了如何处理 Y !
如果我所给的文档特别长，我会指明文档中那个我将会谈及的特定部分。bash 手册 有 44000 个字（真的！），所以如果只说“它在 bash 手册中有说明”是没有帮助的 🙂
告诉他们一个有用的搜索
在工作中，我经常发现我可以利用我所知道的关键字进行搜索来找到能够解决我的问题的答案。对于初学者来说，这些关键字往往不是那么明显。所以说“这是我用来寻找这个答案的搜索”可能有用些。再次说明，回答时请经检查后以确保搜索能够得到他们所需要的答案 🙂
写新文档
人们经常一次又一次地问我的团队同样的问题。很显然这并不是他们的错（他们怎么能够知道在他们之前已经有 10 个人问了这个问题，且知道答案是什么呢？）因此，我们会尝试写新文档，而不是直接回答回答问题。
写文档有时往往比回答问题需要花很多时间，但这是值得的。写文档尤其重要，如果：
a. 这个问题被问了一遍又一遍 b. 随着时间的推移，这个答案不会变化太大（如果这个答案每一个星期或者一个月就会变化，文档就会过时并且令人受挫）
解释你做了什么
对于一个话题，作为初学者来说，这样的交流会真让人沮丧：
- 新人：“嗨！你如何处理 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 问题，可能通过处理其他事情你可以更好地解决这个问题，这就是为什么可以做得更好的原因。”
询问“那个回答可以解决您的问题吗？”
我总是喜欢在我回答了问题之后核实是否真的已经解决了问题：“这个回答解决了您的问题吗？您还有其他问题吗？”在问完这个之后最好等待一会，因为人们通常需要一两分钟来知道他们是否已经找到了答案。
我发现尤其是问“这个回答解决了您的问题吗”这个额外的步骤在写完文档后是非常有用的。通常，在写关于我熟悉的东西的文档时，我会忽略掉重要的东西而不会意识到它。
结对编程和面对面交谈
我是远程工作的，所以我的很多对话都是基于文本的。我认为这是沟通的默认方式。
今天，我们生活在一个方便进行小视频会议和屏幕共享的世界！在工作时候，在任何时间我都可以点击一个按钮并快速加入与他人的视频对话或者屏幕共享的对话中！
例如，最近有人问如何自动调节他们的服务容量规划。我告诉他们我们有几样东西需要清理，但我还不太确定他们要清理的是什么。然后我们进行了一个简短的视频会话并在 5 分钟后，我们解决了他们问题。
我认为，特别是如果有人真的被困在该如何开始一项任务时，开启视频进行结对编程几分钟真的比电子邮件或者一些即时通信更有效。
不要表现得过于惊讶
这是源自 Recurse Center 的一则法则：不要故作惊讶。这里有一个常见的情景：
- 某甲：“什么是 Linux 内核”
- 某乙：“你竟然不知道什么是 Linux 内核？！！！！？！！！？？？？”
某乙的表现（无论他们是否真的如此惊讶）是没有帮助的。这大部分只会让某甲不好受，因为他们确实不知道什么是 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 校对：wxy
本文由 LCTT 原创编译，Linux中国 荣誉推出
