时间: 2021-07-30 09:33:56 人气: 1 评论: 0
编辑导语：产品经理在日常工作中经常**与各部门打交道，比如在做项目时，**与技术部门进行交流沟通，提交需求等，但在沟通的过程中，不免遇到一些难题，比如技术无法实现，这时应该怎么办？本文作者就此进行了详细的分析，我们一起来了解一下。
需求讨论清楚了，方案评审通过了，策划和设计工作也完成了，项目已全面进入开发阶段……
你刚要松口气的时候，技术突然跑过来跟你说：“老哥，你这个需求搞不了啊。”
有项目经验的朋友，应该能够体**到，这个场景多么地令人奔溃！
前面所做的全部工作，可能都得推翻重来。项目进度将**受到巨大的影响。
这样的情况，说多不多，说少也不少。
负责的项目多了，其实还是挺常**碰到的。
如果是你，遇到这样的情况，要怎么办？
直觉上，应该马上暂停项目，然后赶紧召集相关干系人重新对项目进行评审。
这样的“答案”，逻辑上没有问题，挺合理的。
但是，在实操层面，我想说，先别着急，事情可能还远远没到那一步。
进入全面开发阶段之前，项目肯定已经经过了多方的评审。
我们是得到了“可以搞”的保证后，才开始搞的。
到了全面开发阶段，再发现“搞不了”，概率其实很低。
根据经验，大概有80%的概率，是个“假阳性”的误报。
那么，怎么判断项目是不是真的搞不了呢？
我猜，很多朋友可能已经联想到一个老生常谈的争论：
“产品经理需不需要懂技术？”
你可能**想，如果产品经理懂技术，那就可以和技术battle，甚至一开始就不**设计出“技术上实现不了”的方案……
首先，我的观点，向来都是“产品经理不需要懂技术”。
但是，在这里，我不想深入去讨论这个话题，也不希望各位朋友从这个角度去思考本文要讨论的场景。
上面说了，这个“搞不了”的反馈，有80%的概率是个“假阳性”的误报。
在这80%的情况里面，其实更多的是“人”的问题，而不是“技术”的问题。
所以，要甄别它们，靠的也不是“懂技术”。
在全面开发阶段，技术突然跟你反馈说：“这个需求搞不了。”
如果你项目经验比较少，或者对团队不够了解，那么，很可能就**被“唬住”。
因为很多时候，其实完全是搞得了的。
下面，我**罗列出现“误报”的几种常见情况。
你在重新召开评审**之前，不妨先看看，真实的情况**不**是下面这样的。
“这个真搞不了。这里面很复杂，有A、B、C 3种情况。B和C因为某某原因，是不能这么搞的。”
“嗯，所以我PRD上写了‘仅针对情况A’。”
“……那没事了。”
你没有看错，就是这么低水平的乌龙。
老实说，这种情况出现的概率还不低。
所以，我一直强调“在真实的世界里做产品”。
当你不是架空地去想问题，而是真正地去开展工作时，你总能碰到一些意想不到的困难。
在真实的世界中，光是“准确完整地传达信息”，就很困难，经常出差错。
当然，解决方法也很简单。
反复说明，直到信息充分传达为止。
曾经，有个需求是这样的：
“从3个题库里面随机抽取5道题，要保证每个题库至少要有1道题。”
然后技术跟我说，这个搞不了，里面需要很多判断，很复杂。
具体怎么个复杂法，他也没法表述清楚。
我思考了下，说，能不能这样：
“第1题从题库A中随机取，第2题从题库B中随机取，第3题从题库C中随机取，第4、5题则在3个库中随机取，但要去重。”
技术想了想，说这样搞可以。
为什么原来不能搞，现在又能搞了呢？
那是因为，技术以为，“每道题出现的概率要一致”，“题目出现的位置也要随机”。
然而，从业务上看，并不需要做到这个地步。
像这样的问题，无法像第一种情况那样，事先在PRD上完全说明清楚。
因此，需要与技术仔细沟通，并在沟通过程中，细心地甄别出双方在“理解”上的错位。
曾经，我想给某个小模块增加一个状态变化。
但是，负责的技术说没办法搞。
我非常困惑，这应该是非常简单的功能呀，怎么**没办法做呢？
“要增加状态变化，需要新增一个字段来控制。”
“那加就是啦。”
“可我这边只负责调用，没办法加字段。得某某组那边才能加字段。”
“我……”
这看起来，多少有点让人哭笑不得。
但，设身处地想想，其实也挺正常。
我们从外部看，**觉得技术部门就是一个整体，技术的问题他们内部理应自行沟通协商解决。
但是，每个人都有自己的分工，做着自己的工作。互相之间，关联性没那么强。
一个项目，往往需要技术部门不同分工的同事协同完成。
有时候，碰到涉及面较大的问题，更是需要让不同分工的同事聚在一起，从各自的角度出发，提出意见，讨论解决方案。
希望他们能自发地组织起来进行协作，其实是一种挺偷懒的想法。
在没有项目经理的情况下，产品经理应该有意识地成为“组织者”。
当发现需要多人协作时，主动地组织起各方，高效地达成合作。
当然，这就需要产品经理充分了解团队的工作分工。
这个情况是，虽然技术上可行，但是预计花费的时间过多。
如果真的这么去做了，很可能无法按期上线，或者影响到其他项目的上线。
那么，解决思路也很清楚。
要么调整方案，要么修改开发排期，给与更多的开发时间。
要注意的是，有一些比较老油条的技术，嫌麻烦，不想搞，**“欺负”产品经理不懂。
他不说”时间不够“，而是含糊其辞地说，“太复杂了，搞不了。”
这一点，产品新人要注意甄别。
某种意义上讲，没有什么需求是实现不了的，只是成本的问题。
有时候，技术的意思，其实是：
“（因为没法把工作量控制在合理的范围内，所以，）这个需求搞不了。”
比方说，这个项目需要10个单位的工作量。
技术根据自己对需求的理解，认为以这个项目的价值，**过5个单位的工作量，就不合理了。
然而，因为这个项目重要级比较高，哪怕是花费10个单位的工作量，也是值得的。
当然，这个工作量的问题，需要在评审的时候提出来讨论，并且最终与领导达成共识。
不是产品经理自己单方面觉得“值得”就可以了。
这种情况下，产品经理需要把项目的重要级，以及领导已知悉并同意的情况，给技术传达清楚。
特别的，有时候，“搞不了”的意见，是技术组长给出的。
这时候，“纠缠”具体某个技术就没有意义了，应该直接和技术组长沟通。
有2种的态度，我认为是有问题的。
一种是，认为既然领导已经审批通过了，那么技术就应该按要求去完成。
有问题，不关我的事，你们内部自己协商解决。
我只关心结果。
另一种是，盲目地认为“专业的事情交给专业的人处理”。
既然技术说了不行，那就不行。
没必要去了解其中的细节，反正我也不懂。
这2种工作方式，我多少有碰见过。
个人觉得，至少作为产品经理，是不应该如此的。
上面列举的几种情况，需要产品经理具备不同的能力，分别用不同的方式妥当应对。
但是，无论哪种情况，一个不变的前提是，需要产品经理深入其中，充分调研，了解个中细节，敏感地发现问题所在。
从“搞不了”变成“搞得了”的过程中，产品经理的沟通协调工作，发挥了重要的作用。
换个角度来说，这也是产品经理的职责所在。
你是否也碰到过这样的问题？你是怎么处理的？
简明产品论，微信公众号：简明产品论（ID：JianMingPM），人人都是产品经理专栏作家。在真实的世界里做产品。
本文原创发布于人人都是产品经理，未经许可，禁止转载
题图来自 Unsplash，基于 CC0 协议
