上个月遇到一个项目，客户提了一个非常具体的要求：要一个数据大屏，最好带3D效果，能在老板进来看的时候自动轮播。我们团队加班两周，用ECharts做了动态地图、飞线、实时数据刷新，大屏投到会议室80寸电视上。结果客户用了两次就再也没开过。后来复盘，发现我们从头到尾都没问过一个问题：这个屏给谁看？看完要做什么决策？客户自己也不知道，只是觉得“别人都有大屏，我也得有”。
这不是执行问题，是需求分析问题。大多数需求分析都死在同一个地方：把用户嘴里说出来的话当成了需求。用户说“我要一个导出Excel的功能”，你要知道他不是想要Excel，他是想用Excel干一件什么事。用户说“我要给表单增加一个备注字段”，你要知道他可能是想绕过你们系统去记一些他关心但系统没有的东西。用户说的永远是解决方案，而且是你提供的系统的解决方案，不是业务问题本身。
传统需求分析方法论，从瀑布流时代就开始教我们写PRD、画用例图、做实体关系，把用户需求翻译成开发能懂的格式。这一套逻辑看似严谨，实际上最大的bug在于：翻译这件事本身就预设了“用户需求是真实存在的，只是需要被理解”。但大量情况是需求本身是伪的、脆弱的、经不起一问的。敏捷用户故事稍微好一点，强制要求写“作为谁，想要什么，以便什么”，但很多团队把“以便”写成了废话：“作为一名销售，我想要查看客户详情，以便更好地服务客户”。这不叫需求分析，这叫作文填空。
我这些年的独立观点是：需求分析的核心不是分析“需求”，而是分析“决策”。每一个需求背后都应该隐藏着一个业务决策。数据大屏的决策是“老板要不要调整业务方向”；导出Excel的决策是“我如何判断哪些数据有异常”；加备注字段的决策是“我如何记录那些系统模板里没有的关键信息”。系统本身就是决策支持工具，如果你连用户要做决策这件事都没搞清楚，那开发出来的功能就是一堆昂贵的摆设。判断一个需求是否值得做，我有个土办法，问三个问题：第一，这个功能解决了谁的什么决策？第二，如果不做，用户会用什么土办法代替？第三，做完之后，用户的行为会不会真的发生变化？这三个问题只要有一个答不上来，我就建议产品经理先别动手。
你可能会觉得这个说法太苛刻。实际工作中，很多需求根本经不起这么追问。但正是这样，需求分析才应该从“收集、记录、确认”变成“筛选、剔除、引导”。我看到的优秀需求分析师，不是文档写得最漂亮的，而是能站在用户面前，礼貌地说：“王总，您说的这个功能我认为不需要做，因为您真正要解决的是另一个问题。”这句话很难，但这就是需求分析的价值。传统叫需求分析师，我觉得更像是需求翻译官；未来应该叫需求决策师，我们做的是帮助用户做出正确的功能取舍和决策设计。
优先级也可以用决策频率 × 决策成本来估算，而不是靠拍脑袋或者哭闹程度。以前在O2O公司，我们上过一套会员标签系统，产品经理按MoSCoW分类法把“忠诚度模型”标为Must-have，做了三个月，结果业务方根本不知道忠诚度模型能干什么，因为这个决策链条太长了。后来改成先做“高价值用户流失预警”，只用了7天，每天给运营推送一份风险名单，运营立刻用起来了。区别在哪里？流失预警对应的是运营每周都要做的一个具体决策：这周该给谁打电话。忠诚度模型对应的是一个抽象概念：理解用户价值。决策频率完全不同。
所以，需求分析在我的理解里，从来不是一步到位的。你写80页PRD，不如做一次用户访谈中多问一个“为什么”。你画十个流程图，不如让用户给你看看他今天的工作台，他从来不打开那个页面就说明那个功能根本不在他的决策链路上。需求分析这个工种，说起来很高级，本质就是做两件事：搞清楚谁要什么信息做决定，以及帮他把这个决定做得更省力。剩下的，大多是自我感动。