需求就这样，怎么实现我不管，明天上线。
这个需求必须在节前上线，没有多余的人手增加了。
需求不变，时间能否往前赶一赶，老板催得紧。
作为产品经理，以上这些场景你一定都经历过。尤其是在业务和运营驱动的组织里，这种情况更是司空见惯。
尤其是面对一些强势的业务“爸爸”们提出的需求，累心的产品狗更是束手无策。
对于一个需求的落地，要经历“需求评估-方案制定-产品设计-UED设计-PRD评审-技术方案设计-技术实施-代码集成-测试-上线运维”等多个环节。
这是在保证质量以及严谨性的前提下，必要的“工程量”。
而对产品和技术细节不够了解的人，往往只能看到“需求方案-技术研发-测试上线”的短流程。
所以，当需求方和产品经理在评估需求时，往往因为这种认知差异而出现争执。
做业务或者做运营出身的人，很多是没有产品技术细节概念的，这是一个行业普遍现象，我们很难去改变。
曾经听过一位前辈开玩笑似的评价这种窘境：“你不懂，我不怪你，如果你不学，那我就要治治你”。
如何面对需求方更合理的压缩需求，做到有理有据，以优美的姿势回怼呢？
今天教你一招！
每个需求，都包含如下几个共性因素：范围、时间、质量、资源。
例如，一个需求包含三个子需求（范围），在现有团队人手下（资源），一周内必须完成（时间），且保证与现有体验持平（质量）。
我们可以用一个三维坐标轴来分别代表以上几个因素，并且根据每个轴的变动来衡量需求范围。
黄色部分的面积我们可以用来表示在一定条件下，能产出的需求数量和范围。
在时间、质量、资源都恒定的情况下，需求的范围就是恒定的。如果想整体扩大需求范围，那三个因素也得同步调整。
在团队个体能力一定的情况下：
如果想在固定时间内做更多需求，要么牺牲质量、要么增加资源；
如果想在固定资源下做更多需求，要么增加时间、要么牺牲质量；
如果想在固定质量下做更多需求，要么增加时间、要么增加资源；
物质守恒定律，同样适用在需求评估这件事上。
在产品设计和技术研发过程中，存在很大的不确定性，所以一般研发团队都会做一定的计划余量，目的都是为了应对这种不确定性的发生。
比如，可能因为技术研发过程中出现的技术难点，而导致延期；
也有可能是在测试的过程中发现一个重要逻辑的疏漏，产品和研发都需要重新返工；
所以，正是由于这种不确定性，才使得需求会经常延期。而对于不懂产品和技术的需求方，他们很难建立这种认知，从而造成不理解。
通常情况下，他们的反应是：“为什么这么简单的东西这么麻烦，要做这么久”。
对于产品技术细节没有概念的需求方，如果还不讲理、蛮横、不愿意倾听、不愿意学习，你可以试着用上面这个方法帮他分析一下。
知识分子打脸，自古以来都是动作优美的。
“你不懂，我不怪你，如果你不学，那我就要治治你”。
越发觉得，当年前辈说过的这句话，真是恰到好处、字字珠玑。
这下，你是否掌握了这个方法？当下次需求过来，你不知道该如何衡量或者压缩需求时，可以把这个框架用来试试。
都说做产品要方法论，但又不知道方法论到底是什么！
其实，方法论就在生活中，生活就在实践中。那些可复用的、可持续的、有效的实践总结，就是方法论。
如果下次你再遇到“需求就这样，怎么实现我不管，明天上线”这样的情况，你可以做如下回复：
“需求我明白，时间资源都有限，质量命脉不可缺，下个版本见！”
最后，别说我告诉你的！（突然感觉自己胸前的红领巾格外鲜艳）
推荐阅读
互联网职场黑话大全
把梁宁给你们请来了
