邱岳的产品手记
邱岳
无码科技产品经理,公众号二爷鉴书作者
立即订阅
9950 人已学习
课程目录
已完结 48 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 | 产品经理的世界没有对错
免费
01 | 验证码是个好设计吗?
02 | 产品经理工具指南
03 | 产品案例分析·Trigraphy的设计哲学
04 | 如何当好AI时代的产品经理?(学习篇)
05 | 如何当好AI时代的产品经理?(实践篇)
06 | 产品案例分析 · The Guardian的文本之美
07 | 关于需求变更(上):需求背后的需求
08 | 关于需求变更(下) : 化变更于无形
09 | 产品案例分析:Hopper的“人工智能”
10 | 产品被抄袭了,怎么办?
11 | 如何借鉴灵感?
12 | 产品案例分析:LabRdr的设计实验
13 | 无用却必要:产品规划(上)
14 | 留白与节奏:产品规划(下)
15 | 产品案例分析:Mimo与Learn Python的导学之趣
16 | 在内部产品中找到产品经理的价值
17 | 产品经理如何获得非权力性的影响力?
18 | 产品案例分析:WWF Together的情怀设计
19 | 产品经理如何与开发打交道(上):打破思维的边界
20 | 产品经理如何与开发打交道(下):合作与共赢
21 | 产品案例分析:Fabulous的精致养成
22 | 产品经理的图文基本功(上):产品文档
23 | 产品经理的图文基本功(下):产品图例
24 | 产品案例分析:PathSource的混乱与直观
25 | 产品世界的暗黑模式:操纵的诱惑
26 | 写好产品文档的诀窍
27 | 产品案例分析:Quartz&Hooked的对话式交互
28 | 产品分析的套路(上):谁是利益相关者?
29 | 产品分析的套路(中):解决什么问题?
30 | 产品案例分析:Primer的扑克牌交互
31 | 产品分析的套路(下):如何出解决方案?
32 | 从受众规模、需求频率和强度出发:排定需求优先级的方法(上)
33 | 产品案例分析:Arts & Culture 的架构之美
34 | 价值曲线分析:排定需求优先级的方法(下)
35 | 答疑时间:关于产品经理的12个问题
36 | 产品案例分析:解读知识星球
37 | 如何做好需求评审(上):需求评审不只是一次会议
38 | 如何做好需求评审(下):在评审中控住全场
39 | 产品案例分析:SeatGeek的订票设计
40 | 新年给产品经理的几碗鸡汤
41 | 产品经理的项目管理心得
42 | 产品案例分析:Unread的阅读体验
43 | “玩”的力量:从游戏设计中学习产品设计(上)
44 | “玩”的启示:从游戏设计中学习产品设计(下)
45 | 产品案例分析:Chartistic的“复杂”图表
尾声:你的快乐是哪一种
【第二季回归】二爷归来,再次扬帆起航
邱岳的产品手记
登录|注册

20 | 产品经理如何与开发打交道(下):合作与共赢

邱岳 2018-01-04
“兄弟阋于墙,外御其务”——《诗经》
上篇文章,我提到产品经理与工程师之间隔阂的原因,主要是思维方式的差异,以及关注领域的不同,然后聊到了几个加强沟通的方法,比如让产品经理向工程师介绍业务,以及主动去理解和学习技术等等内容,今天我们继续聊这个话题。
之前我提到过,因为角色的差异,产品经理和工程师变成了上下游。也就是产品经理折腾半天,做需求收集、分析讨论等等,然后做出 PRD 交给工程师之后就不管了,工程师拿到 PRD 之后做系统设计研发实施。我们希望工程师可以尽量早地参与到流程中来,产品经理则尽量晚地从流程中退出去。

全流程参与

