精品减低开发过程中的变动依赖项目范围管理

1、减低开发过程中的变动依赖项目范围管理作者：黄绍良 来源：希赛网摘要：在上世纪70年代后期，系统分析师、系统设计师，和其他从事软件工程 的专业人员一直争取希望能够有一个国际公认的资格，类似会计师、律师、建筑师等专业的地位，但到了 80年代中期，这个议题已经不再存在，主要的原因是 软件工程内包含太多专业，除了软件和硬件两大类之外，还渐渐包括网络，通信， 数据库等多方面。个人收集整理勿做商业用途在上世纪70年代后期，系统分析师、系统设计师，和其他从事软件工程的专业 人员一直争取希望能够有一个国际公认的资格，类似会计师、律师、建筑师等专业的地位，但到了 80年代中期，这个议题已经不再存在，主要的原因是

2、软件工 程内包含太多专业，除了软件和硬件两大类之外，还渐渐包括网络，通信，数据 库等多方面。计算机从业人员开始体会及认识到本身的工作与会计师、律师、建筑师等专业资格可以在考核及认证后授予一定的权责，和建立一套环球衡量标准的模式是不一样的。其实软件工程比较像艺术家，大部份的软件是模仿别人的成 果加以个别的应用需求进行个性化的结果，把思维转变成交付成果的一门专业。个人收集整理勿做商业用途过去数年常听到一些软件从业人员的投诉包括：“他们（客户）基本上不知道自己的需求，怎么做他们都不满意，功能不断增加，如何能够完成他们的系统建 设？” “他们（客户）上周说要这个功能，今天说要这个功能，为什么不全告诉

3、我们，让我们可以不用在开发过程中不断更改！ ”一些类似的投诉只说明我们的 软件从业人员基本上没有明白到范围建设的重要性， 而且未能在项目启动前把项 目范围建立起来。 个人收集整理 勿做商业用途范围与功能的分别在“如何把握不存在的需求” 一文中，已经说明范围是有效管理需求变更的唯一 方法。有明确的项目范围，我们才能够学习及分析范围内的作业流程，建立系统的功能需求，并在开发过程中当客户要求变动的时候有效管理我们的工作范围， 才能够有机会按照预算在指定的时间内完成项目的交付。个人收集整理勿做商业用途软件开发项目从开始到今天，一直以来客户都不能够告诉我们需要哪些功能， 他 们只能告诉我们系统需要完成哪

4、些目标。回顾“如何把握不存在的需求” 一文中的第一个例子，20世纪70年代的客户需要把库存管理进行自动化，收到的指 示会像下例：“建立一套库存管理系统取代目前的人工作业流程”。这一句指示是 唯一任务说明。系统分析员在接受这个任务后第一个工作是建立项目的Term ofReferenee （ ToR）。系统分析员会进行初步调查，通过简单的访谈，与库存部 门负责人明确理解他们工作的开始点和终结点，得出的结果可能像下例：“从货品（包括原材料，半成品及制成品）进入仓库开始，到货品因应生产或销售申领 要求离开仓库为止，其中包括货品存入量的统计，存放位置记录，总库存量统计， 申领数目，检货，提取货品，准备出

5、仓，最后更新货品存量统计等工作过程”。这是所谓的Term of Referenee，也是我们今天所认识的项目范围。个人收集整理勿做商业用途在用户及管理层认同上述的 ToR后，这个项目的负责人便需要估计需要对多少 人进行访谈，需要多久时间进行访谈，需要多少时间对访谈结果进行分析， 多少 时间建立项目需求，编写需求说明书，需要多久进行系统设计，多少程序员及多 少时间进行程序编写，如何进行测试，编写系统文档，编写用户手册，什么时候 在仓库安装终端，如何连接主机，什么时候进行用户培训，如何让系统取代目前 的人工作业等等有关工作计划及时间表。个人收集整理勿做商业用途在系统分析员完成访谈后，便需要依据访谈

