1.一个紧急需求
在互联网公司里，为了最大化人力资源，程序猿的时间会被安排得满满的，弹性时间不多。在某个周末，发现自己被拉到了一个小群，在里面，同事们讨论一个项目的进展及遇到的问题，氛围很积极。突然有个运营同事把客户的聊天截图到群里（聊天截图是老板客户在聊自己的做活动的方案），@你问，客户（用户）说的某功能我们可以实现不？实现要多久？
作为公司的技术研发部的程序猿，怎么能说不呢。于是埋头分析下客户（用户）要做的是什么。哦，原来是个送券功能，但这个功能有一部分与自己相关，有些部分自己不是很了解，马上翻下代码，发现应该可以实现。于是在群里反馈，说可以实现，但因有些部分清楚，需要专门花时间来评估。
2.完整做完要一周呢！
接下来自已抽时间对需求进行评估。对于一个未拆解的需求，在过来时，我们按自已的理解，罗列了修改清单，初步估算要一周。当这个时间反馈过去时，需求方会说太久了，项目要几天后就上线了，问下有没简单的方案。
我们反馈说，那可以只做关键的部分，如只发送抵扣券了，就不修改抵扣券了。对方赶紧问，那只做这个要多久？自己估算了下，开发加上测试应该3小时能完成，考虑上风险，一个下午吧，然后给出的时间是一个下午。这时需求方会说，只要半天，能否紧急支持下？
3.一个需求的流程
当一个紧急需求的插入，到最后无论程序猿是做还是不做，其实已经花费了很多时间。理解需求的时间，需求沟通确认，开始评估，到最后给出时间，其实已经花费了不少时间，实际这让产品来评估，确认要做时再来评估时间，这样会更好些。
在这里我们也需要了解需求的完整流程，从开始>需求评审>评估开发时间>项目经理决定要做>设计>进行开发。如果一个需求，自己也认为花费时间不多，就插入到自己的开发列表时，因为没有得到前面几个环节的确认，有可能会有“意外”的结果。
4.产品周期像生孩子
需求就像精子，有很多，数亿个，而开发一个需求相当于卵子，数量很少，资源富贵，因此可以进入开发的只有很少的需求。需求审核流程的目的是减少犯错，减少开发无用的功能，而如果自已跳过需求审核流程，自已插入需求，则有可能有这些问题：
- 开发中途或开发结束时，产品发现了，说这个需求在其它地方实现了，不用再次开发。想哭有木有！；
- 开发中途或开发接近完成时，运营同事说，改用其它方案了。生气！；
- 因为自已插入需求，导致开发原有项目延期。累！；
- 有其它开同事刚好有空闲，但因为你自已做主进行开发，他那边去做优先级更低的任务了。自已的错！。
- 因为自已考虑不周全，没考虑到要其它地方配合修改，导致上线时出bug。心累！；
- 缺少相关配置工具的开发，自己要花时间费来改配置，进而影响自已的开发节奏；
- 需求做完了，也上线了，但不是项目经理立项的需求，不进考核。无奈！
因此当未审核的紧急需求过来时，还是要周知项目经理与产品，避免自已忙错了。
