开发说这个需要做不了，你会如何应答？

长夜漫漫无尽头

编纂导语：作为产品经理，在和开发对接需要的时分，可能会遇到开发说需要做不了的情景，这类时分该怎么解决呢？是砍掉需要或者暴力沟通吗？本文作者以为，实质是问题模型的问题，并分为三步进行了剖析，一同来看一下吧。

这是一个历久弥新的产品话题。
镜同窗置信，简直每个产品经理在和开发对接需要的过程当中，都遇到过这样的情景，按照我的视察，不少产品经理最初都选择了主动让步。
这外面次要有两个缘故：
一是，某些产品经理主观上懒于深化思考，想着既然开发都说完成不了了，那就没方法了呗，更有甚者就以此为上方宝剑，二话不说就调剂需要或者砍掉需要。
二是，产品和开发沟通时没有劣势壁垒，沟通视角自然对峙，又或者开发讲的技术逻辑产品同窗压根听不懂，天然就感觉他们说的颇有情理，要末就走入暴力沟通的死胡同：
他人家能完成为啥你就完成不了？技术我不懂，反正这就是业务需要。反正我就要五彩斑斓的黑。今天要上线，怎么完成我不论。不论是哪一种缘故，最初酿成的后果都是需要不合无奈失掉妥善地解决，遗憾的是，这类状况居然非常广泛，以致于在某些组织环境下，开发造成了惯性认知，致使稍显繁杂的需要，开发都会说技术完成不了。
技术心想，反正你又不懂技术，这样就形成产品经理很主动，而且，这与“咱们要做难而正确的事”这个理念相违抗。
这就似乎堕入理解决问题的瓶颈：产品经理不懂技术，基本无奈解决这些问题，这间接带来了，产品的生态土壤的减速变坏。
事实真的如斯吗？
我在以前的文章中说过得多次：任何一个问题都有一个实质解和N个景象解，咱们只要找到实质解能力从基本上解决这个问题。
在我眼里，懂不懂技术只是景象解，其实不能从基本上解决这种问题，这个问题的实质依然是问题模型的问题。
那末，甚么是正确的办法呢？
我感觉次要能够分为三步，而这关于刚入门的产品经理尤为合适，由于他们有空杯心态，尚无造成固化的任务办法，更易从底层养成正确的办法论。
一、你要有专家效应
专家效应答表面达的是你的权威，我始终倡议产品经理要对根底的产品专业才能要纯熟掌握，好比，在没有筹备好的状况下，不要等闲颁发意见或者组织需要评审，只要在组织内造成了专家效应，后续的任务能力更无利。
产品经理一旦失去权威，就会对后续的需要沟通极其不利。
我举个产品小案例：
咱们团队以前有个产品经理在设计产品需要时，将”性别“这个字段做成为了输出框，而不是下拉选择（男/女），后果被开发广为吐槽，起初他的需要开发都不怎么注重。
这虽然是个很小的细节，但会极大挫伤你的专业才能，很容易失去开发的信赖，相似于这样的事件，咱们一定要防止，好比，常见的坑还有“原型设计”不足根底的交互，需要评审不讲业务场景，需要阐明没有功用定义等等，这些以前文章都有过分享。
总之，产品同窗一定要重视专业才能，这是产品硬实力，是产品职场任务提升的底层根底。
对于产品经理零碎化的专业才能体系，我在以前的问题提到得多次，有兴致的同窗也能够翻看或症结词搜寻以前的文章，好比，就在上一篇文章“矫捷五步，手把手教你画产品架构图。”中就提到，产品架构设计就是展现你专家效应的无效伎俩之一。


