需求就是这样膨胀的

需求就是这样膨胀的

企业信息化应用的需求是巨大的。然而，一些号称适合企业需求的所谓“商品化软件”，与企业环境、业务模式、管理流程有一定的差距，使得“现成的解决方案”总是“好看不好吃”；另一方面，一旦企业决定自己开发信息系统，或者委托开发信息系统，就走上了一条危险而又痛苦的漫漫长路。杭州的吴先生，在与叶知秋的电话交谈中，讲了这样一件既司空见惯、又引人深思的事情。

“鸡肋”难题

S公司是一家国有企业改制后的中型企业，在信息化领域已经有较长时间的积累，这全仗着过去隶属于部委管辖时，大力推进计算机应用所得的好处。

但是，这些过去由上级主管部门“灌”下来的计划、财务、人事、统计等等单项应用系统，逐渐成了公司决策层的“鸡肋”：标准不一、体系不同。扔掉吧，一时还找不到替换的系统，这些系统已经在企业中用了好多年了；不淘汰吧，又很难实现信息共享，无法适应越来越复杂的管理要求。
再三研究之后，S公司董事会决定彻底改造和重建企业的信息系统，以“流程驱动、数据集中、信息共享、实时控制”为目标，建立基于内部网平台的企业信息系统。

考虑到公司计算机应用的延续性和后续服务的因素，S公司没有采取把项目完全外包的方式，而是以与某软件公司合作的模式进行项目开发。联合项目组很快就成立了，合作方派出了曾在日本做过软件开发的一位资深系统分析员领衔，S公司则由信息中心主任带队，信息中心全员参加项目的开发。

项目第一阶段的重点是需求调研。由于这个项目并非从零开始，所以调研方向实际上是两个：一个是业务需求、用户需求、功能需求和系统需求；另一个则是摸清现有应用软件的状况，因为毕竟已经有大量的数据放到了现有的数据库里。

对业务部门和职能管理部门来说，有了几年的计算机应用经验，他们对计算机多少有了一些认识，所以对这次项目开发表现了高昂的热情。但是，正是这种“高昂的热情”，使得项目组一度陷入了错综复杂的“需求旋涡”之中 。

需求旋涡

计划统计部过去一直采用自己开发的管理软件，基本实现了计划编制、汇总、滚动计划更新和经营指标统计的功能，现在一部分手工作业就是在计算机上完成的。公司新成立的市场经营部，对计划功能提出了进一步的要求，比如增加动态计划调整功能，变更某些统计指标的口径，增减一些指标项目等等，计划统计部很难接受这样的说法。一位搞了十几年计划统计工作的老科员说，“我们历来是企业的龙头部门，企业经济效益考核什么，效益怎样，就得从我们的数据中看出来，怎么能轻易变来变去的？”

不过，计划统计部倒是要求项目组考虑把经营部的指标体系借机建立起来，“以后可以实现网上数据传送，我们也没必要跟着屁股催了。”

相比较这两个部门而言，财务部、人力资源部（这是从人事劳资部门重组而来）和生产部面临的问题更多。成本核算和资产管理一直是财务部十分头疼的问题。成本属性不清晰，资产帐目无法反映资产动态变更，财务数据无法准确体现“经营状况晴雨表”的作用，而且报表不全、数据不准。

凡此种种，在1个月的调研时间里，一下子都冒了出来，让项目组一时应接不暇。

这些相互缠绕在一起的业务需求，夹杂着对过去使用的软件系统的抱怨，比如“需要增加分页打印功能”、“增加工作单统计的汇总单位”、“需要班组明细表”、“加强固定资产台帐的管理功能”等等。

对此，合作方建议按照规范的需求管理要求，把这些要求、希望梳理清楚之后，变成准确的、规范的文本，交由各部门一一确认。合作方认为，并非所有的客户表述都可以称之为“项目需求”，这需要深入细致的定义、分析、沟通，也需要大量的协调。

“但是，不知是什么原因，后来并没有按合作方的建议做”，吴先生在电话中带着惋惜的口气说。

可以预见的失败

吴先生认为，像这样“草率开局”的项目，在国内很多企业并不少见。一些企业有自己的计算机队伍，但缺少真正训练有素的系统分析人才，更缺乏必要的方法论指导。

也许正是因为这些人熟悉企业，他们才被视为信息系统开发中“具有相当优势”的一支力量。事实上，很多企业，特别是国有企业的计算机项目就是这支队伍承当的。

但是，这支队伍的一个突出弱势则是：缺少真正“市场化运作”的机制，使得他们很容易对企业计算机应用的需求膨胀采取“听之任之”的态度，因为“信息中心也无非是企业中的一个职能部门”，一位在国企做了近10年信息中心主任的人这样说，“他们不可能实施正规的‘软件工程项目管理’的原因很简单，这里没有合同的概念。”

于是，这些企业中一个常见的现象就是，膨胀需求和重复建设的恶性循环。每次巨大的投入，都可能解决一些问题，但“获得的回报比预期的要小得多”，这位信息中心主任坦率地承认。

管理需求从文档化开始

施乐软件服务公司是设立在新加坡的一家专门为施乐公司提供服务的软件企业。2002年9月6日,该公司的CMM主任评估师Rayney Wong应邀在第五届中关村电脑节上，做了题为《中国软件过程改进的意义》的演讲。

Wong先生在深受欢迎的演讲中说，“现今我们在软件开发过程中所遇到的问题，有些不是技术方面的，而是生产力和项目管理方面存在的问题。在许多情况下软件工程师的工作效率不高，并不是因为他们没有能力完成工作，而是因为项目协调工作和工作流程管理没有做好。”

软件的需求，在很多场合下被误解为“客户表达出来的某种希望、要求”等等，应该说，这些“希望”、“要求”中可能包含许多“需求”的成分，但并非软件工程中所说的“需求”。

换句话说，那种口语化的、不规范的、定义模糊的、白描式的“需求表述”，仅仅是需求分析的“素材”和“底料”，软件工程意义上的“需求”，则有赖于严格的定义、规范的表述和逻辑的分析。这里其实是一个“正确的过程”与“正确的产品”之间辨证关系的概念。

没有“正确的过程”，就不可能有“正确的产品”，这已经是软件管理中的共识，也是软件项目失败的惨痛根源。

在需求管理这个阶段，除了对一致性、完整性、无歧义的要求之外，还有一个非常基本的要求，那就是“把需求的表述转换成规范的文档”。

文档化，这项似乎很不起眼的工作，正是衡量项目需求管理是否到位的试金石。试想，一个缺乏需求文档的项目组，如何能够确保关于需求的种种想法是“基于用户和开发者的共识”？如何能确保项目组成员之间、项目组和用户之间的良好沟通？如何确保“我们正在做用户希望我们做的事情”？又如何保证项目最终的成功？

把需求变成文档，是一件做一次很容易，但坚持做就很难的事情。

本文原载于中国计算机用户