一个需求变更的故事

昨天我们的物流部门提了一个需求,希望我能为他们做一张出库明细报表,以便他们统计和核对数据。嗯嗯,这个很简单的说,复制一个类似的模板,替换下数据源,按日期分组,20分钟搞定!

这里简单插一下,介绍下我们系统中的报表的实现。报表是采用的第三方控件FastReport,通过设计报表模板—>定义报表(选择模板、分期规则、会计主体、报送对象)—>生成报表(即时、按分期规则自动)。

物流部的同事用即时报表功能看过后提了个新的需求或者是BUG,没有按仓库分组呀!亲!

汗呀,疏忽了,赶紧加上,5分钟搞定!然后。。。能不能按客户类型分一下呀?可以!还没开动呢,能不能按产品系列分一下呀?嗯???可以是可以的,不过,你这是要闹哪样呀?这样分真的好吗?我知道的业务不需要分这么细的呀。

咳咳。。。我们每天要做一个汇报,你看,我这个。。。。巴拉巴拉。。。

哦哦,明白了,亲,你这是需要一个汇总表呀,拜托说明白好不好。我们物流的妹子表示很无辜。。。。然后我又复制了一个模板,替换了数据源,搞定!妹子很高兴,表示这个汇总表实在是太棒了,以后她再也不需要手工统计数据了。

你看,用户的需求的提法总是这么地奇葩,要是我完全按物流描述的需求去做,那么:

1、原先的明细表被各种小计分割地支离破碎,破坏了原先合理的结构。虽然说对信息进行分组有利于阅读,但滥用分组必然导致无法正常阅读。

2、缺少真正需要的汇总表,汇总数据需要从明细表中获取,然后手工做汇总表

3、浪费我的时间,付出了劳动却没有产出价值。

这个例子非常有代表性,我们如果不深入理解业务,必然会被需求方的要求各种似是而非的要求牵着鼻子走。最后的产品也就必然变成似是而非的产品,然后改着改着就没法再改了,再改整个系统都要崩溃了。到那时候,什么MVC,什么设计模式,什么先进的技术架构都没法在你的系统面临崩溃深渊的道路上挽救你。

能够让你的系统稳健的唯一方法是深入地理解业务,搭建一个正确的业务架构,在需求发生变更的时候进行分析,在正确的业务里面实现正确的功能才能避免这种情况出现。

时间: 2024-10-10 12:30:12

一个需求变更的故事的相关文章

我们小组项目需求变更管理的方法。。

在每个项目中,客户会在原来的需求基础上进行需求改变或者增加需求内容,所以,一个需求变更管理方法在设计项目中有着十分重要的作用,用户可能在初期阶段对自己的 需求不是清楚,只能根据客户在深入的了解后才知道自己还有哪些需求是需要的.在我们的项目中选择了一个分级需求管理模式,那就是将需求进行分级: 一级需求:是客户提出的需求中最为重要,最需要先实现的需求,在本项目中,我们的客户需要一个简易的通讯软件,所以最重要.最为基本的是实现双方的信息传递和信息输出. 二级需求:它不会影响一级需求的实现,但是没有实现

需求变更的成本为啥着这么高?

软件开发过程中,需求变更是不可避免的. 需求发生变化的原因有很多种 1,前期需求调研不充分,导致错误理解需求 2,客户对需求的描述,认识不准确 3,需求分析人员能力差,输出错误的需求 4,随着时间推移,需求确实发生变化 其中,1和2是比较常见的原因.也是主要的原因. 需求发生了变化,那开发是不是要进行调整呢? 答案是肯定的,软件的目的就是为了满足客户的需求,不符合客户需求的软件是没有价值的. 前期需求调研后,客户对需求的确认,并不意味着后期需求不能发生变化,需求评审和确认只不过是一种仪式,他可以

《小团队项目管理》第三问 --- 如何看待客户的需求变更?

作为一名码农,在项目开发过程中经常会涉及到项目的需求变更,变更的理由也是多种多样,总结而来分为外部和内部,从外部讲,例如:为了顺应某行业新的工作操作规范,甲方要求现有项目在工作流程环节上进行局部功能的变更:从内部讲,通过对市场环境的不间断调研和数据分析,公司产品在同类产品竞争中处于不利地位,市场份额日渐缩小,那么我们的产品设计人员会积极行动起来对产品的整个定位和新业务展开新的思考以寻求更加稳健的创新突破口,这就会对项目产生一定的需求变更. 此图是从CSDN社区截取下的,我相信很多看到这个问题的筒

