※ 引述《wh319 (wh319)》之銘言：
: 工作上除了寫程式還要與 User 討論需求。
: 常發現 User 不一定會講清楚需求，也有事前講得很急但是當程式無成交付
: 測試，卻是一拖再拖似乎沒有之前那麼急...
: 不知道擔任同樣工作的網友，與 User 討論需求時遇過些什麼問題？
談需求是軟體工程的重要一環，需求談得不好整個專案幾乎可以說佈下了失敗的徵兆。
但就我遊戲業的經驗，談規格常會碰到難關：
客戶不懂軟體。估算時程上會有認知上的差異。客戶可能認為電子遊戲APP兩個禮拜就要做完。就跟紙上大富翁一樣，應該是丟到工廠就會產出產品，甚至恨不得應該是已經有現成的模具換個塑料就可以有新的遊戲。時程上的認知差異，就會造成預算上的認知差異，這大家都懂就不講了。
客戶不懂軟體。這會造成對規格的描述錯誤。對實作方式的要求，他覺得應該這樣做。可是常常是繞遠路。譬如說明明可以離線做到的功能，會要求一定要即時。
產業差距，對商品利潤（風險）的認知差異。會有人認為看了新聞遊戲應該要能七百萬賺三千萬，但是實際上大部分的遊戲都是賠錢的。能大賺的遊戲都是鳳毛麟角。而已經流行一陣子，跟風的遊戲除非資本雄厚，或是有區域隔閡很難打贏正在當紅的第一名。就拿電影來說，知名的電影其行銷經費都是開發的至少一半，而遊戲商品，其行銷的經費是更有可能比開發金額還多。這些多出來的成本會造成對於利潤的誤會。
客戶太有專業，這邊講的專業是客戶想要做的東西，一定是他非常了解的專業，想要用軟體或遊戲的方式來表達出來。打比方說客戶要做一個麻將遊戲，那麼客戶本身一定是麻將專長，這時除了麻將以外的功能，如連線，社交，排行榜，控制，介面。在談規格的過程中，其價值就容易被過度輕視，開發團隊會覺得自尊受到傷害，談判就會觸礁。
談規格行政成本的認知差異：客戶本身其實並沒有認真要買單，只是談談看，開發團隊卻誤判情勢。導致花了很時間甚至已經實作下去才發現無法請款，或是對方其實只是比稿。
雙方互信基礎不足，付出過少，過於保護自己：這是上述情形的相反，開發團隊很明確表達要先下訂金才開始談規格，希望客戶做出"專業"的需求文件才動工，在合約上有太多保護自己的條款。但通常事與願違，客戶搞不清楚狀況的機率很高。尤其是台灣大多是中小企業，老闆一人扛全局的情形很常見，老闆才沒有時間跟開發團隊慢慢聊，老闆派出的助理也通常已經業務滿檔，根本無心談好這額外的事情。
另外補充，原文推文中很多人都說要cc給老闆。這其實沒錯。
但是就我的經驗，很多中小企業的老闆是不鳥制度化這套的。
在形式上太過於專業反而很容易達到反效果。
CC是一回事，可是談歸談。不知道有沒有人分的清楚這兩個的差異在哪裡。
開發團隊對於商業行為缺乏敏銳，這種情形是為何要雇用業務的原因。開發團隊可能過於技術本位，認為自己是在賣技術產品，但客戶可能其實是希望買一個技術服務。開發團隊若沒有發現這個原因，很有可能再談價錢的時候錯用單位。（同樣是一百萬單子，依照訂金三十萬，結案七十萬來付錢，這是交付技術產品。開發期三十萬，上線後第一年營運每月支付五萬，然後售後更新服務一年十萬。這是技術服務的談法，後面這種談法讓客戶［消費者］有分期付款的感覺，比較容易談成，而工程師可能會認為前者比較省事簡單）
一點淺見給大家參考參考