需求管理之项目中怎样更好的控制客户需求

      凡是做过不止一个国内的项目的项目主管人员可能都经历过这样的场合：公司的销售人员兴冲冲的拿来一份与客户签订的合同交给你。声称这项目又搞定了，可是当你拿过来合同(或者任务托付书)一看，关于项目范围的说明仅仅有寥寥数行，要么是一些高举高打的套话。要么仅仅说项目都包括什么样的模块，而对详细的业务仅仅是一两句话就完事儿了，假设是一位身经百战的管理者而且对于项目的详细业务非常熟悉还能够。假设不是那该怎样開始这个项目呢？另一种情况。客户在项目进程中，不断对移交的系统提出改动意见，更可气的是，有些问题開始提出更改。某一天客户突然就发现情况不正确，又要求你给改回来。看起来客户的需求总是无穷无尽，作为项目的承担者该怎样应对这样的令人沮丧的局面呢？

　　一、客户需求为何过渡膨胀

　　作为项目的承担着，在规定时间用有限的资源来保质保量的完毕项目，让公司和终于客户都惬意是项目组的神圣职责。可是为了让客户惬意就要满足客户全部的需求吗？由于不断满足客户的需求会不会导致项目失败怎么办呢？为了弄清楚这些原因。首先应该找到这些问题发生的根源。

　　1. 签订合约的时候，项目范围描写叙述不清楚。

这是最常见的问题之中的一个，也正是早期的这些问题没有引起项目组的足够重视，导致后期项目无穷无尽的改动。

　　2. 客户和项目组对写成纸面文件的需求理解不一致。这样的情况也较常见。尽管客户已经确认了项目组提交的项目范围说明书，项目组也是全然依照这个文件规定的内容做的，可是客户还要求改，当项目组拿着纸面的文件与客户对质的时候，才发现客户也认可这需求，可是同一件事情，客户的认知和项目组的认知全然不同。举个简单的样例：客户要求系统能够电子签名，项目组的成员就模拟了一个。自己主动产生客户的签名在系统中，可是当移交给客户的时候才发现，客户要求的电子签名实际上是想把原来手写签名的工作也移植到电子化的系统中。让领导能够通过绘图的方式产生一个手写的签名在文档中应该落签字的地方！

有时候就是当初一点点疏忽，导致项目后期大量改动甚至项目延期。

　　3. 客户总有在结项之前把每一件事情都做得淋漓尽致的初衷。一般来讲。在项目结项之前，客户都会把全部的想法尽量逼着项目组解决，由于一般的客户心理都会觉得：一旦结项了，再想找项目组成员对业务系统进行改动可就难了。由于IT公司人员流动性强的特点，即便以后能够找到承包商，当初做项目的项目组成员也不一定在了，或者非常多公司由于业务繁忙，已经顾不得原来已经结款的客户了。

　　4. 项目组人员总是无条件迁就客户，客户有求必应。

这样的做法的出发点是好的。目的是要客户全然惬意，可是实际上这样的做法不一定能达到目的。

一般的客户需求都是无底洞。这样做对整个项目常常也会带来非常多负面影响。当然，假设过分控制客户的需求，客户肯定也不会惬意。

　　二、解决的方法

　　针对上述项目问题以及发生的原因，结合曾经一些项目的教训经验。我感觉能够通过下面几点来有效屏蔽客户需求过渡膨胀的问题。让项目完毕得更加美丽。

　　未雨绸缪：

　　项目初期一定要制定清楚的目标和项目范围，而且让项目主要干系人(最重要的当然是终于客户了)确认。

　　无论通过什么途径得到的项目，作为项目主管，在项眼下期，能够分三步走。

　　第一个想到的问题应该是“为什么”，也就是客户做项目有什么目的，知道这些以后，才干在以后的工作中更加想客户之所想，不至于项目方向错误，终于争取达到双赢得局面。

　　知道了“为什么”以后，接下来就要非常清楚的知道“做什么”，有一个比較好的办法就是用一两句非常简洁的话概括出来整个项目，而且能够用这样的方法概括出项目中的各个子任务。而且能够让前台业务人员和后台研发人员都能够心领神会。那么说明项目主管对项目的内容在慷慨向上已经有非常好的把握了。

　　最后就要弄明白“怎么做”了，对于比較陌生的项目来讲，这一阶段工作量比較大也非常重要，在这个阶段多花点精力绝对值得，当然。根据详细的情况，也能够在这个需求调研阶段简化一些不必要的工作，这须要项目主管具备平衡那些彼此冲突的项目目标的能力。在实际的工作中。这须要一个过程，值得注意的是，在需求整理完毕形成文档以后。最好先让项目组人员把自己总结的需求跟客户比較详细的讲一遍，在实际的操作中。这样的做法不仅能够把项目人员与客户在业务层面的歧义问题数量大大减少，还能够非常好的发先潜在的问题，而且掌握一些沟通技巧，也会让客户更能深刻的感觉到承包商对他们的重视。

