找出客戶真正的需求（問題）

在執行專案過程中有些事件，就跟「你想通了嗎」[1]一書中提到的情景類似，不過當下卻沒有察覺，都是事後解決才發現問題的癥結。
案例一：
在系統即將完成的後期，客戶才表示，其中一項W功能要增加一個新的表單，當初只談好要作2個表單，每個表單其實是對應到他們現有 一項業務，客戶負責提需求的人忘了提出他們還有另一項業務是不同於前2項的，必需要作一個新表單來專門處理這項業務。如果幫客戶做，則延長開發時間，不合 成本，但若拒絕，則這個系統又少了一項執行重大業務的功能，客戶接受度降低。當然我方大可以不符合約的理由正當的拒絕，但似乎不夠圓融，雖然後來我方委婉 說明，希望客戶打消此念頭，但客戶仍持續提出要求，這似乎是個兩難個局面。
後來的解決方法是在兩個原有的表單加上一個可以自由輸入的欄位，這樣，原有2項表單便免強可以轉作第三項業務使用，算是兩方都滿意的解法。不過這方法一開始也沒想到，是跟客戶討論的時候，被提醒的。這件事，問題的擁有者是客戶，並不是我，也就是問題並不是「要不要作第三個表單？」，而該是客戶心理想的：「怎樣才能讓系統幫我處理第三項業務？」如果這樣思考就能跳脫出先前作新表單的思維中。
案例二：
我們要接手前一家公司做好的系統，並對其作部份的修正，需求很明確，但在專案一開始我們對技術與對方的程式碼都不熟悉的狀況下，客戶基層主管R就要我們提 出每項功能的時程，因為距離預定上線的時間只剩一個月，我們彼此又是第一次合作，因此主管R希望我們儘早告訴他我們的schedule。不過在不熟悉對方 系統架構與程式碼的狀況時，實在是很難估計明確的時間。這是一個兩難局面，隨意給一個時程，恐怕造成我們自己未來難做事，不給時程，客戶又相當堅持。
這問題的解決仍然是因為跟客戶溝通的拉鋸過程中，他偶然提到的訊息，因為他要給系統的user、主管一個交代，因此才要我們提出明確時程，因為距上線只有 一個月，我們就答應在三個星期後完成，中間的時程，之後再提出，這樣才算達成共識。一開始問題好像是「怎麼估計出工作時程？」，但是如果換到問題的擁有 者，主管R身上時，問題變成「我怎麼跟主管、user報告，系統何時可以完成？」
雖然我們常常聽過「換個角度想」，但是要換到哪個角度，卻是個問題，以上兩個都是比較簡單的狀況，只要我們換到問題的擁有者身上去思考，就可以找到問題的 真正解決方法。雖然一開始問題的擁有者好像是我們，但其實都是因為客戶有問題，才會造成我們的問題，要透過「誰造成這個問題」、「這問題從哪來的」等問題，來找到真正的問題擁有者。

[1]你想通了嗎？(Are You Lights On?), 唐納德‧高斯,傑拉爾德‧溫伯格, 經濟新潮社