發表文章

目前顯示的是 二月, 2009的文章

好人難為

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

早點來

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

需求工程

已經是好久以前的事了…

我們到一個部門跟他們談office automation,問他們需要什麼。他們竟然很訝異的說『電腦不是什麼都會嗎?』(雖然過了好多年,這好像仍然是一些人會問的問題)

拿出我們軟工的本領,就開始『需求工程』了,可是問題不太像我以前所碰到的CASE容易,更不像課本裡所說的那麼單純。我們問他們如何作業,沒有人講得清楚,甚至有許多不同版本。結果變成我們替他們釐清問題,替他們定義一些作業方式,就像我們替他們定一堆SOP一樣,結果還被批評一番。經果許多討論與翻修,終於完成。這中間有多少時候我常想,為什麼不是他們,而是我在替他們定需求呢?難道我以前碰過得人,就那麼的合作嗎?

好不容易prototype出來了,他們開始使用好像不太熟悉,可是試用一段時間後,他們終於瞭解原來電腦不是什麼都會,可是同時看到他們可以藉著軟體系統作更多的事。

以後幾年的合作,他們從被動不合作的『使用者』,變成主動且很聰明的『需求提供者』。他們的胃口也變大,可以想出一大堆非常有創意的應用。真的很難想像當初那不太甘願合作的樣子。

不知大家有沒有,相似的經驗?假如以為需求分析,只是問問東西,或是定一些定義出來,那就好像不是這麼一回事了。