对产品经理来说,首先要做到尽可能在项目的早期去跟工程师沟通。我们在安排一些项目的早期,可能因为很多东西没有最终确定,也不太想跟工程师说,觉得等确定了再沟通;但这样做很容易导致说的时候已经来不及了。比如 11 月 3 日通知工程师说:“咱们 11 月 11 日大促,这是三个需求你尽快做一下”,工程师会非常反感这种带着截止期限的突然袭击。
最好的方式是当某个业务有苗头的时候,产品经理就应该开始跟工程师交流,但这时候不要正式地去提需求,而是做一些非正式的沟通,否则后期如果有变化会让工程师觉得你出尔反尔。
除此之外,一定要邀请工程师来参与项目前期的需求收集和需求评审,不要觉得这种场合不需要工程师,等确定了再转述或者产品经理去宣讲就可以了。你需要尽可能让工程师参与,他可以更全面地了解项目和特性的目的,和不同利益相关者的顾虑和立场,也可以让工程师理解一些产品经理对产品细节的坚持。
除了让工程师往前走参与需求过程之外,产品经理也要主动往流程的后半部分延伸,去参与设计、开发、上线中的技术部分。比如在产品上线过程中出了 Bug,服务不可用了。
这时候产品经理应该干什么?可能有的人不参与,等着工程师自己处理,还有的在群里吵,谁的 Bug,什么时候修好等等;但是,其实更合适的方式是能够参与到问题解决中,去问一下具体是什么问题,需不需要帮助。
很多时候工程师在考虑故障的时候,主要会去想如何把出现的问题修好,而产品经理在考虑问题的时候,可能会考虑怎样把问题规避过去。比如说付款流程走不下去,工程师会想着去修复它,而产品经理或许可以协调一些资源,直接在某个时间段内就免费掉,先把付款流程绕过去,不损失用户。
但要注意的是,产品经理可以参与,但不要添乱,人家工程师在紧急地写补丁,你拉着人家说:“别写,先给我讲讲。”这样做就很不得体了。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《邱岳的产品手记》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(13)

  • Ned
    有项目喝酒吃肉谈工作,没项目吃肉喝酒聊生活
    相互尊重是原则,敢于背锅是觉悟

    作者回复: 赞总结

    2018-01-04
    16
  • 刘祯
    句句在理,职场残酷,建立良好的人际关系就至关重要了,二爷文章中的几句调侃真的很赞。

    说起与工程师打交道,我自己的经历可供大家参考。

    小宇是我们创业后认识的一位技术伙伴,熟悉 PhP 程序语言开发,在工作两年后,他辞去知名杂志社工作加入我们的创业团队,他负责技术,我负责产品,两人便因此相识了。
     
    刚认识小宇之时,我还是十分稚嫩,关于需求讨论或是开发进度都不可避免地与他产生各种各样的矛盾,这一度让我十分压抑,似乎我的角色要被代替了。在我看来,他的确经验丰富,对于技术、产品、趋势、商业都有清晰的见解,很多方面我都需要向他请教,但我心里总是有些不甘,希望能够成为全面的产品经理。

    再三反思后,我逐渐转变了自己的工作态度以及沟通方式,虽然他说话直白,但就事论事,我认为是很舒服的交流方式。后来,我们也慢慢变成了无话不谈的朋友,现在还在一起学习成长,相互理解。

    作者回复: 有这样的朋友,比一份工作还有价值,或许你以后会理解,记得一直跟他保持联系

    2018-01-04
    7
  • 孙伟贤
    工程师是我觉得公司里最好沟通的人,单纯的要命。

    作者回复: 哈哈哈哈哈哈哈哈,没错

    2018-01-06
    6
  • 骆驼
    产品经理怎么帮工程师争取利益?还能升职加薪?一般都是各个部门做自己的review,当然二爷这个位置除外,你是老板,我说的是一般岗位的产品经理

    作者回复: 有时候发一封邮件,表达感谢,描述他的出色,抄送他的老板就很好。

    2018-01-04
    3
  • Dylan
    文中提到的对于上线交付时间的模糊处理是个非常好的方法,我准备去应用。总之做大蛋糕,舍满取半
    2018-06-28
    2
  • GeekAmI
    看到这里 作为开发 我很欣慰
    2018-01-10
    1
  • 时间之树
    与工程师合作最让我纠结的就是二爷提到的时间问题。大领导会找产品经理要完成时间,而产品经理需要和工程师沟通时间,周期太长大领导不同意,周期短了大部分情况下会延期,尤其面对工程师的延期,会很无奈。如果情绪处理不好,很容易与工程师产生对立。

    作者回复: 潜移默化的改变,曲线救国

    2018-01-10
    1
  • 拾叔
    适当的在项目过程或者项目结束后,当着工程师领导的面特别感谢这个工程师,效果非常不错,不一定是要正式的,侧面也许效果更佳,不虚伪。

    作者回复: 嗯,总之脑子里得有这根弦儿,有这个意识

    2018-01-09
    1
  • 大冯宇宙
    提意见的渠道呢

    作者回复: 当面提就挺好,可以看看这篇http://qiuyuexp.com/problem-in-implementation/

    2018-01-04
    1
  • Gollum
    我就和开发说光靠我一个想是不够的,大家都要参与进来,多多发表意见,找找产品设计的bug~
    2019-04-21
  • 赫尔曼n
    在哪些情景下是在帮工程师背锅那,有具体的例子吗?
    2018-04-02
  • Bonnie Mei
    目前基本上是需求评审,一般比较顺利,如果中途需求有漏洞,开发也会补上,后续我这边完善需求就行,前提是:不超过半个工作日,但是大问题面前,就要给时间了。
    有次开发跟我说:这是你该考虑的问题,不是我,然后离开了,开发兼项目经理,呵呵哒,我就懵逼了,原型上看不懂的就按照自己想法做,做错了,产品还不能说。后面还好,问题解决了

    作者回复: 看不懂就按自己的想法做是个挺常见的问题,策略地说,委婉地说…

    2018-01-11
  • 小紅帽
    #多听工程师的意见 得到
    最近半年后台产品工作中这个点感受颇多;第一后台产品经验欠缺,第二对行业了解、业务了解基本空白;第一期产品躺过的坑就不计其数,比如何提好一个“API'需求。首先自己心里有畏难情感,不懂不了解相关技术知识,记得当初直接丢一个文档给技术哥哥,答应直接按别人家来做;有天CTO回国外了,技术突然跳出来,这东西做不了,你得重新提需求(这个过错100%由我来负责到底),最终在坎坷、各种放低态度中解决了,平时关系也处理的好。最近提相关的技术需求时,就敲响警钟了;不懂没关系,查相关文档资料,问工程师他所知道的,比如字段、规则、甚至业务。
    强迫工程师做赶着时间节点的评估,我遇到结果是:画的是圆最终实现是椭圆的,然后大家都不满意;彼此付出的劳动成果不被认可,还会被约谈。

    作者回复: 嗯,强扭的瓜不甜

    2018-01-10
收起评论
13
返回
顶部