問對問題，才能得到對的答案：為什麼你的技術問題沒人理？

當你在技術論壇問問題時，是不是常常被「已讀不回」？

還記得你第一次在 Stack Overflow 或技術群組問問題的經驗嗎？

你花了半小時寫了一堆程式碼，描述你的問題，結果等了三天，只收到一個「你先去 Google」的回應，或者根本沒人理你。

你心想：「這些人怎麼這麼冷漠？我只是想要個答案而已！」

但問題可能不在於別人冷漠，而在於你問問題的方式。

《精準提問：找到問題解方，培養創意思維、發揮專業影響力的16個提問心法】》這本書，正是為了解決這個問題。它教會我，提問不是「問問題」，而是「建立對話」，是「創造價值」。

痛點一：問了問題卻得不到答案，反而被「已讀不回」

描述：在論壇或群組問「我程式碼跑不動，怎麼辦？」，結果沒人理

典型災難場景：

👤 新手工程師：
「我的 React 程式碼有問題，請大家幫忙看一下」

（附上一張模糊的手機截圖，程式碼看不清楚）

👥 群組成員：
（一片沉默...）

為什麼沒人理你？

1. 問題太模糊：什麼問題？錯誤訊息是什麼？
2. 資訊不完整：沒有提供足夠的上下文
3. 沒有展現誠意：看起來像伸手牌，沒有自己嘗試過

書中解方：提出一個「好問題」，包含情境與已做的嘗試

一個好的技術提問包含三要素：

1. 我的目標是什麼？

• 你想要達成什麼？
• 預期的結果是什麼？

2. 我嘗試了哪些方法？

• 你已經做過什麼嘗試？
• 參考了哪些資源？

3. 結果如何？

• 附上錯誤訊息或程式碼
• 說明實際的結果與預期的差異
  

改進後的提問範例：

👤 有經驗的工程師：

「大家好，我在學習 React Hooks 時遇到問題，想請教一下：

【目標】
我想要實作一個計數器功能，點擊按鈕時數字會增加。

【我嘗試的方法】
1. 參考了 React 官方文件
2. 看了幾個 YouTube 教學影片
3. 嘗試使用 useState Hook

