• 本文為翻譯文章，利用工人智慧技術同步發表於我的部落格
• 原文為：How to answer questions in a helpful way - Julia Evans
• 本文已獲得作者 Julia Evans 同意授權翻譯並發佈

《回答的智慧》

當你遇到與你共事的人向你詢問問題，
卻描述得不太清楚時，你會怎麼回答？
我認為問問題是門學問，
（請參見我另外一篇文章 How to ask good questions）
【譯註：這是作者另外一篇文章，有機會的話我也會嘗試翻譯。】
然而，如何有效得回答問題同樣是門學問，兩者同等實用。

在開始之前，先做個假設：
我知道大家多少都遇過不尊重你的寶貴時間的提問者，
那種感覺很糟。
但在這篇文章中，
我要先假定這樣的情況不存在。
假設這篇文章裡的提問者都是合乎理性且會盡全力把事情弄懂，
是會讓你想幫助的那種人。
因為身邊和我一起工作的伙伴都是這樣的人，
而我目前就是在這樣的環境下工作。
【譯註：除了讓人羨慕以外，我想這也會讓這篇文章著重在回答問題上，比較不會模糊焦點。】

以下是一些我認為如何更有效回答問題的方法：

如果對方的問題不夠明確，幫助對方釐清問題

初學者常會提出不夠明確的問題，或者提出沒有足夠資訊、讓人無從回答的問題。
這裡有幾個方法可以讓你幫助他們釐清問題：

• 用更確切的問題回問對方。
• 詢問對方沒有提供的那些更加確切的資訊。
  • 例如：你是使用 IPv6 嗎？
• 詢問對方是什麼原因而問這個問題。
  • 舉例來說，有時候我會遇到同事在群組頻道裏面詢問「我們公司的 service discovery 是如何運作的？」
  • 通常會有此一問是因為他們正在嘗試架設或是調整某個服務。
  • 在這種情況下，回問「你現在在弄哪個服務？我可以看一下你目前的 Pull Request 嗎？」會是有幫助的。

很多類似的方法在我的另外一篇文章 How to ask good questions 都有被提及。
（然而我絕對不會對某個人說：「喔，你必須先看過這篇 How to ask good questions 才能問我問題。」）

先瞭解對方已經知道哪些東西

在回答問題之前，先瞭解對方已經知道哪些東西是很有用的。

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

某天有個人要我解釋 "Redux Sagas" 是什麼，我並沒有直接回答：「它們就像等待 action 並幫你更新 store 的背景工作執行緒 (worker threads)！」
而是先從對方對於 Redux, Redux 的 action, Redux 的 store 及其他關於 Redux 的基本觀念瞭解多少著手，如此一來會讓解釋 Redux Sagas 這件事容易一些，因為這些觀念與其環環相扣。

瞭解對你提問的人已經知道哪些東西是很重要的，
因為對方可能是連一些基本的觀念都還搞不太清楚的新手（例如：什麼是 Redux?），
也可能是遇到極端案例（corner case）的老手。
你的回答如果是建立在對方不知道的觀念上，會造成對方的困惑；
你的回答如果是重述對方已經知道的事情，則會讓對方感到厭煩。

在詢問對方已經知道哪些東西的時候，有個實用的技巧是，
與其問對方「你知道 XXX 嗎？」
也許可以試著改成問對方「你對 XXX 瞭解的程度有多少？」
【譯註：第一種問法得到的回答通常只有「知道」或「不知道」，而第二種通常會得到比較詳細一點的回答，能夠比第一種問法容易知道對方的程度。】

告訴對方應該要看哪些文件

「去讀那些他媽的文件」(RTFM) 是最典型的無用回答，
但如果你明確告訴對方要去看哪個文件則能產生很大的幫助。
當我問問題的時候，比起直接得到答案，
我其實比較喜歡被告知該去看哪份文件，
因為該份文件的內容很可能也會順便解決掉我其他的問題。

我認為有件很重要的事情是，
你必須確保當下告知對方的文件真的有回答到他的問題，
如果沒有的話，至少在事後確認它有幫助到對方。
否則你很有可能上演這種常見的場景：

• 問：「我要怎麼做到 X 這件事？」
• 答：（給了一份文件的連結）
• 問：「這份文件沒有解釋 X 啊，只有解釋 Y。」

如果我告知對方的文件太過冗長的話，
我會明確點出我正在說的是其中的哪一個部份。
Bash 的使用說明 有 44,000 個英文字（這是真的！），
所以如果只告訴對方「去看 Bash 的使用說明。」根本沒什麼幫助。

告訴對方可以用什麼樣的關鍵字去搜尋

在工作上，
我時常會使用一些「我知道這會讓我得到答案」的關鍵字來進行搜尋。
然而這樣的關鍵字對於新手來說可能不是這麼顯而易見，
所以告訴對方「如果是我的話，我會用 XXX 關鍵字來搜尋答案。」是很有用的。
同樣地，記得事後確認一下你給出的關鍵字真的有幫助到他們。

撰寫新文件

