项目管理有感之需求调研

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

　　客户想要什么?

 

　　要这干什么?

 

　　为什么这么想?

 

　　会不会有别的想法?

 

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

 

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

 

　　第一步　客户想要什么

 

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

 

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

 

　　第二步　客户要这干什么

 

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

 

　　第三步　他为什么这么想

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

　其方法，具体地说有以下几种：

　　1．参照需求说明，检查产品功能说明书描述的产品将要实现的功能是否已经完整、准确、一致、合理的描述了产品的功能，并确保这些功能是可测试的。

 

　　2．研究产品说明书是否符合现有的软件设计开发的标准或规范。

 

　　3．研究同类软件，预测产品的最终结果。

 

　　可是如果应用到实际的开发流程中，又有着一定的困难。因为很难做到让软件测试人员在项目的初期就参与项目，一般要等到软件的雏形出来后才会让软件测试人员着手进行测试。即便是在初期测试人员参与项目，也只是根据产品说明书和设计计划制定测试计划。测试人员没有被赋予责任去检查产品说明书。

 

　　四、经济的测试

 

　　测试是一项复杂的工作。因此要考虑其效率。经济的测试有几个原则。

 

　　1． 如果一个case（X）依赖另一个（Y），如果Y失败，那么X可以不要测试。

 

　　2． 针对一个子集，如果一个输入导致了失败，那么剩下的输入可以不要测试。

 

　　3． 针对一个case，如果一个测试子集产生了失败，那么其他的子集可以不要测试。

 

　　由此，联想到一个实际问题。开发人员一次送测，按流程，应进行一轮全面的测试。但如果在测试初期发现了缺陷，此轮测试是否要继续？不继续，则此轮测试不完整，无法产出测试报告。继续到完全测试，如果发现的缺陷是严重的必须解决的缺陷，则后面的测试是不经济的，因为此缺陷修复后仍要进行全面的测试。

 

　　按照测试的原则，发现缺陷要及时地反馈给开发人员，以便及时了解软件状态。但在实际操作中，开发人员得到反馈后常常随即给出一个修复版，然后再一轮测试。造成的情况是，到项目结束，发现多少个缺陷，往往就经过多少轮测试，每一轮测试仅仅是验证对一个缺陷的修复。

 

　　所以我觉得，对于什么时候暂停测试，是否需要暂停，开发人员什么时候送测新的修复版本，应该有一个良好的控制。

 

　　五、自动测试

 

　　我们是用Rational Robot编写自动测试脚本进行自动测试。主要用与一些AP的UI测试。由于编写SQA Basic代价较高，所以应用于稍具复杂度的程序或需多轮回归测试的项目是比较经济的，如果是简单的UI，或不需进行多轮回归测试的项目，就要比较编写脚本的投入和实施自动测试的经济了。

 

　　如果多轮回归测试间程序变化比较多，改写脚本也是负担很重的工作。

 

[出处：项目管理者联盟]