时间：项目启动期 地点：经理办公室

    老王[部门经理]：小项啊，销售部的这个CRM系统可是今年的重点项目，领导们都很重视，一定要确保按时交付啊！

    小项[项目经理]：老大请放心，保证完成任务！

    老王：好！不过有些情况还是要注意，这之前的几个拖期比较严重的项目，咱们内部也总结过，差不多都是因为需求变动造成的，这次你可要把好需求管理这道关，别犯过去的老毛病啊！

    小项：是，老大。以前那几个项目，都到了开发阶段还在不停增加新功能，才导致工期一拖再拖，这回我们从需求阶段就把好关，老大你也跟销售部的老大打个招呼，需求一旦确定后就不要轻易变更，这样工期也好控制。

    老王：行啊，没问题，我就等你的好消息了。

    时间：系统开发期 地点：项目组办公室

    小李[业务经理]：项经理，我们部门考核销售员拜访活动的规则做了调整，不但要考察拜访的过程和效果，还要跟具体的项目和客户挂钩，进行综合考察，所以之前咱们讨论过的功能需求也有些变化，你看大概需要多久能改完？

    小项：李经理，需求都已经定了，代码也开始写了，当初原型演示的时候你们也是同意了的，怎么说变就变？这个属于需求变更，按规定要项目管理委员会评审通过我们才能改，可能得延后交付日期，说不好要多久。

    小李：延后交付？那怎么行！上线日期都已经定了，怎么能说延就延？虽说需求我们确认过，可实际的业务发生变化，系统的功能要是不改就根本用不了，这个责任你能负吗？

    小项：我也没办法，反正需求变更的流程是这样规定的，要么不变，要变就得按流程走。

    小李：哼，行，我找我们老大去，就不信变不了！

    地点：经理办公室

    老王：小项，昨天小李他们老大过来找我，说那个拜访考核的变更很重要，直接影响上线后的使用，要不然你就先给他们改了再说，不然系统做出来也没法用，你说是不是？

    小项：老大，不是我不给他们改，确实是那个新考核规则太复杂，肯定会影响到项目进度的，再说，不是说要严格控制需求变更吗，如果这次不按规矩走，那以后……

    老王：哎，我也知道，这不也是没办法么，他们老大直接来找我，说要是不给改整个系统就没必要做下去了，这样的话咱们到老板那里也不好交待呀！

    小项：那变更流程还要不要走？

    老王：这个，你先把该改的改了，至于变更流程的文档什么的，事后补一补，做个记录就行了。

    小项：哦，那好吧。

    地点：项目组办公室

    小郑[QA]：项经理，系统功能里的很多功能点跟《需求库》里对不上啊，下礼拜的阶段评审可怎么做呀？

    小项：呃，小郑啊，这不是进度太赶还没来得及改么，要不这个周末我突击一下，把文档给你补齐咯？

    小郑：（叹气）项经理，文档可不是写给我的，还有，变更需求库之前是要作变更评审的，你连变更请求都没写，怎么能直接改呢？

    小项：唉，这不是没办法么，工期落后快2周了，我差点就焦头烂额了，哪还有工夫作那个什么什么评审的？

    小郑：可是，你不是说需求管理和变更的流程要严格执行吗？

    小项：咳，此一时彼一时嘛，要是有时间我能不写吗？

    小郑：那好吧，记得要在评审前补全……

    小项：知道啦。

    时间一天天过去，其间，销售部经历了一次组织架构调整，负责系统需求的小李被调去新的岗位，改由另一个业务经理接任。但是，这位新的业务经理和小李在许多问题上的看法都不太一样，尽管软件已经进入开发阶段，销售部提出的变更却越来越多。

    由于进度已经落后，小项已经没精力去做变更申请的评估，为了让系统尽快上线，他只好来一个改一个，修改完成后再抽点时间填个《变更实施记录表》了事。至于《需求说明书》也根本来不及更新，离系统实际的功能相差越来越远……

    经理老王也没闲着，他要顶住销售经理和老板的双重压力，拼命争取给项目宽限些时日。可是不管怎么努力，系统上线的日子依然遥遥无期。老王回过头责备小项，怪他没控制住需求，重蹈了过去的覆辙。小项也一肚子委屈，认为责任应归咎于需求管理流程的虚有其表，根本“管”不住蔓延的需求。

    两人各执一词，面对不断拖后的工期，一筹莫展。

    “管”不住的需求管理

    老王和小项面临的困境很多人似曾相识，也许细节不尽相同，但那种眼睁睁看着项目失控的无力感，相信不少人都深有体会。

    案例中的老王和小项事先已经认识到了需求蔓延的危害，并且采取了一定的预防措施，比如对需求库的管理、对变更申请的评估、对变更处理的报告等。可是，为什么到最后却还是一团乱？为什么好好的流程摆在那儿却没人遵守？为什么项目的需求只能跟着业务部门跑？为什么看似严密的“需求管理”制度却根本“管”不住需求？

    看看他们对待变更的态度是如果变化的，大概可以找到些原因。

