有位富翁，家世頗豐，某天想要蓋座新房子，便找上了一家建築承包商，委由他們代工。
包商問富翁想要蓋什麼樣的房子，富翁說："我想要一棟五層樓的洋房，還要有個中庭游泳池，
旁邊再種上一些大王椰子；大門要夠大夠氣派，讓人一看就知道這家主人不同凡響。"
包商一一記下富翁的需求，又問了一些裝潢隔間的要求，感覺一切都沒問題了，於是擇了良辰吉日，破土動工。
等到開始興建時，才發現實行上困難重重；在動工之後，有一兩週的時間，富翁因為忙於私事，出國去談一筆生意，沒空前往工地監工，等富翁從國外歸來，前往工地一看，當場大發雷霆，把包商負責人叫來，指著剛剛打下不久的地基說："你們地基打這麼淺是怎麼回事？萬一遇上地震，屋子垮了，出了事你們擔得起這個責任嗎？"
包商有苦難言，直哈腰說："是是是，您對於這方面的顧慮的確不無道里，但是根據我們承作其他工程的經驗，五層樓的方屋，這樣深的地基已經綽綽有餘了，請您放心。"
富翁手一擺，說："不行，這房子蓋好之後，我可是打算在這安養天年的，地基不牢固些不行，再給我打深三丈。"
包商心裡叫苦不迭，當初在講條件的時候，可沒說清楚地基要打多深，施工的時候，也就想當然爾的根據過去的經驗，決定了地基的深度，沒想到才剛剛開始施工，就踢上了鐵板。說不得，也只好照著富翁的意思，再把已經打好的地基往下打深三丈；說起來容易，這一來一往多出的成本不提，光是要請建築師、工地師傅們研究怎麼把已經打好的地基再往下打深三丈，就不知花了多少功夫，這種事就算是資深的工頭們也沒遇上過半次，偏偏這次遇上了，也只好勉為其難，大傢伙兒硬著頭皮，研究了一個可行的方案，小心翼翼的趕工，總算是達成了富翁的要求。
沒想到還沒完，等到鋪磚蓋瓦，一棟五層樓洋房的雛型剛剛出來，富翁他老人家一到現場，看了一下之後又不滿意了。
富翁："你們這房子是怎麼蓋的，怎麼蓋得歪歪斜斜，亂七八糟的！？"
包商苦著臉說："您請先息怒，我們這可是考量到您的身份地位，替您找來國外有名的設計師，精心設計出來的造型，行家一看，包準知道這房子裡住的人品味不凡啊。"
富翁不買帳："少來這套，我就是不喜歡這種太過摩登的造型，那些凸出來的菱菱角角，統統都要給我拿掉！"
包商一看說理無效，對方是出錢的大爺，也只好摸摸鼻子認了。這下子可就苦了底下的工人了，個個都如丈二金剛摸不著頭腦，嘀咕著："還是頭一次見著這種人，地基打深就算了，現在連專家設計過的造型都不滿意，實在是不識貨。"
咕噥歸咕噥，客戶的要求還是得照辦，於是又是一陣加班趕工，總算沒耽擱太多工期，慢慢地也把進度趕上了。
整個工程進行過程，類似的狀況頻仍－蓋了泳池之後，富翁他老人家不滿意，硬是要把根據國際標準興建的方形泳池，改成橢圓形；一樓大廳的落地窗他也不滿意，直喊著寬度太小，看起來不夠氣派，連採光會因此受影響都牽扯進來。各式各樣的要求，林林總總不一而足。
原本預計一年半完工的工程，過了將近兩年半的時間，好不容易總算是接近完工階段，各個小地方也差不多都折騰過了一遍；要交屋的那天，包商一直皺得像包子的臉，才稍稍舒展開來，心想，忙了這兩年多的時間，總算是把這件苦差事給完成了。
富翁到場之後，四處繞了繞，看了看，好像也頗覺滿意；包商心裡打著如意算盤，等拿到最後這筆尾款之後，可以發點獎金，犒賞底下辛苦了這麼久的工人們；還有些盈餘，可以拿來置辦公司裡的一些家具，太過老舊的就可以汰換掉了。
沒想到白日夢正作到一半，富翁又有意見了："當初這大門要你們蓋得氣派些，你們蓋得是夠氣派，可這樣式....我上星期去陽明山上，似乎在某間別墅門口看到一模一樣的？"
包商心裡一邊腹誹，一邊說："這大門我們也是煞費苦心，參考了不少別墅，最後才選定一個最好、最氣派的樣式，根據這樣式施工建造的，別人一看，就知道您的身份尊榮非同一般。"
富翁搖了搖頭："好聽話就不用多說了，說好聽點你們是參考，講白點，你們根本就是直接去抄襲別人有的東西，拿來在我的房子上直接套用，萬一將來被別人知道了，我這大門跟某某人的一樣，叫我這張臉要往哪兒擺？不行，這大門給我換掉，我要一個獨一無二，與眾不同的大門！"
聽到這話，包商差點沒腦充血，當初這大門作到一半的時候，你可是親眼看過的，當初沒意見，現在意見又一大堆......
後來這工程沒有善了，陸陸續續的修改，比原先估計的工期又多了不少時間，包商實在不堪虧損，只好中止施工，雙方還因此告上了法庭，直到現在，還在纏訟當中。
富翁和包商的故事，在這裡暫且打住；但看到這個故事時，不知道你是否和文中的包商一樣，也有似曾相似的經驗？
三年前，如果有人問我，軟體專案最重要的第一步是什麼？我可能會回答不出來，但是三年後的今天，我的答案是－需求！
沒有搞清楚需求，就盲目以自己覺得可行的方式實作，到最後，就會落得像文中的包商一樣下場，錢燒了，東西作了，但客戶永遠都不滿意，最後的工程也沒辦法順利完成。
沒有需求，就沒有設計；沒有設計，就沒有實作、測試。
沒有需求，即使到最後自己覺得該做的都做了，但怎麼樣都驗收不通過，為什麼？因為我們和客戶心目中的驗收標準，從來都沒有一致過。最好的方式是，白紙黑字，把客戶的需求，明明白白的寫下來，這份需求列表，不只是設計實作的開端，也是將來驗收的清單，但驗收清單可能比需求列表更詳盡，畢竟要用來驗收，最好能把每一項功能都弄清楚講明白，到底客戶要的是怎麼樣的東西？按照怎麼樣的操作步驟，輸入什麼資料，相對就得到什麼輸出，一個個定義清楚，這部份的歧義越少，將來驗收時，遇到的麻煩也越少。
但定義這樣的一份清單，老實說，並不容易。
如果是比較劣質的客戶，可能還不希望有這份清單，就拿上面的富翁來說，他的需求越模糊，對他自己越有利，怎麼說？就拿上文的例子，他要的是氣派的大門，但怎麼樣才算氣派？是鑲滿了黃金鑽石，還是翡翠琉璃？沒人知道。這部份越模糊，留下的灰色地帶越大，將來驗收時他能為自己爭取的福利就越多，藉口刁難的力度就越大。反正這些需求沒人白紙黑字寫下來過，雙方只有口頭協議，說過了就算，萬一有一天真的不幸對簿公堂，沒有呈堂證據說明，也只好期盼法官能站在包商的角度，替這些苦哈哈的建築商設想了。
話說回來，近年來很流行的測試驅動開發(Test-Driven Development)，第一步驟，要求的也是先列表，把要實現的功能列出一張清單，一開始是很粗略的項目，然後開始細化，一項項釐清；至於細化要到什麼程度呢？簡單來說，要到能夠看了這張列表，就能夠開始動手寫程式的程度，而不是看了之後，腦袋裡還有一堆問號，如果發生了某狀況時要怎麼處理？這張單子上看不出來，那怎麼辦？先置之不理，等到有一天被人發現了再說？還是先隨便按照自己設想的處理方式寫一個，等到以後有人不滿意再說？不管是哪一種方式，都只是埋下一個地雷，等到某天被引爆而已！
還不如一開始就把需求弄清楚，讓自己寫程式時，很清楚明白的知道，終點在哪裡，作到什麼程度就算完工，至少心裡也會踏實些，而不是作一天算一天，永遠搞不清楚，到底還有多少事情是沒有完成的。
有了需求列表是第一步，接下來還要根據這份列表，進行時程規劃，還有風險分析。
為什麼要有時程規劃？一來，我們的開發時間有限，一定要列出優先順序，先抓出重點項目，儘可能爭取在時程內把重要的功能先開發完成，再去完成其他的次要項目；二來，有了時程規劃，可以讓專案參與人員心裡有個底，哪些功能是我負責開發的，什麼時候要交付，如果時間很急迫，那可能要加班趕工，儘量在時間內完成，有穩定軍心的作用。一個沒有時程規劃的專案，我相信很多人都經歷過，每天就像是無頭蒼蠅一樣，只能短視的看，我們這週要完成什麼，下週要完成什麼，然後呢？沒有了，我們不知道接下來要幹麼，每個功能好像都很趕，於是每個人拚命加班，終日茫茫而不知何去何從，像是一場拚命向前跑，卻不知道目的地在哪裡的馬拉松，對團隊的士氣，是一種莫大的打擊。
有了時程規劃之後，還需要進行風險分析。風險高的項目，像是某某需要配合的資源可能來不及到位，某某需要特殊技術才能解決的功能，目前團隊裡還沒有人有把握做得出來，這些事情要先抓出來，提前做好因應的措施。就像為什麼颱風預報很重要一樣，如果沒有颱風預報，等到颱風登陸，果農、花農，辛勤了幾個月的心血，近皆付諸東流，在毫無心理準備與因應措施的情況下，損失無疑是相當巨大的；但如果有了颱風預報，我們便可以預先防範，做好準備工作，儘量將傷害降到最低。也許增加人力準備不及到位的資源，或是重新檢討，把不必要的資源精簡刪除(如果不能開源，我們只能節流)；提前找人學習相關技術，儘量將這些高風險項目，對專案帶來的傷害降到最低。
以上拉拉雜雜講了一大堆，只是發發牢騷，其實我心裡還真沒個底，到底台灣有多少軟體專案是這樣做的？(也許其他領域的專案也適用，但我不清楚，不敢妄言)我只知道，如果我們連這樣的觀念都沒有，那根本就不會有付諸實行的一天。到頭來，我們還是像上文的包商一樣，整天跑來跑去，在客戶不斷變更的需求中(不要訝異，需求是會變更的，不過這可能可以另寫一篇文章了)疲於奔命，到頭來毫無所得。
夜深了，牢騷滿腹，點到為止，其他的，有機會改天再敘吧。
留言列表