另外，假设项眼下期得需求人员对技术非常不了解，根据实际情况最好在需求每次提交给客户前与研发人员沟通。以避免不必要的给客户的承诺，更加准确的界定工作量。总之，有效的计算出项目范围将会占用一定的时间，可是相同会节省资源、资金以及解决项目今后令人头疼的问题。比如：需求(范围)变更。

　　另外一个非常值得注意的问题是：项目的需求经过几次确认以后，要让有权力的客户明白确认，最好有书面签字，这个有说服力的文件会在以后客户发生需求变更的时候起到非常好的作用。非常显然，由于客户已经签字确认。总是反悔肯定理亏呀。即便由于业务变化不得不正确项目进行大的调整以至于项目延期。这样的情况下也会是项目组处于有利地位，不至于让自己的公司非常不满，甚至能够以此为根据来要求客户又一次考虑项目经费。当然，对于客户来讲，通过这些非常好理解的需求的阐述。也会以此作为以后交付产品的根据。做到心里有数，消除不必要的疑虑。这个对两方有同等的约束力。非常有优点。

　　灵活应变：遇到变更要与客户沟通

　　常常有这样的情况，项目都已经运行到最后阶段。客户突然提出了新的要求或者要求对已有需求进行更改，这会让项目主管非常为难：一方面要尽量满足客户的需求，另一方面又不能对系统做太大的改动，影响进度计划。这样的情况发生除了和需求阶段有关以外。同一时候说明在实施过程中没有与客户有密切的联系，缺乏沟通。

　　从客户的心理来分析。由于软件的特殊性，客户通常非常关注后期的服务，尤其是在国内大家做的软件绝大多数都是与实际业务紧密相连的。作为项目管理者，非常忌讳的是在做项目的过程中对客户置之不理，而最后交付的时候才与客户突然发生大量接触，本来后期的实施过程出现故障的可能性最大。之前与客户又比較生疏，非常可能会造成非常大的风险。比較稳妥的办法就是在项目进程中也要让项目组与客户保持联系，相互了解，建立更加融洽和谐的沟通气氛。为以后关键的实施移交阶段可能与客户发生的冲突做好准备。

值得一提的是：在项目进程中阶段性的给客户呈现一下项目的进展状况，让客户对项目有一个更加直接可视化的认识，更能及早的发现解决这个问题免除后患。在不断的沟通过中，应该让客户认识到项目组时时站在客户角度着想。让客户的主要负责人也能深深的感觉到他们是项目组的重要组成部分、荣辱与共，而且项目组能为客户提供完好持续的兴许服务。这样能够有效的避免客户绞尽脑汁想把全部的事情在第一次结项之前做完。

　　即便前期工作做得再好，非常多情况下。需求变更是不可避免的。

项目主管通过良好的沟通机制随时掌握变更情况和可能发生的变更，一旦发生了变更，项目组一定要冷静处理这些问题，一般能够依照产品分析—〉成本/收益分析—〉备选方案—〉专家推断这四个步骤来首先评估需求变更，而且尽快形成项目范围变更书面的说明书。它是以后项目决策的基础，当然比較稳妥地办法还是让客户对明显发生的变更做出确定(选择签字最好)。尤其是在评估了变更可能导致的工作量添加以后。让客户认识到过多的变更非常显然会造成项目延期，客户对此也要负责任。

　　在客户提出需求变更的时候。一定要掌握一定的沟通技巧。一定不要总是无条件迁就客户。

一般来讲客户对IT都不太熟悉，他们觉得非常easy的事情。可能要花费项目组大量的无谓得多余精力，所以千万不要觉得客户所说的就一定是他想得到的！

大部分客户都是第一时间突然脑海里面冒出的火花。所以项目组人员要冷静的分析一下：客户究竟想要实现什么目的，抓住问题得本质。一般来讲，实现客户本质的需求有非常多种办法。

在与客户的沟通中，一定避免与客户正面冲突。

在初期认真倾听客户意见，多问一些“您还有什么想法”之类的问题，等客户把他的想法都表述清楚以后，项目组成员成员最好迅速评估一下客户的建议，假设实现起来实在太困难，能够给客户一些更加中肯的提议。多问些“您看这样行不行？事实上能够达到相同的目的。

”之类的问题，最后另一个重要的过程就是要与客户确认这次沟通的结论。

　　总之，项目总体管理是平衡那些彼此冲突的项目目标的一种能力。看起来简单。可是实际上非常复杂。项目主管在项目进程中要学会怎样对常见变更进行控制，控制客户需求的肆意膨胀。保证项目健康稳定的进行。

　　1. 在项目启动时，公司会批准一个新的项目阶段的開始。

　　2. 在范围计划编制的过程中，将制定一份说明书来描写叙述在项目中将做什么。

　　3. 在范围定义中，项目的主要部分被分成更小的部分。