自从90年代中期为澳大利亚的一家百货公司建立了第一个网站销售系统后，很明确地理解到信息化系统的建设需要利用科技为企业带来投资的效益和价值。与自动化系统建设的利用科技提升运营效益的20多年传统系统开发模型和方法有很大的差异。自动化系统建设是基于一套已经相当成熟的业务流程来分析系统功能需求，但大部份信息化系统建设的起始阶段缺乏这样一套完整的业务操作流程，同时信息化系统的范围必须在理解如何实现项目投资最终目标的有关业务流程建立后才能够把项目的范围建立起来，然后才能够分析项目范围的业务流程中所需的系统功能需求(参考“降低软件开发过程变动依赖项目范围管理”一文)。但要建立一个未来系统的业务流程，必须对有关行业的运营模式相当熟悉，或者有一个对这行业相当熟悉的专家(如行业业务分析师)协助下才能够建立一套可操作的业务流程，同时更需要对企业的管理思维有一定的理解，才能够明确信息化系统的应用价值。但在正常系统开发环境中，往往没有足够的时间容许我们去探讨，分析和建设有关的业务流程，然后才建立项目范围，才能够对有关项目进行合理规划，估算项目成本和资源。那么我们该如何为信息化系统建设项目合理地把握项目的范围呢?这个问题一直让我思考了数年，到90年代末期才开始有一个模糊的构思。

任何项目的最终交付都必须符合项目的投资目的，客户对项目的投资是否能够达到预期的目标是依据项目的最终交付物能否满足投资的期盼，无论是自动化时代的效率改善或信息化时代的信息价值，最终交付物所包含的功能是否全面代表项目最终交付本身的质量优劣。要降低开发过程的修改和变动，我们必须建立明确的项目范围，清楚分析范围中所需要执行及处理的事情，然后才能够整理出系统的功能需求，设计科技的应有方法，最终交付能够演示出如何满足投资者的投资目标，才能够完成项目的交付。

智能身份证系统建设的经验

在90年代中后期，我们需要回应亚洲某一国政府准备建设一套智能身份证系统的项目投标邀请。标书要求一套整体解决方案，内容相当详细地说明整个项目所影响的有关部门和项目的最终目的，很明确地说明这套系统的智能卡除了取代传统的国民身份证外，更可以取代驾驶执照，也可以作为邻近国家所接受的旅游证件，更可以代替金融卡用来支付小额费用，如停车费，公交车费等。当时我们的最大挑战是如何能够提供一套合适的硬件配置和网络架构合理地分置于该国各省、市的负责单位中应用，而硬件的整体配置和网络架构的需求也直接影响软件架构的设计，更直接影响未来扩容需求，系统建设和维护的投资成本。

有关国民身份证和驾驶执照的发行和应用已经有一套基本业务流程，但是利用智能卡取代后，某些操作流程将会带来局部调整。那些操作需要进行调整，那些可以保留，是我们需要推论科技的应用能够提升效率外，还能够带来那些价值进行假设性的评估。但作为旅游证件和代替金融卡这两方面是全新的业务模式，这些概念性目标如何能够融合到这套系统中，如何评估这套系统的工作量，需要那些硬件和网络配置，让我们对这份标书的回应缺乏应有的信心。

最后我们同意组合一个十多人的业务分析团队对各种应用方法建立了全面的应用流程，结合该国的人口分布和各应用目标的未来操作流程，总结出一套比较合理的硬件配置和软件架构，让我们在标书回应内容中能够明确说明这套系统将来如何可以满足项目的最终应用要求，对操作流程的前提条件和任何假设透过SOW来说明整个项目的范围和整个项目的最终交付物，让我们的报价远远低于其它竞争对手，轻松地赢取这份合同，并且在完成交付后能够为单位带来合理的利润。

这个项目让我更深入地体会到项目范围、范围中各种操作流程和最终交付物定义在项目初期的重要性。如果我们按照传统的回应方法，依据标书所提供的整体数据进行硬件配置和软件架构推论，我们最后建议的解决方案一定会浪费很多地方上的硬件资源，而且软件和网络的设计会对系统的应用产生操作瓶颈，降低系统的效率，提高初期的投资成本。

其它信息化项目建设经验

在2000年负责加拿大一家金融机构的零售业务部门建立一套客户关系管理系统，当时这个项目的基本要求很简单，也很明确，高层管理人员希望这套系统能够提供以下的应用价值：

1. 客户综合帐户信息管理

2. 分析客户开支模式

3. 提升客户全面财务管理效益

4. 建立正式及非正式的客户沟通渠道

5. 提供银行发展新业务的机遇

