近期一直在梳理需求收集、需求评审流程，就写一写关于这方面的心得吧。针对评审要注意的事项，我梳理了8个问题，和大家一起聊聊我的理解。

今天要讲的，也是看苏杰《人人都是产品经理》的一段描述所想到的：在阿里，产品经理如果要开展自己的项目，要定期整理需求，专门召开立项评审会，带着自己的需求和解决方案「过会」，向资源部门争取资源。

而在这样的评审会上坐着的，都是各实施部门的老大，本着资源合理利用的原则，通常他们会很犀利地提出各种问题和质疑，这就要求产品经理充分理解自己的需求，做足准备，否则很容易就被「PK」掉，不受重视。

尽管很多公司没阿里那么严格，一般都能做到专人专用。但产品经理作为项目的主负责人，还是有必要在收集需求、评审需求时，把控需求的合理性，判断需求的价值，从而保证开发实现的需求是有意义的——这对产品经理而言是必要的，也是很高的要求。

那么具体来说如何做到呢？本文整理了8个问题，分别是：

如果都能客观清晰有条理地回答出来，能通过评审也就八九不离十了。下面就谈谈我的理解。

1. 为什么要做这件事？不做会「死人」吗？

这个问题用来评估需求的重要度。也就是要描述清楚需求的原因，如果不做，是否会带来损失。回答这样的问题，一方面可以站在用户角度，描述我们发现用户在特定场景遇到的困难是什么，这个困难不解决，短期有什么影响，长期有什么影响；另一方面可以站在客户角度，描述客户对我们提出了什么要求，如果无法满足会造成什么经济损失；再一方面可以站在内部人员的角度，描述日常工作的执行效率问题，如果不提升，会损失哪些机会成本。

2. 你的目标是用户目标还是我们的目标？这类用户对我们的优先级是什么？

这个问题用于确认做这件事是为了满足KPI，还是满足用户需求。就算是为用户考虑，也要权衡是为哪个层级的用户服务。

C端产品，用户一般是金字塔形式分层，如果是免费产品，需要更多考虑金字塔底层的使用体验，因为他们是根基。如果是付费产品，则需更多考虑付费用户，也就是偏顶层的体验，因为他们是收入来源。

当然，满足「我们的目标」，也并不代表是不对的，通常这种目标就是销售目标，B端商业变现目标，满足这类「客户」的商业价值，有时候对企业而言优先级则是最高的。

3. 你的需求有普遍性么？能代表多少？怎么采样的？

这个问题要求产品经理说清需求来源和判断过程。产品经理采集需求的来源很多，可以是通过用户反馈后台，或者运营反馈的用户问题，或者是一些调研问卷，再或者是通过用户行为数据。那么在需求整理时，就要讲清楚哪些需求是反馈收集的，反馈人数有多少，这些反馈是否能对应到用户行为数据，数据的来源是怎么计算的，是否能推导出有更多人有同样的需求等等。

举个例子，假设很多用户反馈说希望App支持夜间模式，但开发夜间模式成本很高，这时你就可以在App中先做一个调节亮度的「伪夜间模式」，观察用户点击行为，假设每天有大量用户启动时调节了亮度，就能初步证明夜间模式功能的存在价值。

4. 这个规划未来1年是什么样？实现规划路径如何？

这个问题要求产品经理很清楚自己提的需求，未来的发展路径规划。开发最忌讳的是一次性需求，做完了就完了，没有可复用性。当然也不是所有需求都要持续维护，实际做的时候，产品经理可以对某个项目提出一些「假设」，这种假设可以是功能使用次数，可以是用户反馈数，可以是产生价值数。对需求的未来规划，可以是「分叉」的，比如当数据大于一定量级，用户正向反馈增加，带来的商业价值增加，可以继续增加功能，持续优化，反之则可以考虑转换方向，或者调整策略，或者直接下线。

5. 这么多需求，你打算组建多少人的团队？都需要什么能力？怎么分工？如果只给你2个人怎么办？如果只做一件事，最重要的是什么？怎么做？

这个问题要求产品经理对开发、设计、测试的实现成本有一定估算。可以不用了解具体的实现方式，但需要根据自己的经验和理解，评估出团队成员人数和分工。具体评估是要综合考虑业务逻辑的复杂度，前台页面的数量，上线时间，第一版质量要求等情况。后半句问题，则是从资源利用率最大化，和风险控制角度出发，反向要求产品经理能够给出需求最核心的点，也就是MVP方案，以便在项目产生风险时，能快速应对。

6. 能否给出项目效果是否达成的量化指标？ROI是多少？

这个问题要求产品经理对项目结果负责。提出需求前，产品经理就要对需求能达成的效果有明确的数据指标预估，尤其在资源有限的前提下，每个资源都是「成本」，实施方可以认为是「投资人」，肯定追求的是最大投资回报率。

举个例子，假设我们要上线一套分销系统，允许用户在购买完商品后，分享给好友，好友一购买，就能给分享人返利，好友也能获得返利。这时就要计算：分销系统的开发人力成本（人/天）、上线后预估日购买次数（收益）、日分享次数、每分享购买率（收益）、日返利金额（成本）等指标。当然为了跟踪方便和目标明确，也可以抽出其中1-2个关键指标，持续观察，比如日销售额和日毛利。

7. 这个产品，实际路上会遇到的最大问题是什么？打算怎么解决？需要大家怎么配合你，你打算如何说服大家帮你？

这个问题要求产品经理不仅要描述需求的优点，更要认识到可能产生的风险。

这些风险可能是：

罗列可能的风险后，必须给出对应的解决方案，让大家了解到你不仅对目标明确，还明确达到目标的多条路径。

至于说服的的方法，也是有策略的，有的需要正面回应，有的需要借助外力，有的需要摆出事实，有的需要描绘愿景，总之这个时候就考验产品经理分析问题，解决问题的能力了。

8. 你预计要占用多少开发资源？如何给技术人员带来成就感和成长？

这个问题是第5个问题的细化版本，通常互联网产品占用研发资源是最大的，而研发人员最关心的可能不是支持了什么业务、满足了什么需求，而是这些需求实现后，对他们而言有什么收获。

这种收获，可能是精神层面的，比如用户的正向反馈，比如给公司带来了收入，比如提升了品牌影响力，但这些相对较弱；也可能是物质层面的，比如绩效奖金，但这些相对持续时间较短。

而实际对技术人员影响最大的，还是技术水平的提升，还是遇到复杂问题并解决问题的快感，这些就是对自身能力的肯定。因此，建议产品经理了解一些技术解决方案，可以针对需求中的技术风险重点说明，从而提升大家解决问题的积极性。

至此，全部8个问题也就分享完了，当然，实际评审时，不同公司侧重点肯定各有不同，但产品经理无论如何都要对每个需求深入理解，做到有理有据地说服大家跟你干，产品经理的成就感也就体现在此。我也在这条路上努力着，与你共勉。