如何做需求调研

一个项目中需求调研的充分与否是项目日后成败的关键要素之一,这一点我想没有哪位项目经理不认同吧?不过咱说的需求调研可不只是拿张纸记记客户说什么就完了,调研顾名思义就是调查和研究客户的想法,我感觉应从以下几个步骤入手:

客户想要什么?

要这干什么?

为什么这么想?

会不会有别的想法?

这里也说一个最最最最基本的,只谈项目别谈钱,我们可以说,价钱嘛需要我们回去详细的分析过您的需求后再给您提供一个整体的解决方案,您放心价钱一定合理,不会超出您的预算(真超了再说)。因为现在谈钱就等着挨砍吧,先砍你价钱,再砍你时间,最后加点功能,要点回扣,左一刀右一刀,砍到项目吐血身亡还拖你尾款。这里的客户经理和项目经理们要小心呀。

通过以上四步我们的目标是:搞清客户的要求,找出要求的逻辑,客户想要的结果,同时排除开发的风险,挖掘与控制潜在的要求。下面咱们来一一讨论。

第一步 客户想要什么

这步最简单了,拿出咱们的笔记本。什么?作为项目经理你还没有?太失败了,去找老板申请一个,不给IBM、DELL的,至少也要个软皮的能写字的笔记本吧,(本人就用的一个32开软皮笔记本),一个好记事本可以让客户感到你对此项目的重视,记在固定的记事本中也方便我们日后查询以往的记录,这点很重要的。闲话少说,拿本开始记,让客户开始说,他第一遍说的时候我们要注意几点,多记,少说话,如果你非要说话那就说:好、行、啊,再不过瘾就说OK,为什么呢?因为客户在说的时候,他多半同时在想自己要什么什么东西,不要打断他的思路,尊重对方表达权同时可让他把所有想法系统化的说出来,咱们多记,哪感觉有问题也先标注,一会儿再说,这是其一。其二呢,他说你也说,越说越多,一会儿下班了,最后发现,今天的结果就是下次定个时间再继续说。现在咱是调查阶段,还没到研究呢,至少咱还不知道人家的整体想法呢。所以多记,少说。

OK,他说完了,现在到咱了,首先一条一条的复述,在复述的同时我们就可以发表建议了,看好了,是建议,不是意见,所以态度要把握好,我们是来帮他们作事的,是要把客户的需求合理化,简单化,说白了就是程序别太复杂,风险能排全排除掉,别搞个逻辑又复杂又不实用的东西出来。在这个过程中就进入了第二步。

第二步 客户要这干什么

听完所有的需要,咱们应该可以分析出客户所要东西的重点了,围绕重点开始研究,复述客户的需求,不要认为他说的,你听的就明白了,作事千万别说:“我以为”,以为就问清楚,所以咱再复述的同时以自己的理解解释一遍,这时客户开始听你说,他就开始明白自己刚才说的哪对哪不对了,不对的会加以补充,继续记下来,然后再复述解释。别怕麻烦,现在多说几遍大家都还是客气,比以后大家对需求有争执强。而且这是先礼后兵,今天我可和你解释清楚了,日后签了字你别说不是这么回事。当在需求中遇到比较复杂或怪异的问题时我们启用第三步。

第三步 他为什么这么想

客户大多不是IT专家,当然也有自以为是的,这些人要给他们留面子,有面子他们日后也会给你面子。既然不是IT专家对有的问题可能在程序实现方面就想的比较简单了,还有他们大多是行业专家,对自己所作的行业至少对本公司的行业流程比较清楚,所有我们就需要搞清楚他们的行业流程或说业务逻辑,看看他们到底想让我们用程序为他们实现什么功能,他们要干什么?比如说,产品出货量要有个分析功能,表面一听,好家伙,你要干什么?细一问原来就是想知道每天出多少货,按类汇总一下就OK了,客户在谈需求时,有的人习惯把功能说的比较大,好听,气派,有面子,最常听的“来,咱作个ERP”,“这块我要分析统计”,“那块我要综合查询”什么什么系统,什么什么平台,实际真如其所说的功能并非如此之大,所以这就要我们分析了,不过这也好,你说的大,那就是你认可大,大就有大的价钱,呵呵!所以客户说大不是坏事。另外不少关键问题通过了解其具体想要干什么就很容易的化解掉了。

现在他说完了,你也说完了。时间富裕就再复述复述,闲聊闲聊,没事了就收拾走人了,走时别忘了和人家定个交付解决方案的时间,他不和你定说明他不重视至少不着急,你不和他定说明你不认真。所以定个时间,大家再谈。

