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

1 评论 2135 浏览 14 收藏 17 分钟

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

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协议。

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 懂技术是最好的交流方式,其它的就是个人偏见

    回复