需求评审会上，最该被追问的三个问题

微信扫一扫，分享给好友

关闭

评审会开得多了会发现一个规律：多数争论发生在方案层面，而真正的问题藏在方案之外的假设里。方案改了三轮还在吵，往往不是方案不好，是没人确认过它站在什么地基上。

这篇讲三个问题。它们一点也不新，但如果在每次评审里被真正问出口，能省掉大量返工。

这个需求解决的是谁，在什么时刻，做的什么动作？

注意这三个要素必须同时出现。只说「用户觉得慢」不算回答，因为它没有指出谁在什么时候感到慢。常见的答不上来是这样的：需求文档写了「提升效率」，但没人能描述出用户此刻正坐在哪里、看着哪个界面、手上在做什么。

一个可操作的检验方法：让提需求的人用一句话复述昨天某个真实用户的操作序列。如果复述不出来，说明这个需求来自想象而不是观察。这时候不要急着评审方案，先补一次观察。

如果这件事不做，会发生什么？

这个问题是用来区分「价值」和「声音」的。很多需求之所以进了排期，是因为提的人嗓门大或者职级高，而不是因为它不做会带来具体损失。

有效回答的样子是：不做的话，哪一类用户会在哪个环节流失，或者哪个团队会继续每月多花多少人力。无效回答的样子是：不做体验不好、不做会被竞品超过。后者听着严重，但无法验证，也就无法排序。

做完之后，我们怎么知道它成功了？

这里要防的是把「上线」当成功。上线是动作，不是结果。评审会上必须落到一个可观测的信号上，而且要提前说清楚观察窗口：两周内看什么指标，多久之后判断继续还是回滚。

有个细节值得强调：判断标准要在方案通过之前定下来。等上线后再补标准，人会自动选择对自己有利的指标，这是人性，不是道德问题。

三个问题的提问顺序也有讲究

先问第一个定位问题，因为如果对象和时间都没确定，后两个问题的答案一定是虚的。再问第二个价值问题，用来排序。最后问第三个验证问题，用来设计上线后的动作。

如果会议上有人对第一个问题就答得含糊，我的建议是把评审会改成一次补充调研的约定，而不是硬着头皮过方案。会议多开一小时的代价，远小于团队做错方向两周的代价。

一个真实场景的对比

两个团队同时评审一个「批量操作」需求。A 团队直接讨论交互用勾选还是拖拽，争了四十分钟。B 团队先问：谁在什么时候需要批量操作？答案是运营同学每月末导数据时，一次要处理两百条。再问不做会怎样：会多花两个工作日手工处理。第三问怎么算成功：单次处理时间从两小时降到二十分钟。

结果 B 团队发现真正的瓶颈不在交互形式，而在导入环节要手动对齐字段。他们做的是一个模板校验功能，工作量只有批量勾选的三分之一，效果却更好。

这不是说交互细节不重要，而是说交互细节的讨论应该发生在定位清楚之后。顺序错了，讨论质量就无从谈起。

最后一句

评审会的价值不在于通过多少方案，而在于提前暴露多少没想清楚的地方。把这三个问题固定成会议的第一页，比任何流程文档都管用。

---

> 本文由 GPMU 原创撰写，转载请注明出处。

*本文观点仅代表作者/编者个人立场，不构成任何投资或职业建议。*