6. 开展客户所需的金融服务

7. 建立客户对银行的满意度及忠诚度

除了第一及第二两个目标及一部份第四个目标可以直接利用科技达到目的之外，其它目标如何才能够实现?整个项目交付的内容是什么?范围在那里?

要把这个项目完成最后交付，单依靠技术人员的思维明显不够。所以我们组合了一个工作小组，其中包括金融零售业务的分行负责人，数名老客户，及业务分析师。依据每一个项目的交付目标进行头脑风暴，利用WBS的方法一步一步进行分析，从老客户的那里我们开始知道他们希望银行提供那些服务才能够让他们感觉满意，才能够让他们不会考虑去其它银行储存或处理资产;从业务负责人那里理解他们如何能够透过那些信息找寻商机，开展新业务或强化服务以满足客户的要求，从其它财务管理或投资管理的负责人那里知道如何才能够让客户的储存和资产能够带来更大的回报，从这个过程中我们最终找出项目的交付物定义，并获得管理层的确认。整个过程建立了项目组件分拆的初步模型，当时称为项目结构分解(Project Breakdown Structure， PBS)，把项目的每一个目标分解为交付的模块，让我们能够按照模块的组合提供整体解决方案。经过这些年的应用及改善，最后成为今天所描述的项目组件分拆法(Project Component Decomposition Method, PCDM)。今天的高级软件技术人员必须放弃过去单纯的科技应用方法，必须改变思维，考虑如何能够利用科技的应用带来任何价值或效益，才能够把握信息化时代的软件要求。

项目组件分拆法(PCDM)

项目组件分拆法的主要目的是把项目分拆成主要的模块或组件，这些模块或组件在完成整合后将成为整个项目的最终交付。透过PCDM的应用，可以在最短的时间内建立项目的最终交付定义。对于一些概念型项目，在项目起动阶段把握项目的最终交付，能够更有效地建立项目的范围，规范地管理开发过程中所要求的变动。

任何项目都有一定的投资目标，这些目标也一定会为项目完成后能够为项目赞助人带来预期的信息价值或预期的应用效益，否则项目赞助人没有必要对项目进行投资(当然一些政治性项目除外)。所谓最终交付物是依据项目立项时有关项目赞助人或投资人对项目的未来效益或项目在完成后所能提供的信息价值所需要的软件模块或组件。概念型项目往往有相当明确的价值期盼，但缺乏一套明确的操作过程让技术人员进行有效的分析，建立系统的功能需求。

第一个层次的目标说明需要项目投资者或项目赞助人的参与和确认，需要项目经理去理解项目的投资目标(参考上述客户关系管理系统建设的七大应用价值)，第二及第三层次的分拆工作需要组合一个小组进行头脑风暴会或研讨会方式，项目经理负责指导及协调，小组成员包括系统分析员，系统设计师，业务分析员(可选)及主要项目干系人(未来应用系统部门负责人)共同建立有关“如何做说明(实现方法及手段)”和“做什么说明(解决方案)”。最后是项目经理，系统分析员及系统设计师共同整合有关解决方案，成为项目的交付说明或交付物定义。每一层的分拆成果必须获得小组成员的共识和确认才能够开展下一层的分拆工作。

为了让读者能够更清楚有关项目组件分拆法的应用，在这里特别利用一个案例为大家示范说明：

案例：度假休闲活动管理系统建设

• 一家临近沿海旅游景点的度假酒店希望能够推出一些比较有特色的休闲活动。希望利用现有计算机对这些特色休闲活动进行有效管理。
• 这套系统需要能够提供以下的功能：
  – 建立活动的细则，目前计划推出三种活动，但未来可能增加或删除活动种类：
• 海底世界：每位三百元，每次两小时，在海边附近珊瑚区进行潜水活动，体现漂亮的海底景色。更可以选择深水探险(每位五百元，历时五小时)，到较深的海底观赏沈船的遗迹，但需要旅游者曾经接受过潜水训练，有关经验或训练信息必须确认及记录在档案中。
• 非洲探险：每位四百元，包括午餐，参观邻近的郊野开放动物园，观赏动物在自然环境下的生活状态。参加者必须被告知这个活动需要在早上七时出发，下午四点三十分回到酒店。
• 越野单车：在附近越野单车径体现越野单车的挑战。每位两百元，每次三小时，不包括越野单车租金。租用越野单车另加一百五十元。参加者必须在报名时说明是否需要租用越野单车(16岁以下不能参加)。
• 活动报名：记录报名者参加那个活动，那天参加，参加人数，姓名，预付金等信息
• 储存有关活动信息，并随时可以对活动进行查询
• 提供简单财务管理，说明各团参加人数，总金额，预付金，印发收据等操作能力
• 由于酒店负责人常出差，所以需要把一些表单转换成网页，让负责人可以透过手机对有关信息进行查阅，把有关活动及财务信息转移或传送到负责人的智能手机上。
• 建设一套简单的应用软件，利用目前酒店的计算机设备，

