解决需求乱局

加拿大ADP Employer Services的CIO Hugh Cumming 停下了手中的工作，他正在开发一项用于欧洲某大型公司呼叫中心的管理软件。目前，软件所能实现的功能与40位业务人员列出的需求清单间的差异已经写满了3000页纸，这可能会使已经未能如期交付的呼叫中心项目再推迟4～5年上马。“我的直觉告诉我这个项目已经没有成功的可能了。” Cumming说。

正如每位CIO所知，需求管理是一项难题，但是CIO们往往对这个难题所带来的灾难预估不够。有关分析师的报告显示，71%软件项目的失败原因归咎于糟糕的需求管理，这大大超过了技术、项目延期和管理者更迭等因素。尽管CIO很少直接负责需求管理，却也不能对其造成的恶果开脱。当需求没有处理好时，可能会使项目延期或系统无法实现预期的功能，甚至是软件交付时却不能运行，这将会把整个业务连同CIO的职业生涯一起推向悬崖边。

需求被错误处理可能在任何时候破坏整个项目，如果在交付前的测试过程中再去整合需求，CIO会发现为时已晚。CIO应当建立全面而有效的需求管理系统，通过各种方式实现需求以获得业务方和开发方的认同；CIO还应该发挥中枢职能，将各种复杂的需求归纳、整理成线性结构。

CIO要做到这些并不容易，因为业务部门常常不知道自己的确切需求，也不能指出需求的优先级，甚至提出IT不能解决的需求及无法翻译成代码的需求；而IT部门的分析员、系统架构师、程序员也会由于需求混乱而士气低落，对项目的成功不抱期望。

简而言之，传统的需求管理方式出现了问题，所以许多IT人士开始尝试用各种方法来弥补。尽管每人都承认过程控制是关键，但在具体采用什么控制模式上各持己见：一位CIO认为只需强化已有的流程管理规则，另一位CIO则坚持彻底重写规则；一些CIO跳出传统模式，其中一部分人侧重关注业务流程，另一部分人则愿意通过搭建一个快速的处理流程取代冗长的需求文本。不过，他们都同意应该选择一套正式的需求收集处理模式，并持之以恒。尽管描述需求一直是件困难的事，但经过阵痛之后，需求处理流程会让CIO受益匪浅——它也许能让你在下一个项目中变得从容不迫。

精简需求者

Cumming采取了激进的方式来处理复杂的需求。他在ADP公司总裁的支持下，首先放弃了弥合已有功能和使用者需求间差异的想法，并且剔除了已有且没必要放到新项目中的需求。他还从踊跃提需求的40个业务人员中挑出了5个积极分子，叮嘱他们只能提出必要而简练的需求，同时他也允许其他35人参与进来，但仅限于评估执行计划和需求说明书，而不能增加需求。不到两个月，他就制订出了一份新的需求计划，只占原计划的10%。这个项目实施后，能很便捷地应用到全球12个地区。

Cumming认为，IT部门在需求管理过程中，通常并不处于领导地位，他们通常认为“需求是业务部门提出的，所以必须实现”，这种想法只会使需求变得复杂而无法实现。所以IT人员必须学会一种技巧——“微笑着说不，对他们说‘现在还不是时候’”。

当Cumming将40个需求者削减到5个时，他看到剩下的人非常紧张，这些人担心系统将不能实现自己部门所需的功能。为了缓解他们的恐惧，Cumming和核心人员做了一份重要功能摘要来描述项目及其花费的时间，所有的人可由此掌握项目的进度。他使所有需求者了解到他们应该怎样从系统中获取价值，甚至有些细节是他们从来没想到过的。

当呼叫中心系统开始运行时，越来越多当初被动的员工被调动起来，当系统影响到这些业务部门，部门管理者需要为先前所提出的需求变更负责，这项工作引起了他们强烈的兴趣。Cumming也希望知道是谁在真正影响公司，他还希望能够鉴别那些更具专业技能背景的需求提供者，从而增加需求收集过程的价值。

“根据我的经验，需求列表中的绝大部分内容最终是由少数人贡献的。”Cumming说。

引入新流程

5年前，加拿大蒙特利尔银行的技术发展部主管Jesse Hanspal对内部“大杂烩”式的需求分析就已经感到疲倦，他决定自己开发一套能够组合各种需求并提供质量保证的程序。经过5年的努力，Hanspal已经定义了一套高度抽象的需求确立模式和流程，它能够应用在任何项目中。

“将所有需求者聚在一起，从他们的嘴里套出需求是十分重要的。” Hanspal说，“根据他们的角色来定义使用者，你能更准确地描述需求。”“一旦你定义了一个流程，你就需要为它取得一个ISO9000认证。”他说。这个认证让人们知道他们真正的需求是什么，并帮助银行评估效率和改进流程。Hanspal的新流程初见成效，银行内部涉及需求的软件数量减少了50%。

蒙特利尔银行也希望确保IT分析师能够执行新流程，但不幸的是虽然可以很容易地从外部找到关于项目管理和功能测试的认证，但却没有与业务分析相对应的认证，所以它们自己开发了一套程序。

