产品经理与程序员之间的矛盾冲突,并不特殊,它是一个系统性问题。那么,产品经理应该如何与程序员打交道?

产品经理应该如何与程序员打交道?

01

与程序员打交道,是产品经理的日常工作之一。从网上流传的各种产品与技术起冲突的段子可以看出,产品经理与程序员之间的关系,总的来说,并不十分融洽。

我相信,有相当多的同行朋友,都为之苦恼过,我也不例外。

这几年下来,被程序员怼得多了,渐渐地也就变得波澜不惊了。虽然技术对产品有诸多不满,产品也对技术有各种意见,但是,这里我并不想去大书特书双方的矛盾。

在讨论“如何与程序员打交道”之前,我想先对这种矛盾定个调。

我认为,产品经理与程序员之间的矛盾冲突,并不特殊。

如果关注设计师圈子,你会发现,甲方与设计师之间,也有类似的“恩怨情仇”。其实,在任何协作网络中,处于对接工作的上游和下游之间,普遍存在类似的矛盾冲突。

它是一个系统性问题,简单地将之归因为某些人的某些错误,是一种思想上的懒惰。

从某种程度上讲,我们无需过度关注与程序员的矛盾,等闲视之,做好自己的工作即可。

02

产品经理的工作是围绕着“需求”进行的。

在与技术部门进行对接时,产品经理需要关注的,始终是“需求”。

产品新人很容易在这上面犯错。因为外界夸大了产品与技术之间的矛盾,导致产品新人会不自觉地把自己工作的重心,放在“不惹程序员生气”上面。

在与程序员打交道的过程中,为了避免被怼,过度关注程序员的情绪,想方设法地“讨好”程序员,与程序员“交朋友”。而另一方面,却忽视了“需求”,导致需求传达得不清不楚。

这其实是不专业的表现,在与技术部门对接时,我认为,产品经理的核心任务,是“及时准确地传达需求”。

这里面有3个要点:

2.1 核心目的是传达“需求”

目标是什么,要实现什么效果,产品经理需要将这些“需求”传达给技术部门。这里面容易犯的错误是,混淆了“需求”与“技术实现方案”。

比如说:我要做一个“统计订单总数”的功能。

当有新订单产生时,订单总数需要实时累加,还是说允许一定时间的延迟,这是“需求”。

监控出单情况,一旦有出单就触发累加操作,或者设置一个定时任务,隔一段时间执行一次,这是“技术实现方案”。

产品经理当然需要与技术团队协商讨论具体的技术实现方案,但大前提是,要先将需求传达清楚。

所以,我应该这样表述:我需要做一个“统计订单总数”的功能。最理想的情况是,一旦有新订单,这个总数就实时同步累加。考虑到实际业务需要,如果数据只统计到“昨天”,也是可以接受的。

所以,最好是在出单模块中加个监控,一旦出单,数据同步加一。当然,如果修改出单模块的风险比较大,也可以设置一个定时任务,每天凌晨自动统计一次。

具体哪个方案合适,请技术部门内部自行评估。

2.2 需求传达要“准确”

有些同行朋友,可能会错误地认为,只要提需求,程序员就会不高兴。

因此,当他们在传达需求时,对“需求”本身,总是轻描淡写。

“这就是一个小需求。”

“就是哪里哪里简单搞下,加个什么什么东西就行了。”

这是不对的。需求是什么,不要拐弯抹角,应该直接了当、条理清晰地表述出来。

顾左右而言他,反而会让程序员感到混乱。

2.3 需求传达要“及时”

不同团队,有不同的协作流程。

产品经理需要熟悉自己团队的协作流程,在正确的时机,将需求传达给所有需要传达的人。

如果需求传达不及时,导致开发进度出现问题,开发内容有误,就非常被动了。

03

产品经理在与程序员打交道时,要始终清楚,自己的核心任务是“及时准确地传达需求”。

明确这个核心之后,我们才能正确地应对各种情况。

具体要怎么做,这里简单分享几个建议。

3.1 产品经理需要简单地向程序员说明一下需求的背景

网上有些做得很精致的PRD,第一页会写一些项目的商业背景、市场预期之类的东西,搞得跟商业计划书一样。

这里说的“需求背景”,不是指这些东西。老实说,我自己都懒得去看这些“假大空”的套话。

那么,需要说明什么“需求背景”呢?

这个业务的大体情况是什么样的,为什么要做这个业务,哪位领导对哪个模块比较重视,哪位领导对哪个地方有特殊的要求,当前需求的讨论情况如何,根据经验后续需求变动的可能性如何,当前与上下游公司对接中出现了什么问题,等等。

