我们都听说过这样的故事：某某公司将要开发一套大型的先进的ERP系统。这套系统将要取代三分之一的公司里现有的软件系统，可以消减二分之一的费用，每个人都会因此受益而高兴。但现实中，这个项目超期2年还未完工，花掉的费用比原先预想的多出2倍，最终做成的系统就是一堆垃圾。
于是，追责行动开始了。开发商用瀑布开发模式忽悠客户，收取了高额的需求变更费。软件购买者不知道如何在一个信息系统里扮演客户。需求说明书没写好/不详细/不严格/太宽泛。顾问从一开始就不称职。等等等等。
　　在失败的软件项目中，上面说的各种因素都有可能，但有一个因素却是几乎在所有失败的项目中普遍存在的：软件购买方并不是软件的用户。
　　这个简单的事实却隐含着巨大的祸根。是否听到过“客户根本不知道自己要的是什么”的话?必然，因为他们的确不是真正的客户。大部分的软件项目都几乎完全没有按照最终用户的思维模式去开发。它们的需求要么来自CTO的自负，要么来自CTO的一个碰巧开了一个软件公司的泥瓦匠兄弟的大脑，或者就是因为投标的价格过低所致。不管怎样，软件设计总是要符合开发商的最大利益，并迎合购买方决策者的喜好，却跟真正使用这个系统的人无关。
　　当然，并不是每个购买软件的公司都表现的那么糟糕。很多的公司领导是真正关心系统开发的好坏和关心这套系统的最终使用者。如果不是因为其它的原因，至少是这个项目开发的好坏会直接影响公司的运营。但即使这样也不会好到哪里去，因为他们缺乏一线工作员工的那些经验。他们不知道软件如何做才是最适合它们的最终使用者。如果软件的设计是由XXX组委会/顾问委员会设计的、并有个很大的政治口号，那就更糟了。
　　因为我们几乎没有办法改变当今的这些大型项目的投标招标签约过程，作为软件开发者，我们可以做些什么呢?一句话：换位思考。如果你接到需求后没有任何疑问的去实现它，那你应该自责。所有的失败都归咎于你也不为过。你的责任并不是照本宣科、需求上怎么写你就怎么做。你的任务是为客户——不，是为最终用户——做出有用的东西。为此，不论作为程序员这样做是如何的大不敬，你也必须越职去跟那些将要使用你开发的软件的人交流。
　　这就是为什么让软件程序员去体验最终用户的工作是如此的重要。如果你将要开发一套客服系统，就让你的程序员去客服中心工作一天或一周。如果你要开发Web应用，就让程序员和设计师直接面对用户反馈，不要把它们外包给印度。
　　为了理解软件的真正需求，除了直接跟真正用户交流或在现实生活中真正的使用，没有其它更好的办法。虽然很多的企业型软件项目在开发时没有办法先自己体验/反馈，但你绝对可以将程序员送到真正的客服中心，没有什么能比真正用户的需求和痛苦能让你更深刻的了。任何需求文档都无法提供你一个完全的真实情况。任何技术在没有专业领域知识的支持下都不会出彩。没有人会比那些冲到客户现场第一线的开发者更受客户喜欢。