技术人员提出了一个你不了解的技术方案并要求延期作

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