「不要再管什么需求了，时间有限，今天就开始建系统了！」这句话很熟悉吧？没错，许多从事软件开发的人大概都曾听过或讲过这句话。因为软件开发的时间总是很紧迫，既然都已经有人跟客户谈定了，若不赶快动工，怎来得及？

    是的，一切莫如「赶快敲定，赶快开始，赶快交差，最后 —— 赶快收钱」来得重要，所以许多软件开发团队在派出项目经理或业务经理去「搞定」客户需求之后，大伙儿就立刻一头栽入整个开发流程，你分析、我撰写、他测试，众人忙得不亦乐乎，只求工作如期完成，大家就可以开庆功宴了。

    遗憾的是，真实世界的状况不是如此。所以常会看到庆功宴开不成，反倒以斗争大会代之，大家交相指责，而其中又以项目经理或业务经理成为众人锁定的目标，因为大家一致抱怨：「就是你们搞不清楚客户需求，才让大家白忙一场！」

    「搞清楚客户需求」说起来容易，实际上却不轻松，否则斗争大会的召开频率也不会那么高。

    需求很重要，原因除了确保庆功宴得以举办，另外还有一个重要因素，就是避免成本突然失控、导致案子失败。根据统计，同样一个问题，当它发生在最前面阶段与最后面阶段时，需要投入的解决成本的平均比例是 1 比 200 。需求通常出现在流程前期，因此这正是要重视「需求管理」的原因。

    需求如何管理？

    许多人认为，需求不过就是「客户讲的话」；不过，在 RUP （ Rational Unified Process ）作业准则里，需求的定义是：「一个系统必须遵循的条件或能力；而这些条件或能力可以来自使用者需求，或合约规范中的文字陈述，或其它经确认的正式文件」。另外， RUP 对于需求管理的定义是：「导引、文件化、组织及追踪需求变动的系统化过程」。

    特别赋予定义是为了让「双方完全确定与完全掌握」「客户讲的话」。

    此外，需求可能来自客户端不同层级与不同人员，自己开发团队里的成员也有可能分别协助处理，因此必须确定所有人对需求的「认知」都相同。另外，为了避免「令出多门」，必须特别厘清客户需求的真正决策者 —Stakeholder （行动主体）。

    再来谈谈什么才是「正确」的需求陈述。

    在 RUP 里，需求陈述必须满足以下条件：明确（ Verifiable ）、可以排定重要性先后顺序（ Ranked for importance and stability ）、可修订（ Modifiable ）、可追踪（ Traceable ），以及可以被理解的（ Understandable ）。此外，对任何一条需求陈述而言，它还必须是正确（ Correct ）、完整（ Complete ）、一致（ Consistent ）且清楚的（ Unambiguous ）。

    列出这么多条件，并不是要把需求搞得很复杂，相反地，是为了让需求「清楚、简单、而且可以被完全理解与检验」。

    举例来说，我常常听到客户要求：「系统必须很稳定才行」，但如果直接将此付诸文字可就麻烦了，因为该如何界定「稳定」呢？所以这个需求陈述是错误的。正确的作法可以是这样：与客户进一步沟通后，写成「系统必须可以满足一千个使用者同时上线；当使用者提交一个要求时，系统送出回复的时间必须小于五百微秒；系统必须可以适用于连续七天与每天二十四小时的运作环境」。因为这些陈述都很清楚，也可以被检验。事实上，这个过程就是一种需求管理的实践，因为正确的需求被「导引」出来，并诉诸「正式文件」。

    陈述这些需求管理的原则与作法的目的是：「在既定的预算与时间内，交出符合客户真正需求的优秀产品」。只要达到这个目的，项目就百分之百成功了。

    虽然这个目的简单又明了，真正能达成的却不多；最常发生的状况就是预算或时间意外失控，导致预算膨胀、交货延迟，甚至整个案子胎死腹中。要避免以上的状况，有两点原则值得特别注意。

    原则一：刚刚好就 OK

    客户很精明，都在追求「预算与时间最小化，需求最大化」的崇高目标，但如果开发团队根本无法满足这种需求组合时，该怎么办？

    第一种选择是勉强自己做出承诺，再回公司拼命压榨开发团队，结果往往是交出一个不堪入目的产品，从此跟客户说拜拜。第二种选择是诚实面对自己与客户，然后与客户讨论如何对需求进行合理的切割筛选，事实上，这也是许多人与客户沟通时经常面临的问题。

    大家都知道需求要切割，但如何切割就是学问了。因为必须十分清楚客户的实际需求，要将需求的重要性排列顺序，也要知道如何为众多需求进行正确的排列组合，让他们成为一套可以被客户接受的方案，而且又满足「在既定的预算与时间内，交出符合客户真正需求的优秀产品」的原则，甚至还能为后续开发进行排程组合。事实上，这个过程就是 RUP 需求管理的应用精髓之一，此外，也可以透过适合工具，更容易地掌握、追踪与进行整个需求管理过程。

    原则二：小而美

    根据 Standish Group 在 1999 年统计，一个项目的成功率与它的规模大小有密切的反向关系，成功比例会随着规模增加而递减。例如，当项目的规模小于七十五万美金时，平均成功率大约是 55 ％；当项目规模增加到六百万美元至一千万美元之间时，成功率剩下不到 10 ％，若项目规模大于一千万美元，成功率就变成「零」。

    这种项目规模与成功率的逆向关系其实很容易理解，因为项目越大，需求就越多，必须组成更庞大的开发团队，进行更多的沟通与互动，管理会更为复杂。对软件开发而言，规模是很重要的，因此野心不要太大，细水可以长流。

    容我再重复一次：需求管理的目标就是「在既定的预算与时间内，交出符合客户真正需求的优秀产品」 —— 不降低质量，也不多生枝节，刚刚好就好。