`
liuwei1981
  • 浏览: 752618 次
  • 性别: Icon_minigender_1
  • 来自: 太原
博客专栏
F8258633-f7e0-30b8-bd3a-a0836a5f4de5
Java编程Step-by...
浏览量:156173
社区版块
存档分类
最新评论

闲话需求调研(二) 获得用户的支持搞调研

 
阅读更多

有了用户,需求怎么从用户哪里获取?

 

首先给用户分分类,按照和系统的关联紧密程度排排序。比较好用的办法,就是拿到用户的组织结构图,做信息系统,组织结构图是基础信息之一,系统的功能的操作权限划分,数据来源,业务流程,都是以组织结构为基础的。

 

拿到组织结构图,首先了解下各个部门的领导以及主要用户的一些信息,比如性格特点,办事风格等等,这样在之后的沟通合作中,就能做到有的放矢。这些信息,一般从用户的信息中心部门那里获取最方便。在几次项目过程中,感觉上信息中心是最为配合的部门,项目的成功与否,组织内部推广普及的程度的好坏,其他部门评价的结果,与信息中心的部门工作成绩考核联系最为紧密,是对促成项目成功最积极的部门了。

 

组织结构有了,需要的背景资料也搜集的差不多了,那么从哪里开始着手进行需求调研呢?

 

一锅烩?通过高层领导的命令形式,把各个部门都召集到一起,在一个大型会议室里面,大家耗上大量精力时间开个马拉松式的需求调研会议,众人各抒己见,探讨对系统的理解,描述自己对系统的要求么?很多项目组喜欢这样搞,客户的领导也喜欢这样,好像这样体现了对项目的重视,更会认为这样讨论过后,就能把需求调研工作搞定了,剩下的工作就是项目根据会议的结果去开发软件,坐等软件上线运行。

 

这样的结果通常是大家都精疲力尽,而离项目开发所需要的需求调研结果还是相距甚远。从这个会议中得到的调研结果,杂乱无章,无从下手。

 

这种调研方式也参加过,形式大于内容。其实在项目开始前,各个部门在高层领导的召集下,坐到一起开个动员会,是有必要的。一个项目能不能进展顺利,顺利完成,是否得到了客户高层领导的支持,是关键的因素之一。动员会,可以让部门意识到项目的重要程度,以及自己的领导对其的重视程度,在之后的项目进行中,更好的配合项目组的工作。

 

需求调研,最好的办法是各个击破,一个一个部门进行,这样需求调研的范围小,便于对调研业务内容进行细致的分析,深入的了解业务内容、业务流程等,这样再进行进一步调研,或者与下一个部门进行需求调研的时候,更加有的放矢,与用户更好的进行沟通,获得更有用细致的信息。

 

拿到调研内容,一定要细心梳理,找到各个需求点之间的业务关系,业务流程的走向,而不是简单的罗列在一起,特别是各类数据报表数据来源,加工过程。报表是给客户单位各个领导使用的,报表的结果正确与否,决定了领导对系统的满意程度,直接决定了项目最后的成败,这是现实情况。

 

通过这样的分析,对项目需求的理解就会随着需求调研的进展,越来越深刻,轮廓越来越清晰明了,用户的业务术语也会掌握,这样与用户的沟通就会越来越专业和顺畅,障碍越来越少,这样,用户也愿意与你进一步的探讨需求,系统的问题。甚至还会对现有的业务流程,业务内容有了更好的想法,对其进行改进,这不就是现在常说的业务流程优化么。

 

那么各个击破。从哪个部门开始呢?

 

一般来说,从与系统联系最紧密的部门开始最好。毕竟这些部门与系统联系紧密,他们是系统最常使用的用户,特别是各类重要业务数据的来源,他们的操作,直接决定了系统最终的输出结果的正确与否。很多时候,业务流程的出发点,或者关键的处理节点,都是要流经这些部门,通过分析这些部门的业务,就能得到系统的关键功能的信息,或者大部分的业务功能结构。力系统的全景完成非常接近。

 

系统的关键需求,往往是系统设计的重要依据,很多时候还决定了系统架构的走向,轻视不得。

 

有的时候,这些关键的业务部门业务繁忙,毕竟是客户组织中关键的业务部门,底气足,会认为配合需求调研工作加大了工作量,对需求调研人员的问题很不耐烦,都懒得搭茬,以业务工作忙搪塞推脱,而由于部门性质关系,高层领导也总是睁一只眼闭一只眼,把这些棘手的问题丢给了项目组,不愿与部门产生直接的冲突。

 

怎么办?这时候前面收集的组织结构,部门领导,关键用户人员的背景信息就有了用武之地。先找到他们喜欢的沟通方式,甚至从闲聊开始,先想办法建立一个融洽的调研氛围。比如又一次,一个部门的领导脾气火爆,性格急躁的很,经常把调研人员训的七荤八素,调研人员也觉得很委屈,但也没有太好的办法,部门的调研沟通,还得从领导开始,获得他的支持。偶然的一次机会,了解到他是某知名学校毕业,恰巧是同校的,于是沟通中,闲聊了学校的事情,聊到了领导的毕业学校背景,顺着这层关系和领导套近乎,这样在之后的工作中,就顺利了很多,领导支持很给力。

 

如果实在找不到突破口呢?那就只好用迂回政策了。先从了解到的比较容易配合的部门开始。还是之前的方式,对需求调研结果精心分析,力争做到比用户的理解还要深刻清晰,将分析结果展示给高层领导和之前关键业务部门领导,有条件的情况下,还可以做个仿真模型,让用户能更具体的看到软件产品,有了这样的调研结果,首先高层领导会很满意,关键业务部门的领导也会动心,毕竟这样的分析结果,或者说这样的软件也会对其部门的之后的工作有帮助,这样有了领导的支持,调研的工作就会顺利得多。

 

 

分享到:
评论

相关推荐

Global site tag (gtag.js) - Google Analytics