如何用通俗易懂的语言解释需求变更带来的项目影响

如何用通俗易懂的语言解释需求变更带来的项目影响

你去饭店,坐下来。
“服务员,给我来份宫保鸡丁!”
“好嘞!”
——————这叫原始需求

大厨做到一半。
“服务员,菜里不要放肉。”
“不放肉怎么做啊?”
“不放肉就行了,其它按正常程序做,不就行了,难吗?”
“好的您稍等”
——————中途需求变更

厨房:
大厨:“你大爷,我肉都回锅了”
服务员:“顾客非要要求的嘛,你把肉挑出来不就行了吗”
大厨:“行你大爷”
然而还是一点点挑出来了
——————改动太大,部分重构

餐厅:
“服务员,菜里能给我加点腐竹吗?”
“行,这个应该简单。”
——————低估改动成本

厨房:
大厨:“你TMD,不知道腐竹得提前泡水?炒到一半才说?跟他说,想吃腐竹就多等半天”
服务员:“啊你怎么不早说?”
大厨:“早说你MLGB我怎么知道他要往宫保鸡丁里放腐竹”
然而还是去泡腐竹了
——————新需求引入了新研发成本

餐厅:
“服务员,还是把肉加回去吧”
“您不是刚说不要肉吗”
“现在又想要了”
“...好的您稍等”
——————某一功能点摇摆不定

厨房:
大厨:“日你啊,菜都炒过火了你让我放肉?还好肉我没扔”
服务员:“客户提的要求你日我干嘛?”
大厨:“你就不能拒绝他啊?啊?”
服务员:“人家是客户嘛。”
——————甲方是大爷

餐厅:
“服务员!服务员!”
“来了来了,你好?”
“怎么这么半天啊?”
“稍等我给您催催啊”
——————改动开始导致工期延误

厨房:
大厨:“催你M催,腐竹没泡好,我还得重新放油,他要想吃老的也行,没法保质保量”
——————开发者请求重新排期

餐厅:
服务员:“抱歉,加腐竹的话得多等半天,您别着急哈”
“我靠要等那么久?我现在就要吃,你们能快点吗?”
“行...您稍等”
——————甲方催活

厨房:
大厨:“我日他仙人板板,中途改需求又想按期交付,逗我玩呢?”
服务员:“那我问问,要不让他们换个菜?”
大厨:“再换我就死了”
——————开发者开始和中间人pk

餐厅:
“服务员,这样吧,腐竹不要了,换成蒜毫能快点吗?对了,顺便加点番茄酱”
——————因工期过长再次改动需求

厨房:
大厨:“我日了狗啊,你TM不知道蒜毫也得焯水啊?还有你让我怎么往热菜里放番茄酱啊??”
服务员:“焯水也比等腐竹强吧,番茄酱往里一倒不就行了吗?很难吗?”
大厨:“草。腐竹我还得接着泡,万一这孙子一会又想要了呢。”
——————频繁改动开始导致大量冗余

餐厅:
“服务员,菜里加茄丁了没有?我去其它饭店吃可都是有茄丁的”
“好好好您稍等您稍等”
——————奇葩需求

厨房:
大厨:“我去他二大爷他吃的是斯里兰卡三流技校炒的宫保鸡丁吗?宫保鸡丁里放茄丁??”
服务员:“茄丁抄好了扔里边不就行了吗?”
大厨:“那TM还能叫菜吗?哪个系的?”
服务员:“客户要,你就给炒了吧。”
大厨:“MB你顺道问问他腐竹还要不要,我这盆腐竹还占着地方呢不要我就扔了”
——————奇葩你也得做

餐厅:
“服务员,还要多久能好啊”
“很快,很快...”
“再给我来杯西瓜汁。”
“...好”
“我再等10分钟,还不好我就走了,反正还没给钱。”
“很快,很快...”
——————黑暗前的最后黎明

10分钟后
“咦,我上次吃的不是这个味啊?”
从厨房杀出来的大厨:“我TM就日了你的狗...”
——————最终决战

时间: 2024-10-14 06:52:17

如何用通俗易懂的语言解释需求变更带来的项目影响的相关文章

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

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

需求管理之勇于直面需求变更

软件系统开发过程中的需求变更问题 作为软件开发人员或者软件系统客户,相信我们都遭遇过因为需求变更而需要修改系统的情况,一般说来客户会要求改变界面,改变操作方式,甚至改变业务,说,当时我是那样要求的,不过现在我们的业务调整了-这时需要中断正在进行的工作,需要查证以往的资料,需要修正计划,需要- 需求包括业务需求.用户需求和功能需求.业务需求(Business Requirement )反映了组织机构或客户对系统.产品高层次的目标要求,用户需求(User Requirement )描述了用户使用产品

需求变更

需求变更是因为需求发生变化.根据软件工程思想,需求说明书一般要经过论证,如果在需求说明书经过论证以后,需要在原有需求基础上追加和补充新的需求或对原有需求进行修改和削减,均属于需求变更. 需求变更的出现主要是因为在项目的需求确定阶段,用户往往不能确切地定义自己需要什么.用户常常以为自己清楚,但实际上他们提出的需求只是依据当前的工作所需,而采用的新设备.新技术通常会改变他们的工作方式;或者要开发的系统对用户来说也是个未知数,他们以前没有过相关的使用经验.随着开发工作的不断进展,系统开始展现功能的雏形

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

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

需求变更,产品经理的良心也会痛!

引言:在项目执行过程中,产品经理与后续的合作团队,包括设计.开发.测试等相关人员最尖锐突出的矛盾,就是需求变更,这是产品经理最经常被诟病的地方.频繁的需求变更,对产品.项目进度和团队积极性都有非常大的危害.产品经理一定要不遗余力避免需求变更的情况.本文选自<爆款是怎样炼成的:产品经理晋级宝典>. 作为产品经理,我们一定要理解开发团队及其他团队成员为什么视需求变更为大敌.事实上,需求变更对整个项目都非常有害. 需求有变更,就意味着设计.开发团队的工作有浪费.这首先是资源和时间的浪费. 这会导致团

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

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

通俗的语言解释面向对象

面向对象: Jeff Goodell:请你用尽量简练的语言解释一下,究竟什么是面向对象的软件? 乔布斯:对象就像人一样,也是活生生的生命.他们有知识,知道怎么完成任务:他们有记忆,可以把发生的事情记下来.而你和他们的互动并不是低层次的,你是与他们在一个高度抽象的层面上互动,就像我们现在的对话一样. 我举个例子来说明.如果我是一个“洗衣”对象,你可以把脏衣服给我,然后告诉我说:“请帮我把这些衣服洗了吧!”而我恰好知道旧金山最好的洗衣房在哪,并且 我会说英语,兜里也有美元.于是我出门打了一辆出租车,

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

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

ios学习笔记图片+图片解释(c语言 oc语言 ios控件 ios小项目 ios小功能 swift都有而且笔记完整喔)

下面是目录其中ios文件夹包括了大部分ios控件的介绍和演示,swift的时完整版,可以学习完swift(这个看的是swift刚出来一周的视频截图,可能有点赶,但是完整),c语言和oc语言的也可以完整的学习完所需知识,,其他文件夹的内容如其名说描述一样 没张图片都有文字说明,可以需要该功能的时候搜索一下然后打开图片就可以学习到 网盘下载地址:需要的话给留言我再传上去 http://www.cnblogs.com/langtianya原创 ios学习笔记图片+图片解释(c语言 oc语言 ios控件