成功的需求發展(上)
拿出專業避免落入「你沒說」「你沒問」的無間道！
幾年前的一個晚上，筆者和幾位同事去吃涮涮鍋，吃到一半想加沙茶醬，就請服務生過來。當時我很直覺的請他幫我加沙茶，服務生答了一聲好之後就飛快的轉身回去。這時同事開玩笑說，他不會就只幫你加沙茶吧？果不其然，服務生只添了沙茶就送回來了，只能說他很忠於顧客的指令，什麼佐料都沒有加。過了一會兒，另一位同事也想加沙茶，這時來了另一位看起來比較資深的服務生，她問的可詳細了，只要沙茶嗎？要加醬油嗎？需要佐料嗎？要不要加辣？同時順手又把幾個空盤子收走。
這兩名服務生的應對其實就和我們在和客戶訪談時的情境差不多，第一位服務生是依照客戶的要求提供服務，也沒有設身處地的為客戶想，客戶也是看到他端上來只有沙茶沒有其它佐料時，才知道自己要的不只是沙茶（這位服務生當時也許內心也在OS：「這個顧客真是奧客，要什麼也不一次講清楚！」）；第二位服務生看了桌上的碟子後，判斷客戶要的不只是沙茶，所以進一步和客戶再確認他真的需要的東西，只是多往下問的一個小動作，就可以讓客戶覺得這個服務生很專業。
在生活中有許多這樣的例子，我們也隨時在當別人的客戶，跟別人談我們的需求，我們也不見得能一次把自己的需求說清楚。但身為一個服務提供者，這是我們的專業，我們要有能力盡力去把需求挖出來。否則到最後的對話一定是：開發人員指責是客戶自己沒有說，客戶指責開發人員沒有問，專案一旦走到這種地步，不管後來怎麼收尾，雙方都不會有愉快的經驗。
有次部門聚餐的場合 （不是筆者喜歡吃，只是舉餐飲的例子大家最有感覺），地點是在公司附近的一家燒肉店。由於是吃到飽，我們先點了幾盤後，就針對一些較喜歡的菜色加點。其中有一盤菜我們想要稍做改變，於是我們找來了服務生，沒想到服務生竟然很有自信的回答我們：「根據我們以往顧客的反應與公司的研究，這樣的搭配比例才是最佳的口感哦」。頓時大家都楞住了，一般服務生就算不是粗魯的回絕，也是接了單子後回去和經理討論，能像這位服務生這樣婉拒又讓客戶覺得專業的實在不多。試問有多少系統分析師可以很自信的對客戶講出：「根據我們多年來導入的經驗，這樣的設計才是客戶最能發揮效益的架構」，如此不但可替客戶省下客製化的成本，也消弭了系統穩定性的風險，還能讓客戶感受到專業。
需求相關問題
從以往的經驗與文獻[1]來看，需求的品質幾乎主宰了專案的成敗，常見的需求相關問題不外乎：需求的不斷蔓延、需求模擬兩可、需求鍍金等。
世上唯一不變的就是變－需求不斷蔓延
做專案的人常說：「計劃趕不上變化，變化趕不上客戶(或老闆)一句話」。在專案進行中，需求就是會不按計劃的不斷冒出來，需求不斷蔓延固然是客戶造成的，但不斷答應需求的開發人員也難辭其咎。要管理專案範圍，在專案啟動之初，便需在雙方的啟動會議中，針對專案的目標、範圍、預算、限制、成功條件等形成共識；同時也要建立有效的異動管理程序，以協助客戶評估衝擊與風險，在雙方同意變更的同時，其實也是對變更所衍生的時程、預算、系統品質穩定度等變數做了取捨。
羅生門－需求模擬兩可
有一位計程車司機分享了一個經驗：
司機：「小姐您好！請問去哪裡？」
乘客：「到疾病管制局。」
司機：「好的！」
司機按下計程表，乘客也開始閉目養神。過了一會兒，
司機：「小姐，疾病管治局到了！一共175元。」
乘客望一下窗外：「不對啊，這不是我要去的地方啊！」
司機：「是啊！這裡就是疾病管制局啊！我最近才載過一位主任來上班的啊！」
乘客：「不管啦！我要去的是昆陽街那間啦！」
司機：「我知道的就是林森南路這間啊，昆陽街還有一間喔，你不早說！」
乘客：「我也不知道林森南路也有一間啊，你也沒問！」
常有專案在後期客戶看到系統時才發現，當初需求規格上的描述與自己認知的有差異，當雙方坐下來解讀需求規格時，常會公說公有理，婆說婆有理，相關人員都有其各自的經驗，也經常就把那局部的經驗當作了全部，這也替需求提供了模擬兩可的溫床。這樣的需求會造成不少困擾，開發人員用自己的解讀在設計，測試人員用不同的解讀在做測試與要求，使用者用另一種解讀在看系統，於是「你沒說」、「你沒問」就成為需求走樣的推拖之辭，奈何時間已經浪費了。因此需求務必要直接了當，並力求精準，如：「我要去昆陽街161號疾病管制局昆陽實驗室」。如果要避免這樣的困擾，光是把需求規格以公文傳送的方式讓每個人都看過一遍是不夠的，要是大家都以自己的角度去解讀，且剛好都可以解釋，那模擬兩可的問題就不會被突顯出來。一定要有人能從不同的角度來檢視這些需求敘述，或是以測試個案或雛型來驗證是否有模擬兩可的需求。
好還要更好－需求鍍金
有時候會有比較「熱心」的客戶，會提很多改善的建議，客戶多半不會在乎多加的功能需要花多少額外的時間與成本，而且有些功能雖然會讓系統表面看起來更酷，但對系統不見得會有太多加值作用。為了避免需求鍍金，要建立需求追溯表，把RFP裡所要求的項目展開到功能，如此可以確保每個功能都是為了滿足哪些RFP的項目，也能協助客戶聚焦在能完成其業務所必要的功能上。
參考文獻
[1] Wiegers, Karl E.2003.Software Requirement 2nd Edition, Microsoft Press.