初次見面。我是 PRUM 股份有限公司的工程師 Hitomi。
我平時會整理並分享在程式學習與實務中容易卡住的重點，以及工作中容易發生的「落差」。
如果能幫助到誰，我會很高興。
防止「有說／沒說」——在需求定義中應該使用的提問技術
前言
剛入行的時候，我曾經這麼想過。
「只要會寫程式，工作就能順利推進」
我相信只要精進技術就會受到肯定，因此一直持續學習程式設計。然而真正進到現場後，反而最受肯定的前輩是「很會提問的人」。
即使在會議中仔細做了筆記，事後還是常常因為「我沒有那樣說」、「不是那個意思」而發生爭議。這種事情，我一開始也反覆遇到很多次。
問題不在理解力，也不在技術力，而是在提問方式。
這篇文章會整理在需求定義訪談中真正能派上用場的「提問技術」。
「只要問就好」的誤解
在需求定義的會議上，
你是否有過這樣的經驗？
客戶：「希望系統能再好用一點」
我：「了解，我們會改善」
會議氣氛和樂地結束，
我還以為「好，需求已經掌握了」，
結果實際開始開發後，卻被說「不是那個意思」。
不夠的不是「資訊量」，而是提問的意圖太模糊了。
例如，「希望更好用」的背後，
可能藏著什麼呢？
- 可能是按鈕不好按，屬於 UI 問題。
- 可能是處理太慢，屬於效能問題。
- 也可能是操作步驟太多，屬於設計問題。
以為自己有問到，其實根本沒問到。
這就是大多數「有說／沒說」問題的原因。
Step1 提問有兩個方向
想提升訪談品質，首先要記住的是「水平提問」與「垂直提問」的區別。
水平提問——把資訊橫向展開
「還有其他困擾嗎？」
「這次翻新／改版時，有哪些項目是想優先處理的？」
在會議前期反覆使用這類「擴大範圍的提問」，就能逐漸看出客戶需求的整體樣貌。最可怕的是到了開發後期才被告知：「其實那個功能也需要。」
善用水平提問，就能在早期避免這類規格漏失。
垂直提問——把資訊往下挖深
「具體來說是什麼狀態？」
「您認為這個系統延遲，是網路環境的問題，還是伺服器的問題？」
一旦掌握了整體輪廓，接下來就要針對單一點深入探問。「不好用」的背後一定有具體原因。垂直提問就是為了讓對方把那個原因說清楚的技術。
如果忽略垂直提問，就可能做出南轅北轍的修改。
Step2 與其問「要做什麼」，不如先問「為什麼要做」
現場還有一個很常發生的失誤。
當客戶說「希望做一個使用 AI 的銷售預測系統」時，直接就進入 AI 系統設計。
我從前輩那裡學到的是，
要先問目的，而不是先看需求。
「為什麼會在這個時間點開始考慮這件事？」
「在眾多 IT 技術中，為什麼特別關注 AI 呢？」
這樣一問，
就會聽到「其實每個月都要花 20 個小時人工彙整，真的很辛苦……」
這樣的真心話。這時候，與其做 AI 系統，不如做更簡單的自動彙整工具，成本更低，也往往更受歡迎。
不要只照單全收客戶的話，而是去問那句話背後的「困擾」。只要能做到這一點，你就不只是寫程式的工程師，而會被當成解決課題的夥伴。
Step3 取得「是」或「否」的合意技巧
收集完資訊、確認完目的之後，接下來就是「確認」的步驟。這裡要記住的是兩種問題的用法。
限定提問——用於確認與合意
「這次的會員註冊畫面，不包含社群登入功能，這樣就定案可以嗎？」
「以下個月的某某日之前提交原型，這樣的時程可以嗎？」
不要模糊地問「您覺得如何？」，
而是針對單一點直接確認「這樣可以嗎？」。
只要拿到「可以」這個回應，
就能避免之後的「有說／沒說」問題。
擴大提問——用於資訊蒐集
「導入新系統之後，現場人員理想的操作方式是什麼？」
「在目前的系統中，什麼時候最讓您感到壓力？」
透過這類提問，可以挖掘出客戶自己也還沒完全語言化的資訊。
用「擴大提問」展開，再用「限定提問」定案。
只要意識到這個流程，
會議結束後留下的那種
「感覺很模糊」的狀態就會減少。
Step4 將需求「具體化」與「抽象化」
最後，介紹一點比較進階的技巧。
需求的具體化
剛入行的時候，我曾經被要求「希望能支援手機」，我回答「了解」之後就直接開始設計。
後來才被接連指出：「為什麼不支援 Android？」、「橫向顯示會跑版」，結果只能整個重新設計。
那時候真正需要的是這些確認：
「iOS 和 Android 都是目標平台嗎？」
「要保證在哪些瀏覽器上可正常運作？」
「需要支援橫向顯示嗎？」
把粗略的需求拆成更細的元素。
這就叫做Chunk Down（具體化）。
事先確認好，就能避免設計重做。
將本質抽象化
當對方一直在討論畫面設計的細節時，
可以透過這樣的問題把視角拉高：
「回到根本，這次透過數位轉型，您希望 5 年後組織變成什麼樣子？」
這就是抽象化（Chunk Up）。讓對方暫時離開眼前的規格比較，轉而思考「為什麼要推動數位化」這個本質目的，就能看見真正需要的系統樣貌。
剛入行的我，以為只要把對方說的內容記下來，
就代表已經把需求抓到了。但其實，
光是提問種類不同，能挖出的資訊就完全不一樣。
總結
「有說／沒說」不是技術力的問題，而是提問設計的問題。
重點在於：你是帶著「這個問題想挖出什麼」的意圖去問，還是只是單純聽對方說完就結束，差別就在這裡。
前輩提醒我後，我最先改變的是「減少自己在會議中說話的時間」。當自己一直在說話時，客戶就不會提供資訊。
增加傾聽的姿態，提升提問品質。這樣的改變，應該能減少會議結束後那種「感覺還是很模糊就收尾了」的狀態吧。
PRUM 的工程師有 95% 以上都是從零經驗錄用的。如果你對我們公司有興趣，歡迎看看下面的網站文章。
原文出處：https://qiita.com/prum_hitomi/items/d06e7479122150ee0ad9
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