案例初步分析：项目说明

一些技术人员可能会把上述的内容作为系统的功能需求，而且相当清晰，可以马上进入设计及编程的状态。但我们如何能够知道以上的功能是否全面?如何把握其余的功能需求?如何避免在开发过程中拒绝客户的变动要求呢?项目的范围是什么?我们一无所知。

另一些技术人员可能会认为上述内容便是项目范围，如果是项目范围，我们是否知道范围中各种工作的操作流程，然后进行分析，建立有关的功能需求呢?要知道这些活动只是度假酒店计划未来的新增业务，缺乏一套完善的操作流程，希望透过系统建设为管理这些活动提供一套可选的运营流程，那么我们该先为客户建设一套流程，还是先建立一套系统，在考虑如何融合到运营的过程中呢?

任何客户提供的初步内容只是项目信息的一部份，是客户对未来系统的期盼(参考图一：项目组件分拆发结构)。有关内容是对系统未来质量的基本要求。在进入设计或编程前，我们先要建立这个项目的范围，明确我们需要提供的服务，才能够为客户提供高质的专业服务，才能够在开发过程中降低变动的需求，降低项目失败的风险。

第一层：目标说明(Purpose Statements, PS)

项目经理必须与项目赞助人或指派代表人共同研讨项目的最终价值，所谓最终价值可以透过项目背景进行分析，理解为什么要实现这个项目，实现这个项目的最终目的是什么。

每一个目标是一个独立的目标说明，有别于项目的需求说明，我们探讨的不是系统需要做什么，是系统需要提供那些价值和效益，这方面包括为企业提供额外的竞争能力，提升效率，改善工作及服务质量，简化服务流程，整合分散资源，和其它对企业运营带来价值或效益的目标。当我们对项目的最终目标有了认识后，项目将依据这些目标进行个别分拆，最终的交付应该可以为每一个目标说明提供所需的模块和组件，成为项目的范围。如果是项目赞助人指派的代理人与项目经理共同建立的目标说明，那么这份目标说明便需要项目赞助人进行内容确认。赞助人不一定需要对有关目标说明进行签字确认，可以透过其它方式让项目赞助人认同这些目标的内容，让我们可以依据这些目标说明完成项目范围的建设。

案例研究：目标说明(Purpose Statements, PS)

第一层的分拆是透过与项目赞助人共同协商，确认项目的预期效益和投资价值。一些目标可能只是一个愿景，或对系统的一些期盼，或提供企业额外竞争能力。最后整理出以下七点项目的目标说明：

1. 提供各旅游团基本信息及各旅游团对参加人员的基本要求/条件

2. 加强各旅游团的报名管理能力

3. 提升前台服务员的工作能力，避免报名时提供消费者错误信息而导致意外事故

4. 提供旅游团的基本财务信息

5. 提供管理层PDA/SP浏览各旅游团报名人数及有关各团的财务信息

6. 希望吸引更多外地旅客到酒店度假

7. 更希望吸引其它到当地度假的旅客参加。

案例分析：目标说明的合理性

以上七点项目目标是项目赞助人愿意投资这套应用软件的投资目的。在我们接受项目赞助人所认同的目标说明前，我们必须对客户所提供的项目信息进行比对，看看项目资助人的期盼与项目信息是否吻合。我们可以透过一个简单的对比表进行差异分析(Gap Analysis)，可以更清楚两者间是否存在差异。

表格 1：项目信息与目标说明差异分析比对表

从差异分析比对表中可以很清楚地看到，项目说明中并没有提供任何信息可以比对项目赞助人所提出第6和第7这两点的目标说明。同时整个项目组件分拆法是基于目标说明进行分拆，同时更是项目赞助人决定对项目进行投资的原动力。

我们当然要相信目标说明，但既然项目说明中并没有提出这两点的要求，我们如何判断第6及第7这两点是否应该包含在项目中。如果我们不考虑这两点，我们将不能够顺畅地完成项目验收，但包含这两点，我们便需要理解如何融合到项目信息中。

对有关差异进行一个简单的可行分析(Feasible Analysis)让我们可以考虑科技的应用能否为这两点带来任何价值，这两点与应用系统的关系在那里?科技能否实现这两点目标说明的价值和效益呢?透过“一点不多做、一点不少交”的思维，我们是否能够说服项目赞助人把这两点排除在项目范围外另行处理呢?

