技术人员提出了一个你不了解的技术方案并要求延期,作为产品经理,你该如何处理?

产品老司机手把手教写文档,10天线上课程,零基础掌握产品经理必备7大文档撰写法。了解一下>

《产品经理的技术必修课》是由起点学院发起的,帮助非技术出身的产品经理掌握基础技术知识的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

评论
欢迎留言讨论~!
  1. 自强啊!!!不向程序猿低头,当女朋友? 不存在的

    回复
  2. 看了一半的时候,我在想小编还缺男朋友吗?这是一个什么网站?

    回复
    1. 哈哈,这是咱们的课程学员关于“技术同学提了一个产品同学不了解的技术方案,因而需要延后预定的发版上线时间,作为产品经理,你会如何处理?”这个问题的思考答案哟

      回复
  3. 小题大做了吧

    回复
    1. 每一个看起来小的问题都有值得思考和探索的地方呢,欢迎一起探讨呀~ :oops:

      回复