要么砍需求，要么砍需求方
猿兄：五哥，老板的意志又降临了要插入需求，你这个网站在这个时间点上线有点悬啊。
五哥：猿兄，是人手不够吗？我给你协调多点人呗。
猿兄：五哥，生1个孩子就算10个娘一块生还是要10个月啊，况且我们都把周末都拿来加班了，时间能不能宽松一点？
五哥：这时间点比较关键，也不好推迟。
猿兄：那你懂的...自己动手吧。
非技术瓶颈的项目，如果不能满足排期要求，三个选择，加人，加时间，砍需求（不砍需求也可以，砍需求方）
五哥还是很怕死的：我自己来，你们别插手。
拖出需求list，一阵大刀阔斧，砍完需求，心情痛并快乐着。（砍需求就是爽，如果不是自己需求的话...）
我们在需求评审，版本排期，甚至在开发过程中，都有可能出现版本无法按时上线的情况。砍需求，也是版本控制的有效手段，五哥分享一些如何避免、处理这种情况。（浅谈即止，五哥后续会有专题挨个进行分享。）
分清真伪需求
有问题都要从源头抓起。
不是所有的需求都是合理的，产品经理要把好第一道关，从产品、从用户、从业务的角度，分析这个需求是不是合理的，投入产出如何等，然后把那些不合理的需求过滤掉。
产品经理，不是需求的搬运工。如果我们都不过滤需求，那跟咸鱼有什么分别。
确定优先级
一张图片就能帮你快速确定优先级：
重要紧急的，优先处理，即使要砍需求，也坚决不能动。
重要不紧急的，可以评估对后面版本的影响，斟酌地进行保留或者砍掉。
不重要紧急的，都说不重要了，还那么急干嘛，有时间就做上去，没时间就砍掉。
不重要不紧急，这种需求都出在排期里，工作太不饱和了啊，要多动动脑思考一些痛点啊。
保证需求质量
这里的需求质量，不是指产品经理写的需求文档质量，而是这个需求的关键点程序猿们是否充分理解到。
有时候砍需求不是外部原因，而是在于产品经理有些需求没有想到位，想到位了没有传达给开发，传达给开发了他们没理解，在研发中后期发现问题导致排期不可控。
所以有事没事多找程序猿们谈谈人生，吃吃饭，讨论需求可行性也是极好的。
写在最后
产品经理从源头把控，多与上下游沟通，基本上很少会出现砍需求的情况出现；如果遇到突发情况插入的需求，也要判断这个插入需求的合理性，然后去找需求方进行协调；最后一定要砍需求了，也要很清晰的知道那些必须保留，抓大放小。
|
|
