“需求变更”这四个字，大家应该都切身感受过，对于程序猿来说，更是闻之色变！
原因或许大家都清楚，但今天这个神解释，实在是太形象了，忍不住想跟大家分享一下~
其实，程序员从不怕改需求，程序员怕的是不加钱且不给新加合理工作估时的改需求。
就比如下面这样：
前几天，你拿着图纸，告诉我挖一个30米深的井。
今天，你一拍脑门，突然告诉我，不好意思，图纸拿反了，其实是盖一个30米高的烟囱！
然后跟我说，你把那个井倒过来一下不就行了吗？一天够不够？
正所谓：
程序员对于改需求的抗拒，是有深层次原因的
我们再来几个改需求的例子，一起感受一下：
“房间太小，我们把承重墙砸了吧”——极大提高系统风险
“我们城市交通状况太差了，给你五百万预算，修一条地铁出来，三个月后验收”——低估修改的实际难度和成本
“这条路不应该只能跑汽车，我们还需要它能跑火车，飞机，轮船，火箭，以及未来可能诞生的所有交通工具”——过度追求“完美”
“这片林子我们不种松树了，改种洋槐。什么?已经种了一大半了?洋槐树苗上哪儿搞?那我不管，领导的意思你们敢不执行?”——强行调转大方向
“景区女厕所经常排大队，而男厕所基本不排队，所以我们应该让景区所有商铺都拒绝向女性贩卖饮料”——试图解决问题，但出现归因谬误
“根据调研，99%的人都会在蹲坑时看手机，所以我们应该设计让手机自动出纸，这样人们就不用担心蹲坑时没纸了”——试图解决问题，但忽视了产品本身的局限性
以下五个场景，赶紧收藏起来，包你成为职场老油条~
场景一：这个需求很简单！
老油条：简不简单，等技术评估完给你反馈。
场景二：需求这么简单，今天就可以做完吧？
老油条：等技术评估完给你反馈时间，技术评估估计一天时间，明天可以给你反馈。
场景三：大哥，这个需求改一下。
老油条：没问题，你把需求文档发出来，咱们走一个需求变更流程，咱们重新排任务优先级，重新评估时间，如果工作量不大，就不会影响整体进度。如果工作量很大，影响整体进度，我会通知项目的所有干系人。
场景四：大哥，项目交付时间已经定了，不能延期啊。
老油条：那咱们看看，哪些需求可以砍掉。
场景五：这个项目为什么:没做完/延期了?
老油条：因为某月某日发生了需求变更，我们进行了评估，最终决定，减需求/延期。并以邮件方式通知了所有项目干系人一。
——————————————————
无数次的需求变更
是谁都受不了
上「云队友」在家开启远程副业
100%合作前确定好需求
不再有需求变更
同时赚取可观收入
~
超多远程兼职等你来哦
