document/TranslateProject
2
0
Fork 0
mirror of https://github.com/LCTT/TranslateProject.git synced 2025-03-09 01:30:10 +08:00
Code Issues Packages Projects Releases Wiki Activity

update

Browse Source
This commit is contained in:
TRsky 2017-12-08 14:23:31 +08:00
parent 452410b4be
commit 66ba5bae5b
1 changed files with 55 additions and 41 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

96
sources/tech/20170921 How to answer questions in a helpful way.md
View File

@ -1,14 +1,12 @@
如何以有用的方式回答问题
如何合理地回答问题
=============================
如果你的同事问你一个不太清晰的问题，你会怎么回答？我认为提问题是一种技巧（可以看 [如何提出有意义的问题][1]) 同时以合理的方式回答问题也是一种技巧。他们都是非常实用的。
如果你的同事问你一个不太清晰的问题，你会怎么回答？我认为提问题是一种技巧（可以看 [如何提出有意义的问题][1]) 同时，合理地回答问题也是一种技巧。他们都是非常实用的。
开始 - 有时问你问题的人不尊重你的时间，这很糟糕。
开始 - 有时向你提问的人不尊重你的时间，这很糟糕。
我假设 - 我们来假设问你问题的人是一个合理的人并且正在尽力解决问题而你想帮助他们。和我一起工作的人是这样，我所生活的世界也是这样。
我假设 - 我们假设问你问题的人是一个合理的人并且正在尽力解决问题而你想帮助他们。和我一起工作的人是这样，我所生活的世界也是这样。
下面是有助于回答问题的一些策略！
@ -16,11 +14,11 @@
通常初学者不会提出很清晰的问题，或者问一些对回答问题没有必要信息的问题。
* ** 重述为一个更明确的问题 ** 回复他们（”你是想问 X ？“)
* ** 重述为一个更明确的问题 ** 回复他们（”你是想问 X ？“)
* ** 问他们更具体的信息 ** 他们并没有提供（”你使用 IPv6 ?”）
* ** 问他们更具体的信息 ** 他们并没有提供（”你使用 IPv6 ?”）
* ** 问是什么导致了他们的问题 ** 例如，有时有些人会进入我的团队频道，询问我们的 service discovery 如何工作的。这通常是因为他们试图设置/重新配置服务。在这种情况下，如果问“你正在使用哪种服务？可以给我看看你正在进行的 pull 请求吗？”是有帮助的。这些策略很多来自 [如何提出有意义的问题][2]。（尽管我永远不会对某人说“oh 你得先看完文档 “如何提出有意义的问题” 再来问我问题）
* ** 问是什么导致了他们的问题 ** 例如，有时有些人会进入我的团队频道，询问我们的 service discovery 如何工作的。这通常是因为他们试图设置/重新配置服务。在这种情况下，如果问“你正在使用哪种服务？可以给我看看你正在进行的 pull 请求吗？”是有帮助的。这些策略很多来自 [如何提出有意义的问题][2]。（尽管我永远不会对某人说“噢，你得先看完文档 “如何提出有意义的问题” 再来问我问题）
这些策略很多来自[如何提出有意义的问题][2]中的要点。
@ -32,11 +30,11 @@ Harold Treen 给了我一个很好的例子：
> 前几天，有人请我解释“ Redux-Sagas ”。与其深入解释不如说“ 他们就像 worker threads 监听行为，让你更新 Redux store 。
> 我开始搞清楚他们对 Redux 、行为（actions）、store 以及其他基本概念了解多少。将这些概念都联系在一起来解释概念会容易得多。
> 我开始搞清楚他们对 Redux 、行为（actions）、store 以及其他基本概念了解多少。将这些概念都联系在一起再来解释会容易得多。
弄清楚问你问题的人已经知道什么是非常重要的。因为有时他们可能会对基础概念感到疑惑（“ Redux 是什么？“），或者他们可是是专家并恰遇到了微妙的极端情况（corner case）。如果答案建立在他们不知道的概念上会令他们困惑，且重述他们已经知道的的会是乏味的。
弄清楚问你问题的人已经知道什么是非常重要的。因为有时他们可能会对基础概念感到疑惑（“ Redux 是什么？“），或者他们可是专家但是恰巧遇到了微妙的极端情况（corner case）。如果答案建立在他们不知道的概念上会令他们困惑，但如果重述他们已经知道的的又会是乏味的。
这里有一个有用的技巧问他们已经知道什么 - 比如可以尝试用“你对 X 了解多少？”而不是问“你知道 X 吗？”。
这里有一个很实用的技巧来了解他们已经知道什么 - 比如可以尝试用“你对 X 了解多少？”而不是问“你知道 X 吗？”。
### 给他们一个文档
@ -44,27 +42,27 @@ Harold Treen 给了我一个很好的例子：
我认为明确你所指明的文档确实能够解决问题或者至少经过查阅明确它有用是非常重要的。否则，你可能将以下面这种情形结束对话（非常常见）：
* Ali：我应该如何处理 X ？
* Ali：我应该如何处理 X ？
* Jada：<文档链接>
* Jada：<文档链接>
* Ali: 这个并有实际解释如何处理 X ，它仅仅解释了如何处理 Y !
* Ali: 这个并有实际解释如何处理 X ，它仅仅解释了如何处理 Y !
如果我所给的文档特别长，我会指明文档中那个我将会谈及的特定部分。[bash 手册][3] 有44000个字（真的！），所以只说“它在 bash 手册中有说明”是没有用的：）
如果我所给的文档特别长，我会指明文档中那个我将会谈及的特定部分。[bash 手册][3] 有44000个字（真的！），所以如果只说“它在 bash 手册中有说明”是没有帮助的：）
### 告诉他们一个有用的搜索
在工作中，经常我发现我可以利用我所知道的关键字进行搜索找到能够解决我的问题的答案。对于初学者来说，这些关键字往往不是那么明显。所以说“这是我用来寻找这个答案的搜索”可能有用些。再次说明，回答时请经检查后以确保搜索能够得到他们所需要的答案。
在工作中，我经常发现我可以利用我所知道的关键字进行搜索找到能够解决我的问题的答案。对于初学者来说，这些关键字往往不是那么明显。所以说“这是我用来寻找这个答案的搜索”可能有用些。再次说明，回答时请经检查后以确保搜索能够得到他们所需要的答案。
### 写新文档
人们经常一次又一次地问我的团队重复的问题。很显然这并不是人们的错（他们怎么能够知道在他们之前已经有10个人问了这个问题，且知道答案是什么呢？）因此，我们尝试写文档，而不是直接回答回答问题。
1. 马上写新文档
1. 马上写新文档
2. 给他们我们刚刚写好的新文档
2. 给他们我们刚刚写好的新文档
3. 公示
3. 公示
写文档有时往往比回答问题需要花很多时间，但这是值得的。写文档尤其值得如果：
@ -76,35 +74,35 @@ b. 随着时间的推移，这个答案不会变化太大（如果这个答案
对于一个话题，作为初学者来说，这样的交流会真让人沮丧：
* 新人：“hey 你如何处理 X ？”
* 新人：“hey 你如何处理 X ？”
* 更加有经验的人：“我做了，它完成了”
* 有经验的人：“我做了，它完成了”
* 新人：”...... 但是你做了什么？！“
* 新人：”...... 但是你做了什么？！“
如果问你问题的人想知道事情是如何进行的，这样是有帮助的：
* 让他们去完成任务而不是自己做
* 让他们去完成任务而不是自己做
* 把你是如何得到你给他们的答案的步骤告诉他们。
* 把你是如何得到你给他们的答案的步骤告诉他们。
这可能比你自己做的时间还要长，但对于被问的人来说这是一个学习机会，因为那样做使得他们将来能够更好地解决问题。
这样，你可以进行更好的交流，像这：
* 新人：“这个网站出现了错误，发生了什么？”
* 新人：“这个网站出现了错误，发生了什么？”
* 有经验的人：（2分钟后）”oh 这是因为发生了数据库故障转移“
* 有经验的人：（2分钟后）”oh 这是因为发生了数据库故障转移“
* 新人： ”你是怎么知道的？？！？！？“
* 新人： ”你是怎么知道的？？！？！？“
* 有经验的人：“以下是我所做的！“：
* 有经验的人：“以下是我所做的！“：
1. 通常这些错误是因为服务器 Y 被关闭了。我查看了一下 `$PLACE` 但它表明服务器 Y 开着。所以，并不是这个原因导致的。
1. 通常这些错误是因为服务器 Y 被关闭了。我查看了一下 `$PLACE` 但它表明服务器 Y 开着。所以，并不是这个原因导致的。
2. 然后我查看仪表 X ，这个仪表的这个部分显示这里发生了数据库故障转移。
2. 然后我查看仪表 X ，这个仪表的这个部分显示这里发生了数据库故障转移。
3. 然后我在日志中找到了相应服务器，并且它显示连接数据库错误，看起来错误就是这里。
3. 然后我在日志中找到了相应服务器，并且它显示连接数据库错误，看起来错误就是这里。
如果你正在解释你是如何调试一个问题，解释你是如何发现问题，以及如何找出问题是非常有用的当看起来似乎你已经得到正确答案时，感觉是很棒的。这比你帮助他人提高学习和诊断能力以及明白充分利用可用资源的感觉还要好。
@ -112,21 +110,21 @@ b. 随着时间的推移，这个答案不会变化太大（如果这个答案
这一点有点狡猾。有时候人们认为他们依旧找到了解决问题的正确途径，且他们只需要一条信息就可以把问题解决。但他们可能并不是走在正确的道路上！比如：
* George：”我在处理 X 的时候遇到了错误，我该如何修复它？“
* George：”我在处理 X 的时候遇到了错误，我该如何修复它？“
* Jasminda：”你是正在尝试解决 Y 吗？如果是这样，你不应该处理 X ，反而你应该处理 Z 。“
* Jasminda：”你是正在尝试解决 Y 吗？如果是这样，你不应该处理 X ，反而你应该处理 Z 。“
* George：“噢，你是对的！！！谢谢你！我回反过来处理 Z 的。“
* George：“噢，你是对的！！！谢谢你！我回反过来处理 Z 的。“
Jasminda 一点都没有回答 George 的问题！反而，她猜测 George 并不想处理 X ，并且她是猜对了。这是非常有用的！
如果你这样做可能会产生居高临下的感觉：
* George：”我在处理 X 的时候遇到了错误，我该如何修复它？“
* George：”我在处理 X 的时候遇到了错误，我该如何修复它？“
* Jasminda：不要这样做，如果你想处理 Y ，你应该反过来完成 Z 。
* Jasminda：不要这样做，如果你想处理 Y ，你应该反过来完成 Z 。
* George：“好吧，我并不是想处理 Y 。实际上我想处理 X 因为某些原因（REASONS）。所以我该如何处理 X 。
* George：“好吧，我并不是想处理 Y 。实际上我想处理 X 因为某些原因（REASONS）。所以我该如何处理 X 。
所以不要居高临下，且要记住有时有些提问者可能已经偏离根本问题很远了。同时回答提问者提出的问题以及他们本该提出的问题的恰当的：“嗯，如果你想处理 X ，那么你可能需要这么做，但如果你想用这个解决 Y 问题，可能通过处理其他事情你可以更好地解决这个问题，这就是为什么可以做得更好的原因。
@ -148,9 +146,9 @@ Jasminda 一点都没有回答 George 的问题！反而，她猜测 George 并
这是源自 Recurse Center 的一则法则：[不要假装惊讶][4]。这里有一个常见的情景：
* 某人1：“什么是 Linux 内核”
* 某人1：“什么是 Linux 内核”
* 某人2：“你竟然不知道什么是 Linux 内核（LINUX KERNEL）？！！！！？！！！？？？？”
* 某人2：“你竟然不知道什么是 Linux 内核（LINUX KERNEL）？！！！！？！！！？？？？”
某人2表现（无论他们是否真的如此惊讶）是没有帮助的。这大部分只会让某人1感觉不好，因为他们不知道什么的 Linux 内核。
@ -162,6 +160,22 @@ Jasminda 一点都没有回答 George 的问题！反而，她猜测 George 并
特别感谢 Josh Triplett 的一些建议并做了很多有益的补充，以及感谢 Harold Treen、Vaibhav Sagar、Peter Bhat Hatkins、Wesley Aptekar Cassels 和 Paul Gowder的阅读或评论。
--------------------------------------------------------------------------------
via: https://jvns.ca/blog/answer-questions-well/
作者：[ Julia Evans][a]
译者：[HardworkFish](https://github.com/HardworkFish)
校对：[校对者ID](https://github.com/校对者ID)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
[a]:https://jvns.ca/about
[1]:https://jvns.ca/blog/good-questions/
[2]:https://jvns.ca/blog/good-questions/
[3]:https://linux.die.net/man/1/bash
[4]:https://jvns.ca/blog/2017/04/27/no-feigning-surprise/