6、结果进行分析，理解什么时候知道有 货品进入仓库，什么时候更新有关数据，如何更新，采用哪些表单，仓库人员如 何决定货品应该存放在哪里，如何记录有关信息，如何知道需要检货，什么时候 进行数据更新，如何分别哪些货品要去生产部门或者直接送到客户指定地点等等 信息。这些信息便成为系统在不同过程中所需的功能需求。个人收集整理勿做商业用途从上述的开发过程说明中可以体现功能需求并不是客户或用户提供，是系统分析员在理解目前的人工作业后分析出来的结果。个人收集整理勿做商业用途在系统移交到仓库中运行前，仓库中的工作人员需要对系统的操作进行学习及测 试。要知道当时仓库的工作人员并不是针对系统的功能进行测试，是对系统能

7、否满足他们的工作过程进行测试。基于这批工作人员对人于工作业的过程十分理 解，如果系统未能提供一些他们操作过程中的日常工作，他们会要求技术人员对系统进行修改。这个过程让我们误会用户是对功能需求进行测试，这个误会一直到今天让我们把系统开发的焦点错误地放在功能上，而不是系统的最终交付上。而系统的最终交付是否能够满足 ToR的要求是当时项目成败的主要指标。 个人收集整理勿做商业用途系统集成的范围及需求20世纪70年代的项目多以部门单独运营为主，自动化的目的是提升部门本身 的运营效率进行系统建设。到80年代，企业高层开始体会企业中的数据分散在 不同的部门或子公司的部门中。哪些数据是最新的？哪些是最准确的

8、？应该采用 哪个部门的数据做决定呢？如何整合这些数据，如何获得即时的数据，如何利用当时的区际网络(AreaNetwork )，客户/服务端(Client/Server )，遥程存 取(Remote - Access )数据库(Data Base )等科技来更有效提升企业的运 营效率呢？这些问题提供软件开发项目进行系统集成及数据分享的工作，最终的目的还是环绕原来自动化提升企业 (不单是70年代提升部门)的整体运营效率 为主要目标。 个人收集整理 勿做商业用途这个时候，简单的ToR已经不能够说明项目的范围，但可以采用多个ToR来加以说明。工作说明(Statement of Work)在这个时候诞生

9、，开始取代 ToR成为项目范围的主要工具。一个项目可能有多个Statement of Work(SOW )才能够有效说明项目包含的范围。例如要建立一个订单管理系统(OrderProcessing System ) ”的时候，这个系统可能包括销售部门，库存管理部门， 会计部门，运输部门，生产部门等，这些部门也可能分布在不同的地区。个人收集整理勿做商业用途项目负责人首要是建立这个 订单管理系统”的范围，保证能够提供订单管理的的 全部工作，所以会首先进行初步调查，理解一张订单从不同业务点如何把订单传 送回销售部门，销售部门如何把订单信息转进仓库，如何结合现有库存管理系统， 如何通知会计部门有关销售，

10、如何通知运输部门需要送货，或者如何通知生产部 门需要进行生产等内容。在与个别部门负责人完成初步访谈后会，理解订单在各 个部门的进入点和输出点后才建立这个项目的工作说明(SOWs )如下：个人收集整理勿做商业用途SOW - 1 :连接业务点各终端到销售系统，建立当天的销售记录。SOW - 2 :连接销售系统与库存管理系统，容许销售部门查询仓库管理系统中 有关货品库存量。SOW - 3 :容许销售部门在库存系统中预订货品数量以便运送到客户指定地点。SOW - 4 :容许销售部门指示库存工作人员进行检货，并通知运输部门有关订 单的运送要求。SOW - 5 :在销售部门计算有关订单的总金额，运送费及保

11、险费用，并生成发 票送交客户。SOW - 6 :自动更新仓库货品储存量，如有关货品低于最低数时，建立货品生 产通知单并传送到生产规划部。SOW - 7 :自动通知业务点有关订单发货日期。SOW - 8 :有关发票内容自动转发会计部门，建立有关应收账款记录。SOW并不是我们所说的系统功能，是在项目完结后这个系统所应该提供的最终 目的。以上的SOW 说明了这个项目的范围，包括的有关部门及现有系统的连 接。在客户确认后每一个SOW 将当作一个ToR处理，这个ToR便成为整个 系统建设项目中的一个子项目(也是子项目名称的起源)。如何才知道我们建立 的SOW已经包含整个系统的各个部门，如何保证这个范围能

