小项目怎么做需求分析?

在做项目时,经常会碰到这样的事情.
客户向我们反映在和你们的工程师谈论需求时,他们总是满口答应没问题。可是,当他们做好以后,拿过来一看,根本就不是这么回事。而开发人员也在诉苦:用户什么都不懂,而且他们的需求老是变动,时间又这么紧,你让我们怎么办?
我觉得如果开发人员在做需求分析时,如果注意以下几点,也许可以避免被动的局面.

1、掌握相关的行业知识
  在和客户沟通之前,最好了解一下相关的行业知识。
  有一个项目管理人员说:行业知识可有可无,作为需求人员,最重要的是和客户沟通。最好把客户讲的东西都记下来。然后,由项目组决定后,再把意见反馈给用户。这种沟通方式,既不能有效的发现问题,也容易延误项目时间。
   案例:
   小A某名牌大学毕业,公司为了锻炼他,特意安排他和一个比较重要的客户进行一次沟通。小A和客户电话联系,商定了见面的时间和地点。西装革履的小A提前十分钟来到了见面的地点。一番客套之后,小A和客户就开始进入话题。客户开始谈他的需求,从项目背景到项目目的,从业务流程到相关部门和人员。客户兴致勃勃地说着,小A手忙脚乱的记着。客户停下来,问小A你觉得我的观点有什么需要补充吗?小A老实地回答说,我对业务还不是很熟悉。客户一下兴致全无,对小A说,等你对业务熟悉了,再来找我把。

2、重在沟通
  沟通的方式可以是访谈和调研、会议、电话、电子邮件、小组讨论、模拟演示等不同形式。我的意见是最好是与客户面对面的沟通。金庸武侠小说中的高手过招,都是面带微笑,不露声色,比拼的是内力。面对面的沟通,就是比拼内力。所以,一定要把准备工作都做好了。
  沟通其实也是在相互妥协。对用户合理的要求,要尽量满足。用户的一些不合理的要求,要想办法避免。要委婉地提醒用户,如果这样做,可能要增加项目时间,或者对运行环境有更高的要求。
  沟通一定要有记录,对于交流的结果还可以进行分类,便于后续的分析活动。

3、深究细节
  不要等到项目做好后,才让客户发现问题。
  客户所能提供给你的只是他们想到的功能需求,很多问题并不在他们考虑的范围之内,如果作为项目承担方没有去做分析,简单的按照功能要求去设计、规划,最终出来的系统是很难完全符合客户的业务流程的.这时,在客户看来当然需要更改.但这种更改却被我们看成了需求的更改。既然是需求的更改,那么就需要增加项目成本(资源)或延长项目时间。我看过一篇文章,说要要想项目成功,就得和用户建立亲密的伙伴关系.可是,这种以需求的更改为理由让用户从口袋里掏钱,亲兄弟也不干阿.
  所以,需求分析不仅仅是拿到客户的需求,更重要的是还需进行分析,了解细节,并就细节跟客户咨询,获取最详细的资料。

猜你喜欢

转载自staratsky.iteye.com/blog/192073