《产品经理的技术必修课》是由起点学院发起的，帮助非技术出身的产品经理掌握基础技术知识的7日学习计划。

在前几期的课程学习中，同学们结合自己的学习到的知识，一起探讨了这个在产品经理的日常工作中的常见场景：技术同学提了一个产品同学不了解的技术方案，因而需要延后预定的发版上线时间，作为产品经理，你会如何处理？

我们将其中的3个优秀回答分享给你，希望对你有所启发。

来自@铄的回答

一、分析问题

这道题，翻译成普通话，就是，程序员用自以为你能听懂的外语跟你解释了一下，试图让你听懂并同情他，给他更多的时间。

分析这个问题，我们发现中间有两个问题，

1.我总结为：你说啥我听不懂？我说的你到底有没有听懂？

场景如下：

产品OS：他说的什么鬼，我听不懂，是不是又在骗我……

技术OS：这货估计又没听懂，老天能不能给我一个有智商的产品来交流。

2.我总结为：你跟我说这有啥用？

场景如下：

产品OS：听懂你说啥，有毛线用，我也解决不了，要不你躲开我来写代码？

技术OS：你个画图小能手，实现方案你一点都提不出想法，我要个产品能干嘛？

二、问题总结

以上两个问题就是解决问题的过程：能听懂程序员在说啥 + 能协助解决这个逻辑问题 = 解决问题

三、解决问题

针对第一个问题，推荐四个方法：

1. 和程序员组织一场肉搏战，丫的能不能做，不能做加班做。作为和谐社会的一份子，此方法不建议使用（虽然自己其实很想用）
2. 听不懂就要找个翻译，那就分三种情况，首先自己翻译，自己加强技术方面的基础学习，在程序员不是故意为难的情况下能听懂他在bb什么，当然首推唐老师的《产品经理的技术必修课》课程（此处为真心打的广告）
3. 其次，让程序员翻译，尽量让程序员用简单一些的产品思维给你解答问题，具体要经历哪些步骤或者跟你说一下这么做的最后现象是什么。尽可能的去理解程序员的说法，如果有可能尽量用图示的方法复述过程，来确定你的想法和程序员的是不是一致的。
4. 请个翻译，如果程序员产品思维实在是较弱，你真的听不懂，就要技术负责人，或者该技术的师父或者领导介入，耐心解释，你不是去告状，而是真的想尽快的解决问题。让他们进行技术沟通，尽量简单的让“翻译同志”给你讲解一下其中遇到的困难。

这样四个方案下来，应该大概听懂技术在说什么了。

关于解决问题，我的解决步骤如下：

1. 在听懂他说的技术难点之后，尝试着进行脑暴，看看有没有什么可能得解决办法。注意，这时候的原则是：不要让对方觉得你太蠢。
2. 思考类似的产品，看看有没有类似的功能实现，引导程序员思考一下可不可以参考其他产品的处理办法。
3. 如果还没有什么合适的办法，那就跟程序员聊聊需求，看看这部分想完成的功能点能不能有其他技术比较简单，体验差距不太大的产品方案可以解决。
4. 如果方案没有脑暴出合适的，要求寻求技术负责人的帮助，看看老年程序员有没有什么好的办法解决，最好是提供快捷的技术方案，或者提供一个新的产品思路。原则和之前类似。
5. 如果沟通下来，这个没有任何新的产品方案可以顶替，而且确实是技术壁垒，要判断这个功能点的优先级，如果优先级很高，那么就申请延期，把这个功能做好。如果优先级不高，你和项目经理共同判断没有必要因为这个延期，那么，就放在后面的单独一个版本里面做。但是要注意和程序员沟通，让他留好接口，方便以后添加这个功能。

以上，就是我和程序员撕逼的心得。当然对于我等妹子还有一个一劳永逸的办法，给程序员当女朋友，然后你就可以随意使唤他了[微笑脸]。

来自@Martin_熊的回答

首先我们来抓住题目中的关键字：不了解的技术方案+延后预定的上线时间。以及一个隐含条件，技术同学为什么要提这个技术方案？？？

在答主看来，技术同学主动提出的动机无非是：

• 提高系统模块的可复用性，工作量可以减少。
• 主动优化系统，提高流畅性，展示自己的技艺。

