需求变更谁之过?

这里不谈论因客观市场原因造成的需求变更,不谈论因项目预算原因造成的需求变更。这里的需求变更是指在项目的必要性依然存在,项目的总体目标依然稳定情况下的需求变更。

众所周知,开发人员最头疼的事情是当一个功能(甚至整个项目)开发完成以后,客户却要求变更需求,更改需求文档,从而造成额外的开发工作或者项目延期。在这种情况下,绝大多数开发人员都会理直气壮的把原因归咎于客户本身,是他们的需求有问题。但仔细想想,这些真的都是客户的错吗?

举例来讲,如果客户想要一把水果刀,需求人员经过调研、需求分析,形成了如下的需求文档交付给了开发人员:

1. 这把刀需要比较锋利
2. 这把刀不能生锈
3. 这把刀能削水果

开发人员拿到需求文档,便开始了编码实现,如下是开发出来的水果刀,符合需求文档上的所有需求。单元测试没有问题,集成测试没有问题,项目顺利到达了UAT阶段,可以想象UAT的时候,客户会怎么说,这把刀太大了,所以客户要求更改需求,再加上一条:刀的尺寸需要15厘米长,5厘米宽。

 

 

如上需求变更是客户造成的吗,当然不是,客户只是需要一把水果刀,而开发人员交付的这把大菜刀顶多只是满足了需求文档的要求,而不是客户的要求。

如何避免这种情况出现呢?试想一下,如果需求文档是这样的:“客户需要一把能方便的完成削水果的刀”,开发人员还会开发出来一把大菜刀给客户吗?当然不会,尽管开发人员也许会对“方便”的标准有疑问,但是通过与客户的沟通,完全可以更深入的了解客户对“方便”的需求,从而避免项目满足了系统满足了需求文档,却不满足客户需求的情况。

©️2020 CSDN 皮肤主题: 大白 设计师:CSDN官方博客 返回首页