本文讲述了产品经理与程序员在工作中常出现的冲突，主要源于需求的不清晰和频繁变动。产品经理的核心任务是准确及时地传达需求，避免混淆需求与技术实现方案，明确表达需求，及时沟通。同时，不应过度关注程序员情绪，而忽视需求的专业性。建议产品经理做减法，砍掉无价值的需求，提升自身专业能力。
提起产品经理和程序员，想必很多人会首先想到火爆社交媒体的几条旧新闻。
2018年8月，某产品经理要求“根据用户手机壳来改变APP主题颜色”，跟程序员厮打起来……
对于这样谜一般的需求，程序员最终按捺不住还是动了手。
本以为这仅是一个素来“死对头”即程序员和产品经理之间的一个段子，万万没想到事件得到了进一步的证实。
好巧不巧，刷B站首页就给我推送了一条视频：《程序员之怒：我真想跟产品经理打一架！》
顿时两眼发光，想必这又是一段令人津津乐道的恩怨情仇史。
视频作者江湖人称 水哥，是一位程序员脱口秀艺术家。
他说在公司招了个产品经理，二面他也去了，认为那个产品经理不仅专业过硬，还有个很厉害的优势，口才非常棒。
万万没想到：这导致自己吵架吵不过人家......
于是弹幕大军们纷纷表示同情——
与程序员打交道，是产品经理的日常工作，而日常工作就是围绕着“需求”进行的。在与技术部门进行对接时，产品经理需要关注的，始终是“需求”。
程序员吐槽产品经理最多的原因主要是以下几个（以下内容可能会引起程序员们的极度舒适～）
开发过程中频繁修改需求
验收过程中要求做比较大的修改
说不清楚需求的价值
替程序员评估工作量
需求整理的不够细
即便是知道围绕需求展开的，但产品新人很容易在这上面犯错。
因为外界夸大了产品与技术之间的矛盾，导致产品新人会不自觉地把自己工作的重心，放在“不惹程序员生气”上面。
在与程序员打交道的过程中，为了避免被怼，过度关注程序员的情绪，想方设法地“讨好”程序员，与程序员“交朋友”。
而另一方面，却忽视了真正的“需求”，导致需求传达得不清不楚，导致技术各种返工，这其实更多是产品经理能力不专业的表现。
在与技术部门对接时，产品经理的核心任务，更多是“及时且准确地传达需求”，核心就是以下三点：
一、目的是传达“需求”
目标是什么，要实现什么效果，产品经理需要将这些“需求”传达给技术部门。
这里面容易犯的错误是，混淆了“需求”与“技术实现方案”。
比如说，我要做一个“统计订单总数”的功能。
当有新订单产生时，订单总数需要实时累加，还是说允许一定时间的延迟，这是“需求”。
监控出单情况，一旦有出单就触发累加操作，或者设置一个定时任务，隔一段时间执行一次，这是“技术实现方案”。
产品经理当然需要与技术团队协商讨论具体的技术实现方案，但大前提是，要先将需求传达清楚。
二、需求传达要“准确”
有些产品经理会有错误的想法，会觉得只要提需求，程序员就会不高兴。
因此，在传达需求时，对“需求”本身，总是轻描淡写。
“这就是一个小需求。”
“就是哪里哪里简单搞下，加个什么什么东西就行了。”
这显然是不对的。需求是什么，不要拐弯抹角，应该直接了当、条理清晰地表述出来。
顾左右而言他，反而会让程序员感到混乱，不清楚你的需求。
三、需求传达要“及时”
不同团队，有不同的协作流程。
产品经理需要熟悉自己团队的协作流程，在正确的时机，将需求传达给所有需要传达的人。
如果需求传达不及时，导致开发进度出现问题，开发内容有误，就非常被动了。
在产品工作中，需要和很多人打交道，和领导、和业务、和技术、和测试、和运营，等等。
但无论是与谁对接，产品经理始终是围绕着“需求”进行工作的。
反之，如果忽视了“需求”，哪怕学会了各种沟通的“套路技巧”，也只会显得“不专业”，难以真正得到团队的信赖。
当然追溯背后更深层的原因是可能面临这些问题——
很多做产品的小伙伴在工作了一段时间，都会有一种“接活”的感觉，业务方提了个需求，用户反馈了个需求，老板提了个需求，不管自己想不想，可能只能“躺平”接受，在不情不愿中完成了产品方案，更不用说技术人员怎么做了。
可长此以往，被动接受其他方（甲方、客户、老板）的需求，没有独立挖掘需求的能力，好像只是做了一个合格的“传话筒”。
或许我们可以换个思路，给程序员“减负”——做一个会砍没价值的需求做减法的产品经理。
往期推荐
大疆再遭制裁，设计软件Figma断供！中国工业软件如何应对全面封禁？
1446
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