很多时候,“技术”会觉得领导、业务和产品都是在瞎搞,“产品”会觉得领导和业务都是在瞎指挥,“业务”会觉得领导总是想一出是一出。

那到底是谁出了问题呢?

其实,没有人有问题,只是因为各方掌握的情报量不同而已。

在决策链的最顶端,领导掌握了所有的情报,清楚自己每一个决策的前因后果。所以对他来说,他下的每一个命令,都是有理有据的。而在决策链的最末端,程序员基本就只能被动地去执行。

举个不太准确的例子,就像富士康流水线上的工人,不清楚自己手上的零部件最终用在什么地方,起到什么作用。

因为情报缺失,程序员只能自己去“想象”,无法确切知道每个要求背后的原因,所以就容易觉得这些要求都是在“瞎搞”。

因此,产品经理需要有意识地与技术团队共享这些情报。

这样做,一方面能让程序员更加了解项目,确保其工作能满足项目要求。另一方面,也有利于与技术部门建立共识,使程序员能理解配合产品经理的工作。

3.2 需求讨论结束之后,产品经理需要做一个明确的、书面化的总结

我一直强调,在沟通过程中,信息要准确不失真地传达下去,是一件非常困难甚至不常有的事情。

所有人频频点头,看似都达成共识,实际上很可能每个人的理解都不一样。

举个简单的例子:

产品经理:我想要一只黑色的狗。

程序员:给你一只白色的猫可以吗?

产品经理:不行。

程序员:那黄色可以不?

产品经理:那好吧。

最终,程序员交付了一只“黄色的猫”。

在实际工作沟通中,尤其是在工作群里讨论时,经常会发生这种情况。

因此,在讨论的最后,产品经理需要将讨论的结果,完整准确地表述一遍,最好像写PRD一样,用书面化的语言,然后@上所有干系人,一一确认。

3.3 产品经理无需了解技术细节,但需要关心结论

关于“产品经理需不需要懂技术”,我一向的观点是,产品经理懂技术有好处,但是效用比一般认为的要小很多,而且不是必要的。

产品经理可以不懂技术。要记住我们的核心任务,是“及时准确地传达需求”。

在开发过程中,产品经理在为技术团队提供支持和协助时,始终是围绕着“需求”进行的。注意不要越俎代庖,去“教程序员怎么开发”。

那产品经理不懂技术,怎么和技术团队讨论呢?

很简单。当程序员抛出一个你不懂的专业名词时,百度一下,你就知道了。

需要了解到什么程度呢?

我认为,把百度词条里面前100个字看完,知道这个专业名词大致说的是什么,就可以了。也可以当场直接请教对方,这是一个非常自然正常的事情,我觉得完全没有什么问题。向协作方解释自己负责的工作,本身就是每个职场人的工作职责之一。

当然,更多时候,我们外行是很难简单弄懂各种技术原理的。而很多程序员,也不善于向别人表达说明。但这没有关系,产品经理不需要了解全部技术细节。

很多时候,产品经理只需要关心结论就行了。

“具体技术细节我不懂,我想知道的是你专业的判断,是能做,还是不能做?如果不能做,我们就换一个方案。”

“这里报错了。我现在需要知道,具体我要怎么操作,才能得到我想要的结果?”

“我知道现在碰到了问题,那我这边需要怎么配合你们,需要我提供哪些东西?”

3.4 产品经理下班没事就回家,不要浪费公司的空调

说到“程序员”,就不能不提“加班”。

现在有一种奇怪的观点,认为产品经理提需求,导致程序员加班,是产品经理“麻烦了人家”,所以产品经理需要买奶茶买零食“哄着”程序员,需要陪着程序员加班。

加班,是因为自己的任务无法在上班时间按时完成,所以不得不占用下班时间。它本质上是每个职场人自己的事情。

大家都是成年人,都是能为自己的工作负责的专业人士。如果我加班赶PRD,业务的大哥给我买奶茶饮料,坐在我旁边陪着我、哄着我加班,那情景想想都瘆得慌。

我认为,如果产品经理需要协助答疑,或者验收,那就应该和技术团队一起留下来加班。如果没有产品经理什么事情,那工作安排妥当后,产品经理就不需要再留在公司,该干嘛干嘛去。

3.5 当程序员有情绪时,要在适当的时机将问题升级

有时候,冲突总是不可避免的。其实,在任何场景下的任何两个对象之间,都不可能完全避免冲突。

一些“职场经验”会告诉我们,当发生职场冲突时,我们要努力自行解决。因为这个时候领导在看着你,如果你自己无力解决,还需要求助他人,那就说明你能力不足,让领导失望了。

