超越 XY 問題：為什麼你不應該直接回答第一個問題

當使用者提出技術問題時，大多數工程師的直覺反應是盡可能提供最快、最準確的答案。我們將回應速度視為生產力的指標。然而，對於那些為其他工程師開發工具的人來說，這種直覺可能是一個錯失良機的時刻。

在像 Perfetto（一個效能除錯工具）這樣的高複雜度工具情境下，直接回答一個「奇怪」的問題往往只能解決症狀，卻讓底層的困惑依然存在。透過抵制回答問題第一個版本的衝動，開發者可以揭示使用者心理模型中的關鍵缺口、識別產品缺陷，並避免開發不必要的特性功能。

超越 XY 問題

許多人都熟悉「XY 問題」，即使用者詢問的是他們嘗試採用的解決方案 (X) 而非實際的問題 (Y)。處理 XY 問題的傳統方法是解開謎題：弄清楚使用者真正的意思，提供正確的答案，然後繼續下一步。

但這其中存在更深層次的參與方式。與其將使用者的問題視為待解的謎題，不如將其視為一個契機。產生「錯誤」問題的困惑其實是一個訊號。當開發者探索這個訊號時，對話就會變成一個雙向學習的過程：使用者獲得了對工具更好的心理模型，而開發者則能更清晰地了解產品在哪裡令人困惑或不足。

診斷提問

並非所有問題都需要深入探究。常規查詢和文件缺失最適合透過快速提供連結來處理。而「不回答第一個問題」的策略則保留給那些感覺不尋常的要求。要判斷一個問題是否值得進行更深層次的對話，請考慮以下標準：

普遍性： 我以前見過這個嗎？如果這很不常見，那就值得慢下來思考。
合理性： 考慮到工具的目的，這個要求聽起來合理嗎？如果不合理，為什麼使用者會這樣問？
架構契合度： 使用者是否在不知不覺中與工具的架構作對？

一旦識別出差異，目標是在不顯得輕慢的情況下揭示缺失的上下文。一個有效的溝通框架是：「你目前問題的直接答案是 X，但因為原因 Y，這是一個相當奇怪的要求。你能告訴我更多關於你試圖解決的更廣泛問題嗎？」

當使用者誤解了哲學理念

通常，使用者會帶著對工具「應該」如何運作的預設觀念來使用它。在效能工程領域，這通常表現為將高保真度的 trace 當作通用的指標收集系統。雖然你可以從 trace 中計算任何指標，但與專門的指標系統相比，這樣做既耗費資源又低效。

當使用者要求一個與工具核心哲學相悖的特性功能時，這正是教學更廣泛工程學科的機會。例如，使用者經常詢問如何將大型 Perfetto traces 切割成多個檔案。透過詢問他們為什麼需要切割 trace，通常會揭示他們只是想視覺化特定的感興趣區域。實際的解決方案並非「切割」功能，而是「週期性 trace 快照」——這是一個已經存在但與使用者最初的心理模型不符的功能。

利用使用者摩擦來引導產品演進

這種方法對於產品開發也是一個強大的過濾器。在基礎軟體中，開發不正確功能的成本很高。透過延遲實施一個被要求的特性功能，並觀察多個使用者在同一個問題上掙扎，開發者可以找到需求的「本質」。

過早實施的危險

基於第一個請求就實施一個特性功能，可能會導致嚴大的技術債。Perfetto 中的隨機 UI 定製化是一個很好的例子。使用者抱怨 UI 很難定製，於是團隊實施了它。這導致了擴展性的噩夢，因為每個新功能都必須與每個現有的定製化功能互動。經過一年的重構，團隊才意識到真正的需求是為了個人化而提供的 plugin API，而非直接對 UI 進行修改。

戰略性延遲的價值

相反地，等待實施一個特性功能——例如 trace 的「合併」功能——讓團隊能夠深入理解問題空間。透過提供替代方案並觀察請求的模式，團隊在能在核心需求被完全理解之後，才建立起一個可維護的版本。

平衡引導與專業精神

雖然這種策略很強大，但如果運用不當，可能會被視為居高臨下的態度。為了避免「Stack Overflow 效應」——即使用者在獲得幫助之前被先被告知他們的問題是錯誤的——確保遵循以下準則：

先提供直接答案： 在要求更多上下文之前，務必先給出直接的答案 (X)。這證明了你是在提供幫助，而非單純的阻礙。
了解你的領域知識： 僅在你有深厚專業知識的領域中使用這種策略。如果你自己都不完全理解問題空間，你你無法引導使用者的心理模型。
展現善意： 如果使用者顯然是該領域的專家，請謹慎挑戰他們的做法。假設他們有提出該特定要求的理由。
尊重使用者的判斷： 如果使用者反駁，請尊重他們的判斷。目標是進行尊重且有建設性的討論，而非強迫轉換到特定的工作流程。

透過從立即回應的衝動中退後一小步，開發者可以將一個簡單的技術支援票單轉化為使用者與產品本身的戰略性資產。