需求变更是一个无法避免的事实,它会导致软件开发过程中产生成本增加、质量不过关等风险,而且越往后的变更产生的风险将越大。在项目实施过程中,项目经理所要面对的将是一系列和多方面的考验。经常发生的、也很令人头疼的恐怕就是需求的变更了。因此解决问题的方法应该以控制风险为出发点, 可能产生越大风险的事情就要越早解决。项目管理者联盟
1、需求变更的表现形式及原因项目管理者联盟
需求变更的表现形式是多方面的,如老板临时改变想法、项目预算增加或减少、客户对功能的需求改变等。在IT项目中,变更可能来自方案服务商、客户或产品供应商等,也可能来源于项目组内部。虽然需求变更的表现形式千差万别,但究其根本不外乎以下几种原因:项目管理者联盟
2、范围没有圈定就开始细化
细化工作是由需求分析人员完成的,一般是根据用户提出的描述性的、总结性的短短几句话去细化的,提取其中的一个个功能(用例比较专业点),并给出描述(正常执行时的描述和意外发生时的描述)。当细化到一定程度后并开始系统设计时,范围会发生变化,那细节用例的描述可能就有很多要改动。如原来是手工添入的数据,要改成根据XX计算出来,而原来的一个属性的描述要变成描述一个实体等。项目管理者联盟
3、没有指定需求的基线项目管理者联盟
需求的基线是指是否容许需求变更的分界线。随着项目的进展,需求的基线也在变化。是否容许变更的依据是合同以及对成本的影响,比如软件整体结构已经设计出来是不容许改变需求范围的,因为整体结构会对整个项目的进度和成本有初步预算。随着项目的进展,基线将越定越高(容许的变更将越少),其过程如下:变更请求->比较基线->变更实现。项目管理者联盟
4、没有良好的软件结构适应变化blog.mypm.net
组件式的软件结构就是提供了快速适应需求变化的体系结构,数据层封装了数据访问逻辑,业务层封装了业务逻辑,表示层展现用户表示逻辑。但适应变化必须遵循一些松耦合原则,各层之间还是存在一些联系的,设计要力求减少会对接口人口参数产生变化。如果业务逻辑封装好了,则表示层界面上的一些排列或减少信息的要求是很容易适应的。如果接口定义得合理,那么即使业务流程有变化,也能够快速适应变化。因此,在成本影响的容许范围内可以降低需求的基线,提高客户的满意度。项目管理者联盟
5、需求变更的控制策略项目管理者联盟
按照现代项目管理的概念,一个项目的生命周期分为启动、实施、收尾三个过程。需求变更的控制不应该只是项目实施过程考虑的事情,而是要分布在整个项目生命周期的全过程。为了将项目变更的影响降低到最小,就需要采用综合变更控制方法。项目管理者联盟
综合变更控制主要内容有找出影响项目变更的因素、判断项目变更范围是否已经发生等。转自项目管理者联盟
进行综合变更控制的主要依据是项目计划、变更请求和提供了项目执行状况信息的绩效报告。为保证项目变更的规范和有效实施,通常项目实施组织会有一个变更控制系统。变更控制系统是一个正式和文档化的程序,它定义了项目绩效如何被监控和评估,并且包含了哪种级别的项目文件可以被变更,包括文 处理、系统跟踪、过程程序、变更审批权限控制等。综合变更控制的结果主要有更新的项目计划、纠正措施和经验总结。项目管理者联盟
6、项目启动阶段的变更预防项目管理培训
对于任何项目,变更都无可避免,也无从逃避,只能积极应对,这个应对应该是从项目启动的需求分析阶段就开始了。对一个需求分析做得很好的项目来说,基准文件定义的范围越详细清晰,用户跟项目经理扯皮的幌子就越少。项目管理者联盟
如果需求没做好,基准文件里的范围含糊不清,被客户抓住空子,往往要付出许多无谓的牺牲。如果需求做得好,文档清晰且又有客户签字,那么后期客户提出的变更就超出了合同范围,需要另外收费。项目管理者联盟
这个时候千万不能手软,这并作要刻意赚取客户的钱财,而是不能让客户养成经常变更的习惯,否则后患无穷。相对于需求来说,什么WBS、风险管理、计划进度都是次要的,只要需求做好了就会一帆风顺。项目管理者联盟
7、客观面对需求变更项目管理者联盟
需求一定会变化,我们也不得不面对这种情况,那么用什么办法改善这种现状呢?下面我提几点建议。club.mypm.net
(1)、加强人员培训项目管理者联盟
从客观方面可以采取的措施来说,首先是加强对需求分析人员的培训,尽可能增强软件系统、行业的背景知识,提高与客户的沟通能力,增强服务意识和责任感, 因为将要开发的系统直接建立在需求分析的基础上;同时规范需求分析人员和客户沟通的方式,以及规范需求说明的格式,如果可能的话,尽量采取用户可以理解的图例来对需求进行标准、规范的描述,保证双方对需求达到共同的认识。项目管理者联盟
(2)、加强文档管理项目管理者联盟
需求文档是相当重要的,可是在做文档时大家普遍流于形式,文档也有,格式也正确,但没有人关心文档的真正内容是否正确,格式是否真的合理,是否实用,很多情况下是在几天时间里赶出来或补上去的。项目管理者联盟
结果往往是在需要文档时,文档找到了,完全符合格式的要求,可是在里面能找到的线索是有限的,结果还要花很长时间查找数据表结构、甚至查看数据表的内容,询问当时的开发人员,才分析到所要的关系。这种情况在设计文档里也存在,所以不管是开发人员、还是项目管理人员都要注意文档的有效性和有用性问题,甚至对文档的格式进行一下合理性检查。项目管理者联盟
(3)、项目实施阶段的变更控制项目管理者联盟
|