但更令我印象深刻也难以忘怀的，有的是我亲自经历的、有的是别人讲说的一个又一个的软件项目，他们有的获得了成功，但最多的是惨痛的失败。获得成功的软件项目都是一样的，惨痛失败的软件项目却各有各的原因与问题。我常常在想我们的项目开发到底是怎么回事，然后把自己经历的、别人讲说的进行了深入的分析。有的是时间的问题、有的是技术人员的问题、有的是软件设计的问题等……但最后总结还是更多的是需求的问题。需求分析即是一份体力活但更多的是一份技术活，需要人际交往的软技能，是逻辑分析与严密思考的产物。正是我们在需求分析过程中存在的一个又一个的隐患，最终导致项目的失败。

　　故事来自我一个朋友的项目，是一个和其他企业合作共同研发的一个项目。朋友的团队负责研发项目中一个大板块，板块中包括报表。当时客户把他们目前正在使用的统计报表扔过来，要按照报表的格式做出来。这些报表都是手工报表，许多格式都不规范，又很难用软件技术实现。当时耗费了朋友很多的脑细胞直到最后到了项目期限也没完成。这件事给我们留下了深刻的教训：不能客户怎么说就怎么做，客户是非技术人员提出的需求大多是不考虑软件技术实现的。他们提出的需求大多是理想但不切实际的，毕竟他们不是干技术的。但我们作为技术人员，需求的分析必须是实事求是并且是基于技术可以实现的角度去考虑。那种经常说有条件要上没条件也要上的鲁莽行为最终必然是悲惨的。所以我们要基于技术的实现去引导客户的需求。最后我们要上一套信息化管理系统去取代之前的手工操作，那新系统的优势在哪呢?因此我们做需求分析的时候就要充分理解客户现有的管理模式，然后站在信息化管理模式的角度上去审视客户的管理模式是否合理，最后一步一步按照更加合理的方式去操作与管理。

　　我的最后一个故事可能典型到几乎每个人都曾经遇到过。我们的项目从需求分析到设计、开发、测试都十分顺利。但到了项目进行的后期，快到达最后期限时，我们将我们的开发成果提交给客户看，客户却对开发结果不满意，提出了一大堆修改，而且这些修改工作量还不小。怎么办呢?加班、赶工，测试时间被最大限度压缩。最后项目倒是如期上线了，但大家疲惫不堪，并且上线以后才发现许多的BUG。需求分析不是一蹴而就的，它应当贯穿整个开发周期，不断的分析确认的过程。以上这个事例，如果我们提早将开发成果给客户看，提早解决问题，后面的情况就将不再发生。这就是敏捷开发倡导的需求反馈。敏捷开发认为，需求分析阶段不可能解决所有的需求问题，因此在设计、开发、测试，直到最终交付客户，这整个过程都应当不停地用开发的成果与客户交流，及时获得反馈。只有这样才能及时纠正需求理解的偏差，保证项目的成功。

　　以上两个故事各有各的问题，但最终的问题就是需求分析出现了问题，为了今后我们的项目不重蹈覆辙，看来有必要谈谈怎么样去做需求分析。

　　我们应当怎样做需求调研：认识干线人

　　很多需求分析都是从需求调研开始的，需求调研是需求分析的一个重要环节。在这个环节就体现出需求调研是一份体力活但更是一份技术活。需要我们的理解能力、设计能力、但更多的是需要我们交际与沟通能力。

　　在一个敞亮的会议室，项目经理带着项目组成员和客户见面开项目启动会。会议上大家相互认识、拉拉家常、相互寒暄说一些生活上的琐事，过后渐渐的会议回到了正题。初次接触客户对项目组来说意义重大。客户对你印象的好坏、今后如何与你交际就会确认下来。然而在客户至上的今天，与客户保持必要的谦恭是必须的但是不要一味的唯唯诺诺。为什么这么说呢?因为一味的唯唯诺诺会让客户会越来越强势，这样导致的后果就是客户说什么就是什么，这样的结果就是客户提出很多变态、不切实际的要求，这样我们越来越被动，越来越累最后客户还不认可。

　　正确的做法是首先我们要对客户提出的需求进行深入的理解以后，运用我们专业的软件知识，提出比客户的原始需求更加合理、并且可操作的解决方案，让客户感觉到你说的正是他们所要的。如果这样客户能很好的接受你的解决方案并且还能在客户心理确定你的专家身份，提高你的形象，有更过的机会提出有利的解决方案，降低开发的风险。形成良性循环，为以后进一步的需求沟通奠定基础。做到这点不容易，不仅需要我们专业的知识还需要我们人文交际能力。

　　我们应当怎样做需求调研：识别干系人

　　有了良好的开端，给客户留下了好的印象，为接下来的收集详细需求奠定基础。接下来就是我们一一的去拜访客户组人员收集详细的需求做需求整合并制定短期或长期的计划。不要小看这些计划，这是我们的尚风宝剑，能让客户明白要达到这一目标不仅是我们的责任而是需要大家共同努力。

