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

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）

本文作者 @简明产品论 。

版权声明

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！