领导不满意，技术团队有意见，产品经理怎么做？这道经典的面试题，从产品的角度如何合理解决？作者曾经在这个题上踩过坑，现在有了更合理的解决办法，大家可以参考。

01

毕业找工作那会，有一次，面试官问了这么一个问题：开发团队调动了全部人力，正在如火如荼地开发一个大项目，时间紧，任务重。这个时候，某位领导让你过去，提了一个需求，命令你尽快完成。作为产品经理，你要怎么做？

在当时的我看来，这是一个“两难困境”：要么得罪领导，要么打乱整个项目计划，无论哪个后果，都不是我一个卑微的产品人所能承担的。

我只好回答：

“两害相权取其轻，我选择两个选项中损害较小的……”

现在回过头来看，当年的“解题思路”，看似合理，其实有很大的问题。

做交互设计10年，我为何转岗到产品经理？

真正转岗之后，我发现很多工作还是超出了自己的想象。产品经理的工作确实比较杂。理论上，产品经理的工作包括了产品的方方面面，从市场研究、用户调研、数据分析...

查看详情 >

很多产品新人，在面对类似的情况时，往往也容易犯这样的错误。

具体是什么问题呢，下面我展开说说。

02

新需求是什么？旧项目现在是什么情况？

如果不先去了解清楚，仅凭2个抽象的概念，就自顾自地开始分析，那完全就是空转。

这个道理很简单，但是往往容易被忽略，尤其是在情况紧急的时候。

1、对于新需求，需要初步评估其所需的工作量。

抛开“排期冲突”的问题，先单独看看这个新需求具体要怎么做。

举个例子，比如新需求是向特定用户推送活动短信，感兴趣的用户可在H5专题页上预约咨询。

那么，主要工作就包括：产品和设计输出H5专题设计稿、前后端及测试完成H5专题页的开发测试、数据洗出目标用户明细表、运营配置并推送短信、后台分配预约名单给客服。

根据以上工作内容，再参考以前类似的项目，产品经理就可以大致预估，在开发资源充足的情况下，如果不出意外，需要多少天完成，比如说“一周”。同时，根据以往的经验，有些容易发生且较为影响进度的“意外”，产品经理心里要有所预期。

比如，如果该领导对宣传内容很在意，那么，就很有可能因为对文案或者图片不满意，多次地返工调整。

2、对旧项目，需要大致了解当前的具体进度。

该项目，当前进展到什么程度，计划什么时候完成。

需要注意，越是大项目，按时交付的可能性越低。计划完成日期是一回事，实际完成日期往往又是另一回事。这就需要产品经理结合已完成部分的进度和质量，进行评估和预测。

另一方面，产品经理需要去具体了解每个人员的分工情况。即使是调动了全部开发资源的大项目，也不是说，所有人在所有时候都有任务。新需求涉及的人员，当前手上有什么任务，做到什么地步，需要重点关注。完成现状评估工作后，产品经理很可能会发现，情况不是自己“想当然”的那样。

比如说，新需求的工作量很小，对旧项目有干扰但不大，那完全可以一起做了。

比如说，旧项目按计划马上要完成了，但是调研结果显示，延期的概率很高，那新需求可能就等不及了。

03

准确把握现状之后，就可以思考解决方案。

上面提到了一个词，“两难困境”。其潜台词就是，“这里面有且只有两种解决方案”。

要么，新需求先搁置，等旧项目完成后再开始。

要么，先暂停旧项目，优先把新需求搞上去。

且慢，认真想想，手上真的只有这两张牌可以打吗？

其实，现状没有那么窘迫，可能的解决方案，比想象中的要多得多。

1、有没有可能，相当一部分开发资源已经可以挤出来了。

上一步，把调研的颗粒度，从“项目”缩小到“人员”，作用就在于此。

比如说，到了项目开发后期，接口、后台之类的工作可能已经完成了。前端可能还在调整，但是，也出现了一些“等测试反馈问题”的空档。那么，就有可能挤出新需求所需的开发资源，消解掉“冲突”的问题。

2、有没有可能，可以把任务拆分，分次完成。

比如说，先做核心模块，次要模块后续再安排。

比如说，先做用户量大的站点，其他小站点后续再补上。

不仅是新需求可以考虑拆分，旧项目也可以。原来可能打算一鼓作气一次搞定，现在情况变了，那就得考虑调整计划，分步实现。

3、有没有可能，可以换一种平替的方案。

比如说，原本想要做个预约咨询专题，可以考虑把预约表单去掉，改成“拨打客服电话”的按钮。

比如说，原本想要做个统计数据的后台，可以考虑先挑几个核心数据，让数据人员写个SQL语句，每天手工跑一下。暂时性地满足主要需求，减少工作量，以内容换时间。

解决方案，其实可以有很多。

甚至，还有“全员996，2个项目一起上”的牛马方案，“随便搞搞，整出个电子垃圾先应付下”的老油条方案，等等。

不要一开始就先入为主地把自己的视野给局限住。

04

每个方案，都有其优点和缺点。如何在几个方案之间做抉择呢？

回到开头的场景。

其实，问题不在于“我选的对不对”，而是在于“我选”这个动作。

需求排期，本质上是由所有干系人达成共识后，相互妥协、共同决定的。一般情况下，干系人因为已经认可了既定的决策流程和决策原则，所以也就默认了产品经理基于该流程和原则所做的安排。问题在于，在开头的场景中，这样的“共识”，并不存在。如果此时，产品经理不管不顾，自行做安排，就容易引起另一方的不满。所以，这种时候，需要和主要干系人进行沟通，以建立共识。

上述场景中，主要干系人有2个，提新需求的领导，以及技术团队的负责人。能最终做决定的，是领导。因此，产品经理在完成上述工作后，下一步要做的，应该是“向该领导汇报情况”。需要说清楚“当前面临的问题”、“可能的解决方案”以及作为产品经理的“建议”。最后，让领导来做决定。

需要注意，在向领导汇报之前，最好先和技术负责人碰一下。

1. 确保产品经理了解到的情况，是准确的，技术负责人也是认同的，以免被“背刺”。
2. 确保产品经理考虑的方案都是可行的，同时，也听听技术负责人的其他意见。
3. 让技术负责人了解情况，知悉产品经理已尽了人事，后续无论怎样的牛马结果，都别抱怨。

05

处理这种两难困境，总的来说，需要三个步骤：调研现状、设计方案、建立共识。

需要避免一紧张、脑子一热，就直接输出结论。

产品经理需要回到现场，在具体细节中寻找解决方案。