说说我们开展项目需求分析的过程

 

 软件建设，前期最基本的要算需求分析啦（这里就摒弃和客户搞关系，项目立项等一系列官面活动啦），对于需求分析的实施过程也是让很多项目经理头疼的事情，需求分析做的不好，前期不能认真地了解客户的真是意图和办事流程，最终完成的系统必然被否定，好的就是返工，严重的就是restart 。

     我经历了一些项目（不多5-6个），我发现其实很多时候项目组在客户进行需求分析的时候，客户首先问的是你们打算怎么实现，有无现成的系统，具体的细节等你们做出来再看啦。。。等等，很多时候客户想第一时间看到你的系统，而不是漫天的听你和他进行业务的讨论。如果一个客户能超过半小时听你和他讨论业务，那恭喜你，你遇到好人啦，或者说你的面子够大的。。。。

     某一次，在和客户讨论的过程中，他的一句话提醒了我“你的需求文档太大，没时间看，是否有更直观的东西，比如例子、样品什么的”。知道啦，客户需要的是你去引导他参与你的系统构想，而不是放下手头的工作告诉你系统的业务知识、流程等。

     回来的过程中，我在想如何能拿出个样品给他？去网上下载个开源的东东？去画图？。。。。画图？画图？对我想到啦，将我的需求分析细化到页面上，做一个UI系统，通过静态页面来实现我的系统，如果说写文档是很多程序员都不像干的事情，那么做页面，做业务设计是他们相对喜欢的。说干就干，我召集所有项目组的成员，让大伙都参与进来，毕竟做静态页面是很easy的，没有request，response，action，dao等等。大家一起开工，平均每天能完成2个模块的cuad设计。再让美工做一个大体的frame,ok完事啦。

    没几天，我带着我们的UI系统和负责的对应模块的成员，去见客户啦，在第一时间我让负责模块的成员。演示、介绍其对应业务的处理流程，客户一看原来你是打算这样做的啊。。。。，然后就和我们说，你们这样做哪里不对，哪里少个信息，哪里少个输入项等，在他回复的过程中，我的项目组成员在UI上及时的修改、确认。一天下来，客户对我们的实现方式有了很好的了解，我们呢对客户的需求有了更明确的认识，连页面最基本的element我们都做了认真的讨论，我呢将其讨论内容形成新的需求文档，交与客户签字确认。。

     整个需求分析完成了，我发现最终时间进度向后延迟了50%,但是心想，又要让大伙加班啦。。。。。，可后来发现需求分析完成延迟的进度在数据库设计，详细设计，代码编写的过程中赢回来啦，而其还有提前。最终项目圆满上线。

    通过这个项目，我认识到做这个系统UI的重要性，前期的需求，项目组能和客户讨论细化到页面的element，这样做给项目建设代理很多好处：

1.   对于程序员，在代码编写的时候，对业务有了全面的认识，即使是刚进入没有参与需求活东的项目组成员，也有一个直观的认识；

2.   对于数据库设计，完全可以参照UI来进行业务模型、数据表的建立

3.   使系统详细设计，有了更为直观的参照

4.   大大降低系统建设的风险行，避免系统后期，因客户的需求变更而做的大面积修改

以上仅是个人对项目需求分析提出的一个解决方法，仅限于个人的理解，很多不足，请大伙指教，好久没写博客拉，一定有错别字，哈哈。。。