我认为这种观点是有问题的,或者说,它最多只适用于直属上下级之间的冲突。

曾经我被一个程序员狠狠怼过,场面一度十分尴尬,给我留下了不可磨灭的心理阴影。

那是因为什么原因呢?

我个人工作上的失误,是一部分原因,但这只是导火索。没过多久,这个程序员就辞职了。

原来,他对公司积怨已久,已经相当不满,马上就要辞职走人了。他看我不爽,只不过是因为“我”是这个让他不满的“公司”的一部分而已。

一个员工有情绪,是他的直属上级需要处理的问题,而不是团队其他成员的责任。当产品经理发现对接的技术同事有情绪,沟通有障碍,甚至已经爆发冲突,当然首先需要自我反思,并主动寻求解决。但是,认为全部都是自己的责任,随便揽责,其实并不是一直“负责任”的表现。

当产品经理无法单独解决时,需要及时将情况反馈给对方的直属上级,由他来负责协调解决。

反之,如果产品经理把事情压下来,试图自行解决,最终影响到项目和业务,那反而是产品经理的责任。

04

在工作中,产品经理需要和很多人打交道,和领导、和业务、和技术、和测试、和运营,等等。

越是跟多方打交道,我越觉得,产品经理最终并不是在和“人”打交道,而是在和“需求”打交道。无论是与谁对接,产品经理始终是围绕着“需求”进行工作的。产品经理的责任是把“需求”做好。做好自己的工作,足矣。

反之,如果忽视了“需求”,哪怕学会了各种沟通的“套路技巧”,也只会显得“不专业”,难以真正得到团队的信赖。

自我介绍:

大家好,我是Minami,一个普通小厂的4年产品人。

说来惭愧,我没进过大厂,只能混迹在各种不知名的普通小厂。也正因如此,我发现,前辈们分享的一些优秀产品经验,离开了大厂理想的环境之后,其实非常难应用到自己的日常工作之中。

所以,我想分享一些来自普通小厂的经验教训,给刚入行的朋友提供一个不同于大厂的观察视角。

我不是产品大牛,只是作为一个普通产品人,分享一些日常工作的思考。如果能帮到你,非常荣幸。如果哪些说得不对,欢迎你留言赐教。

作者:简明产品论,微信公众号:简明产品论(ID:JianMingPM)

本文由 @简明产品论 原创发布于人人都是产品经理,未经作者许可,禁止转载。

题图来自Unsplash,基于CC0协议。




互联网人如何进行知识管理?

互联网人如何进行知识管理?

信息爆炸时候,我们每天都吸引了大量知识信息,而庞杂混乱的信息难以为我们提高有效的帮助,我们需要做的就是进行知识管理,通过方法窍门高效利用起来,提升自我。 01 ...

2020-06-19
产品总监晋升之道,游戏思维的团队管理艺术

产品总监晋升之道,游戏思维的团队管理艺术

作为一个产品总监,在面临年轻的团队,如果你的管理方式有问题,对团队乃至整个公司都是一件特别大的灾难。所以,今天我们来聊聊产品总监的团队管理问题与游戏化的团队...

2020-06-19
一个公式,从作品集小白修炼到初级交互设计师

一个公式,从作品集小白修炼到初级交互设计师

本文作者从自己个人经历和想法出发,从三个转变的角度谈谈如何从作品集过渡到行业项目,希望对所有刚刚踏入产品或交互行业的新手们有所帮助。 一、前言 在经历了半年多...

2020-06-18
2020年应聘反思,我总结了这些点

2020年应聘反思,我总结了这些点

在职场生涯中,我们可能会在好几家公司工作,重新应聘必然会遇到很多的问题。本文作者基于自身经历,从五个角度总结了自己的应聘经历,分享给对求职迷茫的童鞋。 先简...

2020-06-18
掌握砍价中的六大用户心理,轻松搞定甲方需求

掌握砍价中的六大用户心理,轻松搞定甲方需求

本文总结了砍价哲学中的六大用户心理,并结合案例对每个用户心理展开了分析说明。沟通的最大技巧是真诚,而谈判的目标是共赢。希望掌握好这六大用户心理,能帮助你更好...

2020-06-17
进大厂,还是进小厂?

进大厂,还是进小厂?

选择大厂还是小厂,对于很多人来说,是难以抉择的。大厂和小厂都有各自的优势、缺点,本文作者结合自己的个人视角,谈谈在大、小厂的经历和感悟。 职场也像个围城,在...

2020-06-09
网易严选交互团队的管理方式进化史

网易严选交互团队的管理方式进化史

