(原创)—需求混乱——项目失败之根源

　　项目的目的是在既定的时间内，用有限的资源做出符合客户需求的东西，把客户的实际
需求做成产品让客户检测并使用。这里有一个标准就是项目的目的——做出符合客户需求的
项目。

　　如果在项目的前期，你对项目的需求没有搞明白，那么你就不能保证做出的项目是符合
客户要求的，不能保证就意味着在没有搞清楚项目需求（至少是既有需求）前就开始进行下
一步的工作那是一种浪费。意味着一开始就错了，就失败了。

　　这正如建大楼打地基，如果地基打错了，基于此的框架设计，等等都是错误的。以后地
基要改动了，基于此的设计也要改动了。

　　Boehm(1981)发现要改正在产品付诸应用后所发现的一个需求方面的缺陷比在需求阶段改
正这个错误要多付出68倍的成本。近来很多研究表明这种错误导致成本放大因子可以高达200
倍。强调需求质量并不能引起某些人的重视，他们错误地认为在需求上消耗多少时间就会导
致产品开发推迟多少时间。传统的质量成本角度分析揭示了需求及其它早期质量工作的重要
性(Wiegers 1996)．——摘自《需求分析》

　　所以，我们要把软件发生的错误解决在萌芽状态。做好需求，有明确的需求目标。

例如：
　　我们公司(下称XX)在4月份接手了YY企业的一个项目D，YY企业负责人L要求我们公司9月1
号完成。接下来，XX公司把这个D项目交给M员工负责，要求M用两个月的时间做出D项目的需求
调研工作，同时XX公司分配给M两个员工Z，C协同M完成此事。
　　但是，M员工及Z,C 员工
　　1、他们根本不知道需求是怎么做的，没有需求调研的实际经验．
　　2、对YY企业的D项目的需求不了解，也没有进行实际的考察。

　　这样做出的需求模型是不是符合客户的需求，他们也没有保证。最后的需求文档也没有通
过客户审核。

　　最后，他们做出的需求仅仅让客户看了一下，长篇大幅的文字。YY企业的负责人L就说，按
照这个你么先做吧，做出来我们看看再说（也许L不明白M的需求，才让M做的一个原型）。

　　结果，可想而知，他们就开始向下做了。——这是一种错误，因为他们还不知道客户的真正
需求。

　　那么做好之后，L根本就不明白他们做的系统为什么是这个样。于是M又进行了一次需求调研。
再次开始做，从头再来。