如何提供有幫助的回答 | Linux 中國

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

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

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

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

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

這些方法很多來自如何提出有意義的問題[1]中的要點。（儘管我永遠不會對某人說“噢，你得先看完《如何提出有意義的問題》這篇文章後再來向我提問）

弄清楚他們已經知道了什麼

在回答問題之前，知道對方已經知道什麼是非常有用的！

Harold Treen 給了我一個很好的例子：

前幾天，有人請我解釋 “Redux-Sagas”。與其深入解釋，不如說 “它們就像監聽 action 的工人執行緒，並可以讓你更新 Redux store。

我開始搞清楚他們對 Redux、action、store 以及其他基本概念瞭解多少。將這些概念都聯絡在一起再來解釋會容易得多。

弄清楚問你問題的人已經知道什麼是非常重要的。因為有時他們可能會對基礎概念感到疑惑（“Redux 是什麼？”），或者他們可能是專家，但是恰巧遇到了微妙的極端情況corner case。如果答案建立在他們不知道的概念上會令他們困惑，但如果重述他們已經知道的的又會是乏味的。

這裡有一個很實用的技巧來瞭解他們已經知道什麼 – 比如可以嘗試用“你對 X 瞭解多少？”而不是問“你知道 X 嗎？”。

給他們一個檔案

“RTFM” （“去讀那些他媽的手冊”Read The Fucking Manual）是一個典型的無用的回答，但事實上如果向他們指明一個特定的檔案會是非常有用的！當我提問題的時候，我當然很樂意翻看那些能實際解決我的問題的檔案，因為它也可能解決其他我想問的問題。

我認為明確你所給的檔案的確能夠解決問題是非常重要的，或者至少經過查閱後確認它對解決問題有幫助。否則，你可能將以下麵這種情形結束對話（非常常見）：

如果我所給的檔案特別長，我會指明檔案中那個我將會談及的特定部分。bash 手冊[2] 有 44000 個字（真的！），所以如果只說“它在 bash 手冊中有說明”是沒有幫助的 🙂

告訴他們一個有用的搜尋

在工作中，我經常發現我可以利用我所知道的關鍵字進行搜尋來找到能夠解決我的問題的答案。對於初學者來說，這些關鍵字往往不是那麼明顯。所以說“這是我用來尋找這個答案的搜尋”可能有用些。再次說明，回答時請經檢查後以確保搜尋能夠得到他們所需要的答案 🙂

寫新檔案

人們經常一次又一次地問我的團隊同樣的問題。很顯然這並不是他們的錯（他們怎麼能夠知道在他們之前已經有 10 個人問了這個問題，且知道答案是什麼呢？）因此，我們會嘗試寫新檔案，而不是直接回答回答問題。

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

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

解釋你做了什麼

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

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

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

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

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

解決根本問題

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

Jasminda 一點都沒有回答 George 的問題！反而，她猜測 George 並不想處理 X ，並且她是猜對了。這是非常有用的！

如果你這樣做可能會產生高高在上的感覺：

所以不要高高在上，且要記住有時有些提問者可能已經偏離根本問題很遠了。同時回答提問者提出的問題以及他們本該提出的問題都是合理的：“嗯，如果你想處理 X ，那麼你可能需要這麼做，但如果你想用這個解決 Y 問題，可能透過處理其他事情你可以更好地解決這個問題，這就是為什麼可以做得更好的原因。”

詢問“那個回答可以解決您的問題嗎？”

我總是喜歡在我回答了問題之後核實是否真的已經解決了問題：“這個回答解決了您的問題嗎？您還有其他問題嗎？”在問完這個之後最好等待一會，因為人們通常需要一兩分鐘來知道他們是否已經找到了答案。

我發現尤其是問“這個回答解決了您的問題嗎”這個額外的步驟在寫完檔案後是非常有用的。通常，在寫關於我熟悉的東西的檔案時，我會忽略掉重要的東西而不會意識到它。

結對程式設計和麵對面交談

我是遠端工作的，所以我的很多對話都是基於文字的。我認為這是溝通的預設方式。

今天，我們生活在一個方便進行小影片會議和螢幕共享的世界！在工作時候，在任何時間我都可以點選一個按鈕並快速加入與他人的影片對話或者螢幕共享的對話中！

例如，最近有人問如何自動調節他們的服務容量規劃。我告訴他們我們有幾樣東西需要清理，但我還不太確定他們要清理的是什麼。然後我們進行了一個簡短的影片會話併在 5 分鐘後，我們解決了他們問題。

我認為，特別是如果有人真的被困在該如何開始一項任務時，開啟影片進行結對程式設計幾分鐘真的比電子郵件或者一些即時通訊更有效。

不要表現得過於驚訝

這是源自 Recurse Center 的一則法則：不要故作驚訝[3]。這裡有一個常見的情景：

某乙的表現（無論他們是否真的如此驚訝）是沒有幫助的。這大部分只會讓某甲不好受，因為他們確實不知道什麼是 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[5] 譯者：HardworkFish 校對：wxy

本文由 LCTT 原創編譯，Linux中國 榮譽推出