产品经理在面试时常会被问到有关需求/项目管理的问题，文章对相关问题进行了梳理总结，与大家分享，希望能给大家带来帮助。

除了必备的产品技能之外，作为产品经理的你需求管理、项目管理是否过关，也是检验是否是优秀产品经理的标准，面试过程中不免也会被考察到。

关于产品经理常见面试题目，本次整理“需求/项目管理篇”，希望对你面试时有所帮助。

产品需求的来源大致可以分为4个维度：

人员反馈：老板/领导（一般是公司的战略规划或者业务的发展要求）、业务方（公司内部人员，包括运营、财务等）、客服、用户反馈、自己的规划 数据分析：产品功能的使用情况，一般是产品后台数据、第三方埋点数据 调研反馈：市场调研、用户调研、公司内部业务方调研 竞品分析：通过直接/间接竞品的产品功能对比，或者与竞品公司在市场上的优劣势对比等

比较常用的工具有马斯洛模型、Kano模型、四象限法、二八原则等，选择适合自己的才是最好的。但是使用这些工具的前提，还是要通过不同维度去结合分析，我一般会从三个维度去分析，研发和运营成本、影响面（包括影响程度和影响范围）、给公司带来的收益（因为笔者做的后台产品，对用户体验要求没那么高，你若是做的C端产品，可以把用户体验这一维度加上）。

举个例子：影响1w人的功能，平均每天使用1次，和影响1k人的功能，平均每天使用1k次，投入的研发成本是一样的，肯定优先解决影响面大的需求。

《更快的马与福特汽车》和《用户与音箱》想必大家对这两个经典案例都耳熟能详，其实最根本的还是你要深层次的挖掘用户的需求，有时候用户说的并不是他想要的。

首先我会明确需求的来源，是公司业务方的专员，还是业务方的领导；是外围用户，还是专家用户；是一两个用户，还是大部分用户（二八原则）。比如业务方的专员他对业务的理解程度肯定不如他的领导，所站的高度不一样，需求的价值也会不同。

每当接受到一个需求的时候，我至少会一步一步的多追问几个为什么，再加上多方面了解，在不断刨根问底的时候，有时也会有意外的发现

这个问题和上个问题有点类似，用户通常提出的需求是基于某种场景下提出的，可能考虑的并不成熟，这个时候就要你深层次的挖掘和分析。

分享给大家高一个level的方法，面试官会瞬间感觉你高一个逼格——

”HWM分析法”意思就是“How might we我们可以怎样”，我们大部分人面对问题时的解决思路是直接给出解决方案。而这种方法可以有效的帮助我们打开思维定式，而不是局限在具体的解决方案里，它的核心重点在“我们”、“可以”、“怎么样”，先最大范围的搜集产品的所有可能性，然后抽象出这些想法背后隐藏的核心概念和产品需求，再整理出具象化的产品设计方案，最后形成可视化的PRD。

大致流程如下：

这个方法对产品创新也有非常大的帮助，不过这个方法要经过长时间的练习，才能逐步培养这方面的能力，长久坚持下去你的思路会如潮水般涌来，堵都堵不住。

面试官是想了解你的产品规划能力，或者你有没有站在更高的视角思考过未来产品的规划。

我会不定期的对产品的现状进行梳理和总结，理清楚产品上线后的效果和接下来的方向应该怎么走：

月度数据分析：对产品线上的数据情况进行分析总结，依托数据规划接下来要做的事情； 需求汇总分析：根据现有收集到的需求进行分类整理、优先级排序，规划接下来几本版本要做的事情。

这个问题主要考察你的沟通协调能力以及项目的推动能力，可以从三个方面入手，了解现状、如何解决、后期如何规避。

首先要清晰的了解目前的现状是什么，是原因导致延期的、与原定的上线日期差多少，是因为技术上碰到了难点，还是开发评估的时间偏差，还是其他原因。只有了解清楚现状，才能有对应的解决方案。

其次根据问题制定出对应的解决方案，若是因为技术上碰到了难点，是否可以协调资源完成，或者在功能上想出一个折中方案不仅能满足业务需求，技术上也能实现。

若是开发评估的时间偏差，是否可以适当加班完成（毕竟当初时间是开发同学自己承诺的，要为自己承诺负责），再看与原定的上线日期相差多少，是否可以相应的砍掉非核心功能，来保证能按时上线。解决方案确定下来之后，要第一时间通知业务方以及干系人，确保他们获取到一手消息，让干系人有心理准备。

最后就是后期如何规避的问题了，方案有很多、比如需求评审的时候细化需求保证每个人充分理解。

我在此推荐一种方法，需求评审完之后，由开发人员评估时间的时候，可以用“估算扑克”（敏捷开发中的一种方法）的方法，这种方法在刚开始用的时候，可能与预计的时间偏差较大，但是用熟练了以后，就会觉得屡试不爽。

这个问题主要考察候选人解决问题的能力和应变能力，需求变更是产品迭代过程中的常态，有时候是业务方临时加需求、有时候是老板提出当前版本必须要上的需求，也有可能需求评审时考虑不周，导致与原需求有偏差，不得不需求变更。

在这里笔者只能为你提供一个解决问题的思路：

首先要了解清楚现状，为什么会变更？是由什么因素导致的？会产生多大影响？不变更行不行？若不变更，是否可放在下个版本进行迭代？若变更后，当前版本会不会出现延期的情况？（项目延期请参考问题5），

另外给大家提供一个我的做法，我们团队研发同学在任务估时的时候会预留1天左右的时间，来应对未来突发状况的产生，若没有突发状况会提前进入下个版本的迭代任务中。

召集高质量跨部门会议，至少提前1天通知参会人会议主要讨论的内容、会议时间时间和地点，提早安排时间避免时间冲突 会议主导避免发生讨论问题跑偏，明确每个事项的责任人和时间（避免后面扯皮、互相甩锅） 形成会议纪要邮件发送每个参与人，也可抄送相关领导 最后就是里程碑跟踪，避免出现脱轨，若出现问题要及时沟通解决。

所有面试问题及答案，笔者仅仅能为你提供一个思路，更多的还是要凭借自己的经验和应变能力，祝你面试顺利。