监理：项目中如何更好的控制客户需求（一）

任何一个做过不止一个国内项目的项目经理，可能都经历过这样的场合:公司的销售人员兴奋地递给你一份与客户签订的合同，声称项目已经再次完成，但当你拿着合同(或委托书)看了一下，关于项目的范围只有几行字，要么是一些冠冕堂皇的说辞，要么只是说项目包含什么样的模块，但关于具体业务只说一两句就够了。如果是的话，那就是。还有一种情况。在项目过程中，客户不断提出对移交系统的修改建议。更可气的是，有些问题开始改了。有一天，客户突然发现情况不对，让你改。似乎顾客的需求永远是无止境的。项目承担者应该如何应对这种令人沮丧的局面？
1。为什么客户的需求会过度膨胀
作为项目的承担者，在规定的时间内用有限的资源完成项目，保证公司和最终客户的满意，是项目组神圣的职责。但是为了让顾客满意，我们必须满足他们所有的需求吗？不断满足客户需求会导致项目失败怎么办？为了找出这些原因，我们首先要找出这些问题的根源。
1。签订合同时，对工程范围的描述不明确。这是最常见的问题之一，也正是前期的这些问题没有引起项目组的足够重视，导致后期项目的修改层出不穷。
2。客户和项目团队对书写纸质文档的需求有不同的理解。这种情况也很常见。虽然客户已经确认了项目组提交的项目范围说明书，项目组也完全按照本文件规定的内容做了，但客户还要求变更。当项目组拿纸质文档和客户对质的时候，才发现客户也认可这个需求，但是客户的认知和项目组完全不一样。举个简单的例子:客户要求系统能够电子签名，项目组成员模拟了一个。系统里自动生成了客户的签名，但是交给客户的时候才发现，客户要求的电子签名，其实是想把原来的手写签名工作移植到电子系统里，让领导通过绘图生成一个手写签名，要写在文件里！有时候就是刚开始的一点小疏忽，导致项目后期的大量修改甚至延迟。
3。客户在销户之前，总有把一切做透的初衷。一般来说，在项目关闭之前，客户会想尽办法逼迫项目组解决他们所有的想法，因为一般的客户心理会认为，一旦项目关闭，就很难找到项目组成员来修改业务系统了。由于IT公司人员流动性强，即使后来能找到承包商，当初做项目的项目组成员也不一定在，或者很多公司因为业务繁忙，无法顾及到已经关闭项目的客户。
4。项目组的工作人员总是无条件地向客户让步，客户要什么给什么。这种做法的出发点是好的，目的是让客户完全满意，但实际上这种做法未必能达到目的。一般客户的需求是无底线的，往往会给整个项目带来很多负面影响。当然，如果过度控制客户的需求，客户肯定不会满意。
二。解决方案
针对以上项目问题及其原因，结合之前一些项目的教训和经验，我觉得以下几点可以有效屏蔽客户需求过度膨胀的问题，让项目更加美观。
采取预防措施:在项目开始时，必须制定明确的目标和项目范围，并得到主要利益相关者(当然最重要的是最终客户)的确认。
不管你是怎么拿到项目的，作为项目总监，在项目前期可以走三步。
想到的第一个问题应该是“为什么”，即客户的项目目的是什么。了解了这一点，在以后的工作中就可以多想想客户的想法，让项目不至于走错方向，最终争取双赢。
知道了“为什么”之后，接下来就是非常清楚地知道“要做什么”。比较好的方式是用一两句非常简洁的话来概括整个项目，项目中的所有子任务都可以用这种方式来概括，无论是前台业务人员还是后台R&D人员都能心领神会，也就是说项目总监在大方向上对项目的内容有很好的把握。
最后，我们要想好怎么做。对于不熟悉的项目，这个阶段工作量大，非常重要。这个阶段多花点精力肯定是值得的。当然，根据具体情况，我们也可以在需求调研的这个阶段简化一些不必要的工作，这就需要项目总监具备平衡相互冲突的项目目标的能力。在实际工作中，这需要一个过程。值得注意的是，在需求整理并形成文档后，项目团队应该首先详细地告诉客户他们总结的需求。在实际操作中，这种做法不仅可以大大减少项目人员与客户在业务层面上的暧昧问题，还可以很好地识别潜在问题，掌握一些沟通技巧，也会让客户更深刻地感受到承包商对他们的重视。另外，如果项目前期的需求方对技术了解不多，在根据实际情况向客户提交需求之前，应与R&D人员进行沟通，避免给客户不必要的付出，更准确的定义工作量。简而言之，有效地计算项目范围需要一定的时间，但也会节省资源、资金，解决项目未来令人头疼的问题，比如需求(范围)的变更。