早點來

這是一個朋友的朋友的故事。

當時他還是一個剛當上PM的年輕工程師,第一個案子就遇到大系統,是一個會計相關的系統。辛苦了兩年系統終於到了收成的時機,但是由於許多的需求一開始沒有說的清楚,客戶不斷的質疑他們功能並不完整,介面也不好用,案子又拖了兩個月都結不案。有一天客戶約他吃飯討論系統功能,他準時赴約。

沒想到客戶劈頭第一句話就說:『怎麼不早點來』?他自認以他的手錶來說是準時的,於是那一場氣氛不太好的飯局並沒有達到共識,雙方不歡而散。

過了幾天客戶又約了吃飯,這次他早了10分鐘。想不到幾個客戶已經坐在那裡喝茶等他了,客戶看了看他,還是說:『怎麼不早點來?』。他心裡悶的很,想到張良的故事。心裡想,我下次提早半個小時來,看你怎麼說。

第三次他提前半個小時來,果然比客戶早些了。在愉快的用餐後準備離開前,客戶起身握著他的手說:『下次再提早來』。他有點震驚,卻也不敢說什麼。回去問他的老前輩,是不是顧客在發什麼神經?

老前輩嘆口氣說:『他的意思是要你提前(錢)來』。年輕的小伙子才恍然大悟。

這自然是不可取的事,卻也說明了軟體驗收的困難。許多細微的地方如果沒有寫清楚、說明白,就等的驗收的時候被刁難吧!所以在定義需求規格的時候,腦袋裡一定要想到『我怎麼驗收這一項需求』。

另一方面,一定要有把需求擴大來想的本事,顧客跟你說:『這裡要可以輸入商品名稱』,不要單純的以為只要用一個 TextArea 放個欄位給使用者輸入就好了,顧客腦袋裡想的是一個『商品管理系統』,到時候商品名稱要用點的、用拉的、絕對不會是鍵盤輸入的(輸入有很多種,鍵盤輸入只是其中一種)。所以要跟他確認,千萬不要一廂情願的往容易的方面想。如果他真的要一個『商品管理系統』,那麼就得加錢、加時間、或至少釐清了我們做不到。

留言

  1. 早一點來 => 提前來 => 提錢來
    這實在是太有創意了,是在我們當PM的FAQ裡嗎?
    可是這還不夠清楚,假如是我的話,錢提來了,還不曉的要作什麼呢!

    Anyway, 說到需求,的確是有許多說不清楚或說沒清楚的事發生。我們在文獻中也看到如何解決ambiguity,或是如何找出implication類的事,的確是不容易。難怪communication(溝通)是一件需求分析中非常重要的功課,可是如何與不同背景的客戶建立溝通模式,又是多麼的困難。

    回覆刪除
  2. 這則故事,不管真假,都有教壞「囝仔大小」之嫌,對於軟工教育恐有負面效應,不足取。我想「提X來」的說法,顯示那位年輕工程師與客戶溝通不良,溝通是發展軟體的主要「罩門」。一個non-trivial project不可能開始就能寫出所有的需求,否則就會忽視重要的feedback loop,當使用者或客戶開始與系統「交往」時,心中就會產生新的需求,這種現象不足為怪,所以說Change是軟工的issue之一。也許有人會認為我的說法有點「老學究」,不過我仍然希望引用Agile Manifesto的一則教條:"Customer collaboration over contract negotiation",即使「提前(錢)來」也要要求客戶參與與合作,否則再怎麼優良的軟體都會有問題,此外,如果系統不是很大(約10人以內)蒐集需求時不要使用use cases,建議使用user stories技術,這樣acceptance testing時或許少問題發生。

    至於「商品名稱」不使用「點的」或「拉的」,可能這位工程師忽視發展軟體系統時要注意"easy to use"的原則之故,試想當你/妳要download免費軟體時,都會被要求先登記,其中有「國籍」一項,難道是用寫的嗎?這就是"easy to use"的範例。從這則故事讓我想起,正確的軟工教育訓練的重要,如果這則故事能讓大家能體會這一點,這就不是教壞「囝子大小」之談了。

    回覆刪除

張貼留言

這個網誌中的熱門文章

CMMI是什麼?

CRC cards - 非正規物件導向發展技術