作为需求的接收方，不论是产品经理、BA还是研发，你可能在以往工作中听到过类似的需求：
- 某 App 有已读未回功能，我们也加一个类似功能。
- 他们的商城账户体系就是这么设计的，我们也可以这样设计。
- 如果没有思路，你们可以参考某公司的同款应用，我听他们宣讲过，做得不错。
- 我们数据系统没有这个数据，那就开个口子，让业务方上来输入数据。
- 我想要个销售漏斗。
- 我希望首页更有科技感，有沉浸式体验。
…
这些需求，有的凭主观判断，人云亦云。还未经过论证和分析（比如上述前三条），就告诉你：“需求就是这样的，这么做就行。”
有的偏离原有产品定位和打乱既有规划（比如第四条）；
有的需求模糊不清，或者价值目标不清晰（比如最后两条）；
对于那些仅凭主观判断，没有经过论证和分析的需求；那些打乱原有产品定位和规划的需求，不符合本身业务特性的需求；那些目标价值不清晰的需求……我们都可以称之为“拍脑袋”需求。
针对这些“拍脑袋”需求，接还是不接？如何接？这是个问题。
分析原始需求，有理有据应对
类似上述“拍脑袋”需求，需求方在提出时描述的可能并不是需求，而是一种解决方案；或者需求方在描述需求时，可能连自己都不知道到底想要做什么。
所以在回应这些“拍脑袋”需求时，首先应该进行需求分析，还原用户场景和问题，通过分析的数据和事实，有理有据的回应，从而帮助团队判断和决策。
1. 还原用户场景，找到问题本源
需求源于问题和痛点，当面对不具体的需求或是太具体的“需求”时，可以通过以下问题，引导需求方还原需求现场，说明他的困惑和遇到的难处
- 这个需求的用户谁？
- 需求在什么场景下发生？
- 当前是怎么解决这个需求的？
- 解决这个需求的过程或者方式有什么问题或者痛点？
- 用户的这个需求不解决，会有什么后果？
先找到要核心解决的问题，再决定是否值得进一步投入。如果没找到需求的应用场景和要解决的具体问题，那就说明它是个伪需求，不存在后续的承接需求并提供解决方案。
2. 需求要符合产品定位或业务特性
除了还原需求场景，还要看需求是否符合产品定位或者业务特性。
一款产品可能有很多需求，但在某个阶段，产品的定位只有一个，产品经理们可以思考该需求是否符合产品的定位，是否满足核心目标用户的需求与期待，是否会对定位的提升起到正向的作用。
比如这个需求：“我们数据系统没有这个数据，那就开个口子，让业务方上来输入数据。”
数据分析平台的定位在于通过汇集处理各方业务数据，进行精细化多维度的统计分析，帮助企业快速分析数据，洞察业务问题，为决策提供依据。而业务数据是业务作业过程中产生的数据，源头来自于业务流程，不应从数据平台中产出。
如果我们把这个需求做了，会让产品间的边界模糊不清，系统定位不明确。
类似这种添加或更新数据的需求，如果不进一步分析，就有可能产生问题，给产品挖坑……针对这类需求，我们可以充分发散并总结坑点。
再比如：“他们的商城账户体系就是这么设计的，我们也可以这样设计。”
“如果没有思路，你们可以参考XX公司的同款应用，我听他们宣讲过，做得不错。”
每个企业的商业模式、运营模式、账户体系是不一样的，即使看起来再同业相似，适合他人的业务模式也未必适用于自身。
3. 分析需求的受众范围以及使用频率
在做需求取舍的时候，除了考虑需求本身的价值，也需要考虑需求的受众范围及发生频率，有多少人会有这个需求，占总用户比例多少，以及用户对需求的需要频率是非常偶尔还是相对频繁？
哪怕需求价值成立，符合产品定位，我们也需要思考该需求是否值得投入，与产出的价值是否成正比。
4. 分析需求的投入和产出是否合理
完成上面的澄清后，更进一步分析，在解决需求问题时，需要多少资源的投入，预计的产出是什么，这种投入产出比是否合理。
通过以上角度的需求分析，我们对需求更加明晰，在回应这些“拍脑袋”需求时，则会更有理有据。
分析困难与风险，共同决策
如果经过分析后，我们发现需求本身一点问题也没有，但还是很抗拒承接这个需求，可以思考一下抗拒的原因，无非就是：
- 实施有难度，工作量太大；或者技术有难度，不能如期交付
- 完成需求的团队资源不足或者能力不足
- 时间紧任务急，或面对自于自上而下的强压，打乱原有计划和节奏
- 方案可能存在风险但没有事实依据
最好的应对方式，可以通过需求范围、时间、成本这个常见的项目三角形来帮助判断和决策。
“需求范围”指固定条件下可完成的需求数量，“时间”指完成需求所需的时间，“成本”指团队可以投入的资源成本，这三个变量组成一个三角形。
需求范围、时间、成本相互影响。
如果需求增加了，意味着时间或者成本需要相应的增加，否则三角形无法闭合，造成无法交付的后果；同理，如果需求要的很紧急，上线时间不能变，那需要考虑减少范围或增加成本；如果成本有限，就要简要范围或增加时间。
如果我们能通过分析当前条件，调整和衡量各方影响因素，说明需要的条件或者限制，那么在和拍脑袋的需求方沟通时，就有了科学依据。只要不耍赖，没人会否定。
如果僵持不下，那就上升或群体决策。
很多时候，我们要做的是摆事实讲逻辑，一味抵抗和纠结实际上并不解决问题。
拖延大法
这里的拖延，不是阳奉阴违，而是一种“缓兵之计”。
针对需求方提出的需求建议，根据现有条件、背景、业务情况，提交合理的实施排期计划，将“拍脑袋”需求的完成时间定在一定的时间段，比如数周甚至数月之后。
时间是最好的炼金石。
如果是不靠谱的需求，经过一段时间，需求方可能会有更多的思考，可能会有新的需求取代了他一时的拍脑袋。
更甚者，外界因素的变化，如市场变化、用户反馈、业务变革等，也可能导致需求本身的变化。
比如上述提到的“在数据系统提供业务输入数据入口”，在产品后续迭代过程中，业务方推进了业务流程规范化和线上化，相关数据也在业务侧留存下来，进而不合理的需求就不攻自破了。
而靠谱的需求，则会通过时间获得实施的紧迫性和资源支持，或是在这段时间内获得更明确和清晰的思路。
总之一句话，需求成立且当下能做的就做，不成立或有困难的就不做。外部信息泛滥，产品同质化严重，思考我们不做什么，往往比思考该做什么更有利于明确自身价值。不做好过瞎做，起码不浪费。当然，如果需求意图就是刻意浪费，那就另当别论了。
