4、对待需求变更的技巧

对用户提出的需求来说，首先项目经理要考虑变更的合理性。不合理的需求要找到推掉的理由，避免直接拒绝。比如，如果一个用户提出的变更和系统的目标不一致的话，让用户自己推倒自己需求。好处是即给了用户面子，客户关系也能得到提高。同时避免产生了工作量。

绊字诀：先把他的招接过来，之后他脚下出一招，让他用自己的冲力把自己摔倒。

封字诀：在我们的系统是不能实现这种功能的”。之所以用这么肯定的语气是要断了他要实现这种功能的念头。封字诀是直接回绝他，清楚的告知这招是行不通的。

拖字诀：对于比较合情合理的需求，但又不是现在要解决的问题.要想办法往后拖，不至于打乱当前的计划。

对于客户内部斗争，千万不要正面参与。有些人可能会直接拿系统做替罪羊，这个时候需要找到更上一级的领导来出面协调。借助客户的力量来摆平。目的推到二期来做。

5、编写需求变更申请表

编 写要尽量详细，并经过客户、高层经理和项目组内部人员的认可。比如测试人员对测试的工作量要参与评估，开发人员对开发工作量要进行评估。数据来源基于基 层，确保数据的准确性。同时补充一点变更带来的质控工作量也应该纳入到变更需求表中，比如可能设计项目总结和数据统计的工作量。

客户提交的问题要做好详细的记录，保证有据可查，对问题要进行面对面的确认，避免含糊其词的用户需求。对确认结果进行记录。

6、变更控制流程转

(1)、内部项目：用户提出需求-》项目组对问题进行分析(不明确的问题要进行确认，区分问题的优先级和解决方案)-》提交变更申请表(包含估计和计划)-》高层领导决策-》审批通过-》依照项目计划执行。

2)、 外部项目：用户提出需求-》项目组对问题进行分析(过滤需求是否合理、是否在本版本来做、能否放到二期、需求的必要性等)-》与客户讨价还价(把不合理的 需求、不必要在本期实现的功能推掉)-》必须要实现的需求-》提交需求变更申请(初步的计划和解决方案)-》高层领导决策-》详细分析需求和解决方案-》 评估工作量-》设定计划-》客户签字确认-》依照项目计划执行

以上两者的区别在于：内部项目一般需求的控制权在高层领导中，有时候不一定关注成本，偏重于系统产生的价值，对用户而且主要关注实用和易用性上。项目经理或团队主要侧重分析用户需求的合理性。

外部项目首先应该考虑是公司投入的成本和获取的收益，比如变更会给公司增加合同额或后期市场拓展的机会和对产皮的提炼(有的项目是项目型的产品)。如果上述条件不满足，则首要考虑的是如何推掉需求。