[转]需求变更的烦恼

客户今天要求变更需求,加某某功能,“这个应该不难吧,某某公司的产品都有这个功能的。”客户的需求一直在变,烦恼。。。

 

开始是需求不明确,客户都不知道要做成什么样,只有一个大概的粗略的描述。等到大楼盖好了,给客户,却发现大楼应该是这样那样的。。。客户方和开发方在一起( WorkShop) 还好,如果分开在两地就更糟糕。。。

 

永远不变的就是变化,这个大家都知道,但关键是如何合理的控制需求变更?

 

我以前做的上百人一年多一个的大项目,完全按照CMMI Level3规范来控制需求变更的。起初有双方签字的经过评审的需求基线,以后需求变更的时候有需求变更委员会(CCB)或专门负责的角色(通常由客户方需求人员来收集和评估最初需求并提交给QAQA牵头需求变更流程)来处理需求变更,具体做法是:

1.         先是客户或项目组成员提出的需求申请,填写《变更申请单》并提交给项目经理。

2.         项目经理组织项目相关人员对需求变更进行评估和调研,然后组织 需求变更评审。

3.         如果同意变更则由CCB授权配置管理员检出配置项由项目组成员对相关的文档(用户需求说明书、需求规格说明书)进行修改,修改后评审(同时 填写《变更管理记录表》)通过后由高层经理审批,然后提交用户确认,最后纳入配置库,更新《需求追踪矩阵》,确保需求和工作产品的一致性;

4.         如果不同意变 更,则项目经理、部门经理与客户共同协商,协商后同意变更,则对相关的文档进行修改。协商后依然不统一,则需求变更结束。

5.         所有的需求变更都需要总经理理进 行审批。需求变更的影响:利用《需求跟踪矩阵》对变更影响进行评估;估计对项目参数的影响规模、工作量、进度影响;超出阀值(整个项目进度的10%- 15%,里程碑30%)的,应提交高层评审/批准。

6.         妥善保存变更产生的相关文档。

 


现在公司做的项目规范较小,完全按照
CMMI的规范来有点多余,所以我们基本上类似于敏捷开发的模式。敏捷编程是拥抱变化,持续重构和改进,迭代开发,频繁交付。在需求变更管理上我们还没有一套完整的合适的流程,具体做法是:

1.         客户提出新需求;

2.         开发人员或项目经理评估后答应了;

3.         继续开发,时间表按照重新评估后的进行;

4.         基本上很少拒绝客户;一方面是为了维护客户关系,另一方面对自己team的开发能力很自信; 结果是上头答应了客户,下头的只能加班加点赶工。 

 

另外还有一些控制需求的做法: 

1.         项目前期会首先快速开发一个产品原型(Prototype)给客户,有界面的先用visio画个界面,以验证业务规则、业务流程和大概GUI等。另外,产品原型也有助于进一步挖掘用户的需求。 

2.         会粗略的列出大体的需求并签字 

3.         频繁交付给客户,短周期的交付可工作的产品,以印证需求与实现是否一致,同时兼做客户教育工作。

 

问题是如果需求变更无休止,则需求变更几乎就不可控,项目开发也无休止。所以我觉得我们公司在需求管理上还缺乏:

1.         需求基线管理,经过评审的双方确认签字的需求基线。以后如果要超出或修改需求基线,则必须有专门的人员对此提出异议,由CCB审核后方可修改;

2.         专门的需求控制负责人。现在基本上是技术人员或是项目经理收到客户需求变更,然后自己评估下就答应了。缺乏专门的需求控制负责人,因而没有需求评审,没有一套专门的严格可控的需求变更流程。

3.         需求功能点列表的书面确认。现在签的只是非常粗略的大体需求,定性而没有定量,以后扯皮发生的可能性非常大;

4.         适 当时候应该拒绝客户的要求。虽然用户有众多的理由,比如他认为改动不大,竞争对手已经拥有该功能,或是新的业务需要,但如果评估后的结果是没有必要,或不 合理,或优先级不高,或风险大于必要,则坚定的拒绝。另外一种变通的方法是,根据优先级重要性有条件的答应,比如放在下一次版本之后。

5.    需求Scope的管理,不仅要明确做什么,而且要明确不做什么。什么是我们负责的,什么不是我们应该负责和提供的。 

另 外在需求变更管理中,和客户有效的沟通、协调和教育非常重要。说的好点,就是“要讲究沟通的艺术”,“多引导客户”;说得俗点,就是“摆平客户”。如果能 够对客户进行很好的客户教育,很多时候客户是可以理解开发过程中的困难,从而达到妥协或折中。比如客户理解了项目后期进度紧张,技术架构难以大改,就会在 资源、进度、功能上做一些折中的选择,比如把功能分主要功能先实现,次要功能后实现;核心业务保稳定,次要业务不能牺牲核心业务的稳定性等等。反之,如果 没有和客户有效的沟通、协调和教育,则会双方各执一词,搞业务的只讲业务、流程和功能,不考虑技术可行性,不考虑资源和时间表;搞技术的只讲技术,没有倾 听客户的正当的商业需求,不能满足客户利益的最大化,这样双方就很难达成双赢的结果。所以,有效的沟通是软件项目成功的关键。

 

客户今天要求变更需求,加某某功能,“这个应该不难吧,某某公司的产品都有这个功能的。”客户的需求一直在变,烦恼。。。

