听棠的“客户需求何时休”深刻的披露了这个问题存在的根源.
需求分析,不仅仅是拿到客户的需求,更重要的是还需进行分析,了解细节,并就细节跟客户咨询,获取最详细的资料.客户所能提供给你的只是他们想到的功能需求,很多问题并不在他们考虑的范围之内,如果作为项目承担方没有去做分析,简单的按照功能要求去设计、规划,最终出来的系统是很难完全符合客户的业务流程的,这时,自然需要更改,被看成了需求的更改.其实,都是缺乏分析所一手造成的.问题等到系统出来了才被发现,这样的系统本身就是先天不足的了.
听棠所说到的几点,感受特别深：
“其实问题出在开头,客户需求只是软件需求分析的一部分,虽然是比较重要的一部分,但也不要只是去记客户的需求,而是要把客户的需求进行分析”
还有客户的需求本身会有矛盾（这矛盾是指在逻辑角度来讲）,客户本身是意识不到的,只有在分析设计时,才会分析出这里的矛盾,而这些问题,如果在期初时,软件负责人不分析,而是纯粹的“听从”客户要求去做,当暴露这些问题时,你怪客户也没用啊.
项目需求分析报告,在了解客户需求时,不要不动脑子,不要一味的点头说“I C”,其实在表面的业务里面可能包含着N多的细节,这些细节是需要你反问客户的,只有当你提的问题越多,最终获取的需求最具体,才能让项目越顺利.而且有很多问题,都是在你的反问中,客户也才开始思考本来没思考过的问题,客户也会找到一种合理的需求给你,有人会觉得这样了解客户需求未免太麻烦了.至于一些在技术上会遇到问题的地方,也要告诉客户,别以为到时候再说,客户是不关心你的技术细节的,但你如果给他解释的话,他也会试着理解的.
客户的需求本身是无休止,因为他们本身也在变,但当你期初的分析合理,后面的变动也将在逻辑上变动,相信代价已经不会那么大了.这其实也体现了系统的扩展性.
需求分析,是一个项目提出方和承担方相互沟通的过程,一方是系统的使用者,一方是系统的制造者,在系统制造过程中,只有双方相互配合,共同对系统进行设计才能最后达到使用的要求.客户是业务上的熟悉者,对业务流程有非常清晰的了解,但是,对于软件需求方面的描述是不了解的,他们所能提供的只是他们最终要达到的功能,但是,这其中包含的业务流程是非常复杂的.我们拿到客户需求后,应该根据功能、流程进行初步的设计,构造出业务流程图,再让客户进行评审,提出业务流程上不对的地方进行修改.这样来回的交流,最终才能取得较全面的需求,并减少后期的修改.