我常常不斷遇到不同的人來問我所處的團隊一模一樣的問題，
但這並不是這些人的錯，
畢竟他們不知道在這之前已經有 10 個人問過一樣的問題，
也不知道答案。
因此，與其一直重複告訴不同的人相同的答案，
我和團隊的其他人改用了以下的步驟：

1. 馬上為這個問題撰寫解答的文件
2. 告訴提問者這份我們新撰寫的文件
3. 皆大歡喜！

雖然撰寫文件花費的時間比直接回答問題還多，
但通常是很值得的，尤其是以下幾種問題：

• 一而再，再而三，不斷被人重複問的問題。
• 答案不太會隨時間而變動的問題。
  • 如果答案是每週或每月就會變動的話，這份文件就很容易過期，也會令提問者感到失望。

向對方解釋你做了哪些事

身為某個領域的初學者時，
如果發生以下對話，真的會令人很沮喪：

• 菜鳥：「你怎麼弄這東西的？」
• 老鳥：「就這樣啊，我弄完了。」
• 菜鳥：「……，但你做了哪些事啊？」

如果向你提問的人正在嘗試瞭解某件事是如何運作的話，
幾個方法將對其有所幫助：

• 帶對方完整跑過一次流程，而不是只做給對方看。
• 告訴對方你是用了哪些方法得到答案的
  【譯註：給他釣竿教他如何自己釣到魚，而不是在他面前釣魚給他看，然後把釣到的魚給他。】

雖然這比你直接做給對方看要花更多時間，
但這對於提問者來說是個學習的機會，
如此一來，他們往後面對相同的問題時就能夠有所準備。

套用這樣的方法，對話狀況就會好上許多：

• 菜鳥：「我在網站上看到錯誤，發生什麼事了？」
• 老鳥：「（檢查兩分鐘後）喔，因為資料庫正在進行容錯移轉（failover）。」
• 菜鳥：「原來！你是怎麼知道的啊？」
• 老鳥：「以下是我做的判斷：」
  • 從錯誤訊息看來，這類的錯誤通常是因為某個服務掛了，我去察看了一下，發現該服務還在正常執行，所以問題不在這。
  • 所以我去看了網站的後台，後台顯示有個資料庫容錯移轉的動作正在執行。
  • 然後我再去察看該服務的紀錄檔，紀錄裡頭顯示連線到資料庫的時候出錯了，看起來問題就出在這。

如果你向對方解釋你如何針對問題進行除錯，
將有利於讓對方瞭解你如何排除其他原因及如何發現真正的問題點。
當你遇到問題時，能馬上判斷出原因，的確是件讓人覺得很爽的事。
但幫助他人學得更好、更深入分析問題，
並瞭解到自己想出來的對策是有效的，
是件更棒的事。

解決最根本的問題

這個方法比較難一點，有時候會遇到一種情況，
提問者覺得自己已經找到了正確的解決方法，
且只差最後一個關鍵就可以把問題解決，
但其實很可能不是這麼一回事。
舉例來說：

• George:「我現在在想辦法搞定 X，然後出錯了，我要怎麼解掉這個錯誤？」
• Jasminda: 「你實際上是不是想搞定 Y？如果是的話，你不應該從 X 下手，你應該要從 Z 下手才對。」
• George：「對耶！感謝！那我要先來解決 Z。」

在上面的對話中，Jasminda 並沒有直接回答 George 的問題，
而是根據經驗推測 George 實際上不是想搞定 X 這件事，
而她對了，這個舉動非常的有用。

但有一點要注意的是，
如果回答者太過於高姿態的話，很可能會造成反效果，
例如：

• George:「我現在在想辦法搞定 X，然後出錯了，我要怎麼解掉這個錯誤？」
• Jasminda:「不用解這個錯誤，你實際上應該是想搞定 Y，然後你應該先從 Z 著手。」
• George:「ㄜ，我真的沒有想解決 Y，我是真的因為某些原因想要搞定 X，我到底該怎麼做？」

所以回答時切忌高姿態，
而且要記住，有些提問者有可能會附上他們已經做了哪些事，
最好的回答方式是，
針對「對方提問的問題」及「對方真正該問的問題」都進行回答，
例如：

「如果你想要解決 X 的話，你可以試試看這個方法，但如果你想用這個方法解決 Y 的話，我建議你用另外一個方法，那個方法比較有效。」

問對方「這樣有回答到你的問題嗎？」

我喜歡在自認為已經回答到對方的問題後，
額外向對方確認：「這樣有回答到你的問題嗎？還有更多想問的嗎？」

然後我會停下來等對方回答這個問題，
這樣做的好處是，人們總是需要個一兩分鐘確認自己是不是真的搞懂了。
我是在撰寫文件的時候才特別發現，
這句額外的「這樣有回答到你的問題嗎？」是很有用的，
我因為這點，
常常在為我已經熟知的事物撰寫文件時，
留下一些對他人而言重要的資訊而不自知。

嘗試當面、視訊或語音通話來溝通，不要只用文字