不说说还有第四步呢吗?是,这步回公司慢慢想去,因为这步比较复杂。

第四步 他会不会有别的想法

需求收集完了,回来咱们就得好好想想了,他要什么?要这干什么?为什么这么想?再来一遍,累呀>_< ,最后咱们来想想他会不会还有别的想法,为什么说这块复杂呢?有人说了,得挖掘潜在的需求,想到客户想不到的事。是,没错。但这并不是关键。关键在于有的想法能挖,有的不能挖,玩过扫雷吧,这块我就喜欢称之为扫雷。因为有的需求对项目有利,有的对项目无利,甚至会毁了我们的项目。比如他们就想作个人员信息记录,你非给分析成人事系统管理。这一分析有几种可能,客户接受了,就按原来的预算办吧,完,赔了!要不客户说是呀,我怎么没考虑到,我再想想,得,项目没信儿了!所以发掘潜需求得在一定的范围内,这需求有一定的项目经验支持,不然挖雷上就全盘皆输了。还有实现比较复杂的功能,自然不要挖,至少不在本期开发挖,等客户提,他们提了再想办法让他们作二期。

另外扫雷还和公司的项目策略有关,看是不是想通过某个需求牵住客户成为长期客户,不是想通过什么功能引发他们的二期开发,这就需求与老板沟通了,所以此步比较复杂,多玩玩扫雷有好处,呵呵

好了,四部全完了,总结一下:在作调研时要把注意力集中在客户为什么这么想?而不是想干什么?因为他想的,不一定是对的,需要我们分析他最终想要的而且是最简洁的解决方式,当然这样一分析,我们就可以把自身的一些风险一并给排除出去了。所有搞清客户为什么这么想很重要。同时挖掘潜需求时要在一定的范围内,客户开发项目是有预算的,不会因为功能的增加而追加,当然有的捞钱项目除外。

所有分析完成,要形成详尽的文档,我感觉最好先出个功能说明,再来个界面设计。

功能说明:比如合同管理模块实现增、删、改、查功能,增与改分别涉及哪些字段,字段的逻辑关系,删除是否支持批操作,查询可按什么字段查询。最后说明与其它模块间是否有逻辑关系。总之你能写多详细就多详细(当然也与项目的规模有关,不过有固定的文档规范写起来其实也没有多难),这个东西签了字盖了章,咱们就有了一定的主动权,好使不好使至少咱们有,总比没有强吧,没有就百分之百没理了。

界面说明:把页面出个草图,用Word、VS、DW,什么都成,就是信息的摆放,把字段放到页面上,这个界面主要说明点什么按钮,出什么东西,哪个页面拥有哪些功能。最后一样签字盖章,为什么又签字又盖章,小心客户方的负责人项目期间离职贝,免的客户来个全盘不认帐。

有这两分文档开发就稳当多了,不过项目没有不变的,古人云,项目中永远不变的就是变化。

所有拿着这两份文档只希望日后变化可控性高一些,改的少一些,咱们的理多一些。有机会咱再谈日后的控制。

转自http://www.cnblogs.com/SoulStore/archive/2008/07/25/1251140.html

时间: 2024-07-30 06:08:44

如何做需求调研的相关文章

我们应当怎样做需求调研:初识

很多需求分析的工作是从需求调研开始的,我们就从这里说起吧.需求调研是需求分析最重要的一环,也最集中地体现了需求分析的特点——既是一份体力活儿,更是一份技术活儿.它既要求我们具有一种理解能力.设计能力,更要求我们具有一种与人交往.沟通的能力. 在一个阳光明媚的下午,项目经理带领着项目组成员,参加了客户组织的见面会,一个新的软件研发项目就这样开始了.双方在一种友好的气氛中进行,相互寒暄,介绍与会人员,拉拉家常.逐渐地,会议开始进入了正题.初次接触客户,对于项目团队意义重大.对方对你印象的好坏,今后如

用leangoo怎么做需求管理及规划?(产品Backlog、用户故事)

传统的瀑布工作模式使用详细的需求说明书来表达需求,需求人员负责做需求调研,根据调研情况编制详细的需求说明书,进行需求评审,评审之后签字确认交给研发团队设计开发.在这样的环境下,需求文档是信息传递的主体,也是一份契约. 然而详细的需求说明书有以下5大弊端: 单向的信息传递,容易出现理解偏差. 文档很正式,我们会误以为它一定是对的,不去质疑它,让我们停止作出判断. 有了详细的文档,我们不会反复讨论它,相互确认. 书面文档不利于团队共享责任,它扮演了证据的角色.Scrum强调团队共享责任,不论是需求人

软件系统开发之前要做的事—需求调研框架

