论如何应对软件项目需求变更.docx
- 文档编号:4397226
- 上传时间:2022-12-01
- 格式:DOCX
- 页数:20
- 大小:109.20KB
论如何应对软件项目需求变更.docx
《论如何应对软件项目需求变更.docx》由会员分享,可在线阅读,更多相关《论如何应对软件项目需求变更.docx(20页珍藏版)》请在冰豆网上搜索。
论如何应对软件项目需求变更
编号 44
项目经理培训班
毕 业 论 文
课题名称:
论如何应对软件项目需求变更
学生姓名 王剑波
学 号 44
专 业 项目经理
班 级 PM-31
2008年 5 月
目录
前言3
1、案例项目概述4
1.1贵州省XXX银行卡业务项目4
1.1.1项目概述4
1.1.2需求变更的影响4
1.2四川省XXX银行信贷风险管理系统5
1.2.1项目概述5
1.2.2需求变更的影响6
2、需求变更理解6
3、软件项目为什么会出现需求变更6
4、需求变更的代价7
5、需求变更遵循原则8
6、需求变更的处理9
6.1需求变更的预防9
6.2需求变更采用方法11
6.2.1方法111
6.2.2方法216
6.2.3方法317
6.3需求变更管理工具22
7、结论24
论如何应对软件项目需求变更
作者及单位:
王剑波四川日达计算机有限公司
前言
需求变更是软件项目一个突出的特点,也是软件项目最为普遍的一个特点。
虽然这与人类认识问题的自然规律是一致的,但是频繁而无管理的需求变更非常容易导致复杂、无形的软件在多变的情况下失控,加剧了软件开发过程中的不稳定性,从而造成多方的损失。
那么如何对需求变更加以有效的控制和管理,从而保证软件开发的进度、成本和质量,便成为软件开发过程中一个值得思考的问题。
1、案例项目概述
1.1贵州省XXX银行卡业务项目
1.1.1项目概述
贵州省XXX银行卡业务项目2005年7月启动,2006年3月结项。
此项目主要是完成贵州省XXX银行核心业务系统卡业务交易和管理功能的开发。
主要功能模块有:
开卡交易、销卡交易、卡存款交易、卡取款交易、卡转账交易、卡密码修改交易、卡状态管理、卡对帐管理、卡授权交易、POS交易、ATM/CDM交易、卡业务批处理、报表管理等模块。
1.1.2需求变更的影响
此项目按合同是2005年12月完成,可是由于以下原因造成项目延期3个月,导致此项目不仅损害了公司利益,也对客户产生了不良的影响。
导致项目延期的最大“功臣”是需求的不断变更。
卡业务对于农村信用社来说,是比较陌生的业务种类,没有可以借鉴的模式,更没有实际的经验,导致在做需求分析时,需求组基本上对项目组提出的方案没有太多意见。
加之项目上线时间急,根本没有充足的时间来对各方面需求做充分的考虑和评估。
一开始就注定项目不会顺利完成。
在项目设计阶段和开发阶段,客户没有提出需求变更,需求变更出现在招集业务骨干统一测试时,由于测试人员业务水平和理解不一样,提出很多需求变更。
有的是在业务基线以外的,有的根本是推翻的系统的设计等等。
测试完汇总需求变更,经过各级讨论(客户提要求按需求变更修改)最终决定修改。
此次改动就是一次重新设计,最终导致项目延期。
1.2四川省XXX银行信贷风险管理系统
1.2.1项目概述
四川省XXX银行信贷管理系统(SCMS)是为了对XXX银行贷款进行全面、严格、规范的管理,实现XXX银行贷款业务操作流程化,信贷管理科学化,信贷风险控制标准化。
四川省XXX银行信贷管理系统(SCMS)项目第一期实现的目标是:
在2007年12月31日前完成以下功能:
信贷基础管理功能
贷前受理、调查功能
贷款审查、审批与风险提示功能
贷款发放管理功能
贷后管理功能
角色权利与参数配置功能
贷款帐务信息功能
提供全面灵活的信息资料导入和录入手段功能
第二期:
于2008年8月31日前完成以下功能的开发。
非信贷资产风险分类管理功能。
综合信息管理功能。
接口管理功能。
贷后管理中的诉讼管理和风险代理功能。
贷款监控与预警提示功能。
第三期:
于2009年6月30日前完成以下功能的开发。
定价功能。
信贷人员的业绩考核评价功能。
贷款营销功能。
数据分析功能。
风险管理功能。
1.2.2需求变更的影响
此项目是正在实施中的,第一期已经延期。
最大“功臣”也是需求变更。
造成需求变更原因如下:
一、第一期从立项、需求分析、设计、开发、测试总共项目时间为3个月,3个月对于一个中型软件项目来说,确实太短了。
以致于各个环节都是按照先保证能按时上线的前提下做需求,流程和环节能省就省,需求分析时也没有作太多的研究,就进入了下一阶段的工作。
二、业务人员对业务规则理解不深、不全,边开发,边学习制度;边学习制度,边提出需求变更。
整个项目乱成了一锅粥,业务人员直接和开发人员交流,不需要任何需求变更审批流程,就直接修改程序。
导致文档,设计、需求不统一,项目处理失控状态。
2、需求变更理解
软件需求是整个软件项目的最关键的一个输入,和传统的生产企业相比较,软件的需求具有模糊性、不确定性、变化性和主观性的特点,它不像生产汽车、电脑等硬件的需求,是有形的、客观的、可描述的、可检测的。
软件需求是软件项目最难把握的问题,同时又是关系项目成败的关键因素,因此对于需求分析和需求变更的处理十分重要。
3、软件项目为什么会出现需求变更
需求变更的表现形式是多方面的,如老板临时改变想法、项目预算增加或减少、客户对功能的需求改变等。
在IT项目中,变更可能来自方案服务商、客户或产品供应商等,也可能来源于项目组内部。
虽然需求变更的表现形式千差万别,但究其根本不外乎以下几种原因:
1、范围没有圈定就开始细化
细化工作是由需求分析人员完成的,一般是根据用户提出的描述性的、总结性的短短几句话去细化的,提取其中的一个个功能,并给出描述(正常执行时的描述和意外发生时的描述)。
当细化到一定程度后并开始系统设计时,范围会发生变化,那细节用例的描述可能就有很多要改动。
如原来是手工添人的数据,要改成根据信息系统计算出来,而原来的一个属性的描述要变成描述一个实体等。
2、没有指定需求的基线
需求的基线是指是否容许需求变更的分界线。
随着项目的进展,需求的基线也在变化。
是否容许变更的依据是合同以及对成本的影响,比如软件整体结构已经设计出来是不容许改变需求范围的,因为整体结构会对整个项目的进度和成本有初步预算。
随着项目的进展,基线将越定越高(容许的变更将越少),其过程如下:
变更请求----比较基线----变更实现。
3、没有良好的软件结构适应变化
组件式的软件结构就是提供了快速适应需求变化的体系结构,数据层封装了数据访间逻辑,业务层封装了业务逻辑,表示层展现用户表示逻辑。
但适应变化必须遵循一些松祸合原则,各层之间还是存在一些联系的,设计要力求减少会对接口入口参数产生变化。
如果业务逻辑封装好了,则表示层界面上的一些排列或减少信息的要求是很容易适应的。
如果接口定义得合理,那么即使业务流程有变化,也能够快速适应变化。
因此,在成本影响的容许范围内可以降低需求的基线,提高客户的满意度。
4、需求变更的代价
一般来讲,需求的变更通常意味着需求的增加,需求的减少相对很少,而且处理需求减少方面的问题也比较容易。
当客户提出新需求的时候,项目开发人员应该分析这些新需求对项目现阶段带来的风险,得出双方实现变更需求的需要的成本,包括时间、人力、资源等等方面。
变更都是有代价的,应该评估一下变更的代价和对项目的影响,在评估代价并且与客户讨论的过程中,要让客户了解变更的后果,变更之后面临最大的问题就是项目延期,让客户一起做判断:
“我可以修改,但您能接受后果吗?
”。
现在会出现三种可能:
客户接受延期这一后果,开发人员按客户要求做出相应修改,让客户知道为此需要付出延期的代价;如果客户认为代价太大,那开发人员就不必修改了,可以记录下需求,待到下一版本再做修改;客户不接受变更的代价,导致项目夭折。
如果客户不知道你为变更付出的代价,对你的辛苦便难以体会,以致没完没了的提出新的变更。
5、需求变更遵循原则
需求变更是因为需求发生变化。
根据软件工程思想,需求说明书一般要经过论证,如果在需求说明书经过论证以后,需要在原有需求基础上追加和补充新的需求或对原有需求进行修改和削减,均属于需求变更。
需求变更的出现主要是因为在项目的需求确定阶段,用户往往不能确切地定义自己需要什么。
用户常常以为自己清楚,但实际上他们提出的需求只是依据当前的工作所需,而采用的新设备、新技术通常会改变他们的工作方式;或者要开发的系统对用户来说也是个未知数,他们以前没有过相关的使用经验。
随着开发工作的不断进展,系统开始展现功能的雏形,用户对系统的了解也逐步深入。
于是,他们可能会想到各种新的功能和特色,或对以前提出的要求进行改动。
他们了解得越多,新的要求也就越多,需求变更因此不可避免地一次又一次出现。
这时,如果开发团队缺少明确的需求变更控制过程或采用的变更控制机制无效,抑或不按变更控制流程来管理需求变更,那么很可能造成项目进度拖延、成本不足、人力紧缺,甚至导致整个项目失败。
当然,即使按照需求变更控制流程进行管理,由于受进度、成本等因素的制约,软件质量还是会受到不同程度的影响。
但实施严格的软件需求管理会最大限度地控制需求变更给软件质量造成的负面影响,这也正是我们进行需求变更管理的目的所在。
实施需求变更管理需要遵循以下六大原则
(1)建立需求基线,需求基线是需求变更的依据。
在开发过程中,需求确定并经过评审后(用户参与评审),可以建立第一个需求基线。
此后每次变更并经过评审后,都要重新确定新的需求基线。
(2)制订简单、有效的变更控制流程,并形成文档。
在建立了需求基线后提出的所有变更都必须遵循这个控制流程进行控制。
同时,这个流程具有一定的普遍性,对以后的项目开发和其他项目都有借鉴作用。
(3)成立项目变更控制委员会(CCB)或相关职能的类似组织,负责裁定接受哪些变更。
CCB由项目所涉及的多方人员共同组成,应该包括用户方和开发方的决策人员在内。
(4)需求变更一定要先申请然后再评估,最后经过与变更大小相当级别的评审确认。
(5)需求变更后,受影响的软件计划、产品、活动都要进行相应的变更,以保持和更新的需求一致。
(6)妥善保存变更产生的相关文档。
6、需求变更的处理
6.1需求变更的预防
按照现代项目管理的概念,一个项目的生命周期分为启动、实施、收尾三个过程。
需求变更的控制不应该只是项目实施过程考虑的事情,而是要分布在整个项目生命周期的全过程。
为了将项目变更的影响降低到最小,就需要采用综合变更控制方法。
综合变更控制主要内容有找出影响项目变更的因素、判断项目变更范围是否已经发生等。
进行综合变更控制的主要依据是项目计划、变更请求和提供了项目执行状况信息的绩效报告。
为保证项目变更的规范和有效实施,通常项目实施组织会有一
1、项目启动阶段的变更预防
对于任何项目,变更都无可避免,也无从逃避,只能积极应对,这个应对应该是从项目启动的需求分析阶段就开始了。
对一个需求分析做得很好的项目来说,基准文件定义的范围越详细清晰,用户跟项目经理扯皮的幌子就越少。
如果需求没做好,基准文件里的范围含糊不清,被客户抓住空子,往往要付出许多无谓的牺牲。
如果需求做得好,文档清晰且又有客户签字,那么后期客户提出的变更就超出了合同范围,需要另外收费。
这个时候千万不能手软,这并非要刻意赚取客户的钱财,而是不能让客户养成经常变更的习惯,否则后患无穷。
相对于需求来说,什么WBS、风险管理、计划进度都是次要的,只要需求做好了就会一帆风顺。
2、项目实施阶段的需求变更
成功项目和失败项目的区别就在于项目的整个过程是否是可控的。
项目经理应该树立一个理念——“需求变更是必然的、可控的、有益的”。
项目实施阶段的变更控制需要做的是分析变更请求,评估变更可能带来的风险和修改基准文件。
控制需求渐变需要注意以下几点:
需求一定要与投入有联系,如果需求变更的成本由开发方来承担,则项目需求的变更就成为必然了。
所以,在项目的开始,无论是开发方还是出资方都要明确这一条:
需求变,软件开发的投人也要变。
需求的变更要经过出资者的认可,这样才会对需求的变更有成本的概念,能够慎重地对待需求的变更。
小的需求变更也要经过正规的需求管理流程,否则会积少成多。
在实践中,人们往往不愿意为小的需求变更去执行正规的需求管理过程,认为降低了开发效率,浪费了时间。
但正是由于这种观念才使需求逐渐变为不可控,最终导致项目的失败。
精确的需求与范围定义并不会阻止需求的变更。
并非对需求定义得越细,就越能避免需求的渐变,这是两个层面的问题。
太细的需求定义对需求渐变没有任何效果。
因为需求的变化是永恒的,并非需求写细了,它就不会变化了。
注意沟通的技巧。
实际情况是用户、开发者都认识到了上面的几点间题,但是由于需求的变更可能来自客户方,也可能来自开发方,因此,作为需求管理者,项目经理需要采用各种沟通技巧来使项目的各方各得其所。
3、项目收尾阶段的总结
能力的提高往往不是从成功的经验中来,而是从失败的教训中来。
许多项目经理不注重经验教训总结和积累,即使在项目运作过程中碰得头破血流,也只是抱怨运气、环境和团队配合不好,很少系统地分析总结,或者不知道如何分析总结,以至于同样的问题反复出现。
事实上,项目总结工作应作为现有项目或将来项目持续改进工作的一项重要内容,同时也可以作为对项目合同、设计方案内容与目标的确认和验证。
项目总结工作包括项目中事先识别的风险和没有预料到而发生的变更等风险的应对措施的分析和总结,也包括项目中发生的变更和项目中发生问题的分析统计的总结。
6.2需求变更采用方法
6.2.1方法1
需求变更管理方法1也称(变更管理七步法)。
七步法印证了项目管理三部曲:
细化、量化、图形化,七步法主要验证了细化和量化的必要性和好处。
我们先来看看下面这幅图:
图一:
项目管理三角形
大家一看就明白了:
噢,原来是项目管理三角形,扯上它干吗呀。
范围可以理解为一个项目需要完成的内容的多少,而时间质量和成本则意味着完成这么多内容的工作必须投入的时间成本以及对应的质量水平。
我们再看下面这幅图:
图二:
项目管理三角形
这幅图一看就不得劲,为什么?
第一副图中三角形内切于圆,而第二副图则完全破坏了这种内切关系,所以显得不伦不类。
为什么应该内切?
工作任务与投入应该相适应,这么一个常识性的东西在我们的IT行业中竟然被破坏得极为彻底!
好,下面我们就一起来看看怎么样这样一幅项目三角形的图形来讲理!
正如我们从变形的项目管理三角形所得到启示:
项目范围变了,对应的时间、质量和成本也应该发生变化!
我们首先来看下面这张变更表
表一:
变更表
所以一看这个表您就明白了,其实这个表反映了一个最朴实的道理:
就是项目三角形在发生变形时需要保持的对应关系。
大家会说,我看明白了,可是这张表应该怎么去使用?
谁去填表?
什么时候填表?
如果有人不愿意填,那该怎么办?
下面我们分七个步骤来讨论操作中可能会遇到的问题
第一步:
变更申请。
首先得说到变更流程的事情。
不管什么样的变更,首先都有第一步:
变更申请。
有人就不乐意听了:
我们的客户都是“变更命令”!
这个回头再说。
只要有人提出变更,我们就称之为变更申请。
我们来看第一节变更内容描述:
大家会说哎呀,这个首先行不通!
我们的客户从来都是口述,打电话或当面交流。
这个我们不怕,客户只要说出来,我们是不是就可以记录下来(有人又不高兴了:
凭什么他说我记呀?
别急,这样做对项目组有好处)?
除非客户不做任何表示让我们猜哑谜,我们是一定能够把客户的需求变更转成文字记录。
大家可能又会说,我们可以帮他们记录,可是他们不愿意签字那怎么办?
签字不是关键,此处我们关心的是把变更描述记下来,我们能不能把纪录的描述给客户看,客户会不会翻脸不认账:
“不是我说的!
”?
不会的,果真这样我们就不做了!
第一个问题是不是解决了?
往后看这可有点悬,什么叫对业务的影响呀?
客户要改需求还需要理由吗?
您说需要不需要?
有人可能会说那是客户的事情,我们干涉不了。
这个说法可是大谬不然也!
业务上不需要的功能我们为什么要做?
有人会说:
客户不需要的功能他们会提出来给我们做吗?
老大,您可是真糊涂了!
你还以为客户每提一个需求都那么深思熟虑吗?
所以得先让客户想一想!
又有人说了,您搞形式主义!
客户直接就写“如果做,对业务是极大促进;反之会对业务造成负面冲击”,你有什么办法?
如果有人竟然有这样的想法,我真是替你们的领导难过:
什么叫斗智斗勇?
你要动脑筋呀!
你能不能从客户的谈话中间去捕获信息?
!
你能不能去了解客户的业务了解变更的必要性?
!
!
当然可以,要不还做什么项目!
彻底成了客户的跟班了!
怎么样?
这个问题是不是也解决了?
第二步:
技术评审。
我们再看第二步:
技术评审。
技术评审评什么?
就是我们能不能做得了?
比如说有这么一个糊涂客户提出说他们要求订单的最大处理时间是0.1秒,你应该做什么?
直接告诉别人做不了。
当然,大部分情况下技术还是可以满足新需求的。
好,第二步问题也解决了吧?
第三步:
评价对工期的影响。
好,接着来看第三步。
第三步评价对工期的影响,有人可能马上会反驳说,工期评价没用,反正是自己消化掉。
其实此处将工期、成本、质量都要量化的重要目的之一就是强迫我们的项目组先要想清楚,一个变更意味着什么。
一定要把它落实到具体的数据上?
为什么?
我们在项目中、甚至工作和生活中,因为没有确切量化数据的情况比比皆是,而结果就是导致不必要的矛盾和摩擦。
这也就是为什么细化、量化、图形化,在细化的基础上去量化才有意义。
先看对具体活动工期的影响,可能是7天也可能是5天或其他;再看对于整体工期的影响,大家应该对关键路径的概念应该比较熟悉了。
一个额外活动的工期需要10天,但是体现在整体工期却不一定是10天,还有可能是5天或者是0天,因为它有可能正好是一项非关键路径上的活动。
所以这两种情况我们都要了解,简单吧?
好,第三步就这么简单。
第四步:
工作量估算。
来看第四步,第四步也不会有什么歧义。
因为一项变更有可能导致项目中需要添加新的人手(可能因为独特的技术背景),而现有的人员怎么样加班也是无济于事的,所以项目组人员可能会增加。
在看对应的工作量增加,这个应该相对容易,估算需要几个人(很多情况会是一个人)、多长时间(天或小时),自然工作量就出来了。
小时工资率是什么?
我们国内企业发工资一般会是基于工作天数的月薪,而许多外企则是基于工作小时数的月薪,所以这里有一个区别:
一天可以是8个小时也可以是18个小时,难怪我们国内企业加班是家常便饭:
没有请你周六周日来啊,不就是每天多那么几个小时嘛!
而外企加班相对少许多:
额外的工作时间要付加班费的(或许是工商局对它们看得比较严,而对我们国内的企业则网开一面的缘故吧)。
说远了,小时工资率的设定与计算可依据组织的特点设定,自己搞不定请财务部门帮你出个数吧。
人时乘以小时工资率不就是人员工作量对应的成本嘛!
其他的有时候可能涉及到材料费用、软硬件的采购费用、差旅费用等,我们统一将它归结为非人力成本好了。
这样我们将这两部分相加就得到需求变更对应的成本增加情况。
第四步也是这么一目了然,没有问题吧。
第五步:
对项目质量影响。
要说第五步还真不太容易给一个统一的建议,这得取决于项目组的情况。
如果项目组没有量化的历史数据参考,只能以定性的方式去描述需求变更对于项目不同阶段的影响。
例如我们在测试阶段的后期实施一项大的变更,那么它对测试阶段的质量影响是可以想见的:
因为引入新功能或更改功能,一定导致更多的缺陷,而在回归过程中如发现新的问题需要修改的话又可能带来更多的问题。
所以对于测试阶段的质量是负面的。
对于产品运行阶段的质量影响也是显然的:
系统的稳定性、可靠性、安全性可能都会受到波及。
当然,如果项目所在的组织有些历史数据作参考,那判断起来就容易多了。
如果变更的需求是30个功能点,又假定测试阶段缺陷密度是0.4/FP到0.8/FP之间,我们容易推测变更将导致增加的缺陷个数介于12到18个之间;而如果残余缺陷密度是0.02/FP到0.05/FP之间,则上线后暴露给客户的问题数目为0.6个到1.5个之间,也即一到两个。
我们将对质量的影响是不是也可做相应的分析?
当然喽!
第六步:
风险分析。
这个小节关注的是风险,变更往往意味着更多的功能,更多的功能意味着更多的工作要做,因而面临更多的变数,也即我们就常所说的风险。
比如说变更往往伴随着工期的延长,而对于在外地开发的项目此种情形尤其有可能导致项目组成员普遍的厌倦情绪,对应的风险表述就是项目组士气低下,导致工作效率下降,甚至会引起人员的流失,对于项目组来说不得不预见这种类型的风险,所以变更分析应该做出对应的风险分析。
第七步:
变更意见。
这一步就很简单了,主要是根据前面的给定的各方面信息权衡以后做出是否变更的决定。
有人又说了:
才不是呢,如果是需求变更,那一定得客户签字,客户如果不签字,我们一点招数都没有!
我们再一次退而求其次:
能不能把客户的名字写上,表明他(她)知晓这件事情?
应该是可以的吧
6.2.2方法2
对待客户频繁的、自上而下的需求变更,建议迅速采取以下办法应对,避免事态蔓延,不让客户养成随意变更的毛病:
1、 立即建议客户建立变更审批下达制度,要求明确审批环节、审批人员、审批事项、审批流程、审批表格样式……,目的有两个:
第一,将客户下达变更的流程尽可能地复杂化、官僚化和长期化,减少张嘴就来的非必要、非紧急、非合理、非高层领导意图的“无效变更”。
第二,留下书面依据,为今后可能的成本变更和索赔准备好“变天账”。
凡未履行审批程序的“变更”,一律是无效变更不予受理,在避免乙方损失的同时,也有助于减少客户无谓的风险。
让我们以“加强管理、优质服务”为理由,说服客户把变更审批流程变得更困难些吧!
2、 强化自身计划管理和节点控制的功夫,立即向客户正式提交一份各阶段主要工作节点和技术关键事项的完成计划,注明任何可能的变更必然引起的时间、事件、成本/工期的代价和增加的具体工作量,建议/要求客户配合这个计划,确定变更时限,控制变更规模,过时变更不候,离谱的变更不做,保大局弃小变,推进项目前进。
3、 对于已经形成惯例的零星变更,要努力争取“集中研究、批量处理”,每周或每两周甚至每月召开一次变更专题会议,集中研究处理这些零碎变更事项,主动控制好工作节奏,硬着头皮顶住要求随时处理这些零星变更的压力,尽量避免由于处理零碎变更而影响项目运行的总体态势。
4、 最后,按照客户爱走上层路线的习惯,乙方PM也要随机应变,手眼通天,善变求生,将有关措施和意见随时抄报双方最高层留档备案,采取简报、文件、传阅、抄报、抄送、会议等多种形式,掌握舆论主动权,逐步让不合理的随意频繁变更,成为客户不好意思开口的尴尬事件,尽快形成正常的项目执行氛围和良好的工作习惯,也为可能受到影响的项目和变更所带来的责任问题留下伏笔。
6.2.3方法3
需求变更控制一般要经过变更申请、变更评估、决策、回复这四大步骤。
如果变更被接受,还要增加实施变更和验证两个步骤,有时还会有取消变更的步骤。
针对变更控制流程,在实际工作中总结出了软件开发人员在需求变更管理实践中的几点对策:
一、对策
1、优先排序、分批实现:
每个需求的重要性是不同的。
由于资源或技术条件的限制,会显得“僧多粥少”,因此不可能把所有的需求一次完成。
怎么办?
把每个需求按照对效益的贡献打个分,排出个优先级来,优先级高的需求先实现,低的到一下版式本实现。
由于不断有新的需求进来,有的需求可能永远没有机会被子实现,但不紧,还是要记录下来,并一起参加排序,保证在每个版本发布时重要的需求先得到满足。
每个需求的实现是需要花时间的,没人有百分百的把握预估得很清楚,但借鉴过去的经验可以大概估算出人力成本,然后根据开发人员和开发周期得出可用人力投入作为上限。
从优先级高的需求中挑,直到挑中的人
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 如何 应对 软件 项目 需求 变更