升级开发方式

对于需求管理，一些CIO认为这个过程应该更加灵活。

Capital One公司的CIO Gregor Bailar是一位“敏捷开发（agile development）”派的支持者。“敏捷开发派”宣称旧体制中的需求管理较为刚性，在使用者和开发者之间筑起了一道壁垒，而软件和业务不断变化的特性将最终导致项目流产。他们认为，开发者和用户需要停止对项目进度频繁的评估和对根据用户的冗长需求分析文档进行变更，他们应该坐在一起并立即开始编码。“我们需要的不是浩瀚的程序，而是从项目中获得价值。” Bailar说。

“敏捷开发”概念从2004年初开始广为流行。Bailar非常支持这一理论，他采取了“敏捷方式”组建团队：Capital One的“敏捷团队”包括3名业务人员、两名操作人员和5～7名IT人员，其中包括1个业务信息指导（实际上是业务部门和IT部门之间的“翻译者”）；另外，还有一个由项目经理和至少80名开发人员组成的团队。这些开发人员都曾被Bailar送去参加过“敏捷开发”的培训，具备相关的技能。

每个团队都有自己的“敏捷指导”（Bailar聘用了20个敏捷指导），他的工作是关注流程并提供建议和支持。最初提出的需求被归纳成一个目标、一堆记录详细需要的卡片及一些供参考的原型和模板。在整个项目阶段，团队人员密切合作，开发有规律地停顿——在9周开发过程中停顿3～4次，以评估过程及决定需求变更是否必要。在Capital One，大的IT项目会被拆分成多个子项目，安排给各“敏捷团队”，这种方式在“敏捷开发”中叫“蜂巢式（swarming）”，所有过程由一名项目经理控制。

为了检验这个系统的效果，Bailar将项目拆分，从旧的“瀑布式”开发转变为“并列式”开发，形成了“敏捷开发”所倡导的精干而灵活的开发团队，并将开发阶段分成30天一个周期，进行“冲刺”——每个冲刺始于一个启动会议，到下个冲刺前结束。

在Bailar将其与传统的开发方式做了对比后，他感到非常兴奋——“敏捷开发”使开发时间减少了30%～40%，有时甚至接近50%，提高了交付产品的质量。

“不过，有些需求不能用敏捷开发来处理。” Bailar承认，“敏捷开发”也有局限性，比如对那些不明确、优先权不清楚的需求或处于“较快、较便宜、较优”的三角架构中却不能排列出三者优先级的需求。此外，他觉得大型项目或有特殊规则的需求的项目，更适宜采用传统的开发方式。

深入流程背后

宝洁制药公司（Procter & Gamble Pharmaceuticals）的IT战略管理主管Robert Sherman认为，需求处理是从业务流程到最终软件应用一系列过程的第一步。他警告道：“如果一个IT经理没有意识到这种相互关联的重要性，整个项目将会崩溃。”

就像ADP公司的Cumming一样，Sherman在上世纪末也走入了需求管理的困局。那时，宝洁的150家工厂只有一套工厂信息管理系统，Sherman和公司其他9位专家一起比较了开发者提供的70页说明书和宝洁提出的200页需求文档。专家们都认同这个文档包含了成功项目的每一个需求——它相当简明和完整，但是它也把他们“带向了地狱”。

起初，Sherman绞尽脑汁也无法明白到底哪里出现了问题，为什么看似完美的需求说明书却不能产生与之匹配的应用。他聘请专人花了两个月追踪每条需求相对应的说明，后来发现有30%的需求都不能找到与之相对应的程序。在Sherman看来，失败的原因应该归咎于项目成员过于依赖对文档的比较记忆，“编写者将看似相同的类型通过复制来编写，以降低代码的复杂性”。Sherman和其他人回顾了整个说明书，它至少在表面看起来好像完全与需求对应，但实际上并非如此。Sherman最后得出了结论——他们使用的管理工具不能将交付使用的产品和业务流程连接起来，微妙的差别导致了项目失败。

Sherman决定用自己的方式和一些工具建立一个系统。他的假设很简单——代码可追溯，他期望通过一小片代码能很快地追溯到它的开发过程、直至需求，然后回溯到每个受影响的业务流程，使之更好地测试其对业务流程的影响，并找到该功能的使用者。

IT部门的努力没有白费，经过5年，他们对业务流程有了相当全面的了解。在开发复杂的制药项目生命周期管理工具中，Sherman开发的程序仅花费了1/4的费用，却比外界的开发少了10%的缺陷。

“如果你能真正深入到工作流程中，就会发现各个角色之间的联系，这样就很容易在最后期限之前完成工作，或者在发现没人买账后迅速停止这个项目。” Sherman说。

“今天，生存需要改变比赛规则——IT也是如此。” Sherman说。错误的理解会导致可怕的后果，“如果你还没有重建规则，” Sherman警告同行，“你的工作会被搅得一团糟。”