“我走过最长的路，就是需求的套路。”—— 某PM前辈

　　已经记不得说话这兄弟的名字，只是眼前偶尔还闪过他有些血丝的干涸眼神，在那个连续996后有些乌烟瘴气的会议室，他摁灭烟头时从嘴角挤出的的几个字，随着烟圈和哄笑散开，让原本压抑的气氛多了几分无奈和尴尬。

　　作为一名产品经理，有幸逃过UI “五彩斑斓的黑”这样的千古难题，也不像开发一样面临“什么是最好的语言”这样的灵魂拷问，但世事无完美，不信抬头看，苍天饶过谁：

　　需求，正是这样的终极存在，他是产品经理存在的意义，也是众多套路的根源。无论是文能提笔写文档、武能调试查异常的老司机，还是熟读《梦的解析》、倒背需求层次论的学院派，和需求打交道的日子也难免“被套路”，比如下面这位：

　　面对千变万化的需求，也许很难抽象出一套普适的方法论，不妨一起来看看需求分析过程中的那些常见套路，或许能有一些值得借鉴和思考。

　　1.披着需求外衣的解决方案

　　从交互细节优化到业务流程调整，我们总会遇到这样一些需求：描述简单明了、细节清晰，几乎稍作整理就可以形成PRD、开发实施：

　　“输入框需要加长一点，保证输入内容完整可见”

　　“工单需要支持批量分配，勾选后自动显示可分配对象列表”

　　“用户注册推送新手任务提醒，引导完善资料，必填项有XXX…”

　　这种情况下，进一步的分析时思维往往容易聚焦在这些地方：

　　“输入框不够长是不是改文本域？文本域也不够用要不换弹层？”

　　“长时间没有操作分配，是否要触发积压预警？”

　　”第一次推送没有响应，要不要隔几天再推一次？或者下发短信提醒？”

　　从需求分析的角度出发点来看，这已经跑偏了，因为这个过程中我们可能从来没有想过：

　　“为什么这里需要输入这么多内容？”

　　“为什么系统会生成这些工单需要人工来做分配？”

　　“为什么要通过新手任务引导用户来完善资料？”

　　而这几个问题才是需求分析应该关注的重点。

　　应对tips：

　　需求分析只关注why，不过问how。

　　既然已经知道需求提出者会自觉/不自觉地对需求进行加工，那么当我们拿到这些构建于不同需求方自身经验之上的“半成品解决方案”时，务必不能直接开始考虑“怎么做”，而搞明白“为什么做”，在不明确需求的前提下谈方案，根本就是耍流氓。

　　2. 需求分析的漏斗效应

　　需求从产生到被分析明了，会经历如下的漏斗模型：

　　原始需求→用户认知

　　从心理学角度来看，人的精神由本我/自我/超我三个层面构成，需求源自本我，又受自我/超我影响，atv，用户自身对这其中关系的认知可能也非常模糊；

　　用户认知→用户表述

　　即便用户能充分了解自己的需求根源，也无法确保用户愿意如实表述，用户想让你了解的需求往往不等于用户真实的需求；

　　用户表述→PM理解

　　用户表述能否准确无误，PM能否100%理解？

　　PM理解→得出结论

　　彼之蜜糖，吾之砒霜。且不论分析方法论是否得当，PM能否完全屏蔽自身的角色干扰，客观准确的得出结论本身就是一个挑战。

　　层层漏斗过滤之后，需求还能保持几分本来面目，真得打一个大大的问号。如果再考虑到最终实现交付，再加上一个需求实现漏斗，也就不难解释为什么会有大量需求是A，设计是B，产品是C的案例了。

　　应对tips：

　　让用户stay foolish