开始是需求不明确,客户都不知道要做成什么样,只有一个大概的粗略的描述。等到大楼盖好了,给客户,却发现大楼应该是这样那样的。。。客户方和开发方在一起( WorkShop) 还好,如果分开在两地就更糟糕。。。

永远不变的就是变化,这个大家都知道,但关键是如何合理的控制需求变更?

我以前做的上百人一年多一个的大项目,完全按照CMMI Level3规范来控制需求变更的。起初有双方签字的经过评审的需求基线,以后需求变更的时候有需求变更委员会(CCB)或专门负责的角色(通常由客户方需求人员来收集和评估最初需求并提交给QAQA牵头需求变更流程)来处理需求变更,具体做法是:

1.         先是客户或项目组成员提出的需求申请,填写《变更申请单》并提交给项目经理。

2.         项目经理组织项目相关人员对需求变更进行评估和调研,然后组织 需求变更评审。

3.         如果同意变更则由CCB授权配置管理员检出配置项由项目组成员对相关的文档(用户需求说明书、需求规格说明书)进行修改,修改后评审(同时 填写《变更管理记录表》)通过后由高层经理审批,然后提交用户确认,最后纳入配置库,更新《需求追踪矩阵》,确保需求和工作产品的一致性;

4.         如果不同意变 更,则项目经理、部门经理与客户共同协商,协商后同意变更,则对相关的文档进行修改。协商后依然不统一,则需求变更结束。

5.         所有的需求变更都需要总经理理进 行审批。需求变更的影响:利用《需求跟踪矩阵》对变更影响进行评估;估计对项目参数的影响规模、工作量、进度影响;超出阀值(整个项目进度的10%- 15%,里程碑30%)的,应提交高层评审/批准。

6.         妥善保存变更产生的相关文档。


现在公司做的项目规范较小,完全按照
CMMI的规范来有点多余,所以我们基本上类似于敏捷开发的模式。敏捷编程是拥抱变化,持续重构和改进,迭代开发,频繁交付。在需求变更管理上我们还没有一套完整的合适的流程,具体做法是:

1.         客户提出新需求;

2.         开发人员或项目经理评估后答应了;

3.         继续开发,时间表按照重新评估后的进行;

4.         基本上很少拒绝客户;一方面是为了维护客户关系,另一方面对自己team的开发能力很自信; 结果是上头答应了客户,下头的只能加班加点赶工。

 

另外还有一些控制需求的做法:

1.         项目前期会首先快速开发一个产品原型(Prototype)给客户,有界面的先用visio画个界面,以验证业务规则、业务流程和大概GUI等。另外,产品原型也有助于进一步挖掘用户的需求。

2.         会粗略的列出大体的需求并签字

3.         频繁交付给客户,短周期的交付可工作的产品,以印证需求与实现是否一致,同时兼做客户教育工作。

 

问题是如果需求变更无休止,则需求变更几乎就不可控,项目开发也无休止。所以我觉得我们公司在需求管理上还缺乏:

1.         需求基线管理,经过评审的双方确认签字的需求基线。以后如果要超出或修改需求基线,则必须有专门的人员对此提出异议,由CCB审核后方可修改;

2.         专门的需求控制负责人。现在基本上是技术人员或是项目经理收到客户需求变更,然后自己评估下就答应了。缺乏专门的需求控制负责人,因而没有需求评审,没有一套专门的严格可控的需求变更流程。

3.         需求功能点列表的书面确认。现在签的只是非常粗略的大体需求,定性而没有定量,以后扯皮发生的可能性非常大;

4.         适 当时候应该拒绝客户的要求。虽然用户有众多的理由,比如他认为改动不大,竞争对手已经拥有该功能,或是新的业务需要,但如果评估后的结果是没有必要,或不 合理,或优先级不高,或风险大于必要,则坚定的拒绝。另外一种变通的方法是,根据优先级重要性有条件的答应,比如放在下一次版本之后。

5.    需求Scope的管理,不仅要明确做什么,而且要明确不做什么。什么是我们负责的,什么不是我们应该负责和提供的。 

另 外在需求变更管理中,和客户有效的沟通、协调和教育非常重要。说的好点,就是“要讲究沟通的艺术”,“多引导客户”;说得俗点,就是“摆平客户”。如果能 够对客户进行很好的客户教育,很多时候客户是可以理解开发过程中的困难,从而达到妥协或折中。比如客户理解了项目后期进度紧张,技术架构难以大改,就会在 资源、进度、功能上做一些折中的选择,比如把功能分主要功能先实现,次要功能后实现;核心业务保稳定,次要业务不能牺牲核心业务的稳定性等等。反之,如果 没有和客户有效的沟通、协调和教育,则会双方各执一词,搞业务的只讲业务、流程和功能,不考虑技术可行性,不考虑资源和时间表;搞技术的只讲技术,没有倾 听客户的正当的商业需求,不能 满足客户利益的最大化,这样双方就很难达成双赢的结果。所以,有效的沟通是软件项目成功的关键。

转载于:https://www.cnblogs.com/xiongbo/articles/2062355.html

  • 0
    点赞
  • 0
    评论
  • 0
    收藏
  • 扫一扫,分享海报

参与评论 您还未登录,请先 登录 后发表或查看评论
©️2022 CSDN 皮肤主题:大白 设计师:CSDN官方博客 返回首页
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值