ITPub博客

首页 > Linux操作系统 > Linux操作系统 > 一个需求分析做的不够的案例

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

原创 Linux操作系统 作者:dearChloe 时间:2009-07-30 15:39:00 0 删除 编辑

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

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

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

人员配置:一个人

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

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

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

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

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

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

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

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

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

请登录后发表评论 登录
全部评论

注册时间:2008-03-28

  • 博文量
    15
  • 访问量
    33280