邱岳的产品手记
邱岳
无码科技产品经理,公众号二爷鉴书作者
立即订阅
9923 人已学习
课程目录
已完结 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的“复杂”图表
尾声:你的快乐是哪一种
【第二季回归】二爷归来,再次扬帆起航
邱岳的产品手记
登录|注册

19 | 产品经理如何与开发打交道(上):打破思维的边界

邱岳 2018-01-02
“横看成岭侧成峰,远近高低各不同。——苏轼”
在产品经理的日常工作中,开发工程师可能是我们打交道最多的角色,可是,这两个角色之间却有很多难以调和的矛盾,网上开发工程师怒怼产品经理的艺术作品很多,各种吐槽图片和文章俯拾即是 。
今年的 QCon 会议我也听一个段子,据说在大会的中午自助餐厅里,不同公司相互陌生的工程师,都靠吐槽自己公司产品经理迅速建立了友谊。
我自己写过程序,又成为产品经理,对这个问题有一些自己的理解,今天我就根据这个话题来谈谈产品经理如何同开发打交道。

为什么与怎么做

首先,我们来一起想想是什么原因导致了这两个角色之间的对立。
在面对产品或者特性时,产品经理和开发脑子里的东西是不同的。对于产品经理来说,他想的可能是客户、市场、盈利、竞争优势、政策风险、从哪里获客等等,这些东西想清楚之后,他的产出可能是 PRD,对产品功能需求的描述。开发一看,你折腾半天就这么一个东西,三页纸,没什么难度嘛。
开发脑子里关注的是什么呢?开发会关注手头的系统是不是遗留系统、系统架构有没有限制、公司的技术栈是什么样的、整个链路架构有没有问题、需不需要重构等等。这些东西产品经理可能不关注或者不懂,所以就看着一个挺大的开发团队做了很长时间,推出了一个特性,好像也没什么难度。
作为产品经理,有时我们会低估一个特性背后的技术成本。看什么都觉得简单,人家淘宝也有这个特性,为什么工程师说做不了呢?
尤其是通常在业务初期的时候,为了快速推进,工程师在实现上会做一些比较临时的东西,后期逐渐流量和复杂度提高,即便功能没变,也要花费大量的精力去调整技术架构。
所以你可以看到,产品经理脑子里的东西偏向“为什么”,而工程师脑子的思维方式会比较偏向于“怎么做”,两者的交集在“做什么”上面。也就是说刚才说到的,工程师看到好像产品经理背着手写了三页纸的 PRD,产品经理觉得工程师忙活半天就是一个简单的小特性。
久而久之,就会由不理解变成不信任,越不信任就越缺乏交流,演变成对立。

甲方乙方

