需求变更的处理
做过的项目同软件，基本上最后的程序同开始时确定的都有些偏差...
总结下，随便说3个常常碰到的:
第一类，常见的合情理但不合规矩的，比如报表增加，文档格式更改，数据的查询，数据统计更改条件等等,事先没有考虑进来但实际中存在的;
第二类，头疼的管理决策层需求同应用者的冲突,管理决策要加入他们的管理思想，而这需求有时与软件终端用户的需求产生不可避免的矛盾冲突，比如管理者需要一个长的清晰明确的数据流过程，寄希望在这一套系统上来完善业务的管理制度，这样不可避免的，系统上就会多了一些内容，而对应用者来说，方便快捷，才是他们想要的，内容越少,流程越短他们的效率才越高；
第三类，最头大的...需求描述与交流不足，理解上的不一致,导致要大改,这个本来应该最能避免的,但常常发生.
下面讲下如何避免发生这类问题：
第一类的问题在于开始时需求就不确定，客户自己都没有碰到过的一些突发事件的考虑是所有人都没有预料的,因此对开发是按行业开发思路还是按使用者的意愿的问题就能明白回答了,在开发时,在数据结构上一定要多考虑,即使一些客户没有要求的,也要按一般行业要求来考虑,要考虑可扩展性,不能因为客户需求没有要求,或从系统性能上优化上考虑,而放弃一些模块的措施,这样能避免很多软件后期更改需求时对数据库或功能模块作大的修改;
第二类解决时应该避免问题放大，确定局部性范围. 现在在企业内部搭建ERP,CRM等性质系统的企业还是不多,很多的客户管理需求只是简单的管理层个人需求而已,而不是说对企业进行系统分析,再对业务流程合理化或重组,制定管理业务标准等措施来把信息技术与先进管理集合起来的大工程, 所以一方面要明确用户需求的来源同优先级别,虽然一般参与系统建立的决策人对业务流程都比较熟悉，但对细节上并不是很了解，一些特性就很少了解,对这些熟悉的还是实际前台操作人员,所以在流程同功能模块上听取客户管理层外,交互界面的处理一定要注意同终端用户进行沟通；另一方面,要多让用户做测试同培训,让用户能在系统完善的过程中熟悉操作同流程,参与系统建立,毕竟接受新事物都有一个过程的,这样当正式使用时就不会产生抵触或被迫的心理.
第三类的问题归根结底就是人与人之间的沟通问题,各方面都有自己的想法同考虑. 有时候语言的交流不如用 DEMO来的有效果,一份初期的DEMO能让双方少走很多弯路,而且,通过 DEMO能确定下来很多文档,省了很多功夫,又能让客户心中对软件系统有个一个大致的概念.
最后说下客户的后期要求,一般除非前期合约说定的很清晰明白,否则,只有妥协,毕竟还没有交货收钱...,当然客户的意见也不能完全听取,并且要适当的通过一些相关行业的实例来引导客户的要求,但也要明白决权还是在客户手中，你的期望不是他的期望,即使最后的软件的质量不会高,也许这也算是做软件的一种悲哀吧.
总结下，随便说3个常常碰到的:
第一类，常见的合情理但不合规矩的，比如报表增加，文档格式更改，数据的查询，数据统计更改条件等等,事先没有考虑进来但实际中存在的;
第二类，头疼的管理决策层需求同应用者的冲突,管理决策要加入他们的管理思想，而这需求有时与软件终端用户的需求产生不可避免的矛盾冲突，比如管理者需要一个长的清晰明确的数据流过程，寄希望在这一套系统上来完善业务的管理制度，这样不可避免的，系统上就会多了一些内容，而对应用者来说，方便快捷，才是他们想要的，内容越少,流程越短他们的效率才越高；
第三类，最头大的...需求描述与交流不足，理解上的不一致,导致要大改,这个本来应该最能避免的,但常常发生.
下面讲下如何避免发生这类问题：
第一类的问题在于开始时需求就不确定，客户自己都没有碰到过的一些突发事件的考虑是所有人都没有预料的,因此对开发是按行业开发思路还是按使用者的意愿的问题就能明白回答了,在开发时,在数据结构上一定要多考虑,即使一些客户没有要求的,也要按一般行业要求来考虑,要考虑可扩展性,不能因为客户需求没有要求,或从系统性能上优化上考虑,而放弃一些模块的措施,这样能避免很多软件后期更改需求时对数据库或功能模块作大的修改;
第二类解决时应该避免问题放大，确定局部性范围. 现在在企业内部搭建ERP,CRM等性质系统的企业还是不多,很多的客户管理需求只是简单的管理层个人需求而已,而不是说对企业进行系统分析,再对业务流程合理化或重组,制定管理业务标准等措施来把信息技术与先进管理集合起来的大工程, 所以一方面要明确用户需求的来源同优先级别,虽然一般参与系统建立的决策人对业务流程都比较熟悉，但对细节上并不是很了解，一些特性就很少了解,对这些熟悉的还是实际前台操作人员,所以在流程同功能模块上听取客户管理层外,交互界面的处理一定要注意同终端用户进行沟通；另一方面,要多让用户做测试同培训,让用户能在系统完善的过程中熟悉操作同流程,参与系统建立,毕竟接受新事物都有一个过程的,这样当正式使用时就不会产生抵触或被迫的心理.
第三类的问题归根结底就是人与人之间的沟通问题,各方面都有自己的想法同考虑. 有时候语言的交流不如用 DEMO来的有效果,一份初期的DEMO能让双方少走很多弯路,而且,通过 DEMO能确定下来很多文档,省了很多功夫,又能让客户心中对软件系统有个一个大致的概念.
最后说下客户的后期要求,一般除非前期合约说定的很清晰明白,否则,只有妥协,毕竟还没有交货收钱...,当然客户的意见也不能完全听取,并且要适当的通过一些相关行业的实例来引导客户的要求,但也要明白决权还是在客户手中，你的期望不是他的期望,即使最后的软件的质量不会高,也许这也算是做软件的一种悲哀吧.
