輕鬆談軟工

兩個小鎮之間有一個荒蕪之地，一些汽車會經過，一個聰明的商人於是在那裡開了一間加油站，生意還不錯。一個月過後有人在旁邊開了一間雜貨店，買點日用品喝點水，再過一些日子有人開了咖啡店，可以休息聊個天。漸漸的有人在那裡蓋房子住了下來，於是餐廳、學校、銀行進駐，慢慢的變成一個小鎮。 同樣一個故事發生在另外一個地方，生意人覺得加油站真賺錢，於是在附近蓋了第二間加油站，生意也還可以，於是第三個人再進來蓋加油站，開始削價競爭，最後三家生意都做不下去紛紛倒店了。 老掉牙的故事，每隔四五年就會聽到一次，但感受卻越來越深。 我們現在做的系統（或事情），是第二個加油站，還是邁向小鎮的咖啡廳？

軟體系統常常背上許多莫需有罪名，有時候是需求的提供者沒把需求說清楚（或根本說了錯誤的需求），有時候是使用者不會用 （沒參與教育訓練或沒看說明書）造成操作不當。當後者的情況發生時，使用者通常會怪罪『介面設計不好』。 的確多數的軟體工程師對於介面的設計不重視也不在行，但有時候使用者也太無理取鬧，把所有的錯誤都賴在介面設計上。 張大叔最近開始使用線上照片沖洗的功能，但照片卻遲遲沒有寄到，他上網查了一下，發現住址寫錯了。他打電話到客服中心發飆。 『你們的系統有問題不穩定，把我家的地址記錯了。明明是100號，怎麼會記成200號？』 客服查了一下，回應說： 『張先生，有可能是您打錯了，系統記錄的的確是200號』 『怎麼可能？我打過無數次了，怎麼可能會把自己的住址打錯？』 客服有耐心的說： 『有可能1和2相鄰，您打的時候打太快了，所以不小心打錯了』 『那你們系統要做檢查嘛，哪有那們笨的系統？要做防呆嘛』 客服楞了一下，還好他邏輯還清楚： 『張先生，我們系統不知道你住100號，怎麼知道您打錯了？沒有辦法喔...』 這下換張大叔楞了一下，但他還是很生氣。 『這照片是我送給老婆的生日禮物，照片我選了好久，沒有按時寄過來這個禮物就沒有意義了』 ，頓了一下又說： 『你們要怎麼賠償我的損失？』 『先生，這是您打字錯誤所造成的，我們沒有辦法賠償。我們會通知郵局將包裹重寄，但您要再負擔一次運輸費用』 客服說。 張大叔一聽還要多負擔就生氣： 『都是你們系統的問題為什麼要我負擔？你們介面設計的太糟，介面要儘量防呆嘛... 比如說不要讓我們用打的，讓我們用選的...』 客服有點聽不下去了： 『先生，忠孝東路門排很多，我們不可能把所有門排都列出來讓你選』 『怎麼不可以，你可以每一個位數都用一個下拉式選單，三個位數只需要三個下拉式選單，你們設計要用點腦筋嘛』 ...

對開發軟體系統的人而言，最害怕的並不是寫程式，而是千奇百怪的需求。一個朋友告訴我他曾經做過某個學校的校務系統，在加退選的前一天： 『第十五個選課的人不可以退選』學校突然向他們要求這個需求。 經過了解才知道一門課至少必須有十五位選課才可以開課，否則就會倒班，所以校方就提出這個需求。但是用這種方式來預防倒班也有點奇怪。 有趣的事發生了。甲生是第十五個選到課的人（當然他自己不知道他是第十五位），而第十六位選到課的同學正好是他朋友，甲生眼睜睜的看到他同學可以退選，自己卻不能退選。接著又有其他人加選後退選也可以，但他剛好又是第十五位，他還是不能退選，你說氣不氣人？ 於是這個問題學生提出來，最後只好把把這個限制拿掉。有時候一個系統的功能看起來沒有幾項，卻是在修修改改之間浪費了很多的時間，如果能夠事先想清楚，是不是可以省很多的時間？如果一個有經驗的系統分析師能夠在顧客提出奇怪的需求時就能跟他們分析這些需求後續可能造成的影響，那就有很大的幫助。