我是一位遠端工作者，
所以我和同事絕大多數的對話都是用文字溝通，
對我來說，文字是預設的溝通方式。

現今，我們活在一個很容易進行視訊會議與分享螢幕畫面的世界。
工作時，我可以點個按鈕就開始和某人進行視訊會議，
並分享螢幕畫面給對方。
許多問題用講的會比用打字的更容易解決。

例如：
最近有人問我要如何規劃與設定服務自動擴充（autoscaling）的容量，
我腦中大概可以想出有哪些東西需要釐清，
但還不是非常確定真正的情況。
於是我們快速通了個視訊電話，
五分鐘之後，
就回答完他們提出的所有問題了。

我特別相信，如果有人對於某件事情不知道如何下手，
以結對程式設計（pair programming）的方式進行當面的溝通，
只要幾分鐘就會很有幫助，
比只用電子郵件或即時通訊軟體來溝通有效多了。

回答問題時不要表現得很驚訝

這個原則出自於 Recurse Center 手冊的其中一條：別假裝很驚訝，
常見的情況：

• 小明：「什麼是 Linux kernel？」
• 小華：「蛤？你竟然沒有聽過 Linux kernel？真的假的啊？」

小華的反應（姑且先不論他到底是真的訝異還是假的訝異）一點幫助也沒有，
只會讓小明因為自己不知道 Linux kernel 是什麼而感到非常受傷。

即便我因為聽到對方不知道某個東西而真的感到有點訝異，
我反而會故作鎮定，能做到這點的話會是件很棒的事。

能夠有效得回答問題是件非常棒的事

顯然的，以上這些方法並不是任何情況都適用，
但希望你至少可以從中找到幾個你覺得有用的方法。
我發現花時間回答問題與教導別人是非常有收穫的一件事。

非常感謝 Josh Triplett 為這篇文章給出許多建議和幫忙新增很多很棒的內容。
感謝 Harold Treen、Vaibhav Sagar、Peter Bhat Harkins、Wesley Aptekar-Cassels 和 Paul Gowder 花時間閱讀這篇文章並給予評論。

更多譯註

• 這篇是目前在 Stripe 工作的 Julia Evans，於今年 9 月 21 日發表在其部落格上的文章：How to answer questions in a helpful way - Julia Evans
  • Julia Evans 是我去年開始在 Feedly 上追蹤的一名美國女性程式設計師
  • 忘記當初是因為哪篇文章追蹤的了，但我很佩服她的一點是，她學新東西的時候都會寫文章紀錄下來，並把東西講得非常詳細。雖然篇幅會非常長，但我每次看她的文章都覺得講得很清楚。
  • 她還有一系列把程式技術相關的名詞畫成簡單的漫畫來講解
    • 內容包括：Linux, Kubernetes, ...等等。
    • 有些小孩甚至會看這些漫畫學習這些新技術，我覺得很酷。
• 可能很多人都有看過 Eric Steven Raymond 的 How To Ask Questions The Smart Way
  • 中文翻譯為《提問的智慧》
  • 最常被人拿出來說的就是 RTFM (Read The Fucking Manual）
  • 這裡有繁體中文版，沒看過的人建議一定要看一下
  • 這篇文章非常強調問問題的人應該做好完整的功課，並且在詢問問題上要做到哪些事情，不要讓人不想回答你或是浪費回答你的人的時間。
  • 但其實在這篇文章最後面有一節的名稱叫作 How to Answer Questions in a Helpful Way （中譯為《回答的智慧》），但篇幅不多。
    • 沒記錯的話其實早一點的版本沒有，好像是後來才加入這章節的。
    • 而 Julia Evans 的這篇文章可以算是大大補足了這個章節的內容，也讓問答的雙方是比較平等一點的。
    • 畢竟有時候還是會遇到準備問題的人準備得很充實，但得到的解答卻是隨隨便便的敷衍的那種狀況。
    • 我想一個良好的問答品質需要雙方共同努力是一定的，這樣才能更有效率得教學相長。
    • 其實如果按照原文標題 "How to answer questions in a helpful way" 來翻譯的話，應該翻成《如何更有效得回答問題》或《如何更好得回答問題》。
    • 但因為 ESR 那篇文章被翻為《提問的智慧》，且裡頭同名的章節被翻譯成《回答的智慧》，所以我覺得這篇直接翻成《回答的智慧》會讓這兩篇文章更有連結性。

心得

看完這篇文章的當下後想了一下，
發現自己之前回答同事的問題算是都有做到這篇文章提到的事情，
但我還有多做一件事：「告知對方下次可以怎樣問會更好。」
這篇也很適合三不五時回來看看並反省自己是否有做到。

如果覺得我的文章不錯的話，
歡迎按讚、追蹤、訂閱、留言、分享，
也可以利用像是 Feedly 等 RSS Reader，
直接訂閱我的部落格：https://blog.m157q.tw。
因為 iThome 這邊未來我不保證持續更新，
雖然目前用起來沒太大問題，
但就是覺得要管兩個地方有點麻煩。