论IT项目的需求管理与范围管理.doc

论信息系统项目的需求管理与范围管理【摘要】本文介绍了本人在担任WMS2.0项目经理期间，服务于某公司（以下简称：业主）设在保税物流中心的海关监管仓的仓储管理系统选型、二次开发和上线实施的过程。进而总结了本项目通过需求工程与范围管理取得项目成功的经验和体会。 该项目的早期难点在于业主的需求不明确，开发团队业务经验不足，以及业主对项目开发团队缺乏信任。通过本人的努力，该项目实施成功、取得显著收益，并在过去两年的时间里支撑了业主公司的业务扩张。业主公司也因此扭亏为盈，走向了良性发展的轨道。 在上述项目中，本人担任了项目经理、业务需求分析师和系统实施顾问等工作，在历时一年多的时间里，为项目的成功付出了大量心血。本文重点对需求工程和项目范围管理的分析和探讨。指出该项目成功要点在于：一、依托丰富业务经验成功的主导了需求开发；二、通过与客户方中、高层领导的多轮需求界定，厘清了项目范围；三、通过严谨的需求变更流程成功控制了需求蔓延，保证了项目如期结项。 【正文】项目背景介绍自2005年起，业主按照集团的部署，开始在某临港物流园区投资建设海关监管仓，主要服务于国际采购商和若干第三物流企业的出口集装箱拼箱业务和国际配送业务。这些业务的特点是国内制造企业根据国际采购商或第三方物流企业的指令，将货物运送到海关监管仓进行短期存储。业主再根据国际采购商或第三方物流企业的指令，进行流通加工、出口拼箱，以集装箱整箱形式装船出口。 海关监管仓的建设是分阶段进行的。计划分五期进行建设。每期各投资兴建一座相对独立的大型仓库。第一期建设一座单层仓，仓库面积是32000平米；从第二期到第五期，都将兴建双层仓，每座的仓库面积均超过60000平米。业主在建设一期仓的同时，委托我们公司开发仓储管理信息系统（简称WMS1.0）。同时，我们公司与当地主管海关合作，共同开发了一套海关联网监管系统，以实现海关对上述海关监管仓的联网监管（采用进出仓货物的电子账册备案制，海关官员通过远程视频监控和不定期入仓查验等方式进行联网监管，并根据企业申报，对仓库进出口货物实行电子账册核销）。 由于业主方和开发方都是初次开展这类业务，经验不足。于是公司WMS1.0项目组在借鉴国内同类软件产品功能的基础上，结合业主提出的业务需求，开发出了WMS1.0系统。该系统在投入使用一年后，业主发现系统存在严重问题。例如：由于海关联网监管系统与仓储管理系统对进出仓货物的计量单位和数量不同，在货物经过多轮进出之后，仓库实物帐和海关系统的电子帐之间就很难形成正确的对应关系，从而导致仓库实物帐与海关电子账册之间不匹配的现象发生。而这一点是海关不允许的。因此，WMS1.0项目组被迫采用了所谓的“一次录入”的方式，即先在海关联网监管系统中进行入出仓申报，海关受理后，再将申报数据导入到WMS1.0系统，形成进出仓数据。这导致了WMS1.0没有实现基本的单-货相符，不能对仓管、理货等生产作业提供有效帮助和指导，也不能实现仓储业务的计费和结算。业主公司的三个工作部门，除了通关事业部满意度较高以外，运营部和财务部均不满意WMS1.0的功能。随着二期仓即将建成和投入使用，业主认为WMS1.0系统将无法满足该公司的业务发展需求。要求尽快对WMS1.0进行升级改造。 在研讨系统升级方案的时候，业主对WMS1.0项目经理的认同度很低。要求我们公司聘用具有丰富业务经验的员工，在业界成熟仓储管理信息系统的基础上进行二次开发，形成真正符合业主公司实际业务需求的系统。为了保持该开发项目的连续性，将新项目命名为WMS2.0项目。公司经过招聘、考查和征求业主的意见，决定任命我为WMS2.0项目经理。WMS1.0存在的问题接手WMS2.0项目组之前，我与业主公司的各级管理者和系统用户做了交流，与WMS1.0项目组的主要成员进行了逐一面谈。我发现：WMS1.0项目组存在着三个非常严重的先天不足。其一：业务经验非常欠缺。虽然有多名项目组成员在业主仓库做过实习，前期也有过长达一年的系统开发、应用和反复修改的项目经历，培养了多名熟悉相关业务的开发人员，但从总体上来讲，这些以技术人员为主体构成的项目组成员站位偏低，对客户的需求理解不全面，不透彻，也仅局限于对业主仓库已有业务和特定作业模式的了解。他们对未来可能发生的业务没有前瞻性。虽然客户本身也是缺乏业务经验，但他们通过不断吸引国际著名物流商入驻园区，至少在视野上比WMS项目组的成员要开阔。这也是业主公司营运部经理等人看低WMS1.0项目组的原因。他们从内心里不认同项目组的业务能力；其二：项目管理水平低下。项目管理水平应该是一个公司的整体管理水平的一部分，而不应该仅仅是项目经理的个人水平。在当时，公司没有建立起一整套严谨的项目管理机制，一个项目的成败完全依赖项目经理的个人能力。WMS1.0项目经理小李由于在项目的中后期得不到双方管理层的认同，在项目组内部的威信也不断下滑，导致前期的项目组成员纷纷离开，而剩下的成员要么是因为还在担任系统维护任务，无法脱身，要么就是正打算离开项目组；其三：我公司的软件开发实力不强。WMS1.0项目在技术路线上沿用了业界流行的J2EE技术框架，但公司在可重用的业务构件（可重用组件）上几乎没有积累。很多通用的技术模块和功能模块，都要项目组成员从最基础、最底层的代码开始写起。代码的复用率相当低。 成功要点分析综合上述问题，我们决定先选择一个系统架构健壮、核心功能成熟的WMS产品，然后在该产品软件源代码基础上进行二次开发，以解决开发周期长，切换上线实施风险大等一系列难题。经过两个多月的考察和选型，我们最终选择了新加坡某软件公司的WMS产品，达成了开放源代码协议以后，项目组接受了该产品的功能、设计和源代码知识培训。 随后，我们在该系统源代码的基础上进行了三个多月的二次开发工作，开发出了符合业主实际需求的WMS2.0系统，又经过一个月左右的双系统并行测试，实现了系统的平稳切换，取得了项目的成功。项目组一致认为：WMS2.0的成功，有赖于以下三点： 一、依托丰富的业务经验主导需求开发工作WMS1.0存在的问题，在根源上讲，在很大程度上是因为该系统的需求分析主要是由用户主导的。而用户由于仓储业务开展的历史不长，并不十分专业。而且不同层级的用户对业务需求的理解是不一致的，甚至是矛盾和冲突的。WMS2.0项目组依托本人和其他外聘专家丰富的仓储管理业务经验和新加坡成熟产品包含的先进管理理念，改变了原来非常被动的需求开发模式。通过全面分析业主的业务诉求，结合先进的仓储管理理念和规范化的作业流程，一方面适当简化了部分作业流程，另一方面，我们通过对关键业务流程的反复讲解、结合未来系统的功能演示，优化了业主的作业流程，提升了业主的管理水平。在这样的基础上，完成了WMS2.0的需求开发工作。WMS2.0项目组与客户方的管理人员和操作人员经过深入交流和细致的需求研讨，修改了原有的单证录入次序，确定了先从WMS2.0系统中录入货物入出仓信息，新开发一个系统接口，实现海关联网监管系统的入出仓申报的半自动化作业。项目组决定，在新加坡系统的基础上，重点开发WMS系统与海关联网监管系统的数据交换接口；又以WMS1.0和新加坡系统作为原型，根据需求研讨形成的方案，对新加坡系统的核心作业流程进行微调，并在新加坡系统原有计费功能的基础上增加更为细致的计费和结算功能，以及大幅度扩充系统的报表种类和数量，满足各类业务对多维统计分析和业务状况报告输出的要求。 通过上述工作，WMS2.0项目需求组编写出了高质量的用户需求说明书和产品需求规格书。 二、通过需求的界定厘清项目范围由于业主自身业务的蓬勃发展，各部门对信息化的需求十分广泛。但我们的一个基本立场就是，并不是所有的信息化需求都应该在WMS2.0项目中实现。必须通过与业主管理层的磋商，通过严格的需求界定，厘清本项目的范围。 例如，财务部的计费工作涉及对代理报关业务的计费和仓储业务的计费。WMS2.0系统只负责实现对仓储业务的计费和结算。代理报关业务的结算，由于基础数据不能从WMS2.0中自动获取，因此，只能通过其它手段实现。而代理报关业务和仓储业务的收费分客户分类、汇总，以及请款追踪和发票开具等业务需求，也不能纳入WMS2.0项目的开发范围。 经过双方协商，决定在完成WMS2.0的开发和实施后，再携手开发一套商务管理系统来实现涉及客户服务和统一结算等在内的业务需求。避免了WMS2.0项目范围的扩大。 三、利用变更控制流程控制需求蔓延WMS2.0项目开发小组在完成产品需求规格书的主要功能开发和修改，经过内部测试后，交由用户方进行外部测试。许多系统操作用户对新系统的强劲功能十分欣喜。他们在提出若干功能和系统操作界面的局部优化意见的同时，也不断提出一些新增设想和比较大的功能建议。而这些功能建议有些是属于锦上添花的建设性意见，有些则是非常不成熟的设想。 WMS2.0项目组通过严格执行需求变更流程，要求用户方对这些意见和建议进行书面签名确认，并组织业主公司各级负责人对需求变更提议进行内部评审，通过后再提交WMS2.0项目变更控制委员会，对这些需求变更进行严格的评审。项目组最终只对少数变更