一則需求分析的故事

小明：「我們來模擬一次客戶需求分析吧。我當客戶，你當軟體工程師。OK?」

小強：「好」

客戶（小明扮演）：「首先有這樣的需求。」

WFH(Work from home)的生活快要結束，請幫我買一個好的藍芽耳機做視像會議。

小強：「不是做軟件需求分析嗎？」

小明：「太複雜了，讀者會跑的。」

小強：「我們說廢話就好嗎？亅

客戶（小明）：「那你就收聲（怒）。這需求夠清晰嗎？明白了嗎？」

工程師（小強）：「嗯，簡潔易明。要是平常的需求都有那麼簡單就好了。」

客戶（小明）：「那麼在採購前，你會推薦買那款耳機？」

工程師（小強）：「當然是某牌子的骨導耳機吧，音質好，輕巧，長期佩戴也不會造成不適，是我誠意推介。」

客戶（小明）：「喂，你有沒有看清楚需求？骨導耳機從一開始就不符合要求。」

工程師（小強）：「哪裏有說不能用骨導耳機！？」

客戶（小明）：「在辦公室有時候很吵，所以最少能隔音，有抗嘈更好，而骨導耳機不能提供這些功能。」

工程師（小強）：「整份要求從來沒有提過辦公室三個字吧？也沒要求過抗嘈功能呀。」

客戶（小明）：「WFH的生活快要結束⋯⋯這代表客戶（即是我）因應潮流準備回到辦公室上班。」

工程師（小強）：「我反對！這是不合理的過度解讀！」

客戶（小明）：「不然客戶提WFH生活結束幹嘛？」

工程師（小強）：「這是背景資料(Background)，目標(Objective)這類！放在文件前二頁的廢話。」

客戶（小明）：「客戶介紹自己做什麼，你真的可以當成是廢話嗎？」

工程師（小強把頭扭向一邊，不望向小明）：「⋯⋯」

客戶（小明）：「那麼我又問，你會提議沒有收音功能的耳機給客戶嗎？」

工程師（小強）：「當然不行，都寫明了做視像會議。」

客戶（小明）：「但收音功能也沒有白紙黑字寫出來呀。」

工程師（小強）：「請用常識判斷！」

小明：「客戶也是用自己的常識去寫需求啊，他”以為”已經說了出來，你有那個聰明的腦袋去理解，原來你沒有嗎？」

小強：「（怒）」

小明：「而且你敢保證說客戶的行業常識跟你的專業常識是一樣的嗎？」

小強：「⋯⋯」

客戶（小明）：「不同行業，甚至不同公司之間就有自己不同的常識，你要求客戶懂軟體開發的常識寫出好的的需求文件，這太奢求了吧。」

小強：「我也不可能懂客戶行業的常識吧。」

小明：「正是如此，現在我是客戶，我說這樣去解讀是常識。」

工程師（小強）：「所以我沒有錯！」

小明：「誰管你有沒有錯，最重要是做不到客戶要求的東西，準備跟客戶爭論／戰吧，最後誰會贏？」

工程師（小強）：「⋯⋯客戶吧⋯⋯但要求做出計劃”原意”的東西，而非白紙黑字的內容，這太鬼畜了吧？」

小明：「沒有早點察覺跟客戶確認，你就認命吧，而且這次算是客戶的”無心之失”吧，有時候會出現更過份的客戶。」

小強：「有八卦分享？」

小明：「某一個客戶在會議中指責軟件開發商竟然忘記了某個再三強調的功能，找PM進行了訓話。」

小強：「好慘。」

小明：「但事後所有人都說沒有聽過那要求，而且文件中無論明示暗示都沒有提過，這是即場創作強逼你接受的要求。」

小強：「！！」

小明：「最後軟件開發商還是做了這功能出來給客戶。」

小強：「⋯⋯到底前世幹了多少壞事才會幹這行⋯⋯」

小明：「不要以為這世界會有完美的軟件需求文件，要是有客戶跟你說句”抱歉，沒有寫清楚，請你幫幫忙”，請好好珍惜這種客戶。」

小強：「這就要珍惜？而且最後還是要做？哈哈⋯⋯」

後記

這故事只為說出需求分析的各種無奈，並非說教或提出任何改善意見，還有一定要說的是：以上內容純屬虛構，如有雷同純屬不幸。