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