在各類型的軟體開發情境中,有時候開發人員會有機會面對客戶的需求。而最近就有一位研發團隊的工讀生,在即將離職時,問了一個經典的問題:
--------------
你們是如何拒絕或調整客戶不合理的需求?
--------------
問題的本身很經典,但是卻必須要追本溯源。
首先,需求(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)讓客戶看到,並且用到那段時間產出。確保客戶對團隊前進的方向是一致。也確保即便團隊方向有誤,也會在一定時間內被發現。
「事實」:有時候事實很難全面探究完整。有時候細節太多,即使都是正確的資訊也過於繁複。
巫醫在同樣的事實上,都會有不同的詮釋。例如:經過鞭打火烤病人之後,病人仍然掛了。巫醫的詮釋通常是:惡靈不願意離開病人,是天命所致。
而以「事實」詮釋「事實」才不是誤人一生的巫醫。當軟體開發團隊常常客戶不合理的需求。不應該隨隨便便將此視為「惡靈不願意離開,乃是天命」。而應該「改變」執行方式,應對不合理需求。如果巫醫不願意改變(註二),換一個醫生是根據事實最合理的方法。
註一:違法的需求,當然是要直接拒絕。這類型的基本常識,不在此討論範圍之內。
註二:如果巫醫很容易以事實說服,那就不是巫醫了