12、够有效地提供一 套 订单管理”的系统，这需要项目负责人对行业有一定的理解，同时为保证开发过程中能够控制范围的变动，在有关文档中明确说明SOW 所包含或不包含那些工作。利用 包含(Inelusive ) ”和不包含(Exclusive ) ”的说明来牢牢地建 立一个固定项目范围。 个人收集整理 勿做商业用途在项目规划完成后，系统分析师便按照被分派的SOW 采用ToR的调查方式进 行深入调查，对有关工作进行访谈，理解有关 SOW的工作流程后对有关流程 进行分析，并找寻初步的解决方案。如何利用科技取代电话咨询库存量， 利用科 技取代传真把订单从业务部门传送回销售部门， 或取代传真送货通知单到运输部

13、门，取代内部文件传送发票副本到会计部门等等工作，什么时候需要进行数据收集，需要进行数据更新，需要打印发票或其它有关报告等工作便成为项目的功能 需求。个人收集整理勿做商业用途如果在开发过程中，用户认为需要货品在运送完毕后，收货单应该自动确认有关 应收账款的作业流程，或者需要增加万一退货后的订单处理操作流程时， 我们便 可以依据原SOW来控制项目的范围变动，因为这两项操作流程并没有在项目 的SOW中说明。如果用户认为一定需要增加这两个操作流程，那么项目的范 围会变动，带出额外的工作量，额外的开发时间，额外的投资预算，修正系统的 架构，增加软件模块，追加人力资源等等因应的后果。 有能力的项目负责人会

14、尽 量说服客户把有关工作在目前的系统建设完成后才进行处理，避免延误项目的进度和交付 日期。 个人收集整理 勿做商业用途这个系统集成的项目再一次说明如何从项目范围中建立有关功能需求。建立功能需求是软件从业人员的责任，不是客户或用户能够提供的内容。在完成人工操作 过程分析订立系统的功能需求后，更要进一步考虑如何让科技提升企业的运营效 率。也许在设计过程中发现当时的货品运送流程是从仓库直接送到销售部门，再由销售部门安排货品连同发票一起送到客户的指定地点，设计师可能考虑是否可以直接从仓库把货品运送到客户指定地点， 销售部门另外把有关发票直接送交客 户？这个改变会为企业带来多大效率改善？有了确实的构思后

15、便需要说服用户 这个系统如何能够更有效地完成有关货品运送的过程，要说服用户这些功能可以 提升货品运送的效率和客户满意度，让销售部门和运输部门可以体会未来的工作 流程将有所改变。决定最终解决方案及用户认可后依据分析师的建议建立有关系 统的功能，交由系统设计师对有关功能进行模块组合及逻辑设计。到这里，我们可以清楚知道系统建设不是依据客户的需求而建设， 是依据如何达到项目最终目 的和项目的最终交付而建设。需求不是客户或用户提供，是我们作为一个专业人 员依据我们要开发的项目目标（如何达到）和项目的最终交付而制定出来的结果。 没有项目范围，我们便不能建立有关系统的功能。 没有项目范围，我们便不能控 制任

16、务的工作量，不能预估完成日期并按时完成。个人收集整理勿做商业用途从上述两个例子中可以看到，功能需求与业务流程直接相连的，理解了业务流程， 便能够建立有关的功能需求，利用科技完成有关工作，提升运营效率，减低业务 部门有关工作量和工作人员的需求。 个人收集整理勿做商业用途软件工匠和软件工程师 如果我们需要客户提供有关功能或需求才能够完成软件开发，那么我们便沦为软 件工匠。一个工匠，如木匠、泥水匠等都是依据客户的需求去完成任务的技术人 员，这个工匠可以把工艺做到很好，很精，很细腻，成为一个很优秀的木工或泥 水工，但永远不会成为大师，因为他们没有创思，没有沟通能力去说服客户如何 能够更有效地达到客户的

