编辑导语：产品经理在日常工作中经常会与各部门打交道，比如在做项目时，会与技术部门进行交流沟通，提交需求等，但在沟通的过程中，不免遇到一些难题，比如技术无法实现，这时应该怎么办？本文作者就此进行了详细的分析，我们一起来了解一下。

需求讨论清楚了，方案评审通过了，策划和设计工作也完成了，项目已全面进入开发阶段……

你刚要松口气的时候，技术突然跑过来跟你说：“老哥，你这个需求搞不了啊。”

有项目经验的朋友，应该能够体会到，这个场景多么地令人奔溃！

前面所做的全部工作，可能都得推翻重来。项目进度将会受到巨大的影响。

这样的情况，说多不多，说少也不少。

负责的项目多了，其实还是挺常会碰到的。

如果是你，遇到这样的情况，要怎么办？

直觉上，应该马上暂停项目，然后赶紧召集相关干系人重新对项目进行评审。

这样的“答案”，逻辑上没有问题，挺合理的。

但是，在实操层面，我想说，先别着急，事情可能还远远没到那一步。

进入全面开发阶段之前，项目肯定已经经过了多方的评审。

我们是得到了“可以搞”的保证后，才开始搞的。

到了全面开发阶段，再发现“搞不了”，概率其实很低。

根据经验，大概有80%的概率，是个“假阳性”的误报。

01

那么，怎么判断项目是不是真的搞不了呢？

我猜，很多朋友可能已经联想到一个老生常谈的争论：

“产品经理需不需要懂技术？”

你可能会想，如果产品经理懂技术，那就可以和技术battle，甚至一开始就不会设计出“技术上实现不了”的方案……

首先，我的观点，向来都是“产品经理不需要懂技术”。

但是，在这里，我不想深入去讨论这个话题，也不希望各位朋友从这个角度去思考本文要讨论的场景。

上面说了，这个“搞不了”的反馈，有80%的概率是个“假阳性”的误报。

在这80%的情况里面，其实更多的是“人”的问题，而不是“技术”的问题。

所以，要甄别它们，靠的也不是“懂技术”。

02

在全面开发阶段，技术突然跟你反馈说：“这个需求搞不了。”

如果你项目经验比较少，或者对团队不够了解，那么，很可能就会被“唬住”。

因为很多时候，其实完全是搞得了的。

下面，我会罗列出现“误报”的几种常见情况。

你在重新召开评审会之前，不妨先看看，真实的情况会不会是下面这样的。

1. 技术没看清楚需求内容

“这个真搞不了。这里面很复杂，有A、B、C 3种情况。B和C因为某某原因，是不能这么搞的。”

“嗯，所以我PRD上写了‘仅针对情况A’。”

“……那没事了。”

你没有看错，就是这么低水平的乌龙。

老实说，这种情况出现的概率还不低。

所以，我一直强调“在真实的世界里做产品”。

当你不是架空地去想问题，而是真正地去开展工作时，你总能碰到一些意想不到的困难。

在真实的世界中，光是“准确完整地传达信息”，就很困难，经常出差错。

当然，解决方法也很简单。

反复说明，直到信息充分传达为止。

2. 技术没有正确理解项目的要求

曾经，有个需求是这样的：

“从3个题库里面随机抽取5道题，要保证每个题库至少要有1道题。”

然后技术跟我说，这个搞不了，里面需要很多判断，很复杂。

具体怎么个复杂法，他也没法表述清楚。

我思考了下，说，能不能这样：

“第1题从题库A中随机取，第2题从题库B中随机取，第3题从题库C中随机取，第4、5题则在3个库中随机取，但要去重。”

技术想了想，说这样搞可以。

为什么原来不能搞，现在又能搞了呢？

那是因为，技术以为，“每道题出现的概率要一致”，“题目出现的位置也要随机”。

然而，从业务上看，并不需要做到这个地步。

像这样的问题，无法像第一种情况那样，事先在PRD上完全说明清楚。

