布魯斯跟基德搞了老半天，
還是對於怎麼進到玟萊國王後宮沒概念。
於是布魯斯只好跟吉娜討救兵：這真的在scope裡面嗎？
那有可能進得去玟萊國王的後宮呀？你去跟客戶橋橋看吧。
鄭和下西洋(六)：發掘隱性需求的能力
鄭和下西洋(六)：發掘隱性需求的能力
獨孤木 2006/06/19
布魯斯跟基德搞了老半天，還是對於怎麼進到玟萊國王後宮沒概念。於是布魯斯只好跟吉娜討救兵：這真的在scope裡面嗎？那有可能進得去玟萊國王的後宮呀？你去跟客戶橋橋看吧。
吉娜：讓我翻翻合約。糟糕，合約寫得很含糊。裡面只講說要送他到任何他想去的地方。不過報酬是扣除我們的費用加一倍。當初可沒有設任何排除條件。
布魯斯：業務部每次都簽這種合約，這要怎麼做？我不會。連半條對我們有利的都沒有喔？
吉娜：讓我想想，他只講玟萊國王的後宮？什麼其它的requirement都沒說？
布魯斯：沒有呀。還有什麼requirement？
吉娜：窮則變，變則通。你連絡一下高義那個狗雜碎，他不是在拉斯維加斯開賭場嗎？叫他在那邊開一家夜總會，名字就取名叫做『玟萊國王的後宮』。翻一下會議記錄，確定這個名字跟客戶講的一模一樣，我們先把客戶送出國，夏威夷繞一繞，再送去拉斯維加斯，等到他賭累了就把他拖到夜總會。接下去就把它當做是一個誤會。反正多找一點漂亮美眉去把他纏住，既然就只講說要去玟萊國王的後宮，我弄一家店名字一模一樣，再當做搞錯了，這不就得了？反正在他回國之前，我們大家把獎金領完，然後公司趕快解散，再去維京群島換個名字登記，不就結了？
布魯斯不禁拜服：高招，確實是高招。老闆果然是智計過人。
X X X X X X X X X X X X
正是因為雙方溝通如果單靠文字，實務上在溝通時會非常不精確。同樣的一句話，可能會有很多種不同的解讀方式。所以我們在開發系統時，會採用各式各樣的模型、畫面、與敘述來進行溝通。
然而當溝通的雙方對於想要溝通的內容還是有不同意見時，我們通常會怎麼做？嗯，既然大家意見不同，那就開個會吧。開完會就打打會議記錄簽個名吧。
你認為這樣就一切ok了嗎？事實上，會議記錄通常也是一堆文字的集合。用會議記錄去記載大家的共識，其實還是會存在很多模擬兩可的地方。從會議記錄到你要的功能之間，還有很漫長的路要走。
正因為我們會用招標文件、合約書、會議記錄…這類型的書面文件來當做開發的基準，當你在文字上不夠精確或者是不夠翔實，或是遇到刻意曲解的人，就有可能會引起爭端。
你要怎麼樣用文字描寫一匹奔跑得飛快的汗血寶馬？當你乘坐在上面時，只感覺到這匹馬放開四蹄，邁步狂奔，一時之間，僅覺得耳畔風聲作響，房屋樹木不斷後退。當你從這個角度去描寫時，怎麼樣去描寫你視線所看不到的地方？比如馬的眼睛是怎麼樣張開的？馬的尾巴又如何迎風飄逸？
透過文字，又怎麼樣在他人的腦海中重建出一幅客觀的標準？例如，汗血寶馬跑得是很快，可是到底時速是多少公里呢？譬如說我們在文字中常常描述說快如雷馳電掣，問題打雷是音速，閃電是光速，兩個速度相距甚遠，一匹馬真的跑得有這麼快嗎？如果我們沒有辦法透過文字對系統給一個明確的定義，光在文字上打迷糊仗，這其中的空間就相差很大了。
當然，如果我們把很多重要的資訊給量化，那相形之下就會有比較精確的資訊。比如說系統要可以同時允許200個user上線查詢，反應時間應該在4秒之內，也就是說盡量使用數學來記錄相關的資訊，這樣一來，就比較沒有模糊的空間。
不過，大多數在跟你溝通的客戶，可能並不具有良好的數學能力，所以你開發的基準會建立在比較含糊的文字敘述上。這個時候，開發人員就必需要培養發掘隱性需求的能力。
發掘隱性需求的能力
喜歡看福爾摩斯探案的人都知道，這位名偵探擅長從別人沒有注意到的小細節，再搭配廣博的知識與推理，就可以在一團迷霧之中，直接撥雲見日，找到真正的罪犯。他如果換做生在今日，跑來開發資訊系統，應該就會是一個很好的系統分析師。
開發軟體有時候會需要從極有限的資訊中，找出打造系統的線索。特別當需求是透過口述，透過會議記錄，透過文件傳遞的話，常常會只從某個角度去描寫，而忽略某些特別的狀況。講出來的話，常常有些人會期待你能夠自動明瞭其中的微言大義。當你隱而未明的訊息越多，如此一來，想要傳達的訊息就會形成某種程度的失真。當我們越晚發現這個隱藏起來的需求，它對於專案的影響就越大。
X X X X X X X X X X X X
讓我們看看三流小說家所寫的場景：
女生哽咽地說：你不愛我了。(因為你都不再送花給我，我們上一次去餐廳裡喝美酒、聽音樂、吃大餐是多久以前了？更不要說已經有多久沒有開車到山上看夜景數星星了。)
男生很困窘：你怎麼會這麼想呢？寶貝？我當然一直都是很愛你的呀。(奇怪，難道昨晚我表現太差了嗎？)
女生繼續抽泣：你對我，跟以前完全都不一樣了。以前，你是那麼地用心…(你以前會陪我去逛街買東西，現在只想留在家裡面看球賽轉播。)
男生恍然大悟(果然！最近熬夜都很晚睡，那有辦法撐那麼久？看來只好請藍色小精靈來幫忙了。)：寶貝，我最近陪你的時間比較短。(女生點頭了，男生在想，原來你就是嫌我快！)我會好好補償你的。
女生繼續抽泣：真的嗎？(好期待這個浪漫的燭光晚餐。)
男生：當然啦，寶貝。(等著吧，我馬上去買威而剛。我看，還要再多逛逛情趣商店。)
X X X X X X X X X X X X
當雙方有太多話語沒有明確地表達出來時，就形成了溝通上的障礙。這也就是為什麼domain knowledge在開發系統時會不斷被人強調是個很重要的因素。主要是因為當你做過越多這樣的系統，累積了越多domain know-how，就越能夠在不夠完整的描述中，幫客戶補足他們在思考時所缺乏的部份。
從專案管理的角度來看，溝通不良衍生出來的問題就會是不斷的會有requirement change。事實上很多被稱為requirement change的東西，都是溝通不良，或者是開發的人沒有使用正確的方法來收集使用者的需求所造成的。
面對這種現象，難道我們一點辦法都沒有，只能像是望著女友劈腿的宅男，面對自己的電腦啜泣嗎？這未免也太過高估這個問題的難度了。很多人頭一次打造系統時，總認為這是千百年來，頭一次有人遇到這麼困難的千古奇案。天將降大任於斯人也，必先苦其心志，所以只有我這個經過上帝挑選的人，才會遇到這種困難的問題，這個問題一定要用我驚人的腦容量才可以提供出完美的解答。
事實上，要解決這個問題，整個資訊產業界其實運用了兩種不同的哲學來當基準。這兩種作法不見得有什麼是非對錯可言，你必需要視狀況來決定要用那一種方式來解決問題。
留言列表
