《产品经理的技术必修课》是由起点学院发起的，帮助非技术出身的产品经理掌握基础技术知识的7日学习计划。
在前几期的课程学习中，同学们结合自己的学习到的知识，一起探讨了这个在产品经理的日常工作中的常见场景：技术同学提了一个产品同学不了解的技术方案，因而需要延后预定的发版上线时间，作为产品经理，你会如何处理？
我们将其中的3个优秀回答分享给你，希望对你有所启发。
来自@铄的回答
一、分析问题
这道题，翻译成普通话，就是，程序员用自以为你能听懂的外语跟你解释了一下，试图让你听懂并同情他，给他更多的时间。
分析这个问题，我们发现中间有两个问题，
1.我总结为：你说啥我听不懂？我说的你到底有没有听懂？
场景如下：
产品OS：他说的什么鬼，我听不懂，是不是又在骗我……
技术OS：这货估计又没听懂，老天能不能给我一个有智商的产品来交流。
2.我总结为：你跟我说这有啥用？
场景如下：
产品OS：听懂你说啥，有毛线用，我也解决不了，要不你躲开我来写代码？
技术OS：你个画图小能手，实现方案你一点都提不出想法，我要个产品能干嘛？
二、问题总结
以上两个问题就是解决问题的过程：能听懂程序员在说啥 + 能协助解决这个逻辑问题 = 解决问题
三、解决问题
针对第一个问题，推荐四个方法：
和程序员组织一场肉搏战，丫的能不能做，不能做加班做。作为和谐社会的一份子，此方法不建议使用（虽然自己其实很想用）
听不懂就要找个翻译，那就分三种情况，首先自己翻译，自己加强技术方面的基础学习，在程序员不是故意为难的情况下能听懂他在bb什么，当然首推唐老师的《产品经理的技术必修课》课程（此处为真心打的广告）
其次，让程序员翻译，尽量让程序员用简单一些的产品思维给你解答问题，具体要经历哪些步骤或者跟你说一下这么做的最后现象是什么。尽可能的去理解程序员的说法，如果有可能尽量用图示的方法复述过程，来确定你的想法和程序员的是不是一致的。
请个翻译，如果程序员产品思维实在是较弱，你真的听不懂，就要技术负责人，或者该技术的师父或者领导介入，耐心解释，你不是去告状，而是真的想尽快的解决问题。让他们进行技术沟通，尽量简单的让“翻译同志”给你讲解一下其中遇到的困难。
关于解决问题，我的解决步骤如下：
在听懂他说的技术难点之后，尝试着进行脑暴，看看有没有什么可能得解决办法。注意，这时候的原则是：不要让对方觉得你太蠢。
思考类似的产品，看看有没有类似的功能实现，引导程序员思考一下可不可以参考其他产品的处理办法。
如果还没有什么合适的办法，那就跟程序员聊聊需求，看看这部分想完成的功能点能不能有其他技术比较简单，体验差距不太大的产品方案可以解决。
如果方案没有脑暴出合适的，要求寻求技术负责人的帮助，看看老年程序员有没有什么好的办法解决，最好是提供快捷的技术方案，或者提供一个新的产品思路。原则和之前类似。
如果沟通下来，这个没有任何新的产品方案可以顶替，而且确实是技术壁垒，要判断这个功能点的优先级，如果优先级很高，那么就申请延期，把这个功能做好。如果优先级不高，你和项目经理共同判断没有必要因为这个延期，那么，就放在后面的单独一个版本里面做。但是要注意和程序员沟通，让他留好接口，方便以后添加这个功能。
以上，就是我和程序员撕逼的心得。当然对于我等妹子还有一个一劳永逸的办法，给程序员当女朋友，然后你就可以随意使唤他了[微笑脸]。
来自@Martin_熊的回答
首先我们来抓住题目中的关键字：不了解的技术方案+延后预定的上线时间。以及一个隐含条件，技术同学为什么要提这个技术方案？？？
在答主看来，技术同学主动提出的动机无非是：
提高系统模块的可复用性，工作量可以减少。
主动优化系统，提高流畅性，展示自己的技艺。
（牺牲核心需求体验的偷懒就不谈了，精神鼓励下技术，但是这个真的不可以…）
那么综上所述动机基本都是好的，我们就从以下三步来处理这种情况。
一、了解方案
不了解的地方在哪，不了解转化为问题，然后细化问题。所有的技术细节我们只需要转化为前端的UI体验是怎样的、解决需求的程度。尽量将技术方案转化为前端可视化体验思维。
运用这个方案的话需要多少时间？与老版本迭代需要多大的安装包？
理解了我们进行下一步，不能理解只能Pass（大家都不能理解，一个人懂没办法预测效果啊）
二、分析方案
1、再次提出当前版本核心需求，和技术同学二次确认，研究下此方案是否方向正确。
引导技术同学以解决问题的思路，方向不对，另想一个正确的方案。
2、实现此技术方案所需要的时间和满足需求的程度、产生的利益之间进行权衡
也就是成本、质量、盈利之间权衡
情况一：技术利用这个方案提升了后期开发的效率，提升了系统的流畅性，但用户难以忍受现阶段版本。
解决方案：这种情况时间是第一要素，避免流失更多的客户，运营是老大。
调至流量稳定后再进行改版。
情况二：当前版本基本满足核心需求，用户基本稳定。
解决方案：这种情况，站在技术同学一方，劝说运营，为后期敏捷开发或稳定性奠定基础。
三、协调与执行
情况一：Pass掉技术员的方案，考虑到所有因素，以当前版本所要到达核心要素为由拒绝，并表扬技术同学，协商如果这个方案真的好。另行确定研发时间。
情况二：采用方案，利用方案的有利因素，劝说其他部门进行版本延误等待。
四、总结
遇到此种情况，分析技术同学的方案，如果不理解，可不可以协调成可视化便于理解，或者找一个“翻译”。在理解的基础上，要明确当前时间节点的最重要需求是否可以延迟。
五、附件
来自@Dennis 的回答
首先面对这样的问题，先开启产品思维（从战略、方向、价值）然后再开启技术思维（开发成本、技术架构、版本）；
if ( 产品同学给出的技术方案不满足这次版本的战略和方向 )
{
直接P掉
}
else if ( 这个功能在这次版本需求的排序较低 )
{
能否完善后再下个版本进行更新
}
if ( 必须在这次版本更新 )
{
// 开启技术思维
先询问这次方案需要完成的具体时间，具体的难点在哪里，是需要重构现有架构还是现有架构上开发。
能否把此功能拆分成几个小版本进行迭代
if( 可以拆分 )
{
把大的功能拆分成几个小版本，先从可用、能用到好用，进行版本迭代
}
else
{
通过加班或轮班，外加福利奖励的方式进行替代
}
}
在整个课程的学习过程中，可以发现老师有期间有几个关键词重复了几次 —— 技术思维、沟通组织者、同理心。
结合我平时的工作情况，我觉得这几个词几乎贯穿了与工程师们交流的全过程：
首先，技术思维是建立你与工程师的沟通前提，只有掌握了技术思维，才能站在同个频道进行沟通。
其次，成为沟通组织者，工程师们大多都是理性的，他们只讲逻辑不讲故事。所以跟他们沟通只需明确问题，然后协同各方的参与者一起聚焦解决方案并最终达成一致。
同时工程师们天生就有一种成就感和使命感，所以作为项目的沟通组织者，需要明确工程师们在项目中的重要位置和项目可以给予他们的价值，让他们觉得是项目的参与者而不是被管理者。
只有建立在此基础上，工程师会更努力的来完成项目，甚至会给你提出很多不错的解决方案，来提升他们的成就感。
最后，你可以利用同理心，多站在工程师的角度想问题，至少让工程师觉得你是懂他们的人，这样才能建立起良好的沟通机制，同时给工程师心理刻上靠谱的标签。
