“管”不住的需求管理

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

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

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

• 严防

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

• 松懈

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

• 纵容

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

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

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

    把需求“管”起来

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

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

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

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

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

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

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

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

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

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

    管理已确定的需求

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

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

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

    管理变更的请求

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

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

    管理用户的需求

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

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

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

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

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

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

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

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

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

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