輕鬆談軟工

這是一個專班學生的故事。 他的工作是跟物料管理系統的開發相關。公司用的實作框架中包含一個 tree 的 model。有一天，因為使用者的需求變更，他的上司決定把 tree  model 改掉以快速的解決顧客的問題。他仔細的看了這個方法，知道一定會對後續的成本計算產生問題，因此請主管不要改 tree model。 但是顧客的問題必須要馬上的被解決，所以主管決定還是要改。有軟體工程概念的他，瞭解這個問題的嚴重性，他深深的知道這個東西一改，以後的程式都會以這個基礎下去開發，到最後成本計算穩死無疑，因此堅決不可以改，兩個人於是吵了起來。 其他的組員覺得他很奇怪，沒事為什麼要跟主管過不去，還跟主管吵架。在一個保守的組織中，他的『雞婆』並沒有受到肯定，也沒有人有時間深入瞭解他所說的道理，只是覺得他很『機車』，他只好閉上嘴巴照做。 過了三個月，這個問題浮現了，大家忙得雞飛狗跳。但是，沒有人知道他們所遇到的問題是主管所造成的，也沒有人想到他。大家忙著找一個可以立即解決成本計算錯誤的方法。也許，再把 tree model 亂改一通吧。 大家覺得這個故事有哪些啟示呢？

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

已經是好久以前的事了… 我們到一個部門跟他們談office automation，問他們需要什麼。他們竟然很訝異的說『電腦不是什麼都會嗎？』（雖然過了好多年，這好像仍然是一些人會問的問題） 拿出我們軟工的本領，就開始『需求工程』了，可是問題不太像我以前所碰到的CASE容易，更不像課本裡所說的那麼單純。我們問他們如何作業，沒有人講得清楚，甚至有許多不同版本。結果變成我們替他們釐清問題，替他們定義一些作業方式，就像我們替他們定一堆SOP一樣，結果還被批評一番。經果許多討論與翻修，終於完成。這中間有多少時候我常想，為什麼不是他們，而是我在替他們定需求呢？難道我以前碰過得人，就那麼的合作嗎？ 好不容易prototype出來了，他們開始使用好像不太熟悉，可是試用一段時間後，他們終於瞭解原來電腦不是什麼都會，可是同時看到他們可以藉著軟體系統作更多的事。 以後幾年的合作，他們從被動不合作的『使用者』，變成主動且很聰明的『需求提供者』。他們的胃口也變大，可以想出一大堆非常有創意的應用。真的很難想像當初那不太甘願合作的樣子。 不知大家有沒有，相似的經驗？假如以為需求分析，只是問問東西，或是定一些定義出來，那就好像不是這麼一回事了。