软件开发需抓得住客户需要

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

是的，所有莫如「赶紧敲定,客户信息管理系统，赶紧开端，赶快交差，最后 赶快收钱」来得主要，所以许多软件开发团队在派出名目经理或业务经理去「搞定」客户需求之后，大伙儿就立即一头栽入全部开发流程，你剖析、我撰写、他测试,企业内部管理，世人忙得不可开交，只求工作如期实现，大家就可以开庆功宴了。

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

「搞明白客户需要」说起来轻易，实际上却不轻松，否则奋斗大会的召开频率也不会那么高。

需求很重要，起因除了确保庆功宴得以举行，另外还有一个重要因素，就是避免本钱忽然失控、导致案子失败。依据统计，同样一个问题，当它产生在最前面阶段与最后面阶段时，须要投入的解决本钱的均匀比例是 1 比 200 。需求通常呈现在流程前期，因此这恰是要器重「需求管理」的起因。

需要如何治理？

很多人以为，需求不外就是「客户讲的话」；不外，在 rup （ rational unified process ）功课准则里，需求的定义是：「一个系统必须遵守的条件或才能；而这些条件或才能可以来自使用者需求，或合约标准中的文字陈述，或其它经确认的正式文件」。另外， rup 对需求管理的定义是：「导引、文件化、组织及追踪需求变动的系统化进程」。

特殊赋予定义是为了让「双方完全肯定与完整控制」「客户讲的话」。

此外，需求可能来自客户端不同层级与不同职员，自己开发团队里的成员也有可能分辨帮助处置，因而必须断定所有人对需求的「认知」都雷同。另外，为了防止「令出多门」，必须特殊厘清客户需求的真正决议者 —stakeholder （举动主体）。

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

在 rup 里，需求陈说必须满意以下前提：明白（ verifiable ）、能够排定主要性先后次序（ ranked for importance and stability ）、可订正（ modifiable ）、可追踪（ traceable ），以及能够被懂得的（ understandable ）。此外，对任何一条需求陈说而言，它还必需是准确（ correct ）、完全（ complete ）、一致（ consistent ）且清晰的（ unambiguous ）。

列出这么多前提，并不是要把需求搞得很庞杂，相反地，是为了让需求「明白、简略、而且可以被完整懂得与测验」。

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

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

固然这个目标简略又明了，真正能达成的却未几；最常产生的状况就是预算或时间意外失控，导致预算膨胀、交货延迟，甚至整个案子胎逝世腹中。要避免以上的状态，有两点原则值得特别留神。

准则一：刚好就 ok

客户很精明，都在寻求「预算与时间最小化，需求最大化」的高尚目标，但假如开发团队基本无奈满意这种需求组合时，该怎么办？

第一种取舍是委曲本人做出许诺，再回公司拼命压迫开发团队，成果往往是交出一个不堪入目标产品，从此跟客户说拜拜。第二种抉择是老实面对本人与客户,SFA，而后与客户探讨如何对需求进行公道的切割筛选，事实上，这也是很多人与客户沟通时常常面临的问题。

大家都晓得需求要切割，但如何切割就是学识了。因为必须非常清楚客户的实际需求，要将需求的重要性排列次序，也要晓得如作甚众多需求进行正确的排列组合，让他们成为一套可以被客户接收的计划，而且又满意「在既定的估算与时间内，交出契合客户真正需求的优良产品」的原则，甚至还能为后续开发进行排程组合。事实上，这个过程就是 rup 需求管理的精华之一，此外，也可以透过合适工具，更容易地把握、追踪与进行全部需求管理过程。

准则二：小而美

依据 standish group 在 1999 年统计，一个项目的成功率与它的规模大小有亲密的反向关联，胜利比例会跟着规模增添而递减。例如，当项目的规模小于七十五万美金时，均匀成功率大概是 55 ％；当项目规模增长到六百万美元至一千万美元之间时，成功率剩下不到 10 ％，若项目规模大于一千万美元，成功率就变成「零」。

这种项目范围与胜利率的逆向关联实在很轻易理解，因为项目越大，需求就越多，必须组成更宏大的开发团队，进行更多的沟通与互动，管理睬更为庞杂。对软件开发而言，范围是很重要的，因而野心不要太大，细水可以长流。

容我再反复一次：需求管理的目的就是「在既定的估算与时间内，交出合乎客户真正需求的优良产品」 不下降品质，也未几生枝节，刚恰好就好。