自打公司开张以来，一边给用户开发实施，一边醉心于设计自己心目中的理想ERP系统；而以前在企业中从事ERP实施工作，也经常带领团队从事管理软件项目的开发，多少积累了一些关于管理软件开发设计的经验。现在越来越觉的，整个管理软件开发的过程中，需求分析实在是最重要的一步。

　　从事管理软件设计，一般都是从用户需求分析开始。从事软件工作的，大概谁都知道需求分析的重要性，可能大部分人都吃过需求分析不充分的亏。兵法云，“谋定而后动”。对一个项目而言，需求分析应该是“谋”的一部分，谋不好就急吼吼地从事后面的工作，实在是一件非常危险的事情。

　　让需求分析者最兴奋的事是，遇到一个既精通业务又对自己的业务信息化有许多想法的人，甚至他是一个软件爱好者。有时遇到牛人，他提出的需求，你记录下后稍作改动就直接可以当做需求分析规格说明书用了。当然，这种事情千年难遇，可遇而不可求啊。而且，在这种情况下，其实真正搞需求分析的应该是他而不是你。

　　让需求分析者觉得最倒霉的事是，遇到一个信奉“沉默是金”的用户。或者你问他什么他一言不发，或者他以业务烦忙为由今天推明天，明天推后天。如果是开需求会，他更是像一座沉默的大山，找一个最角落的位置坐下来，只带耳朵不带嘴巴。真让人难受啊，真所谓“不怕你骂，不怕你打，就怕你不理我。”

　　经常遇到一些不爱思考的用户，他或者是个老好人，什么都说好——我管你，等你弄出来再说；他或者是个刺头，什么都说不好，这样到时出了问题他就用不着承担任何责任——反正当初我就说不行了。对于一个从事需求分析的工作者来说，其实这两种人没什么区别，都是那种不会提出真正需求的人。

　　我听得最多的好像是这句话：你现在别问我，我也说不清楚，你得让我操作软件我才知道呢。天，我不是正在设计软件吗？哪有软件给你操作。你不说说你的基本业务，我甚至连原型也搞不出来。这个时候，我往往告诉他，是的，软件会有的，到时会给你试用，但现在还不到那一步，这就像下棋一样，你得多算出几步，预测预测事情的下一步。然后尽力引导他们设想他们可能的新的工作流程，为原型界面的设计打下基础。一句话，有时是需要逼着用户思考的。

　　另外，永远不要轻视原型的重要性。发现许多开发者根本不在乎原型的设计，跟用户交流了三言两语后就闷头从事系统设计工作甚至直接写代码。这样做实在蕴含着极大的风险。软件工程学认为，问题发现得越早，解决起来所花费的代价就越少。如果能充分调动用户的积极性，他们发现问题的可能性较IT人要大得多，而且他们发现的问题也要严重得多。原型是个能调动用户积极思考的很好的工具，也是跟用户确认需求的手段。

　　花代价搞原型开发，只为了给用户演示演示，演示完后完全抛弃，这对程序员来说实在是个非常残酷的事情，好像自己做了许多无用功一样。

　　但应该想到，在演示的过程中，用户提出的好多意见，如果在软件开发出来后才发现，可能会让你花费比原型开发多得多的代价。有时甚至用户的一个重要意见会让你重新考虑系统的整体架构也未可知。