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