※ 引述《wh319 (wh319)》之铭言：
: 工作上除了写程式还要与 User 讨论需求。
: 常发现 User 不一定会讲清楚需求，也有事前讲得很急但是当程式无成交付
: 测试，却是一拖再拖似乎没有之前那么急...
: 不知道担任同样工作的网友，与 User 讨论需求时遇过些什么问题？
谈需求是软件工程的重要一环，需求谈得不好整个专案几乎可以说布下了失败的征兆。
但就我游戏业的经验，谈规格常会碰到难关：
客户不懂软件。估算时程上会有认知上的差异。客户可能认为电子游戏APP两个礼拜就要做完。就跟纸上大富翁一样，应该是丢到工厂就会产出产品，甚至恨不得应该是已经有现成的模具换个塑料就可以有新的游戏。时程上的认知差异，就会造成预算上的认知差异，这大家都懂就不讲了。
客户不懂软件。这会造成对规格的描述错误。对实作方式的要求，他觉得应该这样做。可是常常是绕远路。譬如说明明可以离线做到的功能，会要求一定要即时。
产业差距，对商品利润（风险）的认知差异。会有人认为看了新闻游戏应该要能七百万赚三千万，但是实际上大部分的游戏都是赔钱的。能大赚的游戏都是凤毛麟角。而已经流行一阵子，跟风的游戏除非资本雄厚，或是有区域隔阂很难打赢正在当红的第一名。就拿电影来说，知名的电影其行销经费都是开发的至少一半，而游戏商品，其行销的经费是更有可能比开发金额还多。这些多出来的成本会造成对于利润的误会。
客户太有专业，这边讲的专业是客户想要做的东西，一定是他非常了解的专业，想要用软件或游戏的方式来表达出来。打比方说客户要做一个麻将游戏，那么客户本身一定是麻将专长，这时除了麻将以外的功能，如连线，社交，排行榜，控制，接口。在谈规格的过程中，其价值就容易被过度轻视，开发团队会觉得自尊受到伤害，谈判就会触礁。
谈规格行政成本的认知差异：客户本身其实并没有认真要买单，只是谈谈看，开发团队却误判情势。导致花了很时间甚至已经实作下去才发现无法请款，或是对方其实只是比稿。
双方互信基础不足，付出过少，过于保护自己：这是上述情形的相反，开发团队很明确表达要先下订金才开始谈规格，希望客户做出"专业"的需求文件才动工，在合约上有太多保护自己的条款。但通常事与愿违，客户搞不清楚状况的机率很高。尤其是台湾大多是中小企业，老板一人扛全局的情形很常见，老板才没有时间跟开发团队慢慢聊，老板派出的助理也通常已经业务满档，根本无心谈好这额外的事情。
另外补充，原文推文中很多人都说要cc给老板。这其实没错。
但是就我的经验，很多中小企业的老板是不鸟制度化这套的。
在形式上太过于专业反而很容易达到反效果。
CC是一回事，可是谈归谈。不知道有没有人分的清楚这两个的差异在哪里。
开发团队对于商业行为缺乏敏锐，这种情形是为何要雇用业务的原因。开发团队可能过于技术本位，认为自己是在卖技术产品，但客户可能其实是希望买一个技术服务。开发团队若没有发现这个原因，很有可能再谈价钱的时候错用单位。（同样是一百万单子，依照订金三十万，结案七十万来付钱，这是交付技术产品。开发期三十万，上线后第一年营运每月支付五万，然后售后更新服务一年十万。这是技术服务的谈法，后面这种谈法让客户［消费者］有分期付款的感觉，比较容易谈成，而工程师可能会认为前者比较省事简单）
一点浅见给大家参考参考