关于这个话题我采访过我媳妇,她是做运营的,我说:“开发和产品之间矛盾这么激烈,你怎么看这个问题?”我媳妇觉得很奇怪,问我,你们不是一伙儿的吗?搞不懂为什么天天吵。
其实大部分公司中,最初设计组织的时候都会把产品和开发放到一起来看,希望这两个角色能够合力完成产品的设计和实现;但是在这个团队内部,随着人越来越多,就会有角色的分化,进而有了流程的分化,慢慢形成了甲乙方,或上下游。
如何去分辨团队从合作关系变成甲方乙方的关系呢?
有几个非常明显的信号,第一个是留证据,就是说了什么不算数,要发一个邮件签字画押;第二个是开小会,也就是在跟工程师开会之前,先自己角色内部开个小会,商量怎么对付对方,准备好对策之后再开大会;第三个是用词的方式,当你发现大家的用词越来越谨慎,并且开始在闲聊的时候区分我们和他们,设置大家开始试着从第三方了解彼此在干什么,了解对方对自己的评价等等。
类似的信号如果反复不断地出现,通常就意味着双方开始逐渐走向了对立,如果不加干涉,合作氛围就会出问题,一定要及时发现、及时处理。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《邱岳的产品手记》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(11)

  • 精卫鸟
    我见过的产品同学被怼,通常逃不出下面两点诱因[偷笑]

    1. 需求变更其实没什么,之前没想清楚就说没想清楚,千万别拿用户和体验当幌子,把自己摆在道德高点,让变更变得理直气壮。

    2. 永远不要和开发说这个需求你也不想做,都是老大们让做的; 或者说你这个功能不是我要的,是业务部门要的。开发通常会觉得你没担当,而不是理解你的无奈。 原则上不能守护好产品特性的产品经理,与不能守护好代码完整性的开发,都是很难获得尊敬的。

    作者回复: 对,要有担当,敢承认自己错了

    2018-01-04
    26
  • Little__ZM
    我也是开发专产品。
    理解痛点,技术难点。这有时候是好事,有时候会拦住我的想法。
    好的一面,我的产品文档,大家愿意看。不好的一面,每次想方案,都会被这个好实现么,拦住脚步。

    作者回复: 是的,这是个问题,我也会受到影响

    2018-01-19
    5
  • 张伟
    二爷聊的这个确实是一个不错的选题,建议可以做成一个系列,把产品跨职能沟通过程中遇到的坑分享和分析一下,应该是比较有意思的系列

    作者回复: 好主意~

    2018-01-03
    4
  • yaxin
    作为开发,最烦产经说的一句话,“你去网上搜搜,肯定有现成代码”。
    第一,这让开发感觉被看轻。好像开发连基本的检索能力都不具备,还要你产经来提醒。
    第二,既然开发提出了代码可能达不到预期,就代表项目里可能出了问题。产经根本听不懂,只是一味强压。

    还有一点儿,开发提出图片不合适需要修改,产经来了句“反正下次要改版,先凑合用就行。”那反正要改版,我代码是不是也不写你的新需求了?

    2018-09-15
    3
  • 小紅帽
    #我与开发沟通日常经验得到

    1.好好说话达成共识,彼此工作目的服务于上级,实现价值。

    2.了解彼此,提好需求,同开发技术哥讲清楚为什要做这个功能,最终要实现的结果是怎样的;同时要去了解怎么去实现,过程是否会遇到问题及开发成本。

    3.多一起吃工作餐多交流,绝大部分问题都可在此化解。

    4.态度一定要好,关于技术相关知识不懂的,多问一句,私下自己多补一点。

    作者回复: 最好还是服务一个目标,而不是一个人

    2018-01-04
    3
  • 拾叔
    作为后台产品经理,我天天跟开发厮混到一起,可以充分了解开发自己对产品的需求,其实很多开发并不是只单纯想怎么做,很多时候他们会关心为什么做,做的好处是啥,是否是可以复用的?然后在充分了解需求后,好的工程师甚至会给你提供多种实施方案,和产品一起讨论最终得出最优方案。
    必要的沟通,就是给开发工程师的尊重,让开发能倍感尊重,开发出的代码质量都会好不少。

    作者回复: 我做后台的时候也是天天跟开发厮混,哈哈哈哈哈

    2018-01-09
    2
  • 刘祯
    面对功能的第一反应,我是从用户、场景与问题入手,从第一要点来看,二爷是先考虑业务需求吗?

    关于与开发沟通,我最深的感触就是,要讲清楚为什么,以及这件事情与整个产品的关系,开发不会单独为了某个需求而改变架构,要让他们理解这是产品的分支,而不是另辟蹊径。

    还有就是,真的需要提前花时间沟通,而不是现场冲突,很多想法在开会时其实不见得容易问出来,就像二爷说的,每个人都有防备心理,毕竟这是工作,不是闲聊,有些事情不提前搞定,后续再开会就十分难看了。

    作者回复: 业务需求也来源于对利益相关者和其利益的分析,而用户通常就是最重要的利益相关者。

    2018-01-02
    2
  • Dylan
    大家都是有一致目标的:让一个产品活的更好,活得更久,所以产生对立的情况,是由于双方共享信息不够透明及时,信息不对称导致猜疑和矛盾。主动沟通,弥补对方的信息短板,市非常好的沟通法则。学习了,产品把“why”讲明白,是在讲,用户场景需求,工程师把相对通俗易懂的“how”讲懂,双方共同决定“what”的方向。
    2018-06-27
    1
  • 时间之树
    作为产品经理,与开发沟通时,其实也应该把他们当成用户,站在他们的角度分析其真正的需求是什么,关心的是什么,然后以诚恳的态度加强沟通。
    2018-01-10
    1
  • 龙猫
    1、思维不同:产品经理是“为什么这么做”,研发是“怎么做”。交织点是“做什么”。
    要互通有无,产品经理需要讲自己思考“为什么这么做”的过程,适当地告知研发,增进理解;研发也可以把“怎么做”告知产品,增进理解;
    2、产品经理,时刻关注团队内部成员之间的关系变化(开小会、用词用语等);
    3、专程讲述,平时闲聊/吃饭/散步时,主动厚脸皮聊你对产品的思考。刚开始会显得神经病,但慢慢地对方会感受你是真的在沟通,也是真心的在对产品进行思考。而后,在需求分布会时,研发可能会发自内心地配合你了。
    2019-04-20
  • 热爱学习
    我觉得除了自己做好以外,也只能多沟通,多吃饭,多洗脑了,深受研发“简单实现”之苦
    2019-03-11
收起评论
11
返回
顶部