需求变更是软件工程项目中最为常见的问题之一,同时也是项目交付中最大的一个风险点,那我们看一下需求变更常见的一些问题和场景。

1、合同没有约束:甲方是上帝,我们做项目时有时会过于迁就甲方,没有做太多的交付约束或者没有验收标准,这在后期会存在很大隐患。甲方一旦想变更需求或者添加需求,乙方会很被动,大家有时会出现扯皮现象。所以建议在合同里附加一些,需求范围说明和验收标准。

2、甲方也不明白产品或项目要做成什么:这在现象往往在项目初期,大家沟通都很开心,描述者项目有什么有什么,但没有把它可视化出来,一旦到了项目执行层面,我们会发现,大家都忘记了当时说过的话。会造成项目来回变更,一个版本一个样都不为过。因为一个产品或者项目,在不同的角度都存在主观性,大家都会有很多想法,但很多时候有没有对与错,所以尽量把需求原型化,然后再确定好,再然后就是要去执行,哪怕是错的,再然后再去根据用户使用去完善。

3、需求确认太含糊:需求确认是一个很严肃的过程,很多时候该确认的时候大家都忙,或者说就先这样做吧,但结果会发现,你做出来了,不是他想要的。所以一定要严格去做需求确认。还要也可以用Scrum敏捷开发的模式去小版本迭代。

需求变更并不可怕,也是一种常态,我们只有做到相对的减少。最好还是建议在做项目管理时可采用一些项目管理工具来去梳理,做到相对的量化和大家心中有数。