• 严防

    刚开始的时候，老王和小项对需求蔓延导致的延期风险心有余悸，一致认为这个项目应当加强需求管理，减少需求蔓延的风险。

• 松懈

    当变更出现时，小项牢记当初的承诺“不允许轻易变更”，可是他的坚持并没有挡住业务部门的压力，变更被接受了，规矩被破坏了，可当时的情况还没有变得太糟，隐忍之后也就慢慢习惯了。

• 纵容

    当变更不断、无法控制时，小项干脆放弃了对需求的管理。反正销售部架构变了、流程变了、一切都变了，不满足新需求系统根本无法交付，上了贼船的小项只能被变更牵着鼻子走，慢慢从习惯、到麻木、再到纵容，最后演变成一场灾难。

    说到底，需求蔓延的根本原因还是管理制度执行不下去。小项说的对，那些规章制度根本“管”不住蔓延的需求。

    尤其是，当我们被层出不穷的变更压得喘不过气，当我们为了节省时间绕过了应有的评审，当我们因为一次的“捷径”忘记了失败的风险，当我们把需求管理弱化成机械的文档填写，当我们面对变更麻木的自以为是，我们已经失去了应有的警惕，失去了防范风险的机会，一套被“形式化”的需求管理规范，除了生成无用的事后文书之外，毫无用处。

    把需求“管”起来

    “管”不住需求的管理流程根本毫无作用，却像一座高墙禁锢我们的洞察力，让我们沉浸在“只要把报告补充完整就是做了需求管理”的虚假幻像中。

    面对高墙，我们不能依赖别人的救赎。就像小项不能指靠销售部自愿放弃提出变更请求一样，只有正确认识需求管理的实质、掌握需求管理的技巧、努力坚持下去，不被暂时的挫折和困境打倒，才能达到真正意义上的“管理”。

    首先，认识需求管理的实质

    需求是可以管理的，需求蔓延是可以控制的，只要我们采用正确的、恰当的管理方法，它不会成为项目进展的阻碍，哪怕有时候它看上去的确占用了大把的时间。

    需求管理包含两方面的内容。一是对已经确定的需求进行跟踪和管理，确保每个需求点都被实现或者被关闭。二是对用户提出的变更请求进行评估、跟踪和监控，确保新的变更不会与现有需求冲突，如果有冲突，那么需要在更大的范围内评审，或者修改此前的需求，或者拒绝变更的请求。

    需求管理的目的是保证需求被正确的理解和实现，没有遗漏，保证最终交付的产品符合用户的要求。不管从哪个方面来理解，需求管理都绝不是写几篇文档那么简单，那种突击式的补齐文档应付QA的做法是不可取的。

    在案例中，老王的初衷是好的，提醒小项通过需求管理降低项目拖期的风险，小项在对待李经理提出的变更请求时也坚持了变更管理规范（虽然他拒绝变更的闭锁态度并不可取）。

    但也许销售部经理太强势，也许是小项他们的管理规范不够细致，总之正常的变更管理流程先是被老王“简化”成一句话，而后又被小项进一步“演绎”成了空洞的文档填写，需求管理至此彻底失去了“管”住风险的机会。

    其次，掌握需求管理的技巧

    对需求管理，我们不但要正确认识其本质，也要具备足够的能力，掌握需求管理所需的能力和技巧，真正做到“管理”需求。

    管理已确定的需求

    一份通过评审并取得各方认可的《需求规格说明书》是需求管理的基础，在此基础上建立起的《需求库》和《需求跟踪矩阵》能够帮助需求管理员对分析、设计、开发和测试阶段，每个需求点被实现的情况进行跟踪和管理，这是做好需求管理的基础。

    《需求规格说明书》和《需求库》是产品的设计基线，要进行严格的版本控制，不能随意修改。在对其改动前，必须通过变更管理委员会的评审，以保证需求的稳定性，防止需求蔓延的风险。

    案例中的小项编制了这些文档，但是却没有给与足够的重视，尤其是在变更频繁、进度落后的压力下，他选择了罔顾QA小郑的提醒，把这些当作纯粹的文案工作来对待，忽视了产品基线对于稳定需求的重要性，导致需求变更失控，需求说明书成了摆设。

    管理变更的请求

    没有哪个项目的需求是不发生变化的，只是多少不同罢了，因此，如何管理变更就显得更加重要。案例中，小项的项目其实是有变更管理流程的，只是没有发挥应有的作用而已。

    一般来讲，我们会通过一系列的表格和报告来实现变更的管理，比如《变更申求表》、《变更评审报告》、《变更实施记录》、《变更请求处理报告》等，千万不要把这些报告看作是僵化无用的文档，它们实际上体现了组织对变更的管理方针，从变更的提出、评审、执行、结果监控到基线变更管理的全部过程，只有对每一步都认真执行，才能实现变更的有序管理。

    管理用户的需求

    在我们看来，用户总是会提出各种奇怪的要求，并且总是犹豫不决，常常要求推翻之前的论断从头再来。对此不必太紧张，用户的需求不是小怪兽，我们也无需变成奥特曼，只要掌握一定的规律和技巧，用户的需求也是可以管理的。

    为了控制变更的数量和频率，与各方干系人就项目的目标达成一致是十分必需的，通常情况下，用户不断增加需求是基于“这点改变不会影响项目进度”的认知提出的，如果让用户了解变更对进度的影响，对目标实现的影响，只要我们是据实以告，大多数情况下用户是能够理智对待的。

    对于案例中的小项来说，后期频繁的需求变更主要是由于销售部架构调整和业务负责人更替造成的，属于重大的意外情况，应当作为重大变更来处理。小项应该就此事与项目的各方干系人坐下来讨论，必要时由老王出面协调，对有关项目工期、范围和需求变动等关键问题重新评估并达成一致，制定出一分新的启示可行的项目计划。这样既避免了无限制的延期，也不会被变更压得喘不过气来。

    最后，强调需求管理的跟进

    对需求管理，持续跟踪是王道，无论进度压力多大都不应该松懈，这样才能达到“管理”需求的效果。三天打鱼两天晒网的做法，从来不是需求管理的那盘菜。

    需求跟踪是一件艰难琐碎的事，从《需求跟踪矩阵》的表格设计就可见一斑，它几乎涵盖了软件开发所有阶段的需求点实现情况，除非该项需求通过变更评审后被关闭，否则必须从需求分析阶段跟踪到验收测试阶段，不能有任何遗漏。

    对任何项目来说，如此细致的跟踪监控都需要有极大的耐心和毅力才能完成。尽管它费时费力，但作用却不容小视。有了准确及时的跟踪矩阵，我们就可以轻松掌握用户需求的实现情况，避免重要的功能点被遗漏，避免在无效的需求上浪费精力，保证交付的产品是用户需要的。

    案例中的老王或许清楚需求管理的重要性，也制定了相关的制度，但是他本身的一些言行和做法却直接打破了这种规范，比如他绕过了变更申请的评估流程，让小项“先改了再说”。我们都知道，这种“绕行”现有制度的行为一旦开了头，就会有无数的人跟上，因此后面变更泛滥的情况也就不足为奇了。

    小项由于进度压力没有及时更新跟踪矩阵，或许他应该找一个专制的需求管理员来做这项工作，但是不管怎样，集中突击补文档的做法总是不可取的，没有了持续跟进和及时监控，再完美的文档也会失去“管理”的功效，只能成为无用的故纸堆。

    为了让需求管理真正能“管”得住需求，我们应该不厌其烦的从小处做起，把每一次变更都当作可能引发蔓延的风险来管理，保持警惕和洞察，坚持不懈的跟踪和管理，才能让需求成为真正可控制、可度量、可管理的对象。