该帖子同步发自：(yanglinux的博客  访问该博客)

每天都在讲范围、说需求，真的到了想整理出点什么的时候，却一下子不知从何说起。也许是熟悉麻痹症吧。根据我的破经历，在需求方面有几个是最搞人的，只要我们方法得当，虽然不一定能够完全驾驭，但起码可以改善一些或者说当板子落下来的时候至少我们不会受伤。

当用户或出资方能提出要求但就是总在拖拖拉拉怎么办？用时间盒子限定需求！给他一个最后日期，说明在什么什么时候之前必须提出，否则过期不候。当然，也有可能这招没效。没关系，记录下来，让其签字，至少白纸黑字写下来了，以后用这个来催他会好一点。或者他不签字，也不碍事，将相关沟通结果告知你的上层。既然遇到了这么不配合的出资方，如果不把自己保护起来到时候嘿嘿就有得自己受了。事情要做好，这是终极目标；可是我们生活在一个现实的环境下，所以过程是相当重要的。

当用户催的很急，资源也不能增加，范围也框定了，怎么办？排定需求优先级并实现最紧急的。这个在实际操作中也不一定是那么顺利的，有的出资人很倔强——什么都重要，那就得给他耐心解释了，必要的时候要给他上上课。这中间会考验项目带头人的多种素质，事在人为而已。按照优先级去实现系统的功能，即使到时候真的完成不了，损失也可以降低到最小。

当需求不停变更时，该怎么办？建立变更控制流程！不管是甲方的，还是我们乙方内部的，都需要，好处太多了，费的那点时间后面会无数倍的赚回来。

变更，既是客户的权利，也是客户自己也没有完全弄清楚的地方，虽然我们作为乙方遇到经常变更或反复变更的情况时会很头疼，我们应该真诚体谅和积极配合。问题是，不能让权力滥用，绝对不能把本来不好意思的变更，宠惯养成堂而皇之的坏毛病。我们要想办法控制变更，目的是保证我们的有限资源尽可能配合“有效变更”，同时尽可能减少“无效变更”对成本、工期和合同履行带来的负面影响。

1．立即（通过公司层面）建议客户建立变更审批/下达制度，目的有两个：第一，将客户下达变更的流程尽可能地正规化，减少张嘴就来的非必要、非紧急、非合理、非高层领导意图的“无效变更”。第二，留下书面依据，以后玩扯皮游戏的时候掌握一点点主动权。

这个事情最好是得到对方的高层首肯，事情就好办了。一般来讲，高层都懂管理，你以“加强管理、优质服务”为理由，对方应该是会同意的。

2．强化自身计划管理和节点控制的功夫，向客户正式提交一份各阶段主要工作节点和技术关键事项的完成计划，注明任何可能的变更必然引起的时间、成本、工期的代价，建议或要求客户配合这个计划，保大局弃小变，推进项目前进。

3．对于已经形成惯例的零星变更（前提是必须要处理的变更），要努力争取“集中研究、批量处理”，每周或每两周甚至每月召开一次变更专题会议，集中研究处理这些零碎变更事项，主动控制好工作节奏，硬着头皮顶住要求随时处理这些零星变更的压力，尽量避免由于处理零碎变更而影响项目运行的总体态势。

4．对于不合理的变更，尽量往后推，可以告知客户“我们在下一阶段实现”。切不可用户提什么就答应什么，并马上着手给他们开始处理，那样就患上了不治之症啦。哈哈！

总之，说易行难，真正要落到实处，还有很多工作要做。路漫漫其修远兮，吾将上下而求索。