17、投资目的。 个人收集整理勿做商业用途希赛顾问团首席顾问张友生博士认为，一个专业的技术人员需要理解本身的专业 能力，理解客户投资的最终目的，理解如何更有效地达到客户的最终目标而建议 客户应该如何进行建设或改良，才有可能成为这个行业的大师。目前我国充斥着 很多软件工匠，如果我们要把自己打造成为一个软件工程师，我们便需要放弃以前的思维，不用老是抱怨 客户不明确本身的需求，所以我们不能够完成项目的 交付”我们需要思考如何才能够把握项目的最终目标，建立系统的功能需求。个人收集整理勿做商业用途从20世纪90年代中期开始，计算机在企业中已经从自动化的时代进入信息化 的时代，从科技的应用提升企业的运营效率，转

18、变成科技应用所能带出来的价值, 让企业能够减低运营成本，改善产品，提供增值服务，开拓市场，增加利润等成 为软件开发的主要目标。个人收集整理勿做商业用途客户在决定投资一套软件系统建设的项目前， 本身很明确知道希望这套系统能够 带来什么价值，但对于如何能够利用科技来达到目标则一概不清楚。希望透过软件工程师的专业知识来告诉他们如何才能够满足他们的愿景，客户希望透过人工智能（AI）去理解顾客的采购习惯，背景，行为和对现有产品的反馈对产品进行 改良；他们希望透过企业资源规划（ERP）来减低生产或运营成本，提升资源对 企业的价值；希望透过客户关系管理（CRM）软件的应用来保留顾客对企业品 牌的忠诚，增加顾

19、客对企业的满意度。这些都是透过科技应用所希望带出来的普 遍价值和投资愿景。但技术人员仍然停留在科技应用的层面上， 希望客户能够告 诉他们需要那些功能来达到这个愿景，让他们能够利用技术完成客户的系统建 设。这些构思型或愿景型的项目如何进行交付， 是上世纪末期开始对软件行业的 一大挑战。个人收集整理勿做商业用途在这种情况下，技术人员如何能够满足客户的愿景， 客户如何能够告诉技术人员 有关这个投资项目的功能需求，变成项目在实施过程中不断进行修改， 不断延误的主要原因。如何解决这个困境是当时急迫需要处理的难题。所以计算机行业新增加了一个岗位，叫做业务分析师（Bus in ess An alyst或简称

20、BA），业务分析师应该有深厚的行业知识，透过BA对行业的理解，对愿景项目进行流程分析 及建设，然后让技术人员对有关流程进行分析，建立功能需求，设计有关模块， 为这些构思型或愿景型项目提供所需的基本信息。但可惜行业知识与技术知识两者还是有相当大的距离，BA未能发挥应有的效益。美国PMI也是在这个时候 订立项目赞助人（Sponsor ）及项目干系人（Stakeholders ）的角色，在项目 开发过程中，项目赞助人需要确认 BA的流程建议，需要取人系统建设每一个 阶段的交付。项目干系人需要确认流程及系统功能不会影响部门的正常操作，两者要确保整个项目能够达到预期的交付愿景和目的。个人收集整理勿做商业

21、用途应用系统。希赛顾问团需求工程首席专家徐锋认为， 这些工具和方法误导了这个 行业的技术人员，让他们在项目启动的时候便把重心放在把握功能需求，而不是建立项目范围，直到今天，很多软件工匠在项目起动时便尽量希望能够把握项目 的功能需求，一些学者更把如何把握需求当作教育重点来让我们不断培育软件工 匠。让技术人员忘记了建立范围的重要性，让技术人员未能发挥本身的智慧，为 客户建立所需的解决方案，让这些工匠不能够有效地考虑如何利用科技来提供客 户期盼的价值，发挥本身的创作力和创思。智能让技术人员不断跟着客户后追寻 那些不存在的项目需求。 个人收集整理勿做商业用途软件工程在21世纪的挑战在20世纪90年代中期，互联网与 Windows开始进入个人及企业的空间。当 时，笔者被任命为澳大利亚墨尔本市的一家百货公司建立一套网络销售系统。当时我对互联网的认识相当肤浅，如何完成这个任务对我及整个交付团队是一个考 验。我花费大量精力及时间与客户沟通，希望理解他们建立这套系统的背后目的， 在过程中我们共同建立了一套假设的业务流程， 因为双方都不清楚顾客在网络的 另一端在过程中会有些什么反应，所以我们依据不同的反应建立相当数量的流 程。在这套业务