（牺牲核心需求体验的偷懒就不谈了，精神鼓励下技术，但是这个真的不可以…）

那么综上所述动机基本都是好的，我们就从以下三步来处理这种情况。

一、了解方案

• 不了解的地方在哪，不了解转化为问题，然后细化问题。所有的技术细节我们只需要转化为前端的UI体验是怎样的、解决需求的程度。尽量将技术方案转化为前端可视化体验思维。
• 运用这个方案的话需要多少时间？与老版本迭代需要多大的安装包？

理解了我们进行下一步，不能理解只能Pass（大家都不能理解，一个人懂没办法预测效果啊）

二、分析方案

1、再次提出当前版本核心需求，和技术同学二次确认，研究下此方案是否方向正确。

引导技术同学以解决问题的思路，方向不对，另想一个正确的方案。

2、实现此技术方案所需要的时间和满足需求的程度、产生的利益之间进行权衡

也就是成本、质量、盈利之间权衡

情况一：技术利用这个方案提升了后期开发的效率，提升了系统的流畅性，但用户难以忍受现阶段版本。

解决方案：这种情况时间是第一要素，避免流失更多的客户，运营是老大。

调至流量稳定后再进行改版。

情况二：当前版本基本满足核心需求，用户基本稳定。

解决方案：这种情况，站在技术同学一方，劝说运营，为后期敏捷开发或稳定性奠定基础。

三、协调与执行

情况一：Pass掉技术员的方案，考虑到所有因素，以当前版本所要到达核心要素为由拒绝，并表扬技术同学，协商如果这个方案真的好。另行确定研发时间。

情况二：采用方案，利用方案的有利因素，劝说其他部门进行版本延误等待。

四、总结

遇到此种情况，分析技术同学的方案，如果不理解，可不可以协调成可视化便于理解，或者找一个“翻译”。在理解的基础上，要明确当前时间节点的最重要需求是否可以延迟。

五、附件

来自@Dennis 的回答

首先面对这样的问题，先开启产品思维（从战略、方向、价值）然后再开启技术思维（开发成本、技术架构、版本）；

if ( 产品同学给出的技术方案不满足这次版本的战略和方向 )

{

直接P掉

}

else if ( 这个功能在这次版本需求的排序较低 )

{

能否完善后再下个版本进行更新

}

if ( 必须在这次版本更新 )

{

// 开启技术思维

先询问这次方案需要完成的具体时间，具体的难点在哪里，是需要重构现有架构还是现有架构上开发。

能否把此功能拆分成几个小版本进行迭代

if( 可以拆分 )

{

把大的功能拆分成几个小版本，先从可用、能用到好用，进行版本迭代

}

else

{

通过加班或轮班，外加福利奖励的方式进行替代

}

}

在整个课程的学习过程中，可以发现老师有期间有几个关键词重复了几次 —— 技术思维、沟通组织者、同理心。

结合我平时的工作情况，我觉得这几个词几乎贯穿了与工程师们交流的全过程：

首先，技术思维是建立你与工程师的沟通前提，只有掌握了技术思维，才能站在同个频道进行沟通。

其次，成为沟通组织者，工程师们大多都是理性的，他们只讲逻辑不讲故事。所以跟他们沟通只需明确问题，然后协同各方的参与者一起聚焦解决方案并最终达成一致。

同时工程师们天生就有一种成就感和使命感，所以作为项目的沟通组织者，需要明确工程师们在项目中的重要位置和项目可以给予他们的价值，让他们觉得是项目的参与者而不是被管理者。

只有建立在此基础上，工程师会更努力的来完成项目，甚至会给你提出很多不错的解决方案，来提升他们的成就感。

最后，你可以利用同理心，多站在工程师的角度想问题，至少让工程师觉得你是懂他们的人，这样才能建立起良好的沟通机制，同时给工程师心理刻上靠谱的标签。

《产品经理的技术必修课》第4期学员招募已经开启。

《产品经理必懂的技术那点事儿》作者亲自带班，每日定时答疑，专属社群学习，每日小作业思考总结，大作业梳理所学知识，帮助非技术出身的产品经理掌握基础技术知识。

原价299元，前100名报名享受早鸟价99元

了解详情，戳 http://t.cn/R0SsYnF