对需求分析和范围界定的认识
摘要：需求分析和范围界定是范围管理的关键部分，有了清晰的需求分析和范围界定，才能避免产生争议，让项目顺利进行.本文根据项目实施过程遇到的问题和解决经验，分析论述了需求分析和范围界定的作用. 关键词：范围管理需求分析范围界定
项目的范围管理就是要明确项目中应该做的工作是哪些，哪些工作不应该包括在项目内，还有工作要做到什么程度.在整个项目管理中，范围管理的工作要在项目前期完成.没有定义好范围，项目实施起来就没有方向，没有指导，很容易让项目人员觉得什么都要做，又或者是什么都不用做，在实施过程中造成多方扯皮，互相推诿，严重影响项目的实施进度。
有很多项目在实施过程中，经常有这种经历：当工程出现需要多方配合的多工序时，因为项目实施前没有界定好，一开始都没人管。而做信息系统的工程总是项目的最后工序，项目是否完成在信息系统中直接体现，等到项目工期逼近，而前面工作又没人处理，在多方沟通都没有结果的情况下，只能不情愿地把前面工序做完，好让自己的工序可以开工，导致成本超出预算.还有一种情况也比较常见：在项目实施过程中，客户不断提出新的要求，让施工方疲于应付，感觉客户在无理取闹，影响互相之间的沟通配合，结果是不但项目的周期拖长，项目成本增加，还降低了客户的满意度，影响公司信誉.上述对项目不
利情况出现的原因都涉及到范围管理，都是在范围管理方面做得不够，需求分析不足、范围界定不清造成的后果.因此，做好项目的范围管理，是项目管理的重中之重，是项目成功的前提。
在前不久，我担任项目经理一职负责完成客户的生产调度决策系统.该系统需要对客户的生产数据采集并储存，各数据组合形成不同的数据库。在生产过程中采集到的实时数据代入相关数据库进行比较，利用特定的计算方法分析在当前环境下最优的生产组合，并产生报表供客户管理者参考。管理者在分析结果的指引下作出正确的判断，让生产效率提高，减少生产中的损耗，从而降低生产成本。
该项目的提出是基于客户管理者在多年生产管理的经验中总结出来的，同行业还没有相关的成果可供参考，而且因为客户的生产模式比较独特，其它行业经验可借鉴的地方也不多。还有项目中由于需要大量的生产数据和收集客户的有关
生产经验值，客户也需派人员参与项目的实施。因此，该项目前期的工作量最大，包括项目的主要目标、我方和业主方的工作界定、实施结果的指标量化等等，这些都要在项目前期确定并形成文字让各方确认后，才能减少项目中产生纠纷的可能性，让项目得以顺利地执行下去，这些都属于范围管理的主要内容。在项目实际操作中，我运用了范围管理的有关知识，把项目范围界定清楚，使各方在实施过程中有清晰的指引，加强了相互之间的沟通，避免了扯皮的现象，让项目从启动到验收结束都非常顺利。
范围管理有五个过程，包括范围管理计划的编制、范围定义、创建工作分解结构（WBS）、范围确认、范围控制.
项目确定由我负责后，我马上着手编写初步的范围说明书，明确了项目在“可交付物"层次上需要做的相应工作，也明确了项目及相关产品和服务的特性，还有范围控制和验收方法。然后初步制定了项目的管理计划，对项目中主要实施内容作了大致的分工，规定了项目不同阶段应完成的工作。上述内容都是在项目合同的基础上编制，还没涉及到项目的细致分工，组织项目各干系人开会研究，很快就得到认同，也没耽误太多时间。
接下来对项目进行需求分析、范围界定是项目初期的重点和难点工作。在信息系统项目中，存在两个有相互关联、相互影响的范围：产品范围以及项目范围。产品范围指的是项目承诺交付的产品或者服务所包含的功能，项目范围指的是为了完成项目所必须做的工作，如何确定系统范围被称为“需求分析”.需求是每个项目的开端，是项目实施的基础。而信息系统项目本身存在项目周期长、涉及业务多的特点，项目经常会出现需求不稳定的现象.如果在需求分析上没有控制好，需求不明确，范围界定不清，项目范围就会失去可控性，随之而来的就会出现盲目的现象，事情越做越多，毫无止境，严重影响项目进度和成本，更有可能导致项目的失败。出现这种情况主要有几个原因：
第一，项目管理者对范围管理的控制认知不足，没有意识到范围管理的重要性。有的项目管理者认为
合同就等同于项目的需求，没有对其细化就按照自己对合同的理解开展工作，有的项目经理因为是技术出身，没意识到自己是项目管理者的角色，项目开始就埋头于自己喜欢的技术工作，这些导致的结果是显而易见：因为需求不明确造成项目计划不周，工作任务分配不均，项目进度时快时慢不受
控制，项目组成员只能凭自己经验各做各的，有的很忙、有的很闲，浪费人力资源.
第二，项目经理与客户沟通不足。有的项目管理者已经认识到范围管理在项目管理中的重要性，但在进行需求分析、界定范围时只在内部讨论，或只与客户的项目管理者商量，得出来的结果就认为是项目范围，项目按照该结果实施就行了.但随着项目的实施，客户方的技术人员、维护人员和操作人员陆续进场，他们的知识背景不同，对项目的理解也就不一样，所以他们根据自己的经验习惯会对项目的实施结果提出不同意见，由于项目完成后系统平时的运营维护都是他们来负责，客户的项目管理者必须要接受他们的意见，如果意见和实施结果有冲突，施工方还是需要重做，也就增加了项目的成本和进度。
第三，项目管理者对项目实施中的需求变动估计不足。根据以往项目的经验，随着客户对项目的认识加深，还有对项目相关专业知识的了解加深，他们会在项目的不同阶段对项目提出新要求，也就是需求变更。如果项目经理对这些需求变动估计不足，没有在需求分析时防患于未然，尽可能地把稳定的需求和易变的需求分析清楚，以便在系统设计时，把系统的实施建立在稳定需求的基础上，同时也要
留出变更的空间。在出现需求变动时就会措手不及，为了满足需求变动而仓促改变施工计划，容易造成返工.
第四，项目范围定义不明确，没有量化。在确定项目需求时，很多时候只是定性要求，而不是定量的。如“界面友好，操作方便”等，这样的要求模糊不清，让各人对其结果可以有不同的理解，验收时就容易造成扯皮。这些要求应该有定量的说法，如说清楚界面上需要多少按钮，控制界面分多少等级，界面中设备不同状态的颜色标识等，这样在项目验收时可以根据相关规定逐条确认，不会产生异议。
针对这些原因，我在项目启动初期，经过与客户方的项目经理沟通后，组织双方的领导小组、双方技术负责人、客户方运营部负责人、客户方维护部负责人共同召开项目动员大会。在会议中，我首先指出范围管理的重要性，让大家都认识到只有明确了项目需求、范围界定清楚后才能走下一步，而界定范围不止是施工方的责任，还需要客户方努力配合，才能大大缩短界定时间，项目得以早日进入实际操作阶段，保证项目工期。有了这样的共识后，双方很快定下各自名单组
成项目管理小组，由我方为主导，客户方大力配合，负责确定项目的需求、界定项目范围。有了这个管理小组，使项目范围确定的工作效率大大提高，当在需求分析有争议时，可以在短时间内召集有关人员开会讨论，得出的就是权威的结果，不会在项目后期产生争议。在确定项目需求时，我强调项目
管理小组要提出定量的要求，如：要形成多少个数据库、每个数据库包含多少个数据、数据采集的频率、通过不同的计算方法可以得出的结果有哪些等等，总之凡是项目管理小组通过的要求都要具体量化，不能含糊不清。由于各人早已取得共识，虽然工作量大，时间很紧，但他们都尽心尽力去做，偶尔还因为某个需求还没取得共识加班加点。在这样的工作氛围下，项目需求、范围界定得以在短时间内确定.在此基础上就可以创建工作分解结构，把项目分成细小的、易于管理的工作包，充分利用了项目的人力资源，项目进度也更容易控制。有了充分的前期工作，项目在有序的环境下进行，编程、调试很快完成，而且由于有了定量要求，各人按要求检查，没有扯皮的现象，项目最终按时验收，受到客户好评。
该项目能顺利完成，清晰地确定项目需求、范围界定是主要原因.但在前期工作中还是有些做得不够的地方，如在确定需求时，我们只是互相讨论，比较耗时，如果能尽早请有关专家作指导，会大大缩短确定时间，项目有更充足的时间完成。以后还要多充实自己，多吸收项目管理知识，让项目能按时保质完成.
