邱岳的产品手记
邱岳
无码科技产品经理，公众号二爷鉴书作者
立即订阅
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
收起评论