home―88必发

网站首页 > 新闻中心行业媒体
网站首页 > 新闻中心行业媒体
利用优先级拥抱项目中的需求变更 -home―88必发-88必发唯一官网-首页 发布时间:2016-08-30    阅读次数:

    需求变更这件事,每个开发人员都遇到过,每个产品经理也都遇到过。

     以前,我们会追求需求不变更,但无论是产品型团队还是项目型团队,需求不变更都是天方夜谈,不可能实现的。即使把需求变更的成本提得很高,流程搞得很复杂,又要填变更单,又要几级经理审批,又要需求评审,依然无法避免。

     于是,团队的目标变成了少变更,希望尽量少的变更既能满足业务的需要,又能减少开发团队的反感。但‘少’是个相对的概念,我们无法在数量上区分什么情况是少。

     现在,在敏捷开发模式下,团队要拥抱变化,响应变化,甚至要积极变化。需求是在不停的变,但麻烦也来了,开发团队因为需求变更有了额外的支出,与产品经理的矛盾也在加深,变还是不变,成为产品团队与开发团队PK的永恒话题。

     显然,有效的变更是所有人员都不否认的,也是对用户有利、对公司有利的双赢结果。那么在变来变去之间,如何减少变更的成本,提高变更的收益呢?

     在这里我想谈的就是发挥需求优先级的作用。

     在软件需求管理中,有关于需求优先级管理的必要性、定义、识别方式等很多相关的内容,这里不再赘述。我们还是来看一个迭代过程当中比较典型的情况,随着迭代的进行,开发出来的交付物的增多,产品经理提出某个需求要变更,这个时候如何来做?

     如果这个变更是一个删除行为,即该需求不在本迭代做了,那通常容易解决,开发团队也乐于处理,但做为管理者要注意的是这里有开发成本的浪费。即使该需求没有投入开发,那也经过了需求评审、技术方案设计、测试用例撰写、交互设计输出等工作。不过这个既然不是与开发人员的矛盾之处,就不再多说了。

     如果这个变更是一个修改行为,即对正在开发中的某个需求进行修改,产品经理需要将变更交给开发团队进行可行性和工作量评估,如果工作量比原来启动会上的要少或相当,也问题不大,至少不影响迭代计划,大家都可以接受。如果工作量在增多,那就与新增需求的处理方式相同了。

     如果这个变更是一个新增的需求,需要投入更多的工作量,那么要想在有限资源的前提下满足迭代产出,就必须进行优先级调整,产品经理要明确这个变更是必须的、有条件的、还是可选的,开发团队用这个优先级来决定开发顺序。如果是必须的,且已经没有资源支持,那么就要重新评估未开发的需求优先级,对其他的部分进行降级等调整。同时,优先级的定义过程,也是产品和开发团队深入思考需求的又一个契机,会促进整个团队对需求、成本、目标方面的一致性理解。

     当然,这也为产品经理提了更高的要求,那些10个需求使用了10个优先级的产品经理,你这样的优先级定义你们Boss造吗?

     总之,需求变更不可避免,敏捷开发拥抱变更,但变更是有成本的,也是易于产生矛盾的,优先级定义就是缓解矛盾的工具之一,利用优先级,把好钢用在刀刃上。


Q Q

QQ在线咨询

扫一扫 关注88必发唯一官网
了解项目管理资讯

全国免费咨询热线 0755-26716122
在线留言