我自己以前很喜歡寫程式，現在不年輕了就較懶惰，所以大家猜的出來這故事發生在很久很久以前... 一顆1MB的RAM要一千塊美金，而且要排隊一個月才買得到的時代 。 我當初為了一家forwarder/broker（海陸運）公司寫一些應用程式。幫他們架網路，再完成了會計系統、出入口系統等業務的東西，終於要幫Sales的人們開發他們的系統。花了一些時間，把基本需求完成，然後很雞婆的幫他們作了一個小工具。結果，那個小工具成為Sales的人們最喜歡用的功能。 為什麼說雞婆呢？因為這沒有在他們本來的需求裡，而是在某幾次吃飯或咖啡場合聊他們做事的方法，我自己去作一些prototype開發出來的。其實那個功能需要跨幾個資料庫撈一些資料再整合，只是我們當初所使用的資料庫系統會鎖住資料庫，沒辦法邊看邊編輯資料。其實是為了安全的考量，資料庫鎖住是很合理的事。可是為了這限制，我一直沒有辦法完成我想要的功能。最後，在某一次的嘗試中，動態跑到作業系統裡把lock挪掉，做完工作，再把lock搬回，竟然就完成了所期待的工作。雖然有些危險，但是我非常有把握在這些功能的使用範圍內，應該是不會發生任何問題。 事實上，這工具他們之後用了很久，而且沒有發生任何意外。直到有一天我接到越洋電話... 時間已過幾年，我也搬來台灣。原來他們要upgrade系統，再重建構系統，所以希望我說明當初到底用了什麼撇步完成那功能。 坦白說，我連什麼功能都忘了，哪裡記得什麼妙法？ 不知道各位有類似的經驗嗎？很多時候拼命coding，不是trial-and-error，就是靠著一些靈感完成工作。然後，沒記下來，過幾天就忘光光了。 明明知道要加註解，可是怎麼可以停下這麼順的『手感』，就繼續code下去了。更不用講到文件了...

這是一個朋友的朋友的故事。 當時他還是一個剛當上PM的年輕工程師，第一個案子就遇到大系統，是一個會計相關的系統。辛苦了兩年系統終於到了收成的時機，但是由於許多的需求一開始沒有說的清楚，客戶不斷的質疑他們功能並不完整，介面也不好用，案子又拖了兩個月都結不案。有一天客戶約他吃飯討論系統功能，他準時赴約。 沒想到客戶劈頭第一句話就說：『怎麼不早點來』？他自認以他的手錶來說是準時的，於是那一場氣氛不太好的飯局並沒有達到共識，雙方不歡而散。 過了幾天客戶又約了吃飯，這次他早了10分鐘。想不到幾個客戶已經坐在那裡喝茶等他了，客戶看了看他，還是說：『怎麼不早點來？』。他心裡悶的很，想到張良的故事。心裡想，我下次提早半個小時來，看你怎麼說。 第三次他提前半個小時來，果然比客戶早些了。在愉快的用餐後準備離開前，客戶起身握著他的手說：『下次再提早來』。他有點震驚，卻也不敢說什麼。回去問他的老前輩，是不是顧客在發什麼神經？ 老前輩嘆口氣說：『他的意思是要你提前（錢）來』。年輕的小伙子才恍然大悟。 這自然是不可取的事，卻也說明了軟體驗收的困難。許多細微的地方如果沒有寫清楚、說明白，就等的驗收的時候被刁難吧！所以在定義需求規格的時候，腦袋裡一定要想到『 我怎麼驗收這一項需求 ？ 』。 另一方面，一定要有把需求擴大來想的本事，顧客跟你說：『這裡要可以輸入商品名稱』， 不要單純的以為只要用一個 TextArea 放個欄位給使用者輸入就好了，顧客腦袋裡想的是一個『商品管理系統』 ，到時候商品名稱要用點的、用拉的、絕對不會是鍵盤輸入的（輸入有很多種，鍵盤輸入只是其中一種）。所以要跟他確認，千萬不要一廂情願的往容易的方面想。如果他真的要一個『商品管理系統』，那麼就得加錢、加時間、或至少釐清了我們做不到。