web项目经理手册-【4】需求变更管理

 需求变更管理是web项目管理中最重要的一个环节,需求变更管理的有效性直接影响项目的成功与否。

  对待变更的态度:
1、变更是不可避免的。
2、变更必须被管理。
3、积极发现引起变更的因素,促使变更尽可能早的出现,减低变更带来的风险。

需求变更管理的目标:
1、相关的干系人必须清楚地了解发生的变更。
2、变更处于有效的管理中。
3、尽量降低变更带来的风险。

  通过制定需求变更的流程,确保项目中的需求变更有效地进行,实现上述的目标。

  需求变更流程:
1、确定需求的基准线。
 通常我们会以User Case作为需求基准线,在User Case确认之后的任何需求改变,都需要走需求变更流程。没有走需求变更流程的需求将不被认可。

2、首先项目经理接收到需求变更的要求。
  需求变更的提出者可以是项目中的任何人包括产品经理、客服、开发人员、测试人员等。
 
3、项目经理评估该需求变更。
  项目经理可以召集相关人员讨论该需求变更的合理性、可行性,实施的代价以及对项目的影响。
 项目经理作为项目的负责人,对项目的成功负有主要的责任。所以需求变更的决策者应该由项目经理承担。
 
4、需求变更确认后由专人将需求变更记录下来(格式如下),通知给项目中所有成员。其中以下人员对需求的变更是紧密相关的,他们必须知晓并认可此需求变更。包括(客户方代表,需求分析师,测试人员,相关开发人员)。
需求变更表的格式:


序号


变更提出时间


变更描述


变更类型(是对原有需求的修改还是新增需求)


原因


变更提出者


开发人员


对进度的影响(工作量)

5、相关人员接收到确认的需求变更后,做以下事情。
需求分析人员修改需求说明书和User Case的相关内容。
测试人员修改测试用例的相关内容。
开发人员修改代码中的相关部分。

6、需求冻结
 项目越到后期,需求变更对项目的影响就越大,所以在一定时候我们会进入需求冻结阶段,不再接收需求的变更。

时间: 2024-09-30 15:32:49

web项目经理手册-【4】需求变更管理的相关文章

web项目经理手册-【5】项目经理的工作内容

一.项目经理的目标 1.满足项目利害关系者的不同需求. 清晰明确地了解每一个项目利害关系者的需求和期望,投其所好. 项目利害关系者包括:项目团队成员和项目团队外成员(比如各部门的部门经理,客服等). 2.保证开发项目按时保质的完成. 二.项目经理的职责 1.建立有效的流程保证项目的顺利进行. 2.制定详细周密的项目计划. 3.跟踪,推动项目按计划进行. 4.积极解决项目过程中出现的问题和冲突. 5.调动开发团队的积极性,创造力,推动团队成员在项目过程中不断成长. 三.项目经理的具体工作 1.项目

web项目经理手册-【7】项目经理需要铭记在心的话

1.项目经理不是来管人的,而是来支持人的.         解析:不光是项目经理,任何经理的职位都是如此.但现实中很多人并不是那么做,这也是为什么他们没能把项目做成功的原因.作为项目经理首先要端正态度,认识到这份工作职责的本质. 2.好的开始是成功的一半.         解析:一个好项目的失败,往往是由于前期的准备不足.计划不周密.所以在项目初期要舍得花时间做前期的需求收集.讨论.技术准备等工作.尽管前期的工作看起来并没有直接产生效益,但这块工作做好了,后面的工作往往会事半功倍.否则前期准备不

web项目经理手册-【2】开发时间估算

       项目经理制定项目时间表的时候,需要估算每个任务所需的时间,其中开发任务中模块的分配和时间估算是其中最主要的部分.本篇专门就这部分作一个阐述. 一.在分配模块和估算开发时间时,我们需要把握的原则和目标: 1.保证项目整体的进度. 2.有助于确保开发编码的质量. 3.有助于提高开发编码的速度. 二.每个公司都拥有自己的技术框架,开发人员主要的工作通常投入在具体的商业逻辑上. 通常每个模块所需的开发时间取决于以下三个因素: 1.该模块的商业逻辑的复杂程度. 2.开发人员的技术水平和对项目

