做变更申请的评估，为了让系统尽快上线，他只好来一个改一个，修改完成后再抽点时间填个《变更实施记录表》了事。至于《需求说明书》也根本来不及更新，离系统实际的功能相差越来越远……
经理老王也没闲着，他要顶住销售经理和老板的双重压力，拼命争取给项目宽限些时日。可是不管怎么努力，系统上线的日子依然遥遥无期。老王回过头责备小项，怪他没控制住需求，重蹈了过去的覆辙。小项也一肚子委屈，认为责任应归咎于需求管理流程的虚有其表，根本“管”不住蔓延的需求。
两人各执一词，面对不断拖后的工期，一筹莫展。
“管”不住的需求管理
老王和小项面临的困境很多人似曾相识，也许细节不尽相同，但那种眼睁睁看着项目失控的无力感，相信不少人都深有体会。
案例中的老王和小项事先已经认识到了需求蔓延的危害，并且采取了一定的预防措施，比如对需求库的管理、对变更申请的评估、对变更处理的报告等。可是，为什么到最后却还是一团乱？为什么好好的流程摆在那儿却没人遵守？为什么项目的需求只能跟着业务部门跑？为什么看似严密的“需求管理”制度却根本“管”不住需求？
看看他们对待变更的态度是如果变化的，大概可以找到些原因。
严防
刚开始的时候，老王和小项对需求蔓延导致的延期风险心有余悸，一致认为这个项目应当加强需求管理，减少需求蔓延的风险。
松懈
当变更出现时，小项牢记当初的承诺“不允许轻易变更”，可是他的坚持并没有挡住业务部门的压力，变更被接受了，规矩被破坏了，可当时的情况还没有变得太糟，隐忍之后也就慢慢习惯了。
纵容
当变更不断、无法控制时，小项干脆放弃了对需求的管理。反正销售部架构变了、流程变了、一切都变了，不满足新需求系统根本无法交付，上了贼船的小项只能被变更牵着鼻子走，慢慢从习惯、到麻木、再到纵容，最后演变成一场灾难。
说到底，需求蔓延的根本原因还是管理制度执行不下去。小项说的对，那些规章制度根本“管”不住蔓延的需求。
尤其是，当我们被层出不穷的变更压得喘不过气，当我们为了节省时间绕过了应有的评审，当我们因为一次的“捷径”忘记了失败的风险，当我们把需求管理弱化成机械的文档填写，当我们面对变更麻木的自以为是，我们已经失去了应有的警惕，失去了防范风险的机会，一套被“形式化”的需求管理规范，除了生成无用的事后文书之外，毫无用处。
把需求“管”起来
“管”不住需求的管理流程根本毫无作用，却像一座高墙禁锢我们的洞察力，让我们沉浸在“只要把报告补充完整就是做了需求管理”的虚假幻像中。
面对高墙，我们不能依赖别人的救赎。就像小项不能指靠销售部自愿放弃提出变更请求一样，只有正确认识需求管理的实质、掌握需求管理的技巧、努力坚持下去，不被暂时的挫折和困境打倒，才能达到真正意义上的“管理”。
首先，认识需求管理的实质
需求是可以管理的，需求蔓延是可以控制的，只要我们采用正确的、恰当的管理方法，它不会成为项目进展的阻碍，哪怕有时候它看上去的确占用了大把的时间。
需求管理包含两方面的内容。一是对已经确定的需求进行跟踪和管理，确保每个需求点都被实现或者被关闭。二是对用户提出的变更请求进行评估、跟踪和监控，确保新的变更不会与现有需求冲突，如果有冲突，那么需要在更大的范围内评审，或者修改此前的需求，或者拒绝变更的请求。
需求管理的目的是保证需求被正确的理解和实现，没有遗漏，保证最终交付的产品符合用户的要求。不管从哪个方面来理解，需求管理都绝不是写几篇文档那么简单，那种突击式的补齐文档应付Q