对于 IT人员,特别是作项目管理的,难免会提出一个问题:客户为什么总是反反复复。有感于自己的多年电信行业项目管理实践,也谈谈工程性项目的变更需求管理。项目经理博客
在自己的软件项目管理职业过程中,几乎天天面对用户的需求变更,切身感受到,如果不能有效处理这些需求变更,项目计划会一再调整,软件交付日期一再拖延,用户的耐性渐渐消逝,研发人员的士气也越来越低落,最后所有的人都在等待一个结果:项目最好马上结束。
在讨论问题解决之前,我们先了解一下目前在电信行业的需求变更。大家一向认为需求变更对开发商或集成商来说是个非常负面的因素,对项目来说是个巨大的风险。但现在很多一级系统集成商,比如神州数码思特奇,提出欢迎变更,欢迎风险的说法。问题在于我们有了很好的好应对变更的方法论,能够有效的应对变更,在风险中寻找机遇。项目管理者联盟
我们的秘诀就在于对需求变更的主动管理。具体说来:项目经理圈子
1:在项目合同中,成立变更控制委员会CCB),并规定严格的变更控制流程。一般而言,在合同阶段,我们客户是很乐意接受这种规范的管理方式的。
2:取得了合同阶段的主动后,在实施阶段的严格执行也很关键。不能因为严格执行变更流程,就影响和客户的关系,这方面就要依靠项目经理和技术经理的的管理和沟通艺术的。我们的目的不是让用户不提出变更,而是让用户不轻易,随便的提出变更。项目管理者联盟
3:对于用户提出的变更,可以看实际情况处理,站在客户立场上为客户考虑,有些需求,是可以引导客户在后期的项目中实现,这样也可以为公司带来好的项目机会。项目经理博客
在不断的学习和实践中,我总结了两点比较有效的方法,在软件研发阶段能够较好地解决这方面的问题。转自项目管理者联盟
需求分析阶段通过原型明确用户需求项目管理者联盟
在软件项目的需求分析阶段,有大量需求信息需要收集、筛选、加工,这是需求管理的开始。客户和研发两方面的人员对需求的理解呈现“大体上共识多,细节上差异多”的特点。即使通过反复沟通,最终在时间表限制之内也能拿出一份“用户需求说明书”,但是以实践经验,用户需求的描述永远是“不够清晰”、“不够明确”的。这主要是因为在这个阶段,所谓的产品都在大家的大脑中构思,在此阶段,原型开发是一个较好的辅助手段,它将存在于大家头脑中的虚境实实在在地表达出来,一个界面,几个控件,外观形式固定了,功能描述明确了,这就是研发部门对用户的需求理解。此时与用户再次沟通,用户基本上可以说出来:“这是我想要的”,或者“不,这不是我想要的,我要的是……”。一般情况下,原型之后的需求沟通就实际得多,双方的理解迅速向一个折衷方案靠拢,一个可以指导研发过程的需求说明书正式诞生了。项目管理者联盟
采用严格的需求变更管理流程项目管理者联盟
一旦需求分析阶段结束,此后如果用户要求有新的需求加入交付的软件系统中,需要走需求变更管理流程。这个流程必须在软件项目成立之初与用户约定好,一般的软件企业内部有需求变更的管理流程,可以向用户解释这种管理的必要性,直至与用户就此问题达成共识为止。不必担心用户不会接受,有过多次成功研发软件项目经验的需求变更管理流程,有着它不容置疑的合理性,这正是软件企业的经验和价值所在,用户最终会理解和同意的。club.mypm.net
需求变更管理流程各家企业有各家的做法,在我们项目组,通过变更管理流程软件来实现需求变更。步骤如下:项目管理者联盟
1:提出变更申请项目管理者联盟
(1):客户提出需求变更,提交给客户方责任人;项目管理者联盟
(2):客户方责任人审核需求变更,认为属于变更范围,允许变更,则转给我们责任人;如果不允许变更,则转给需求变更提出人,要求完成内容或取消需求变更;项目管理者联盟
2:变更评估项目管理者联盟
(1):我方责任人接收到需求后,初步了解需求,之后和客户进行沟通,详细化需求情况;项目管理者联盟
(2):初步估算变更产生的工作时间和费用情况;项目管理者联盟
3:变更决策项目管理者联盟
CBD对需求变更作出决策。由于其中设计到工作时间和费用,需要相关人员,包括客户参与作出决策。项目经理圈子
4:接收变更项目管理者联盟
双方达成变更的决定;项目管理者联盟
5:实施变更项目管理者联盟
针对达成的变更,实施变更;项目管理论坛
|