早點來
這是一個朋友的朋友的故事。
當時他還是一個剛當上PM的年輕工程師，第一個案子就遇到大系統，是一個會計相關的系統。辛苦了兩年系統終於到了收成的時機，但是由於許多的需求一開始沒有說的清楚，客戶不斷的質疑他們功能並不完整，介面也不好用，案子又拖了兩個月都結不案。有一天客戶約他吃飯討論系統功能，他準時赴約。
沒想到客戶劈頭第一句話就說：『怎麼不早點來』？他自認以他的手錶來說是準時的，於是那一場氣氛不太好的飯局並沒有達到共識，雙方不歡而散。
過了幾天客戶又約了吃飯，這次他早了10分鐘。想不到幾個客戶已經坐在那裡喝茶等他了，客戶看了看他，還是說：『怎麼不早點來？』。他心裡悶的很，想到張良的故事。心裡想，我下次提早半個小時來，看你怎麼說。
第三次他提前半個小時來，果然比客戶早些了。在愉快的用餐後準備離開前，客戶起身握著他的手說：『下次再提早來』。他有點震驚，卻也不敢說什麼。回去問他的老前輩，是不是顧客在發什麼神經？
老前輩嘆口氣說：『他的意思是要你提前（錢）來』。年輕的小伙子才恍然大悟。
這自然是不可取的事，卻也說明了軟體驗收的困難。許多細微的地方如果沒有寫清楚、說明白，就等的驗收的時候被刁難吧！所以在定義需求規格的時候，腦袋裡一定要想到『我怎麼驗收這一項需求？』。
另一方面，一定要有把需求擴大來想的本事，顧客跟你說：『這裡要可以輸入商品名稱』，不要單純的以為只要用一個 TextArea 放個欄位給使用者輸入就好了，顧客腦袋裡想的是一個『商品管理系統』，到時候商品名稱要用點的、用拉的、絕對不會是鍵盤輸入的（輸入有很多種，鍵盤輸入只是其中一種）。所以要跟他確認，千萬不要一廂情願的往容易的方面想。如果他真的要一個『商品管理系統』，那麼就得加錢、加時間、或至少釐清了我們做不到。
早一點來 => 提前來 => 提錢來
回覆刪除這實在是太有創意了，是在我們當PM的FAQ裡嗎？
可是這還不夠清楚，假如是我的話，錢提來了，還不曉的要作什麼呢！
Anyway, 說到需求，的確是有許多說不清楚或說沒清楚的事發生。我們在文獻中也看到如何解決ambiguity，或是如何找出implication類的事，的確是不容易。難怪communication（溝通）是一件需求分析中非常重要的功課，可是如何與不同背景的客戶建立溝通模式，又是多麼的困難。
這則故事，不管真假，都有教壞「囝仔大小」之嫌，對於軟工教育恐有負面效應，不足取。我想「提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"的範例。從這則故事讓我想起，正確的軟工教育訓練的重要，如果這則故事能讓大家能體會這一點，這就不是教壞「囝子大小」之談了。