c、需求管理策略

　 谁也不希望需求变化，更不希望同样的一件事情，三个用户给了你三个“必需按我的要求来修改”的需求。对于这种你往左他往右的需求，可能是PM和顾问们最头疼的事情。很可能就是今天改过去明天该回来。

　 当项目确定了项目《需求报告》或者《项目解决方案》后，双方项目经理可以坐下来明确一个可控、可追溯的需求管理方案，保证所有的需求变更都是“有人承担责任的”。

　 没有规矩不成方圆，在项目开始阶段明确了计划管理、工作管理和需求管理的方法，我想PM后期需要去协调的工作会少很多的。

　 前面说了项目开始要注意的东西，协调过程中的一些事情，以及如何给项目一个合理、有效的轨道让用户能够配合实施方PM的工作，让项目在友好和合作的氛围中前进。随着时间的推移和实施的深入，项目自然会到了需要准备验收的时候。

　 今天就说说有关项目验收的问题吧。

　 项目何时验收、如何验收这可能是PM们被直接领导、老板们问的最多的问题，也是很多PM们很头疼的问题：用户平时配合的挺好，怎么一说准备验收了，什么都不好了，什么都要等等再说了……借口多的很，就是不配合你验收。诸如此类的事情，在项目验收过程都可能遇到。不验收用户不给钱，公司催死PM；要验收用户提了一堆问题，PM难死公司……面对验收工作，PM们该如何展开操作呢？

　 从个人一贯对于项目验收的理解来看，PM去操作项目验收工作是没有什么标准方法的。虽然项目验收的标准程序很多，很多地方都能看到：各类验收步骤、各类功能验证、各类文档、各类测试报告、各类手册、功能清单……别的地方都能看到的东西，所以这些不是我想说的。有标准的东西都是可循的、可以量化的，这些东西只要花点时间下去，都能准备完成。真正带给我们项目验收的压力的东西是那些非量化的东西：这个那个功能不符合要求、使用不方便；承诺的某某功能没有实现；与合同、投标文件对比还有×××功能没有实现（这些功能很可能是售前、销售为了拿单子不管死活的写上去的。）；系统才上线×个月问题还没有暴露，再等×个月验收也不迟……这些东西PM们该如何应对呢？

　 在继续开始之前，要说明一个问题。

　 关于项目，我们可以去追求完美，但是考虑到给我们发工资的老板的心情，所以，在研究项目验收这个问题的时候，让我们先把做个完美的项目这个念头扔到别的地方，重点去关心如何让一个项目在大家都能接受的底线之上去验收。

　 事实上，项目验收应该从PM接到项目的第一天，从看招标文件、投标文件、技术协议那天就开始准备。道理很简单：PM之后做的所有工作就是要完成这个项目，所以从这天开始PM就要为项目验收而准备。

　 看招标文件、投标文件、技术协议不是去弄明白要做什么事情，而是要“清楚的知道那些用户要求的东西、公司承诺的东西、合同里写清楚的东西，在事实上是无法实现或者在成本分析中实现这些东西是不划算的”。这些东西PM要明确的把他们从这三份合同相关的文件中识别出来，然后去和销售经理、售前顾问聊聊，看看这些东西都是怎么跑到合同或者标书里面去的，那些是可以去考虑回避的，那些是用户很关心，需要去考虑实现的。

　 行了，弄清楚这些事情之后，组织好你的小组成员和顾问，把这些东西说清楚，考虑好需求调研的时候对这些问题采用何种方式去调研之后，可以着手准备项目启动会（第一次设计联络会）了。

　 其实，做项目的过程，就是去将那三个文件（再罗嗦一次：招标文件、投标文件、技术协议）逐渐衰减的过程，当PM所担心的问题都“合理”的衰减了（合理是很重要的，有时候老板们会用一些“粗鲁”的方法解决问题，表面看暂时解决问题，事实上后遗症很厉害。），那么项目也可以验收了。但愿这个表述，大家能理解。
    PM如果能抓清楚影响项目未来发展和验收的主要问题，那么就需要在前面讲的协调、沟通过程（就是我说的吹牛过程，鉴于大家的理解有误，我改正为协调、沟通）中一点一点去把握用户对这些问题的心态和想法，然后加以诱导和说服。感觉条件具备的时候去选择一个合理的方式去将这些心中的石头释放掉。

　 有那些合理的方式呢？

　 会议显然是首选了。需要考虑清楚的就是会议的主题是什么，不要傻傻的去开有关功能、需求变更为主题的会哦，这会吓到用户的。关于开会的问题前面也说了很多，就不多说了。需要注意的就是选好主题，然后把你想实现的事情合理的安排进去，并讨论通过。

　 第二选择就是个别沟通了。每个功能点总有核心用户部门的，那么就去和这些部门的领导去沟通、协调吧。

　 还有第三种好办法吗？那就是希望用户不要提这些问题了。但是谁能保证他现在不提，你准备验收的时候不提呢？装傻，不是好办法。还是主动去排雷比较好，免的炸的时候你很惨。