艾伟也谈项目管理,项目管理有感之需求调研

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

  1、客户想要什么?

  2、要这干什么?

  3、为什么这么想?

  4、会不会有别的想法?

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

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

  第一步 客户想要什么

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

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

  第二步 客户要这干什么

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

  第三步 他为什么这么想

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

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

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

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

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

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

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

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

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

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

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

时间: 2024-10-05 07:06:22

艾伟也谈项目管理,项目管理有感之需求调研的相关文章

软件需求调研“五步法” 收藏

  软件需求调研"五步法" 收藏 摘要 客户需求,是软件生产加工的"原材料",是团队展开工作的"依据",是项目管理的"基石",需求调研是获取这此基础信息的启始阶段,良好开始是成功的一半.在需求调研分析阶段,项目经理和需求分析人员无法推动需求调研,客户参与积极性不高,获取客户需求信息不完整,且没有得到客户的认可.将决定能否奠定项目成功的保障,决定软件项目实施的成败.本文介绍"B项目"需求调研不深入所造成项目经

艾伟也谈项目管理,需求管理成熟度的五个级别

需求管理是软件开发全生命周期重要的一个环节,我们每个人都知道它的重要性,但是要真做做好并不简单,我也写了一本在线电子书业务分析与需求.pdf来讲解需求相关内容.对于每种技术和方法,就像以前我写过的企业架构成熟度模型(EAMM)的一样,我们都不可能一下子就精通,而是按照一种学习的曲线进展,本篇本篇主要介绍一下需求管理成熟度的六个级别. 级别0:没有需求(no requirements) 没有任何明确的需求被记录下来,他们假定知道要构建什么,希望节省需求的时间来做开发,但这势必会给开发工作带来混乱,

艾伟也谈项目管理,ERP项目实施要未雨绸缪不要亡羊补牢

在ERP项目中,要做到在项目实施的未雨绸缪,不会出现亡羊补牢的情况就需要项目管理和实施人员在项目推进过程中队下面的阶段进行预测,把握好发展的趋势,掌握项目的主动权.下面就提出一些建议,供大家讨论.希望对大家有用. 一.要考虑每一个项目阶段普遍存在的问题 ERP项目可以根据项目进度,分为项目立项.需求调研.业务流程重组.模拟运行.并向运行.正式上线等几个阶段.其实不同的企业,虽然有各自的特性,但是也存在着一些普遍的问题.有经验的项目管理员,对各个阶段普遍存在的问题有深入的了解.此时他们就可以预先采

艾伟也谈项目管理,软件架构引言之项目管理的问题

软件架构引言之项目管理的问题   很多朋友都有过或者正在管理一个或者多个软件项目,那么我的文章就从这个问题开始:如果单纯从表象来说,软件项目管理过程中暴露的最大问题是什么?   不同的人的会有不同的答案,但是大致这样的答案我想大部分人都是会认可的,那就是"进度拖延".进度拖延当然是表象之一了,其他诸如质量不过关.功能不完整等等,我觉得都是和进度拖延密切相关的.很多项目经理都想去做那些认为是十分必要的事情,比如计划.测试等,但是"没有时间".为什么会没有时间?等到项目

艾伟也谈项目管理,动起来再调整 - 向项目经理推荐敏捷

要成为一个好的项目经理需要学会逆水行舟.虽然顺水推舟有时也能到达目的地,但学会逆水行舟,你才能到达任何地方. "虽然很有道理,但我认为现实不允许,很多项目都有规定的期限.中途还有给客户演示效果,往往实际项目中都是按最后上线日期来进行项目规划管理的." "写得不错,但是有些建议过于理想化了.毕竟说得很有道理,但实际中具体做起来又不是那么一回事了." 这是两位网友对<软件项目经理新手上路>的评论.这话很有道理,也是在现实生活中碰钉子碰出来的.在项目中确实存在

艾伟也谈项目管理,关于项目管理的一点体会

这段时间,一直在负责一个项目的管理与开发.在时间短.任务紧,而团队人员又大部分是没有经验的菜鸟的恶劣情况下,我带领接近40人的团队,终于在客户规定的时间范围内如期交付产品.这其中,经历了需求变更.人员变动(因为其它任务,先后有近10人离开团队)等诸多问题,项目仍然取得成功了,不能不说有几分侥幸,但此外也有一些经验与教训可以与大家分享. 一.项目开发方面 需求 项目应以需求为核心.一个项目是否能够成功,对需求的准确把握在成功因素中要占上60%的比例.不管系统的架构设计.团队管理有多么的成功,如果需

浅谈软件项目管理之测试

笔者从事软件行业相关工作将近十年,其中与测试相关时间有7年之久,现浅谈软件项目管理中测试的必要性,供大家参考. 一.测试的必要性 为什么需要测试,那是因为由于分工的精细化,软件开发必须经历客户.需求.设计.开发多个环节.为了保证最终的结果符合要求,上下游是需要确认的. 用户告诉我们:我需要什么?软件企业需要在理解正确.表达正确的情况下完成需求规则说明书,把客户的原始需求转变为IT需求,表达出能够提供什么 需求的下一环节是设计,设计主要是要要说清楚:我要让软件做什么.需要与前一环节确认理解正确了.

浅谈软件项目管理环境下的质量管理

浅谈软件项目管理环境下的质量管理 摘要:软件项目管理是为了使软件项目能够按照预定的成本.进度.质量顺利完成,而对成本.人员.进度.质量.风险等进行分析和管理的活动.软件项目的质量管理就是产出的软件,满足客户明确需求.隐含需求的能力的所有特性.在现实生活中,监控所有对质量有影响的关键点,采用有效的测量手段来管理软件的质量,从而实现软件项目的"高"质量.使软件项目管理较之其他项目管理而言有其特殊性.采用CMM标准可以确保软件项目的质量,CMM是美国卡纳基梅隆大学软件工程研究所提出的软件研发

需求调研中的5W+1H定律

对于软件的需求调研活动,曾经写过三篇相关的需求管理文章,出发角度是从整体的需求管理过程考虑:在引入CMM(二)需求管理KPA活动的基础上,列举了如何进行需求调研前的需求管理计划活动:在失败的项目中,找出规范和管理软件需求过程的关健点及需求关联的模型架构(这些可以参考以前写过的<CMM需求管理实践经验记录谈>.<从CMM角度考虑需求管理计划>.<如何用CRC模型来确定需求>). 一直以来,感觉自己在经过几个项目试验的基础上对于软件的需求管理应该是有一定的基础和经验了,然而