　　中国人做事往往比较重视感情，感情深了啥事都好办。所以跟客户慢慢培养感情，感情培养起来才好慢慢做事，需求调研也是一样。

　　需求调研不是一蹴而就的事情，而是持续数月甚至数年的事情。在这个漫长的岁月了，我们需要依靠客户这个群体，一步步掌握真实而又可靠的业务需求。技术不是万能的有些需求我们确实实现不了，这个时候就需要客户的理解和包容。客户为什么理解和包容你?这都需要和客户良好的合作关系。现在的软件项目都不是一锤子买卖，是一个持续的过程包含后期长期的维护。按照这样的理念，软件供应商与客户互惠互利、长期共盈。这更体现出要与客户长期且友好的合作关系。

　　尽管如此我们也不能期望客户中所有的人都与我们合作，很多项目中会存在阻碍项目进展的人。例如很多的ERP项目会损害销售和采购人员的利益，因为信息化的管理阻断了他们的财路;很多的企业管理软件会有来自企业基层管理人员的抵触，因为这会增加他们的工作量。

　　分析一个客户群的关系，要知道那些人是支持我们的，那些是反对我们，那些是无所谓额的人都对我们至关重要。

　　那些通过这个项目可以提高政绩，提高自身价值的人，都是我们可以争取的盟友。他们是我们最可以依赖的人，我们一定要与他们站在一起，荣辱与共，建立战略合作伙伴关系。

　　对那些对我们怀有敌意的人。尽管有敌意，但我们能够坦荡的，敞开心扉的与他们交往。虽然不能奢望太多，但拿出诚意去争取他们，也还是有机会化干戈为玉帛、化敌为友。如果能够那样，那是再好不过了

　　最后一种人，即使软件获得了成功，也与他没有太多关系，但你与他相处得好，却可以给予你巨大的帮助，这种人是我们需要拼命争取的人。所谓领域专家，他可以给你多讲点儿，但随便打发你，对他也没太大影响。报着谦虚谨慎、相互尊重的态度，大方地与他们交往。当他们帮助我们以后，真诚地予以感谢。这是我总结出来的，与他们交往的准则。

　　最后经过一番交往，我们逐渐的在客户中认识了一批对我们有帮助的人。今后的日子里我们依靠他们去学习和识别客户需求，为日后的研发工作奠定基础。

　　我们应当怎样做需求调研：需求研讨会

　　经过一番努力，我们终于从客户中找到一批人，可以解答困扰我们多时的业务问题。在这里我介绍几种我学习PMP收集需求的几种工具，希望能为大家带来灵感。

　　1、访谈

　　访谈是一种通过与客户直接交谈，来获得信息的正式或非正式的方法。访谈的典型做法是向被访谈者提出预设和即兴的问题，并记录他们的回答。通常采取“一对一”的形式，但也可以有多个被访问者/或多个访问者共同参与。访问有经验的项目参与者、干系人和主题专家，有助于识别和定义可用的需求。

　　2、焦点小组会议

　　焦点小组会议是把预先选定的客户人员和主题专家几种在一起，了解他们对所提议产品、服务或成果的期望和态度。由一位受过训练的主持人引导大家进行互动式讨论。焦点小组会议往往比“一对一”的访谈更热烈。

　　我们应当怎样做需求调研：需求研讨会

　　经过一番努力，我们终于从客户中找到一批人，可以解答困扰我们多时的业务问题。在这里我介绍几种我学习PMP收集需求的4种工具，希望能为大家带来灵感。

　　1、访谈

　　访谈是一种通过干系人直接交谈，来获得信息的正式或非正式的方法。访谈的典型做法是向被访谈者提出预设和即兴的问题，并记录他们的回答。通常采取“一对一”的形式，但也可以有多个被访问者/或多个访问者共同参与。访问有经验的项目参与者、干系人和主题专家，有助于识别和定义可用的需求。

　　2、焦点小组会议

　　焦点小组会议是把预先选定的干系人和主题专家集中在一起，了解他们对所提议产品、服务或成果的期望和态度。由一位受过训练的主持人引导大家进行互动式讨论。焦点小组会议往往比“一对一”的访谈更热烈。

　　3、引导式研讨会

　　通过邀请主要的跨只能干系人一起参加会议，引导式研讨会对产品需求进行集中讨论与定义。研讨会是快速定义跨智能需求和协调干系人差异的重要技术。由于群里互动的特点，被有效引导的研讨会有助于建立信任、促进关系、改善沟通，从而有利于参加者达成一致意见。该技术的另一好处是，能够比单项会议更快的发现和解决问题。

　　4、群体创新技术

　　可以组织一些群体活动来识别项目和产品需求。

　　头脑风暴法：用来产生和收集对项目需求与产品需求的多种创意的一种技术。

　　德尔菲技术：由一组选定的专家回答问卷，并对每一轮需求收集的结果再给出反馈。专家的答复只能交给主持人，以保持匿名状态。

　　结束语

　　总之需求调研是一份体力活也是一份技术活，与客户打好人际关系为以后迭代的收集需求创造更有利的条件。