English

TOP

软件开发项目的范围管理

项目管理九大知识领域中,项目范围管理是排在整体管理之后的第一个知识领域,也是非常重要的领域。离开了范围管理,项目的计划、执行和监控就会无的放矢。

    范围管理
工作内容包括制订项目初步范围说明书、范围规划、范围定义、制订WBS、范围核实、范围控制。从项目管理的通用过程来看,制订项目初步范围说明书属于启动过程,范围规划、范围定义、制订WBS属于计划过程,范围核实、范围控制属于控制过程,范围管理工作涵盖了除收尾阶段以外的项目生命期的各个阶段,其中范围定义和范围控制是范围管理最主要的内容。

一、范围定义

    范围管理
从确定项目的边界(又叫范围定义)开始,是范围管理最为重要的组成部分和基础。
   
确定项目边界的过程,就是项目的有关各方对项目的范围达成一致意见,并清楚地描述出来的过程。对项目范围的陈述可以让大家清楚的了解哪些工作是项目范围之内的事情,而哪些工作不属于该项目范畴。项目范围界定得越明确,对项目后续工作的开展就越有利。

   
应用软件开发项目源于用户,终身服务于用户,项目是否成功的标准是用户的满意度。对于应用软件开发项目来说,确定项目边界的工作分三步进行。第一步是需求调研,研究客户提供的业务需求书,学习行业背景和行业术语,学会用客户的语言与客户交流。在初步了解客户业务的基础上,开展需求调研,充分挖掘用户的潜在需求,充实和修改业务需求书。第二步是需求分类,在充分理解用户需求的基础上,与客户一起确定项目的功能范围和性能要求,编写软件需求书。第三步是需求分析,按照软件需求书中确定的项目范围,进行需求分析,确定用户界面,编写软件需求规格说明书。

1.
需求调研

   
客户提供的业务需求书中,往往只描述了显性的、明示的需求,很少描述隐性的需求,需要通过需求调研挖掘出来。

   
在调研开始前,要组织一个需求调研团队团队中最好有行业专家参加。如果乙方没有行业专家,那就要更多地依赖甲方的专业人士。以笔者长期实践的经验来看,在需求团队中加人几个甲方专业人士作为需求调研工作的主力、并跟踪项目的全过程,是一个比较好的解决办法。

   
需求调研的目的是将需求尽可能地挖掘出来,因此调研对象要有代表性和广泛性。采用调研工作会议和调查表交替进行的工作方式有助于调查结果的正确性和普适性。

   
调研工作会议的会前,要充分准备好会议议题、不明确和有异议问题的清单、业务需求书讨论稿,事先发给与会者,让与会者做好充分的准备。会中要让与会代表充分发表意见,求同存异。会后应立刻整理会议纪要,发给所有与会者核实内容,消除歧义,避免遗漏。调研工作会议后,要将达成的共识整理到业务需求书之中,将不明确和有异议的问题整理成调查表,进行广泛的调查,调查表要尽量设计成选择题而不是问答题,这样可以有效提高调查表的反馈率。根据结果,修改完善业务需求书讨论稿,整理不明确和有异议问题的清单,准备下一次调研工作会议的议题和内容。如此周而复始,直到所有问题都彻底解决。范围定义工作的要求是明确、可量化、可验证。在协助客户编写业务需求书时,切忌撰写界面友好、可操作性强、用户满意度高之类含糊其辞的需求,需求书中的这些词句常常是导致项目扯皮的根源。

2.
需求分类

   
业务需求书更多地表明了用户需要一个什么样的东西,项目能做成什么样还要受成本、时间、技术能力、软硬件环境等条件的制约。软件的功能也符合80/20规则,即20%的功能实现了80%的价值,另外20%的功能花费了80%成本。在做需求分类时,应对每个功能进行技术实现可行性和时间成本可行性分析。在项目的范围内进一步细化需求,编写软件需求书。软件需求书是乙方需求分析人员对业务需求理解分析后的产物,是乙方需求分析人员写给甲方专业人士看的,其中的细节要向甲方专业人士解释清楚。软件需求书的目的是让甲、乙双方对相关需求的理解都足够细致,没有歧义,并且可以依据其内容准确工作。它是确定项目范围的一个重要环节,需要双方签字确认才能生效。大型软件开发项目如果缺少这个环节,容易造成甲方拿业务需求书说事,乙方拿软件需求规格说明书说事,双方不在一个层面上说事,对项目的范围各说各的,达不成一致的意见。