需求变更大讨论:需求变更的原因

 需求变更的原因 需求包括业务需求.用户需求和功能需求.业务需求(Business Requirement )反映了组织机构或客户对系统.产品高层次的目标要求,用户需求(User Requirement )描述了用户使用产品必须完成的任务,功能需求(Functional Requirement )定义了开发人员必须实现的软件功能. 会导致需求变更的原因会有很多,如老板临时改变想法.项目预算增加或减少.客户对功能的需求改变等.在IT项目中,变更可能来自方案服务商.客户或产品供应商等,也可能来源于项

作为产品人,如何更好的应对需求变更?

如何制定一份缜密的项目计划对于产品经理来说可能并不是项目中最难的事情,要应对计划之外的情况,才是最令大家头痛的地方.在项目实际推进过程中,不加控制的需求变更往往给项目带来沉重的负担和无法预料的风险.因此,设计一套合适的需求变更管理流程和规范,对项目和项目经理而言都是不可或缺的. 问题分析 首先对笔者所在项目做一个简单介绍:产品层面,我们是一个C端产品,需求主要来源于运营和策划,就产品阶段而言正处于转型期,现阶段主要以新功能探索为主:项目层面,由于功能较为复杂庞大,可切割空间不大,因此每个版本周期

如何控制项目需求变更管理

Trufun UML2建模工具.Trufun Bacon  需求管理工具. Trufun ALM全生命周期产品.Trufun 研发云管理工具等 按照现代项目管理的概念,一个项目的生命周期分为启动.实施.收尾三个过程.需求变更的控制不应该只是项目实施过程考虑的事情,而是要分布在整个项目生命周期的全过程.为了将项目变更的影响降低到最小,就需要采用综合变更控制方法.综合变更控制主要内容有找出影响项目变更的因素.判断项目变更范围是否已经发生等. 进行综合变更控制的主要依据是项目计划.变更请求和提供了项目

摆平客户的需求变更之表单扩展属性

客户永远是对的!客户的需求永远是多变的! 需求说明文档写得再详细,说改还得改,程序猿永远这么苦逼. 为了应对客户多变的需求,今天先说说表单的扩展属性.目的是在不修改代码,不重新发布程序的情况下完成表单的扩展. 先下下图: 从这个界面上可以定义如何对表单上进行扩展,在表单上增加一个什么控件,大小.内容.验证都可以的. DEMO地址:http://121.40.148.178:8080/ . 用户名:guest,密码:123456 是的,如果是下拉框的话还能绑定数据源,选择就可以完成,绑定了数据字典

码农的产品思维培养第2节----一个需求的奋斗史(人人都是产品经理)

今天我们继续坚持每日一节的产品思维培养,我喜欢在纸上画,喜欢做笔记.不是为了自己后面回去看,而是为了当时更好理解.不知道大家是否认同这点. 今天看到苏杰的一句话,其实和我之前讲过的是一致的,看来英雄所见略同,还是给大家分享一下"和学习任何领域的知识一样,建议大家在了解了知识框架之后,坚持"需求驱动学习"". 第二章,讲述的是一个需求的奋斗史.其实就是描述如何从用户那里得到需求,得到需求后如何处理的一个过程.今天,我们这一节讲如何从用户那里拿到需求. 用户研究,或者说

[转] 项目管理---项目经理如何应对客户的需求变更?

项目管理---项目经理如何应对客户的需求变更? 目录(?)[+] 相信做软件开发的我们,大家都有这样的体会,当我们辛辛苦苦的熬了几个月的通宵.加班后,终于完成了客户提出的V1.0功能需求,当我们大家准备按部就班的进行系统上线时,客户.企业用户突然改变了需求,不想这么做了,提出了新的需求,新的变动,这样对于我们整个团队来说,正如晴天霹雷,很恐怖的事情啊,因为有时候,用户只是简单的一句话,但是对于系统的调整来说工作量是非常大的. 需求变更,本应是客户的权力,但也是实施顾问的为难之处.如果确需变更,当