在各類型的軟體開發情境中，有時候開發人員會有機會面對客戶的需求。而最近就有一位研發團隊的工讀生，在即將離職時，問了一個經典的問題：
--------------
你們是如何拒絕或調整客戶不合理的需求？
--------------
問題的本身很經典，但是卻必須要追本溯源。
首先，需求(requirement)本身是很難被界定清楚，因為客戶也許也不能清楚的界定需求。Henry Ford 福特 - 福特汽車的創辦人，現代化造車的始祖 - 早在一百年前的名言，至今仍難屹立不搖：
--------------
“If I had asked people what they wanted, they would have said faster horses.”
"如果我問客戶要甚麼，他們會希望跑得更快的馬"
--------------
然而，「直接了當的詢問」仍然是基本的第一步。不過也要先確定問到正確的對象，問了正確的問題，正確地理解回答。透徹的了解問題，才能知道客戶的需求是不是真的不合理，抑或，其需求背後有另外的需求。接下來才能知道怎麼反應。
還沒經過深思熟慮就直接拒絕，很有可能是自己故作姿態，甚至是知識技能不足的表徵。(註一)
反過來說，隨意「答應」客戶，風險也很驚人。因為也許答應了一件根本不應該做的事情，或者答應了一件其實客戶表達錯誤的事情。最悲哀的結果是雙輸：客戶與企業都受害，甚至三輸：客戶企業與社會三者都受害。
而這聽起來極端荒謬的事情，卻一直在企業界發生。
因為誤解客戶需求，或者不夠及時調整需求導致於雙輸的例子，在近20年內的有很多，隨便找一些範例如下：
* FoxMeyer的SAP引入案例(1,2)
* Waste的SAP引入案例
* 台灣戶政系統當機事件(1,2,3)
那到底要怎麼做？
抽象化的形容詞，對溝通不會有助益。
例如：「高可靠度的系統」「網路速度很快」「網站介面很好用」「滿足業務需求」「盡快完成」
抽象化的言語，在務實的書面報告中越少越好。當然某些摘要形式的報告，會很抽象，但隨後必定附上務實的參考依據。
例如：
「高可靠度系統」：已兩台伺服器互為備援的方式，達到高可靠度
「網路速度很快」：過去對外連線的速度是1MB，現在提高到1TB，因此網路速度很快。
「網站介面很好用」：過去每個月平均有150次客服電話，是在詢問網站某些功能要怎麼使用，現在每個月僅有10次。並且，每個月平均使用人數並沒有減少。
互相理解現在的情況是第一步。接下來要做什麼是第二步。
為什麼決定接下來要做什麼和「客戶不合理的需求」有關？
首先，合不合理的判斷本身就很難客觀。對某人來說不合理的事情，對另一個人可能完全正常。彼此價值觀的差異不可能在短時間彌平。但是「具體要做的下一個動作」卻是清晰可見，只要接下來的執行「事項」，確實都是雙方認為最重要的事項即可。
和第一段相同，具體內容必須是清晰可見的動作(action)
例如：
* 將第一批手機抽15%樣本共150隻，進行電池過度充電放電測試。並在N月N號之前，給出測試結果報告。
* 將iOS app送到apple-store進行上架審核。
* 在使用者帳號管理系統上，增加可以使用fb帳號登入的功能，在N月N號之前，給出設計文件。
不是清晰可見的動作，會造成很多不必要的誤解，而誤解就會產生不合理的需求。
不清晰的動作例子如下：
* 產線上的手機抽樣測試一下有沒有爆炸問題 -- (這是要多少樣本測試，一隻也可以嗎？要測試哪種類型的爆炸？太陽曬到玻璃破碎也算嗎？)
* 我們的iphone app要趕快上架了 -- (？是要上架到哪邊)
* 讓fb帳號也能登入系統 -- (是什麼時候要完成？只要登入就可以，細節我們自己決定就好了嗎？還是要先看一下設計文件)
這可能是最重要，但最被台灣企業所忽略，也最容易被企業巫醫上下其手的地方。
可參考這幾個地方：(a) 錯誤檢討，(b) 自我反省，(c) Scrum檢討
「務實」：指的是根據事實來檢討，而非根據感覺。即便是需求檢討也是。
例如：某中國企業要求網站系統必須能讓IE8使用。但是IE8上的javascript版本實在太舊，這樣的要求讓專案經理非常不高興，覺得根本不合理也太不可思議。
如果不務實檢討，那麼每次與客戶的會議，大概就在針鋒相對中度過。但是探究事實，其實是因為該企業內部系統無法擺脫WinXP，而又因為WinXP能使用的IE就是IE8，導致客戶有此需求。就網站廠商來說，當然不可能協助內部全面升級為Win10，但卻可以提供其他在WinXP上，仍然持續更新的瀏覽器(firefox)。
「密集」：指的是Scrum的精神。需要在一定時間(sprint)讓客戶看到，並且用到那段時間產出。確保客戶對團隊前進的方向是一致。也確保即便團隊方向有誤，也會在一定時間內被發現。
「事實」：有時候事實很難全面探究完整。有時候細節太多，即使都是正確的資訊也過於繁複。
巫醫在同樣的事實上，都會有不同的詮釋。例如：經過鞭打火烤病人之後，病人仍然掛了。巫醫的詮釋通常是：惡靈不願意離開病人，是天命所致。
而以「事實」詮釋「事實」才不是誤人一生的巫醫。當軟體開發團隊常常客戶不合理的需求。不應該隨隨便便將此視為「惡靈不願意離開，乃是天命」。而應該「改變」執行方式，應對不合理需求。如果巫醫不願意改變(註二)，換一個醫生是根據事實最合理的方法。
註一：違法的需求，當然是要直接拒絕。這類型的基本常識，不在此討論範圍之內。
註二：如果巫醫很容易以事實說服，那就不是巫醫了
“If I had asked people what they wanted, they would have said faster horses.”
"如果我問客戶要甚麼，他們會希望跑得更快的馬"
--------------
然而，「直接了當的詢問」仍然是基本的第一步。不過也要先確定問到正確的對象，問了正確的問題，正確地理解回答。透徹的了解問題，才能知道客戶的需求是不是真的不合理，抑或，其需求背後有另外的需求。接下來才能知道怎麼反應。
還沒經過深思熟慮就直接拒絕，很有可能是自己故作姿態，甚至是知識技能不足的表徵。(註一)
反過來說，隨意「答應」客戶，風險也很驚人。因為也許答應了一件根本不應該做的事情，或者答應了一件其實客戶表達錯誤的事情。最悲哀的結果是雙輸：客戶與企業都受害，甚至三輸：客戶企業與社會三者都受害。
而這聽起來極端荒謬的事情，卻一直在企業界發生。
因為誤解客戶需求，或者不夠及時調整需求導致於雙輸的例子，在近20年內的有很多，隨便找一些範例如下：
* FoxMeyer的SAP引入案例(1,2)
* Waste的SAP引入案例
* 台灣戶政系統當機事件(1,2,3)
那到底要怎麼做？
1. 根據事實的正確溝通
抽象化的形容詞，對溝通不會有助益。
例如：「高可靠度的系統」「網路速度很快」「網站介面很好用」「滿足業務需求」「盡快完成」
抽象化的言語，在務實的書面報告中越少越好。當然某些摘要形式的報告，會很抽象，但隨後必定附上務實的參考依據。
例如：
「高可靠度系統」：已兩台伺服器互為備援的方式，達到高可靠度
「網路速度很快」：過去對外連線的速度是1MB，現在提高到1TB，因此網路速度很快。
「網站介面很好用」：過去每個月平均有150次客服電話，是在詢問網站某些功能要怎麼使用，現在每個月僅有10次。並且，每個月平均使用人數並沒有減少。
2. 透過具體內容決定接下來的執行事項
互相理解現在的情況是第一步。接下來要做什麼是第二步。
為什麼決定接下來要做什麼和「客戶不合理的需求」有關？
首先，合不合理的判斷本身就很難客觀。對某人來說不合理的事情，對另一個人可能完全正常。彼此價值觀的差異不可能在短時間彌平。但是「具體要做的下一個動作」卻是清晰可見，只要接下來的執行「事項」，確實都是雙方認為最重要的事項即可。
和第一段相同，具體內容必須是清晰可見的動作(action)
例如：
* 將第一批手機抽15%樣本共150隻，進行電池過度充電放電測試。並在N月N號之前，給出測試結果報告。
* 將iOS app送到apple-store進行上架審核。
* 在使用者帳號管理系統上，增加可以使用fb帳號登入的功能，在N月N號之前，給出設計文件。
不是清晰可見的動作，會造成很多不必要的誤解，而誤解就會產生不合理的需求。
不清晰的動作例子如下：
* 產線上的手機抽樣測試一下有沒有爆炸問題 -- (這是要多少樣本測試，一隻也可以嗎？要測試哪種類型的爆炸？太陽曬到玻璃破碎也算嗎？)
* 我們的iphone app要趕快上架了 -- (？是要上架到哪邊)
* 讓fb帳號也能登入系統 -- (是什麼時候要完成？只要登入就可以，細節我們自己決定就好了嗎？還是要先看一下設計文件)
3. 務實的密集檢討事實
這可能是最重要，但最被台灣企業所忽略，也最容易被企業巫醫上下其手的地方。
可參考這幾個地方：(a) 錯誤檢討，(b) 自我反省，(c) Scrum檢討
「務實」：指的是根據事實來檢討，而非根據感覺。即便是需求檢討也是。
例如：某中國企業要求網站系統必須能讓IE8使用。但是IE8上的javascript版本實在太舊，這樣的要求讓專案經理非常不高興，覺得根本不合理也太不可思議。
如果不務實檢討，那麼每次與客戶的會議，大概就在針鋒相對中度過。但是探究事實，其實是因為該企業內部系統無法擺脫WinXP，而又因為WinXP能使用的IE就是IE8，導致客戶有此需求。就網站廠商來說，當然不可能協助內部全面升級為Win10，但卻可以提供其他在WinXP上，仍然持續更新的瀏覽器(firefox)。
「密集」：指的是Scrum的精神。需要在一定時間(sprint)讓客戶看到，並且用到那段時間產出。確保客戶對團隊前進的方向是一致。也確保即便團隊方向有誤，也會在一定時間內被發現。
「事實」：有時候事實很難全面探究完整。有時候細節太多，即使都是正確的資訊也過於繁複。
巫醫在同樣的事實上，都會有不同的詮釋。例如：經過鞭打火烤病人之後，病人仍然掛了。巫醫的詮釋通常是：惡靈不願意離開病人，是天命所致。
而以「事實」詮釋「事實」才不是誤人一生的巫醫。當軟體開發團隊常常客戶不合理的需求。不應該隨隨便便將此視為「惡靈不願意離開，乃是天命」。而應該「改變」執行方式，應對不合理需求。如果巫醫不願意改變(註二)，換一個醫生是根據事實最合理的方法。
註一：違法的需求，當然是要直接拒絕。這類型的基本常識，不在此討論範圍之內。
註二：如果巫醫很容易以事實說服，那就不是巫醫了