3.
需求分析

   
按照软件需求书中确定的项目范围,进行需求分析,确定用户界面,将需求分析的结果编写成软件需求规格说明书。软件需求规格说明书由乙方的需求分析师和架构师编写,主要是写给乙方项目团队人员看的。需求分析过程也是进一步细化需求的过程,编写过程中会对需求细节再讨论、再确认,因此软件需求规格说明书也需要双方签字确认才能生效。生效后的软件需求规格说明书要纳人基线管理,在整个项目周期中,乙方依据其内容开展后续工作。

二、范围控制

   
范围控制包括范围核实和变更管理。

1.
范围核实

   
范围核实要解决来自乙方的问题:一是超出项目范围的镀金行为,项目团队有时会自以为用户需要而为项目附加额外的功能,或为项目设计过高的性能指标和安全指标,从而使项目成本或进度失控;二是防止项目范围内的工作遗漏或达不到基线的要求。这两方面的问题通过范围核实来检查和纠正。

2.
变更管理

   
变更管理主要解决来自甲方的变更要求。应用软件开发项目是否成功是以用户的满意度为标准的,只有满足了用户的需求用户才会满意。用户的需求通常都比较模糊,因此客户在项目开始之前不能明确所有的需求。即使他们能够做得比较好,整个业务环境也在不断变化。随着时间的推移、业务的发展、用户认识的提高,用户的需求也在发生变化,需求变化了,客户提出变更是不可避免的。如果坚持不变,项目的价值会受到影响,用户的满意度也会受到影响。因此,乙方需要具备在项目进行的过程中根据需要做出变更的能力。变更并不可怕,可怕的是随意的、没有控制的变更。为了使变更有序,需要与甲方一起,建立变更决策组织、制定严格的变更制度、变更流程,将一切非必要、非紧急、不合理、非高层领导意图的无效变更屏蔽掉,同时采用变更申请表格和配置管理工具有效地管理变更。

(l)
建立变更决策组织

   
在人民银行的信息化项目建设中,每个大型项目都会成立一个由业务方、管理方、承担方三方高层领导参加的项目领导小组,下设办公室,办公室由三方的中层领导和项目经理组成,负责项目日常指挥工作,遇到重大问题提交领导小组会议决策。项目领导小组实际上起到了变更控制委员会的作用。一般变更由三方项目经理签字决策,如果三方有异议的一般变更或较大变更提交领导小组办公室会议决策,重大变更提交领导小组会议决策。

(2)
制定变更制度

   
变更工作应按照严格的制度执行,只有被授权的人员才有权执行变更。

(3)
制定变更流程

   
项目应制定统一的变更流程。所有的变更都应以书面的方式提出,变更提出方(通常是甲方)要填写统一的需求变更申请表。甲、乙双方都应对变更进行分析,评估变更的性质是重大变更、较大变更还是一般变更,变更能带来多大的价值,变更给项目带来的风险,变更对进度、成本的影响。根据变更的性质,提交相应的组织确认和审批。对于成本和进度影响大的变更,决策者应考虑为项目配备相应的资源,如延长时间和追加资金等。

   
对于经常性的细微变更,要尽量集中研究、批量处理,每月召开一次变更专题会议,集中研究处理这些零碎变更事项,控制好工作节奏,尽量避免由于处理零碎变更而影响项目总体进展的事件发生。

(4)配置管理
活动

   
按照上述的变更决策机制、变更制度、变更流程进行的每一个变更,通过配置管理活动和配置管理工具管理起来,以保证项目工作产品及其变更在整个生命周期中的完整性和可追溯性。

 

关键字:
】【打印繁体】 【关闭】 【返回顶部

最新报道

图片主题

热门

推荐

相关