【程式碼】
```javascript
import React, { useState } from 'react';

function Counter() {
  const [count, setCount] = useState(0);
  
  return (
    <div>
      <p>Count: {count}</p>
      <button onClick={() => setCount(count + 1)}>
        Increment
      </button>
    </div>
  );
}


【問題】
程式碼可以執行，但按鈕點擊時數字沒有更新。控制台也沒有錯誤訊息。

【環境】
- React 18.2.0
- Chrome 瀏覽器
- 使用 Create React App

請問可能是什麼原因？感謝大家的時間！」

👥 群組成員：
「看起來程式碼沒問題，可能是瀏覽器快取問題，試試看 Ctrl+F5 重新整理」
「或者檢查一下 React DevTools，看看 state 有沒有正確更新」

關鍵差異：

• 具體明確：清楚說明目標和問題
• 展現努力：列出已嘗試的方法
• 提供完整資訊：程式碼、環境、錯誤訊息
• 表達感謝：尊重別人的時間

痛點二：會議或討論時，抓不到問題核心，討論一直發散

描述：需求會議開了半天，大家各說各話，討論一直發散，最後沒有結論

典型災難場景：

PM：「我們需要一個新的功能」
工程師：「什麼功能？」
PM：「就是讓用戶可以分享內容」
工程師：「分享到哪裡？」
PM：「社群媒體」
設計師：「要設計新的按鈕嗎？」
PM：「對，要好看一點」
工程師：「技術上要怎麼實作？」
設計師：「顏色要符合品牌色」
PM：「還有，要能追蹤分享次數」
工程師：「這需要新的 API」
設計師：「按鈕要放在哪裡？」
PM：「先放在文章底部」
工程師：「那分享按鈕要幾個？」
PM：「Facebook、Twitter、Line」
設計師：「要設計三種不同的圖示」
工程師：「API 要怎麼設計？」
PM：「還有，要能統計分享數據」
設計師：「按鈕要多大？」
工程師：「什麼時候要上線？」
PM：「下週」
設計師：「來不及設計」
工程師：「來不及開發」
PM：「那先做一個簡單的」
工程師：「多簡單？」
設計師：「多簡單？」
PM：「...」

為什麼會這樣？

• 沒有明確的問題定義
• 大家都在說解決方案，沒人在問「為什麼」
• 缺乏結構化的討論框架

書中解方：使用「5 Whys 分析法」挖掘根本原因

5 Whys 分析法的核心：
當有人提出需求時，不要馬上思考「怎麼做」，而是連續追問幾次「為什麼需要這個功能？」

改進後的討論範例：

PM：「我們需要一個新的功能」
工程師：「什麼功能？」
PM：「讓用戶可以分享內容」
工程師：「為什麼需要這個功能？」
PM：「因為我們希望增加網站流量」
工程師：「為什麼增加流量很重要？」
PM：「因為老闆希望提升品牌知名度」
工程師：「為什麼品牌知名度重要？」
PM：「因為我們要準備下一輪募資」
工程師：「為什麼需要募資？」
PM：「因為我們要擴展到海外市場」

【結論】
原來真正的目標是「為海外擴展做準備」，而不是單純的「分享功能」。

【重新定義問題】
如何提升品牌知名度，為海外擴展做準備？

【可能的解決方案】
1. 分享功能（原提案）
2. 內容行銷策略
3. 社群媒體經營
4. 合作夥伴關係
5. 產品功能優化

【下一步】
評估各種方案的 ROI 和可行性，而不是急著開發分享功能。

5 Whys 分析法的好處：

1. 找到根本原因：避免解決表面問題
2. 重新定義問題：可能發現更好的解決方案
3. 建立共識：大家對目標有共同理解
4. 提高效率：避免做錯的事情

我的實踐：將提問技巧應用到技術工作中

技術提問的三個層次

第一層：問技術細節

「這個 API 怎麼用？」
「這個錯誤訊息是什麼意思？」
「這個套件要怎麼安裝？」

第二層：問解決方案

「我遇到這個問題，該怎麼解決？」
「這個功能要怎麼實作？」
「這個架構有什麼問題？」

第三層：問思考過程

「為什麼會出現這個問題？」
「這個解決方案的優缺點是什麼？」
「有沒有更好的做法？」

實際應用場景

場景一：Code Review 中的提問

不好的提問：

「這個函式寫得不好」
「為什麼不直接用 for 迴圈？」
「這個命名很奇怪」

好的提問：

「這個函式的職責似乎比較多，我們可以考慮拆分成兩個函式，一個負責驗證，一個負責處理，這樣會更容易測試和維護，你覺得呢？」
「我看到這裡用了 map，但如果我們只需要找到第一個符合條件的元素，用 find 可能會更有效率，你覺得呢？」
「這個變數名稱 userData 比較通用，如果改成 userProfile 或 userInfo 會不會更明確一些？」

場景二：需求討論中的提問

不好的提問：

「這個需求不合理」
「技術上做不到」
「時間不夠」

好的提問：

「我理解你想要達成 X 目標，但目前的方案可能會遇到 Y 問題，我們可以討論一下是否有其他方案？」
「這個功能在技術上是可行的，但需要 Z 時間，如果我們先做核心功能，其他功能分階段實作，會不會更符合時程？」
「我擔心這個方案可能會影響到 A 功能，我們可以一起評估一下風險嗎？」

提問的藝術：從「索取」到「創造價值」

傳統思維 vs 新思維

傳統思維：

• 提問是「索取答案」
• 重點是「我要什麼」
• 期望別人「給我解決方案」

新思維：

• 提問是「創造對話」
• 重點是「我們一起解決什麼」
• 期望「共同探索更好的方案」

建立「提問文化」

1. 鼓勵好奇心的提問

「我很好奇，為什麼我們選擇這個架構？」
「我想了解，這個決策背後的考量是什麼？」
「我注意到一個有趣的現象，大家覺得這代表什麼？」

2. 挑戰假設的提問

「我們假設用戶會這樣使用，但實際上是這樣嗎？」
「我們假設這個方案最好，但有沒有其他可能？」
「我們假設這個問題很急，但真的是這樣嗎？」

3. 探索可能性的提問

「如果我們換個角度思考，會看到什麼？」
「如果我們有更多資源，會怎麼做？」
「如果我們重新開始，會怎麼設計？」

總結：提問力是工程師的軟實力

1. 好的提問展現你的思考深度
2. 好的提問創造有價值的對話
3. 好的提問幫助團隊找到更好的解決方案

實務建議：

• 提問前先自己思考 30 分鐘
• 提供完整的上下文和已嘗試的方法
• 用「為什麼」挖掘根本原因
• 將提問視為學習和成長的機會

好的提問不是為了得到答案，而是為了開啟更好的對話。

明天我們來聊聊，如何用「非暴力溝通」來改善 Code Review 的體驗。

#精準提問 #溝通技巧 #問題解決 #工程師軟實力 #吳桑泥的升級書單