需求分析怎么做？我做了8年产品，踩了7个坑后总结出这套“减法”方法
先讲一个真实案例。2019年我在一家电商公司做后台产品，运营总监提了一个需求：“增加批量导入商品功能，因为每次上新都要一个个填，太慢了。” 我当时觉得很有道理，就写进了PRD。开发花了5人天做完，上线后我盯了一个月的数据，发现使用率只有2.7%，而且用的都是运营部那3个实习生。为什么？因为正式运营都用ERP系统直接同步了，根本不用后台。这个需求就是典型的“伪需求”——用户说的痛点是真的，但解决方案是错的。后来我复盘，如果当时多问一句“你们平时用什么工具管理商品？”，就能避免这5人天的浪费。根据Standish Group 2020年的CHAOS报告，只有31%的项目成功，50%面临挑战，19%直接失败。而失败原因中，需求不明确或需求变更占了近40%。所以，需求分析不是写文档，而是做决策。
那为什么需求分析这么难？因为需求本身是模糊的、动态的、甚至矛盾的。我对比过两种做法：传统瀑布式要求前期冻结需求，签完字才能开发。但现实是，一个项目从立项到上线平均要3-6个月，这期间市场变了、老板想法变了、竞品出新功能了，需求变更率超过40%是常态。敏捷式拥抱变化，用用户故事和迭代来应对，但容易陷入“范围蔓延”——每个迭代都加需求，最后上线遥遥无期。我待过一家大厂，有专门的用户研究团队，做一次用户访谈要花2周，样本量200+，输出几十页报告。也待过一家20人的创业公司，产品经理就是老板，需求就在微信群里发语音。两者没有绝对好坏，但核心问题是一样的：如何确保你理解的需求，就是用户真正需要的？我的独立观点是：需求分析的本质是“减法”，不是“加法”。90%的工作应该是砍需求，而不是写需求。因为资源永远有限，做10个平庸的功能，不如做1个让用户尖叫的功能。
具体怎么砍？我总结了一个“三刀流”方法，用了5年，至少帮我砍掉了60%的无效需求。第一刀：砍伪需求。问三个问题——不做这个功能，业务会死吗？用户会流失吗？竞品有吗？如果答案都是“不”，直接砍。第二刀：砍低频需求。问使用频率：每天用？每周用？每月用？如果一个功能一个月用不到一次，但开发成本超过3人天，砍。第三刀：砍高成本低价值需求。算投入产出比：开发成本（人天）× 维护成本（每年人天） vs 预计带来的收入增长或效率提升。比如之前有个需求是“支持自定义报表导出格式”，开发要8人天，但只有2个用户提过，预计每年节省人力成本2000元。投入产出比太低，砍。砍完之后，剩下的需求用Kano模型排序：基本型需求（必须有）、期望型需求（越多越满意）、兴奋型需求（惊喜）。优先做基本型，再做兴奋型，期望型最后。
光砍还不够，还得让开发、测试、运营都理解你写的东西。我见过太多PRD，产品经理洋洋洒洒写了30页，开发看完说“这不是我想要的”。问题出在沟通偏差。一个需求从提出到开发，平均要经过5次转述：用户→运营→产品经理→开发→测试。每次转述信息衰减率大约20%-30%。所以，我的做法是：写完PRD后，不急着评审，先拉开发、测试、运营开一个15分钟的“对齐会”，只做一件事——让每个人用自己的话复述一遍这个需求。如果复述的和我想的不一样，当场澄清。然后，PRD里必须包含：背景和目标（用OKR量化，比如“将下单转化率从3%提升到5%”）、用户故事（As a... I want... so that...）、业务流程图（用Visio或ProcessOn）、界面原型（用Axure或Figma，标注清楚交互）、异常流程（网络断了怎么办？数据为空怎么办？）、数据埋点（要统计哪些事件？）、验收标准（每条需求可测试）。比如一个“优惠券”需求，验收标准要写：用户点击领取后，优惠券进入账户，有效期7天，满100减10，不可叠加，过期自动失效。这样开发才知道边界。
最后说点实在的。需求分析做久了，你会发现最难的不是工具，而是人心。开发觉得你瞎指挥，运营觉得你不懂业务，老板觉得你慢。我有一段时间特别焦虑，每天开会、写文档、改需求，感觉自己像个传话筒。后来我想通了：产品经理不是需求的搬运工，而是价值的过滤器。你不需要让所有人满意，但你需要让团队相信，你砍掉的需求是为了更重要的目标。如果你现在正在做需求分析，我建议你试试：下次拿到一个需求，先别写PRD，先问三个“为什么”，再算一笔账（成本vs收益），最后拉上开发喝杯咖啡，问问他“如果让你做，你会怎么做？” 很多时候，答案就在那里。对了，我整理了一份《需求分析检查清单》，包含12个问题，每次评审前过一遍，能避免80%的返工。需要的可以留言。