因此，需要与技术仔细沟通，并在沟通过程中，细心地甄别出双方在“理解”上的错位。

3. 技术他自己的确搞不了，因为还需要其他技术来配合

曾经，我想给某个小模块增加一个状态变化。

但是，负责的技术说没办法搞。

我非常困惑，这应该是非常简单的功能呀，怎么会没办法做呢？

“要增加状态变化，需要新增一个字段来控制。”

“那加就是啦。”

“可我这边只负责调用，没办法加字段。得某某组那边才能加字段。”

“我……”

这看起来，多少有点让人哭笑不得。

但，设身处地想想，其实也挺正常。

我们从外部看，会觉得技术部门就是一个整体，技术的问题他们内部理应自行沟通协商解决。

但是，每个人都有自己的分工，做着自己的工作。互相之间，关联性没那么强。

一个项目，往往需要技术部门不同分工的同事协同完成。

有时候，碰到涉及面较大的问题，更是需要让不同分工的同事聚在一起，从各自的角度出发，提出意见，讨论解决方案。

希望他们能自发地组织起来进行协作，其实是一种挺偷懒的想法。

在没有项目经理的情况下，产品经理应该有意识地成为“组织者”。

当发现需要多人协作时，主动地组织起各方，高效地达成合作。

当然，这就需要产品经理充分了解团队的工作分工。

4. 其实是技术没时间搞

这个情况是，虽然技术上可行，但是预计花费的时间过多。

如果真的这么去做了，很可能无法按期上线，或者影响到其他项目的上线。

那么，解决思路也很清楚。

要么调整方案，要么修改开发排期，给与更多的开发时间。

要注意的是，有一些比较老油条的技术，嫌麻烦，不想搞，会“欺负”产品经理不懂。

他不说”时间不够“，而是含糊其辞地说，“太复杂了，搞不了。”

这一点，产品新人要注意甄别。

5. 技术对项目的重要级认识不足

某种意义上讲，没有什么需求是实现不了的，只是成本的问题。

有时候，技术的意思，其实是：

“（因为没法把工作量控制在合理的范围内，所以，）这个需求搞不了。”

比方说，这个项目需要10个单位的工作量。

技术根据自己对需求的理解，认为以这个项目的价值，超过5个单位的工作量，就不合理了。

然而，因为这个项目重要级比较高，哪怕是花费10个单位的工作量，也是值得的。

当然，这个工作量的问题，需要在评审的时候提出来讨论，并且最终与领导达成共识。

不是产品经理自己单方面觉得“值得”就可以了。

这种情况下，产品经理需要把项目的重要级，以及领导已知悉并同意的情况，给技术传达清楚。

特别的，有时候，“搞不了”的意见，是技术组长给出的。

这时候，“纠缠”具体某个技术就没有意义了，应该直接和技术组长沟通。

03

有2种的态度，我认为是有问题的。

一种是，认为既然领导已经审批通过了，那么技术就应该按要求去完成。

有问题，不关我的事，你们内部自己协商解决。

我只关心结果。

另一种是，盲目地认为“专业的事情交给专业的人处理”。

既然技术说了不行，那就不行。

没必要去了解其中的细节，反正我也不懂。

这2种工作方式，我多少有碰见过。

个人觉得，至少作为产品经理，是不应该如此的。

04

上面列举的几种情况，需要产品经理具备不同的能力，分别用不同的方式妥当应对。

但是，无论哪种情况，一个不变的前提是，需要产品经理深入其中，充分调研，了解个中细节，敏感地发现问题所在。

从“搞不了”变成“搞得了”的过程中，产品经理的沟通协调工作，发挥了重要的作用。

换个角度来说，这也是产品经理的职责所在。

你是否也碰到过这样的问题？你是怎么处理的？

#专栏作家#

简明产品论，微信公众号：简明产品论（ID：JianMingPM），人人都是产品经理专栏作家。在真实的世界里做产品。

本文原创发布于人人都是产品经理，未经许可，禁止转载

题图来自 Unsplash，基于 CC0 协议