二、多元化思惟，拓展才能界限
产品经理是一系列产品思惟的表白载体，综合才能集中体当初问题的解决上，这就需求跨学迷信习，多元化思惟，这两头就包罗“技术思惟”。
上周咱们在设计客户瓜葛办理时，对于“公海规定”的一个需要，开发说完成不了，过后技术同窗倡议客户附属于公海，产品经理反馈给我后，我在群里发了动静，起初问题失掉了妥善的解决。
究其缘故在于我有一些浅陋的技术积攒，加上同理心理维，站在技术角度去思考并将产品言语翻译成技术言语去压服他们。
我是这样回复的，分享给你，但愿能对你了解“多元化思惟对产品的价值”有帮忙：
对于“客户办理零碎中，同一个客户同时知足并触发多条公海规定，如何流入处置”的倡议：
1、公海的次要业务场景是依据规定发出客户，用以进步业务效力，其实质上实际上是数据权限办理，即成为某个或多个公海成员的用户，有权限查看并支付该公海里的客户。
2、明确了这个业务场景，若客户A同时属于公海①、公海②，当规定同时触发时，应该同时流入公海①、公海②，好比团体事业部场景，客户A属于危化企业，智慧环保为公海①，平安科技为公海②，两个事业部均可以推动团体业务，此时应该允许公海①、公海②下的成员有权查看并支付。
3、客户应该为实体类，独一标识应该是客户ID，不该该为担任人或者附属公海，担任人或附属公海都是该客户数据的两个动态字段。
处置倡议：
计划一：当客户同时知足多条公海规定时，应该流入两个公海，当在某个公海中被支付之后，同时在另外一个公海中也同步移除，再也不展现，客户数据是同一个数据（应优先按这个逻辑处置）计划二：当客户同时知足多条公海规定时，流入最新创立的那条公海（指定公海规定便可）我的这个产品经理没能压服开发自身，次要在于这个产品经理没有技术思惟，又不足深度思考和沟通的办法，所以把开发的反馈主动当成为了实质解决计划，没能无效解决这个需要。
固然，不同岗位任务自身有界限，产品经理其实不需求深化技术自身，不外，适量懂一些技术思惟和根本常识，在产品任务中能进行无效结合和融会思考，就可以极大的进步需要传递效力。
这也是我在以前文章中，重复保举的一本书《畛域驱动产品设计》的缘故。
三、聚焦问题自身，留意沟通办法
得多时分，沟通都是无方法的，压服他人的症结在于聚焦问题自身，不要情绪反抗，就这件事上，试着找到已有解决计划的案例，往往比红润的沟通更有压服力。
我想起了多年前在以前公司做的一个小需要，过后的需要是要在“组织机构设计时”减少了搜寻功用，由于咱们团体使用这个零碎，组织机构是每个事业部的业务单元，好比，每个城郊区域可能都是一个组织机构。


这就会致使有上百个组织机构，因此，对业务经营来讲，能够搜寻到某一个组织机构就显得颇有用，这也是业务自身的需要。
过后我是和一个前端开发对接，阿谁开发同窗反馈说不太好完成，可能他也是刚入门技术才能无限，也多是名目时间太紧了。
然而，我知道这个需要是颇有业务价值的，我还知道：繁多的沟通问题自身，远远不如找一个案例更有压服力。
因而，我和他说，我们不焦急，先一同想一想方法，起初，我间接搜寻“可搜寻的树形组件”，很快就找到了一个产品案例：


拿着这个案例，咱们沟通很快就达成为了共鸣，而且，他不会以为你是浅陋的需要翻译官，当你从业务场景讲述需要价值，用同理心思解他的岗位技巧，试图和他同频共振，再找一个产品案例去沟通交流，很快就可以压服他。
并且，这类事件还会不停减少你的专家效应。
说到这里，让咱们总结下，为了无效应答开发反馈说技术完成不了，从产品任务一开始咱们就有须要履行三部曲：确立专家效应→找到基本缘故→使用沟通软技巧。
其实，最首要的仍是要找到面前真实的缘故，由于，得多时分开发反馈技术完成不了，其实不一定就是技术瓶颈。
咱们在解决这些问题时，只要找到了面前真实的缘故，能力更高效地解决问题，由于，面前真正的缘故往往是实质解，但这其实有时分很难辨认。
不信，你试着回忆斯宾格勒的一句话：秒针这一秒指向59，下一秒指向60，59就是60的缘故吗？
最初，真的但愿本文对你能有产品启示。
#专栏作家#
产品大峡谷，大众号：产品大峡谷，人人都是产品经理专栏作家。七年B端产品经理，供给链物流与金融畛域，长于需要设计、业务指点、商业视察等。
本文由@大众号：产品大峡谷 原创公布于人人都是产品经理，未经许可，阻止转载。
题图来自 Unsplash，基于CC0协定。