管理团队是一个艰巨的任务,不仅需要管理者的智慧,也需要具备相关的管理知识。本文作者从具体的工作分工、文档管理分发和人员培养这三个方面出发,分享了网易严选交互...

2020-06-08
如何通过一张表,提高20%的工作效率?

如何通过一张表,提高20%的工作效率?

在日常工作中,每周的工作都充实而有所沉淀吗?是否觉得自己在假忙碌?如何有序推进工作进展,有序记录自己的工作?本文作者结合自身实践,讲述了在方法论上对自己工作...

2020-06-08
2020年,转行数据分析师需要注意哪些问题?

2020年,转行数据分析师需要注意哪些问题?

随着大数据在各个领域的应用越来越广,数据驱动产品和精细化运营已经成为企业经营的制胜法宝,相应地,数据分析师这个岗位也越来越受到关注。2020年,还能转行数据分析...

2020-06-05
京东群面题|如何用0.01元买到一瓶可乐?

京东群面题|如何用0.01元买到一瓶可乐?

这是一道京东的群面题,作者给出了一个简单的回答思路。 任何交易都遵循等价交换原则,如果一瓶可乐价格为0.01元(正常售价约为2.5元),那么必然需要其它形式的价值填...

2020-06-05
“空降型”产品经理快速入场指南

“空降型”产品经理快速入场指南

无论是内部调岗,还是职场跳槽,许多产品经理都必须面对融入的问题。就如一个空降兵,面对历史遗留问题,和现实的剧震,依旧需要义无反顾地发起冲锋。除了需要勇气,更...

2020-06-04
腾讯产品能力框架之通用能力篇:执行力

腾讯产品能力框架之通用能力篇:执行力

执行力就是以目标为导向,以结果为准绳。本文讲解腾讯产品能力框架中的通用能力——执行力,从五个层级分解学习能力,助力职场人走得更远。 本文是产品能力框架的第三篇...

2020-06-04
如何正确构建和使用产品知识库?

如何正确构建和使用产品知识库?

产品知识库的价值不在于文章数量的多少,所以不要刻意追求更新频率和更新数量。能够运用知识库去解决实际工作中遇到的问题,这才是其真正的价值。 1. 什么是产品知识库...

2020-06-04
解决80%以上职场冲突的认知方法——事实最大

解决80%以上职场冲突的认知方法——事实最大

事实最大。你掌握的事实越透彻,也就越强大。 日常人和人的沟通中,80%以上的冲突和挫败,来自与“事实”有关的两个问题: 问题1:没有基于事实来沟通。 假如,你是一位产...

2020-06-04
面试最烦的一种人——刷面经、背题型、找套路

面试最烦的一种人——刷面经、背题型、找套路

正如上次写群面的文章说的,群面的目的是做一名合格的「Horsekeeper」,而不是去想着争风头、当leader、抢reporter这些花里胡哨的。同样单面也不是刷面经、背题型这么简...

2020-06-04
我的14年设计路:从新人到设计总监

我的14年设计路:从新人到设计总监

从初入职场的野蛮生长到独当一面的设计总监,作者在职场摸爬滚打了十四年,分享自己的经历和总结,希望对你有所帮助。 最近,我从蘑菇街辞职了,我在这家公司一共呆了9...

2020-06-03
转岗交互前,我做了哪些准备(下)

转岗交互前,我做了哪些准备(下)

从UI设计到交互设计,作者回顾了自己的转岗之路,对过程中的经验与思考进行了总结,希望能对你有所帮助。 上篇文章我分享了交互设计师的产出物和我是如何学习交互设计...

2020-06-02
从职场菜鸟到独当一面,这三点建议要牢记

从职场菜鸟到独当一面,这三点建议要牢记

刚步入职场的新人最希望的就是能够以较快的速度成长起来,具体应该怎么做呢?本文给出了三点有用的建议。 现在外部大环境不是太好,就业压力巨大,岗位的竞争尤为激烈...

2020-06-02
我花了两年,成功把自己「毁」掉了

我花了两年,成功把自己「毁」掉了

初入职场的年轻人总是特别害怕和迷茫,不知道该怎么在职场中生存。本文作者将用自己两年的职场经验,告诉你什么路该走,什么路不该走。 毕业后的时光过得很快,今天是...

2020-06-01
锅背得冤不冤?产品经理的丛林生存法则

锅背得冤不冤?产品经理的丛林生存法则

甩锅体质:趋利避害是人的本性,甚至是动物的本性。产品经理作为被重点甩锅的对象,可以有108种背锅方式。究竟产品经理的黑锅,背得冤不冤? 一、锅都有哪些? 1. 进度...

2020-06-01