项目的需求说明书,还是应该用文档来维护,对于开发测试工作的开展都是很有利的。当然,仅仅有需求文档是不够的,最好有配套的页面原型,相应维护部分就多了一部分内容。但往往很多项目都是在没有原型,没有文档的基础上开始的。这就给后续的工作带来了很大弊端,可以说,这样的项目是很不规范的,项目一开始的工作就没有准备充分。
尽管如此,我们也只能去适应这种不太规范的工作流程。那么有没有什么方法可以尽量减少这种方式带来的负面影响呢?首先,需求如果是用页面原型来维护的,那么对美工的要求就会非常的高,各个模块,任何需求上的变化都要尽快的在原型上体现出来。最好可以有多个美工可以负责不同的模块,不然当多个模块并行进行需求分析的时候,一个美工是无论如何不能完成这繁重的任务的。其次,任何需求的变化都要尽快的通知模块或项目的相关人员,尤其是测试人员,测试人员不是仅仅听个结果的人。需求是测试,开发人员的基础,很多项目往往不会忽略开发人员,但是测试往往是脱离了需求的,那真正到测试的时候是会很可怕的。尤其如果测试人员连最初的需求介绍都不能参与。当然,这样的话问题就在于在最初的流程制定上就存在问题,有些时候需要测试人员强烈要求要参与需求介绍,要让大家意识到不参与需求介绍的后果是非常严重的。如果经过百般努力都不能满足测试人员的要求,那么只能寄希望与会后开发人员,测试人员,包括客户的精诚合作上了,不要指望有人会有空屁颠儿屁颠儿的跑过来告诉你哪变了,只能追着人家屁股后面不停的问,根据页面原型去猜一些功能是做什么的,不懂的,猜不出来的就去问。但是如果自己的一些东西不能按时交付,那就要马上和相关人员沟通,但一定要争取不要有第二次,不要给自己犯第二次这样问题的机会,如果同类的有了第二次,第三次将会让自己陷入一个很难看境地.
在项目初始如何和客户一起商讨制定开发规范,开发流程是技术性很高的.要可以让客户跟着你的步调走,而不是客户说什么就要做什么,客户说怎么做就只能这么做...如果被客户牵着走,到最后,是会被拖累死的.