web项目经理手册-【3】Code Review

    Code Review是保证项目中代码质量非常重要的一个环节,其主要工作是: 1.发现代码中的bug: 2.从代码的易维护性.可扩展性角度考察代码的质量,提出修改建议. 1.代码中的bug主要会出现在下列两个地方: (1) 与商业逻辑无关的bug.         比如,系统中打开的流/文件/连接等没有及时关闭:或是存在thread safe问题,或是存在性能低下问题等,这类问题对有经验的开发人员是比较容易发现的. 2.与商业逻辑相关的bug.         这类bug是非常隐蔽的,如

web项目经理手册-【1】版本控制流程

       大家在项目过程中是否会经常发生以下问题: 1.测试人员在测试阶段更新测试环境时,发现编译不通过,或者应用出现异常,无法进行测试.后来发现的根源是测试和开发共用一个分支. 2.有一天某个人群发了一条邮件通知,"我们的项目代码已经发到主干,这段时间大家不要修改主干信息",这样影响其他项目的正常发布. 3.项目进行了比较长的时间,等最后发布,需要与主干进行合并的时候,出现大量的冲突,几乎没法处理.而且冲突处理完后我们还需要重新再做测试,以保证我们的冲突处理没有问题,这样又会需要

应变之道 浅析需求变更管理

阅读提示:本文作者从项目管理的角度来讨论对变化需求管理的策略.首先是讨论在构建前需求的质量,然后说明了如何在构建过程中对需求进行跟踪,最后讲述了当真正发生需求变更的时候,我们应该如何去面对. 需求总是在变化,客户总会有新的想法,项目好像没有终结,我们软件开发人员应对软件需求变化时,为了拥有更多的准备,应该做些什么呢? 这个世界唯一不变的就是变化了.月有阴晴圆缺,潮涨潮落,千年前的沧海是现在的良田,这是自然界的变化:人有悲欢离合,生老病死,这是人情世故.变化是并不一定总是给我们带来惊喜,更多的是带

需求变更管理综述

需求变更是软件项目一个突出的特点,也是软件项目最为普遍的一个特点.虽然这与人类认识问题的自然规律是一致的,但是频繁而无管理的需求变更非常容易导致复杂.无形的软件在多变的情况下失控,加剧了软件开发过程中的不稳定性,从而造成多方的损失.那么如何对需求变更加以有效的控制和管理,从而保证软件开发的进度.成本和质量,便成为软件开发过程中一个值得思考的问题. 下面,我们将"需求变更管理"作为一个"项目",按照问题定义.需求分析.设计.开发等步骤,从软件工程的角度来加以分析,而这

浅谈项目需求变更管理

"项目一旦启动,变更也就随之而来." 变更是无法避免的,作为一个合格的项目经理,我们应该有有效的方法来管理项目变更. 先来看一个小案例: A公司正在实施一个业务系统项目,该项目包括人事行政部.信息部.业务部.财务部.生产部等多个部门人员. 系统采取外包的形式,雇佣了某知名软件B公司的10名开发人员. 系统实施时,出现了下述情况:A公司一个系统的用户向他所认识的B公司一个项目开发人员抱怨系统软件中的一项功能问题,并且表示希望能够进行修改.于是,该开发人员就直接对系统软件进行了修改,并告诉

需求变更的烦恼

客户今天要求变更需求,加某某功能,"这个应该不难吧,某某公司的产品都有这个功能的."客户的需求一直在变,烦恼... 开始是需求不明确,客户都不知道要做成什么样,只有一个大概的粗略的描述.等到大楼盖好了,给客户,却发现大楼应该是这样那样的......客户方和开发方在一起( WorkShop) 还好,如果分开在两地就更糟糕...... 永远不变的就是变化,这个大家都知道,但关键是如何合理的控制需求变更? 我以前做的上百人一年多一个的大项目,完全按照CMMI Level3规范来控制需求变更的