| |
| 项目范围与需求 |
|
[ 2007/11/21 10:52:00 | By: pbs ] |
项目范围与需求
－黄绍良教授
项目范围与项目需求是两个完全不同的内容,但两者却不能单独处理。让我们回到上世纪70年代的时候，国外企业正进行自动化的过程。项目基本上是把人工作业流程转变成计算机程序。那时候并没有项目范围这个名称，我们用“Terms of Reference (ToR)”来界定项目的周边，采用文字描述的方法说明这个项目要做什么。例如要为企业建立一个“库存管理系统”，这个项目的ToR会说明货品从进入仓库开始，到货品因应生产或销售申领要求离开仓库为止，其中包括货品存入量的统计，存放位置记录，总库存量统计，申领数目，检货，提取货品，准备出仓，最后货品统计等内容。这个项目的Term of Reference只说明这个项目“库存管理系统”的范围，包括一些需要执行的工作，记录等。
在项目实施过程中，系统分析员会对库存管理全过程进行调查，采用访谈或观察等方法，记录上述范围中的整个工序的过程，每一个数据的更新，参考记录数据的报告格式和任何有关的工作单据。这些工序，数据更新，报告打印等工作最后便成为系统的功能需求。
到上世纪80年代中后期，国外企业的自动化过程已经接近尾声，企业开始整合部门的计算机系统，加上个人电脑开始取代终端，项目多包括跨部门或跨地区的系统集成，数据库应用，远程计算（Remote Access），网络连接等为项目主体。在这种情况下，传统的ToR已经不能够明确说明项目属于那个部门，从那里开始，如何才是项目完结。ToR已经不能够有效地界定项目的范围，所以我们利用多个描述来说明，成为我们今天所认识的项目范围（Project Scope）。开始的时候采用段落说明项目中所需提交的各种不同的工作，但往往文字的描述容易产生误解，最后才把段落描述的方式转变成简单的Statement of Works （SOW）,利用明确的语句来说明项目中包含的每一个工作内容。例如在一个Project Scope中包括的一个SOW是:“连接A市及B市两地办公室的主机，通过A市数据中心的中央货品库存数据库，为A市工场和B市销售中心提供即时货品存量查询及货品预订功能”。这个SOW便成为这个工程其中一个需要提交的成果。利用Project Scope 中的SOW替代ToR，一个项目可以容许多个SOW来描述系统建设的内容，所有的SOW描述的建设内容都包含在这个项目的范围中。但实际上每一个SOW的结果如何实现，还是需要技术人员透过调查和进行分析后才能够清楚具体的操作该如何实现。每一个SOW的具体操作过程都成为这个SOW的功能需求。整合全部SOW的个别操作过程，才是项目的功能需求。
简明的说，每一个SOW都是一个小范围，它本身也不是一个需求。我们还是需要透过理解SOW的内容才能够把握这个SOW的需求。从上述的历程中可以看到，用户或客户告诉我们的永远都不是需求，是客户或用户希望在最后交付物中看到的部分成果，永远不会完整，只是客户或用户的部分期盼、愿景。如果把这些期盼和愿景当作了需求，那么我们永远不能满足用户对交付物的期盼。需求从来不是用户或客户提供，需求是技术人员依据范围中需要实施的工作过程进行分析后寻找出来可以提交项目最终交付物的结果，然后才能够把这些需求转变成一个软件工程，在项目指定的范围中利用科技达到用户的最终目的。
近二十年的项目多包含很多SOW，要能够把握每一个SOW的具体操作过程并不容易，不小心便常遗漏一些操作细节，导致后期的范围变动。今天我们面对的项目更为复杂，而且往往是从一个概念开始，如何实现用户的愿景，更需要我们这些技术人员与用户共同寻找实现的过程，才能够把握有关的需求，才能够利用科技让用户获取期盼的项目最终交付物。很多项目的重点已经不是科技的应用，而是科技应用所带出来的价值。今天的项目主要是支撑业务的发展，辅助市场的开拓，创新的科研成果等最终目标。SOW提供我们一个工作的框架，让我们进行信息搜集、分析后组合成业务流、数据流。建设出具体的操作过程，再转换成这个SOW框架中的功能需求。
自上世纪90年代中期开始，企业从自动化的技术应用过程开始转型到信息化的技术应用价值为最终目标。项目的目标也渐渐地从明确的技术应用过程转变成为虚模的理想或愿景。例如建立一个系统为企业提供业务方向决策，让管理层能够判断产品在市场上那个地域的市场需要进行调整，属于那类消费群，如何开拓一个新市场等，又或者希望利用因特网为企业提供一个电子销售的渠道。这些项目要能够把握系统的功能需求相当困难，而且在实施过程中采用不同的科技应用方法也会带出不同的项目交付物。所以透过功能需求的把握也不一定能够提交客户期盼的最终交付，让项目的建设过程不断变动，不断受到延误。
客户对项目的验收是依据我们的最终交付物，那么在项目启动时能够把有关的最终交付明确下来，是否能够降低项目失败的比例呢？过去10年我对项目的交付多采用这种方式，利用客户提供的期盼和愿景作为建立项目最终交付的基础。在明确用户的愿景最终目的后，透过科技的应用来整合这个项目最终交付。至于工程中的功能需求，采用调研，分析和设计的过程作出结论，成为项目质量管理计划中的部分内容。利用这个初期制定的最终交付作为项目范围，大部份项目多能够完成最终交付，顺利进行验收，而且可以达到“一点不多做，一点不少交”的目标。
|
| 发表评论：
| |
|
