对于用页面原型维护需求的项目

  项目的需求说明书，还是应该用文档来维护，对于开发测试工作的开展都是很有利的。当然，仅仅有需求文档是不够的，最好有配套的页面原型，相应维护部分就多了一部分内容。但往往很多项目都是在没有原型，没有文档的基础上开始的。这就给后续的工作带来了很大弊端，可以说，这样的项目是很不规范的，项目一开始的工作就没有准备充分。

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

  在项目初始如何和客户一起商讨制定开发规范,开发流程是技术性很高的.要可以让客户跟着你的步调走,而不是客户说什么就要做什么,客户说怎么做就只能这么做...如果被客户牵着走,到最后,是会被拖累死的.