|
这里不谈论因客观市场原因造成的需求变更，不谈论因项目预算原因造成的需求变更。这里的需求变更是指在项目的必要性依然存在，项目的总体目标依然稳定情况下的需求变更。
众所周知，开发人员最头疼的事情是当一个功能(甚至整个项目)开发完成以后，客户却要求变更需求，更改需求文档，从而造成额外的开发工作或者项目延期。在这种情况下，绝大多数开发人员都会理直气壮的把原因归咎于客户本身，是他们的需求有问题。但仔细想想，这些真的都是客户的错吗?
举例来讲，如果客户想要一把水果刀，需求人员经过调研、需求分析，形成了如下的需求文档交付给了开发人员：
1. 这把刀需要比较锋利
2. 这把刀不能生锈
3. 这把刀能削水果
开发人员拿到需求文档，便开始了编码实现，如下是开发出来的水果刀，符合需求文档上的所有需求。单元测试没有问题，集成测试没有问题，项目顺利到达了UAT阶段，可以想象UAT的时候，客户会怎么说，这把刀太大了，所以客户要求更改需求，再加上一条：刀的尺寸需要15厘米长，5厘米宽。
如上需求变更是客户造成的吗，当然不是，客户只是需要一把水果刀，而开发人员交付的这把大菜刀顶多只是满足了需求文档的要求，而不是客户的要求。
如何避免这种情况出现呢?试想一下，如果需求文档是这样的：“客户需要一把能方便的完成削水果的刀”，开发人员还会开发出来一把大菜刀给客户吗?当然不会，尽管开发人员也许会对“方便”的标准有疑问，但是通过与客户的沟通，完全可以更深入的了解客户对“方便”的需求，从而避免项目满足了系统满足了需求文档，却不满足客户需求的情况。
|
