学术堂首页 | 文献求助论文范文 | 论文题目 | 参考文献 | 开题报告 | 论文格式 | 摘要提纲 | 论文致谢 | 论文查重 | 论文答辩 | 论文发表 | 期刊杂志 | 论文写作 | 论文PPT
学术堂专业论文学习平台您当前的位置:学术堂 > 管理学论文 > 项目管理论文

中小软件项目需求变更现状

来源:学术堂 作者:陈老师
发布于:2016-10-27 共5604字
  第三章 一种适用于中小软件项目的需求变更评估模型
  

  3.1 中小软件项目需求变更现状
  

  3.1.1 中小软件项目开发特点
  
  近年来,国内的软件行业得到了高速发展,各行业都纷纷上线各种项目,用于提升企业形象,提高企业服务水平,优化企业内部管理水平。其中小规模的软件项目比重也越来越大。但是实际情况是,项目虽然都进行的如火如荼,但其实并不都很顺利,很多项目不断地遇到各种问题困扰,导致项目周期延长,预算大幅度增加。作为项目参与者,无论是客户还是开发人员,经常会感觉到项目似乎是个无底洞,怎么做也做不完。这其中有一个因素不能忽视,即需求频繁变更,造成项目的管理出现了问题。
  
  目前国内的中小软件项目,基本上有以下一些共同特征:
  
  3.1.1.1 项目周期短
  
  由于竞争激烈,企业往往需要在短时间内推出一个能在相关市场领域内占据优势的软件项目,因此项目周期都很短。一旦项目延期,可能会错失市场机遇,造成各种损失。
  
  另外一方面,对于项目开发人员来说,这意味着更大的挑战和更高的要求,要有能力在短时间组织协调好相关资源,尽可能的达到项目的时间要求。
  
  3.1.1.2 项目预算和资源紧缺
  
  企业是以盈利为目标的,总是希望能在最少的时间、资源等投资下,获得最大的投资回报,因此项目往往会限制一定的资源和预算。在激烈的竞争环境下,许多项目开发方,为了生存或者进一步的发展优势,往往会以一定的代价去换取项目开发机会,从而满足客户较为苛刻的预算和资源条件。
  
  另外一方面,作为开发方,由于资源有限,公司往往会集中优势资源参与到对公司而言最有回报的项目中去,这样其他的项目很可能会面临尴尬的境地,在开发人员,资源等方面捉襟见肘是经常会遇到的情况,这对开发人员也提出了更高的要求,要有能力在限定的资源情况下,按时高质量的完成项目开发。
  
  3.1.1.3 项目功能日趋复杂
  
  随着互联网急速的发展,很多所谓中小软件项目,其规模和功能已经远远超出了几年前的概念。例如一个简单的 B2C 项目,最基本的就包括客户管理,产品管理,订单管理,支付管理,网站建设等非常庞杂的子系统。而每一个子系统内,功能也是越来越细化,要求越来越高。在这样一个背景下,开发人员往往面临着巨大的挑战,必须在有限的时间、资源条件下,实现复杂的项目功能。
  
  3.1.1.4 项目需求变化快
  
  需求变化快是中小软件项目的显着特征。因为市场竞争激烈,客户会不断的跟踪行业的最新动态,希望能将最先进和最流行的功能加入到项目中来。在项目初期,客户很可能只有一个比较粗的功能需求,随着项目的进行,提供给客户感受的成果越来越真实,客户逐渐对某些功能会有更新的体会,会不断的有新的要求或者改进意见提出。这种快速的需求变更特点,对于项目开发方提出了非常高的要求,要有能力在有限的时间,资源内实现复杂的功能的同时,还要能合理的处理需求变更,成功的完成项目。
  
  3.1.2 中小软件项目需求变更产生原因分析
  
  在软件项目的开发过程中,需求的变化是不可回避的基本事实,对于中小软件项目来说,变化的主要来源于以下几个方面:
  
  3.1.2.1 客户相关因素
  
  客户在项目中是非常重要的参与者。项目的最终成果是要给客户提供有价值的成果,最终的使用人员是客户自身。项目的需求最初是由客户提出,需求的变更也往往是由客户提出。
  
  一般而言客户对于自己需求的描述是比较概括和粗略的描述,客户虽然对自己的业务非常熟悉,但是缺少从系统和设计的角度对其进行梳理和抽象的能力。这就给开发人员在系统初始阶段的需求分析带来了挑战。需求阶段很有可能会漏掉一些比较重要或者- 21 -潜在的功能需求,随着项目的进行,这些需求才可能逐渐被发现并引入项目,这将会造成需求变更。
  
  客户对于系统的功能要求,往往是随着项目进展而发生变化。可能是因为市场上出现了新的技术或者功能,出于竞争需要,客户要求在项目中予以新增。也可能是因为随着项目的深入开展,客户对原来的功能理解发生了改变,发现原计划的功能并不能完全反映真实的要求,或者是项目已经提供了一部分的成果后,经过实际体验后,对原有需求提出了修改要求。
  
  客户对于需求的更改有时候有很大的不确定性。特别是在中小项目中,客户往往对变更带来的代价没有直观的认识,认为有些需求改动是很容易的事情,并且无法意识到其对整个项目的影响。有的时候甚至会产生抱怨开发团队总是推托和不愿意多承担责任的意见,这会对项目造成非常不好的负面影响。
  
  3.1.2.2 软件开发自身因素
  
  从理论上讲,如果能获取客户全部的需求,然后结合开发方的恰当资源,就能在设定的限制条件内,实现项目的所有功能需求。但是实际的情况却是完全不同的。
  
  一方面,在目前的软件开发条件下,现有的需求分析方法并不能获取全部的、准确的需求描述。
  
  另一方面,项目的参与者是人,在人与人的沟通中,由于互相知识背景的差异,开发人员往往对客户的业务知识没有比较深入的了解,而客户又对于开发人员的专业知识知之甚少,所以会导致沟通过程中出现需求的表达没有正确传递,甚至被误解的现象。这些都为需求变更埋下了隐患。
  
  中小软件项目在实施过程中,往往会受到很多条件的制约,比如项目周期短,资源紧张等,项目管理流程不太规范等。在前期需求分析阶段,需求的收集过程,有的是直接基于客户提出的功能要求,稍作修改就作为项目需求。有的则是完全凭借开发人员的经验,从开发角度提出的需求。这些都缺少客户与开发团队的紧密合作与充分讨论,并没有真正理解客户的业务逻辑和真实要求,最终产生的需求文档,必然会隐藏很多不确定因素。当项目进行到一定阶段,客户发现某些需求并非当初的设想,或者某些模块漏掉了一些功能,就会导致需求变更的产生。
  
  3.1.2.3 开发人员相关因素
  
  开发人员的素质,也是项目成败的一个关键因素。在需求分析阶段,开发人员需要积极的了解和学习客户的业务知识, 深入的与客户进行沟通。同时也要提供相应的简单有效的手段,让客户了解一些开发相关的知识和术语,便于更加流畅和有效的沟通。如果在此阶段没有充分调动双方的积极性,尽可能的覆盖所有的功能点,很可能在项目的后续阶段导致需求变更更加频繁的出现。
  
  另外,开发人员的技术水平和选用的技术方案,也是决定项目成败的重要因素。如果选用的技术不当,会造成系统的某些功能设计出现一定的难度,增大了需求变更的可能性。这里的需求变更对客户而言是不可见的,但是会对项目的周期和成本产生重大影响。比如,采用一些新出现的技术可能会解决一些使用老技术很难实现的功能,这时候,项目开发人员就要权衡是否需要修改设计相关的需求,从而为使用新技术做好准备工作。
  
  3.1.3 中小软件项目需求变更现状急需改进
  
  当一个需求变更请求提出之后,就必须对其进行评估和分析,如果评估结果在整个项目的周期、预算等可承受的范围之内,才可以付诸实施。这里的评估和分析是非常重要的一个环节,正确合理的评估一方面为变更带来的代价做出了合理的预测,为项目计划的更改提供了正式的参考依据,另外,根据评估结果可以过滤掉一些不必要的,或者项目无法接受的更改要求,使得项目能够集中精力继续进行。
  
  中小软件项目在实施过程中,往往会受到很多条件的制约,比如项目周期短,资源紧张等,项目管理流程也不太规范。虽然有的项目甚至都成立了变更管理委员会,但是对于变更的评估,基本上是建立在项目经理和相关人员的简单沟通的基础上,并没有从设计角度给予太多重视,由此获得的评估结果,往往并不能反映真实的开发代价。
  
  同时,开发人员对于客户的要求,也往往没有有效的分析方法进行较为准确的评估,甚至会碍于情面或者仅仅依据经验做出判断。等到变更开始实施以后,才会发现很多问题一个接着一个,最终将整个项目推向了周期延长,成本失控,甚至质量无法保证的尴尬境地。
  
  最后,中小软件项目的周期往往比较紧张,需要做出快速响应。在各种压力之下,当需求发生改变的时候,往往会忽视需求变更评估的重要性,往往会草率做出结论,这为后续项目的顺利开展和评估都会留下不好的因素。
  
  综合以上论述,目前中小软件项目的需求变更普遍存在问题,需要得到相关人员给予足够的重视,并提出相应的对策和解决方案。
  
  3.2 项目案例
  

  3.2.1 项目简介
  
  3.2.1.1 项目背景
  
  该项目是为国外一家知名的保健类产品公司上线一套电子商务系统。该公司在行业内占有一定的领先优势,首次进入中国市场,并成立了中国分公司。他们希望能在最快的时间内建立起一套完善的,本地化的电子商务平台,主要的功能需求包括:
  
  § 一个先进的在线购物平台(B2C)
  
  § 一个先进的呼叫中心系统(Call center)
  
  § 一个先进的客户关系管理系统(CRM)
  
  客户希望能借助该系统,初步建立起一整套的运营模式,将其产品迅速推入中国市场。因此其总部对这次项目非常重视,并投入了一定的资源来保证项目的顺利实施。
  
  3.2.1.2 子系统 - 在线购物网站 - B2C
  
  该网站有在线购物平台和企业宣传门户的双重作用。一方面要能全面展示该公司的产品,包括产品线,功能特色,同时还要包括一部分关于健康方面的学习功能。另外一方面,该系统又是一个典型的网上购物平台,要提供产品浏览,产品比较,购物车,支付,订单管理等典型功能。另外该系统还需要提供商品管理,库存管理,物流管理等方面的后台功能。总体来说,该系统涉及的功能非常多,具有一定的代表性。国内的很多系统都有类似的特征。
  
  该系统主要功能需求如下:
  
  § 公司形象展示
  
  § 保健知识学习
  
  § 网上购物网站,如商品流量、搜索、订单支付等
  
  § 客户管理功能,如注册、登录、资料管理
  
  § 订单管理功能,如创建维护等
  
  § 支付管理功能
  
  § 仓储管理功能
  
  § 物流管理功能
  
  3.2.1.3 子系统 - 呼叫中心系统 - Call center
  
  客户基于其高定位的要求,准备建立起专业的客服呼叫中心,所以需要配备先进的呼叫中心系统。该呼叫中心将包括两方面的功能,一方面作为一个电话购物系统,用户可以直接拨打呼叫中心电话,在客服人员的帮助下,通过电话直接下订单。另外一方面,该呼叫中心又是典型的客服中心,为用户提供产品资讯,解决使用中遇到的问题,处理质量、投诉等问题。
  
  主要的功能需求如下:
  
  § 呼叫中心功能
  
  § 电话购物功能
  
  3.2.1.4 子系统 - 客户关系管理系统 - CRM
  
  CRM 系统,客户关系管理系统,可以充分利用现代计算机时代的管理技术,将整个公司的业务活动以客户为中心,全部完整有机的结合起来。
  
  本项目的客户刚刚进入中国市场,由此需要快速积累起中国市场的用户数据资源。
  
  该系统一方面可以保存最重要的客户信息,同时又有其他更多复杂的高级功能。比如,客户资料内部员工共享,潜在客户分析,广告推送等。这些都是提高一个公司的管理水平和提高市场竞争力的重要工具。
  
  主要功能需求如下:
  
  § 客户资料管理功能
  
  § 客户资料分析功能
  
  § 潜在客户广告推送功能
  
  3.2.2 项目存在的问题
  
  3.2.2.1 项目周期短
  
  客户需要在 10 个月内完成所有项目的开发和部署,以便能够配合其市场活动的计划,如进入中国发布会等。项目从一开始接触,时间就变成了一个关键问题。当然在快速消费品这个领域,速度可能会直接决定市场的成功与失败,作为开发方,我们也是有一定的理解。但是这将给项目开发带来非常大的难度,根据经验,中小软件项目中的时间因素是造成项目管理困难的重要问题之一。在紧张的周期中,项目管理就会变得不太规范起来,需求的变动也就容易被轻视,这些都会给后期的开发留下隐患。
  
  3.2.2.2 需求模糊
  
  由于客户也是首次进入中国市场,由此对自身的本地业务并没有现成的模式。在前期的需求分析阶段,基本上都是项目参与人员根据其总部的运营模式,再参考本地的几个有竞争力的对手的运营模式,来确定该项目的需求。
  
  这里最大的问题在于,这时候的需求分析,并没有完整的反映出客户的业务逻辑和需求。随着项目的进行,客户对自己的业务也在不断的总结和规划,又将提出许多新的需求或者需求变更要求。这对于项目来说是非常不利的一个因素。特别是在开发周期很短的情况下。
  
  3.2.2.3 系统功能复杂
  
  根据以上的分析,可以初步看出来,该项目主要包括了购物网站,呼叫中心,客户管理系统等子系统。每个子系统都有非常庞杂的功能点,在子系统内部,实现其各种常见需求,相对来说也是比较易于开发的。但是该项目最大的难点在于,这几个子系统并不是孤立运行的,根据需求分析的结果,他们必须是紧密联系在一起的有机整体。
  
  具体来说,客户管理系统是整个系统的数据中心,所有经过网站系统和呼叫中心系统的客户数据,最终都将流入客户管理系统。
  
  网站系统里提供的客户管理,订单处理等都是基于 CRM 中资料来进行业务流程。
  
  网站系统用户注册,订单生成等功能,都将与 CRM 的客户数据保持一致。
  
  呼叫中心也是同样的情况,通过呼叫系统进来的咨询、下单等数据,也会同步到 CRM中。当有来电时,系统会提供用户的历史数据,便于客服人员进行综合使用,本次的业务内容也会自动保存。
  
  客户管理系统又是整个系统的决策中心,不仅仅只是用来保存用户数据。公司的市场人员会基于网站和呼叫中心的历史数据,利用系统进行数据分析和挖掘,统计出当前销售特点,并可以找出各种潜在的客户。对于老客户和潜在新客户,可以采取不同的营销策略,正确的进行广告投放等市场营销活动,达到高效的市场推广水平。
  
  所以,要确保该项目的顺利实施,必须要能理清各个系统的功能定位和协作关系。
  
  从系统复杂度和时间安排来说,都是面临着比较大的挑战。
  
  3.2.2.4 需求变更频繁
  
  该项目的性质决定了客户的需求一开始是模糊的,需求分析无法完整的涵盖用户的所有需求点。甚至在开始阶段,包括客户和开发人员都不太明确某些业务逻辑或者功能要求。随着项目的展开,业务逻辑被逐渐理清,客户发现很多需求需要进行改动,并且需要提出很多新的需求出来。频繁的变更产生了非常大的风险干扰。
  
  3.2.2.5 与客户的沟通问题
  
  项目的周期非常之短,因此很多改动对项目影响非常大。同时客户缺少相关的系统使用经验以及开发项目经验,客户往往无法理解这些影响的代价。认为提出改动或者新的要求理所当然,或者对造成的影响程度没有充分的理解。这些交流的障碍成为很多问题的根源。
相关标签:
  • 报警平台
  • 网络监察
  • 备案信息
  • 举报中心
  • 传播文明
  • 诚信网站