近期在做的一个软件需求调研,从以下一些方面进行了了解,当然这些只是初步的一个需求框架,还打不到设计开发的基本,只是让软件公司能够对软件需求有一个总体的了解而方便对软件有一个大概的估算. 公司情况 实现的根本目的 现有软件情况(现有应用.架构部署情况.使用技术:技术文档.是否需要进行数据对接,需对接方是否提供技术支持) 涉及人员 业务类型 业务流程 业务规则 关注重点 其他非功能性需求 数据规模 数据频率 应用环境

团队作业二之需求调研

这次的软件工程团队合作我们我们小组准备合作制作一个针对校内师生的购书网站,简单来说就如同京东淘宝当当那些大型电商网站一样,但我们能力有限,只能面对我们学校师生制作一个购书网站,来解决教科书购书难,使用过后闲置的问题,如今学期过半,也早已没有那种为教科书无处订购.价格昂贵的问题而发愁了.但在刚刚开学的时候,我们却感觉这是个很头疼的问题,向学长学姐借的书目不全.单人购买的昂贵.找不到集体购买的渠道,着实让我们很伤脑筋,,每个学期初买书需要将近400块钱费用,有的同学会向学长学姐借书,但是不能保证学长

浅析软件工程的需求调研

正如老师上课所说,软件开发的过程,就是 “用户最需要的东西” 在下面这一链条中传送,转换,实现,扭曲或丢失的过程.由此可见,用户需求是我们开发的源头. 但不得不承认这样的客观规律,用户需要的,往往经历以下过程:用户最需要的 ——>  用户表达出来的—— >软件团队能理解的 (老板/PM) + 团队的商业目标 ——>软件团队成员具体表达出来的 (PM 写 spec) ——>在各种约束条件下,具体执行表达出来的 (dev 写代码) ——>验证通过的 (Test) ——> 通

需求调研的几个误区

软件系统的建设工作,大多数是从需求收集工作开始,逐一开展建设.需求调研,既是软件系统建设的头等大事,也是难点.很多失项目,由于走入需求调研工作的误区,导致项目失败.因此,本文就需求调研的几个主要误区展开分析讨论,以求避免问题的发生. 误区一:需求调研计划不够切合实际 曾经给一个客户做一个业务审计系统,项目组就访谈的潜在对象列出了调研问题清单,计划列出了近期的调研工作安排,并且将很多不符合项目范围的内容也列入调研内容中,导致项目推进速度非常缓慢. 误区二:需求调研浅尝辄止 本来系统是面向整个公司的

关于奇异扫雷的需求调研

作业: 每个小组做 一次需求调研,要求如下: 选一种合适的需求调研方法 为你的小组找到一个目标用户 (到教室外找到别的班级的同学) 如果目前已经有原型系统,让她/他使用软件解决真实的问题 (观察,记录) 如果没有原型可以展示的小组可以采取“调查问卷/深入采访” 的办法 总结用户反馈 录像,把录像上传至团队博客 讨论及调研: 过程还是比较崎岖的,主要是第一次做用户调研,讨论组里面七嘴八舌,但是一致认为需求调研的质量对于一个应用软件来说,是一个极其重要的阶段,它的质量在一定程度上来说决定了一个软件的

产品经理 - 需求调研常用方法

需求获取一般包括这几种方式: 观察法.体验法.问卷调查法.访谈法.单据分析法.报表分析法.需求调研会法.这是需求调研的"七种武器",它们各有优缺点,无论你想要了解的是什么需求,都需要将这些方式组合应用,针对你想要了解的内容,以及需要了解的对象的工作特点,采用不同的方式.学会并坚持使用这七种武器后,我想你很快就会成为需求调研的真正高手. 观察法 观察法,就是你自己跑到工作现场,看!这个看上去相当简单,貌似走马观花,有些不在行的兄弟会弄得跟公费旅游一般,车间里走走散散心,撩撩HR妹子,就认

CSDN高校俱乐部有奖调查:实习就业需求调研

CSDN高校俱乐部有奖调查:实习就业需求调研 随着就业形势的变化,不少用人单位开出"要求有工作经验"的招 聘条件.暑假期间,大学生们放弃休息投身"假期实习"战场,积累实践经验,为即将来临的求职大战做准备. 有了学哥学姐们就业难的前车之鉴,大一.大二的低年级学生也开始了就业前的预演,纷纷加入到实习行列.无奈僧多粥少,"一份实习难求"几乎成为大学生的普遍心声.当他们历尽千辛万苦走进实习单位时,却遇到了从未经历过的困惑和尴尬.  种种迹象表明,实习难是