最后我们说服项目赞助人可以透过印刷和在各地代理分派有关度假活动的宣传单张来吸引更多客源，同时可以在当地用不同的方式进行推广，成功地从目标说明中排除了第6及第7点。我们接下来的工作便集中在余下的五点目标说明中。开始组合有关小组进行第二层及第三层的组件分拆。

第二层：如何做说明(How-to Statements, HS)

所谓如何做的概念是“如何才能够做到这个目标说明的预期价值或效益。在开始第二层组件分拆的时候，项目经理必须组合以下资源进行头脑风暴会或研讨会：

1. 高级系统分析员或资深软件工程师

2. 项目主要干系人

3. 系统设计师(可选)

4. 业务分析员(可选)

项目经理将依据已经确认的目标说明进行独立分拆，让每一个参会人员能够发表个人对有关目标说明的想法及提出“如何做”的构思，一个目标说明可以分拆成一个或多个方法或手段，同时一个方法或一个手段可以处理一个或多个目标说明。在完成这部分的研讨后，我们可以明确知道如何才能满足项目的各项目标说明。

在过程中我们可能需要分析及否缺一些不合理的方法或手段，如何判断那些方法或手段是不合理，取决与这个方法或手段是否能够为有关目标说明带来相关的价值和效益。

案例示范：如何做说明(HS)

透过小组的整体思维，最后从目标说明(PS)的项目科技应用价值中分拆出实现的方法和手段，这些方法和手段分别成为独立的“如何做说明(HS)”。

图表 2：目标说明(PS)分拆成如何做说明(HS)中各种实现方法或手段

第三层：做什么说明(do-What Statements, WS)

在完成第二层研讨后，项目经理需要引导同一个小组对每一个“如何做说明”进行第三层的分拆，找寻我们要“做什么”才能够满足每一个“如何做”明的方法或手段。做什么的结论将成为项目解决方案的基础。

做什么说明不一定局限于技术上能够解决“如何做说明”的要求，它也可以包括业务流程改变，操作人员的培训或岗位的变动，也可能是需要搜猎一些特别人才，或进行采购，或进行外包等方案。小组在最后同样需要分析及评估每一个方案对项目的目标说明能否带来预期的价值或效益。同时也可能否缺一些方案以降低项目的成本和缩短项目生命周期。

案例示范：做什么说明(WS)

通过分拆如何做说明(HS)，小组针对每一个方法或手段进行思考，整理出一套较为完整的解决方案，成为项目组件分拆过程中的“做什么说明(WS)。

图表 3：如何做说明(HS)分拆成做什么说明(WS)的各个解决方案

第四层：交付说明(Deliverable Statements, DS)

在小组完成解决方案的分拆和一直认同该“做什么”后，接下来便需要系统设计师对有关解决方案进行组合成为项目的独立组件，在整合的过程中可以同时建立组件的宏观逻辑，成为项目最终的交付说明(DS)，这个交付说明让我们很清晰地体系整个项目的内容，成为软件开发的项目范围。

在进行交付整合的过程中，系统设计师需要考虑每一个项目组件是否影响到项目的开发时间，交付成本及是否符合项目信息中所涉及的质量要求。

案例示范：交付说明(DS)

图表 4：做什么说明(WS)分拆成交付说明(DS)中的项目组件

案例分析：交付组件的合理性

在整合项目最终交付的过程中，发觉要完成第5点的目标说明(提供手机浏览活动及财务信息功能)，会增加大量的投资成本，同时增加客户的数据转移及维护需求，更增加手机数据流量的费用，建议客户透过语音查询，拨号会酒店进行有关信息查询。最后被客户接受，减少一个模块的建设。

项目组件分拆法(PCDM)的应用效益

项目组件分拆法可以让我们利用最短的时间建立项目的范围和宏观的系统逻辑，更能够让项目赞助人和项目干系人参与系统建设的过程中，让项目赞助人及项目干系人更明确知道系统完成后他们将面对的应用如何及主要操作逻辑，强化软件开发的透明度，把项目的范围紧紧地构建起来，降低开发过程中的变动要求。

最重要的一点是让技术人员回归软件开发的正确路线，先建立项目范围，然后透过分析推论出项目的基本功能需求。透过项目干系人的参与，可以更深入理解行业的特色，提升技术人员的创思，带出软件创新的成果。

在余下的数篇文章中，我会针对目前软件开发的一些瓶颈进行分析和建议，让我国软件工业能够进入一个高效，创新的开发模型。