如何提供有幫助的回答

如果你的同事問你一個不太清晰的問題，你會怎麼回答？我認為提問題是一種技巧（可以看 如何提出有意義的問題) ，同時，合理地回答問題也是一種技巧，它們都是非常實用的。

一開始 —— 有時向你提問的人不尊重你的時間，這很糟糕。理想情況下，我們假設問你問題的人是一個理性的人並且正在儘力解決問題，而你想幫助他們。和我一起工作的人是這樣，我所生活的世界也是這樣。當然，現實生活並不是這樣。

下面是有助於回答問題的一些方法！

如果他們的提問不清楚，幫他們澄清

通常初學者不會提出很清晰的問題，或者問一些對回答問題沒有必要信息的問題。你可以嘗試以下方法 澄清問題：

• 重述為一個更明確的問題來回復他們（「你是想問 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 個人問了這個問題，且知道答案是什麼呢？）因此，我們會嘗試寫新文檔，而不是直接回答回答問題。

1. 馬上寫新文檔
2. 給他們我們剛剛寫好的新文檔
3. 公示

寫文檔有時往往比回答問題需要花很多時間，但這是值得的。寫文檔尤其重要，如果：

a. 這個問題被問了一遍又一遍 b. 隨著時間的推移，這個答案不會變化太大（如果這個答案每一個星期或者一個月就會變化，文檔就會過時並且令人受挫）

解釋你做了什麼

對於一個話題，作為初學者來說，這樣的交流會真讓人沮喪：

• 新人：「嗨！你如何處理 X ？」
• 有經驗的人：「我已經處理過了，而且它已經完美解決了」
• 新人：」...... 但是你做了什麼？！「

如果問你問題的人想知道事情是如何進行的，這樣是有幫助的：

• 讓他們去完成任務而不是自己做
• 告訴他們你是如何得到你給他們的答案的。

這可能比你自己做的時間還要長，但對於被問的人來說這是一個學習機會，因為那樣做使得他們將來能夠更好地解決問題。

這樣，你可以進行更好的交流，像這：

• 新人：「這個網站出現了錯誤，發生了什麼？」
• 有經驗的人：（2分鐘後）「oh 這是因為發生了資料庫故障轉移」
• 新人： 「你是怎麼知道的？？！？！？」
• 有經驗的人：「以下是我所做的！」：
  1. 通常這些錯誤是因為伺服器 Y 被關閉了。我查看了一下 $PLACE 但它表明伺服器 Y 開著。所以，並不是這個原因導致的。
  2. 然後我查看 X 的儀錶盤 ，儀錶盤的這個部分顯示這裡發生了資料庫故障轉移。
  3. 然後我在日誌中找到了相應伺服器，並且它顯示連接資料庫錯誤，看起來錯誤就是這裡。

如果你正在解釋你是如何調試一個問題，解釋你是如何發現問題，以及如何找出問題的。儘管看起來你好像已經得到正確答案，但感覺更好的是能夠幫助他們提高學習和診斷能力，並了解可用的資源。

解決根本問題

這一點有點棘手。有時候人們認為他們依舊找到了解決問題的正確途徑，且他們只要再多一點信息就可以解決問題。但他們可能並不是走在正確的道路上！比如：

• 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中國 榮譽推出

本文轉載來自 Linux 中國: https://github.com/Linux-CN/archive