一个需求分析做的不够的案例

突然发现，这段时间被失败的项目包围着。其实认真想想，做了那么多项目，成功的不太记得了，失败的却总是纠缠着你。

这个项目，要说它失败呢。它还运行了2-3年，业务一直在用它在监控库存，很依赖它来制定订货数量和时间。要说它成功呢，到现在业务部门还不断地要求修这里改那里。

项目简介：是一个库存监控报警系统。系统每天计算那些东西的库存量低于一个标准值（该值根据时间段内的发料情况来设定，系统自动计算），把需要报警的列在页面上。业务人员每天查看。但因为库存保障这种东西，完全靠机器是靠不住的，因为有很多特殊情况。所以系统给的只能做参考，采购人员必须在基于系统给出的结果上，自己需要再查看其他参数（系统也列出来），以及其他情况来确定采购的数量。

人员配置：一个人

架构和技术：struts1+spring+hibernate , oracle

开发情况：当时我刚进公司，稀里糊涂领导就交了这个任务给我。于是我就乖乖地按照业务部门说的开发。其实这个项目也不困难，我自己一个人开发很快就完成了。

使用情况：开始用后，业务部门根据一些实际情况要求做出调整，因为我把所有的业务逻辑写在存储过程里（我真感谢我当时的做法），所以改起来其实很方便。然后，业务部门领导换了，但后来的领导也凑合着用这个系统，但提出一些新的想法，我又按照他的新想法，修修补补了一下。然后，有一天，我觉得老系统不好用，应该做的更好。刚好我比较闲。我就重新写了一个系统。把逻辑模块分的更清晰一些，并且为了减轻业务人员工作量，我做了一些功能辅助他们工作。

结果：让我万万没有想到的是，从此以后业务部门就疯狂向我提需求，疯狂到他们自己本部门的人都看不下去了。让我有挫折感：以前那么粗糙的系统，他们用起来还没有那么多问题，结果给他们做细了，反而问题多了。虽然我很烦，但是因为希望把事情做好，他们提出的需求，我基本上都满足。

让我重新思考这个系统的事件是：业务部门又提出一个新问题，他们以前没有提过的。要求我修改程序，我思考后，觉得不应该修改程序，因为业务人员只需要少操作一下，就跟我修改程序的效果一样。我跟业务人员说，结果他们很不高兴，找各种各样的理由。我突然意识到：不能改！因为，这样修修改改，不但让程序存在更多隐患，而且解决问题的效果很差。

然后我思考为什么这个项目会那么失败呢？追溯到源头，当时就没有好好做需求，第二次改写程序也没有做需求（这完全是我的责任，第一次因为不清楚状况；第二次因为自大造成，我觉得我对业务很了解，不需要跟他们谈了）。结果就造成做好后，业务部门这个要加一下，那个要改一下，占了我很多时间。是我做的最烦的一个项目。

解决方法：我打算找业务部门领导和我们领导，还有业务人员，一起讨论怎么解决这个问题。这个系统必须有个重点：要不让业务人员工作轻松；要不就保障库存。因为这两点一起实现，会产生很多问题。把问题讨论清楚，把项目范围圈定，我再做工作计划来重写或者修改这个系统。

这又一次告诉我，需求是多么重要。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/13353915/viewspace-610854/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/13353915/viewspace-610854/