遇到不配合的研发,怎么搞?

贝壳号 | 发布于2021-06-22

编辑按:本文转载至微信公众号 “唐韧” ,贝壳投研经授发布

今天周一,一大早收到一个星球同学的提问,他说自己周末刚加了两天半,感觉人都要废了。

原因是最近在推一个紧急需求,已经连续加班两个星期了。其实工作本身还好,就是研发的不配合让他特别恼火。

他们公司是业务驱动型的产品,说白了就是产品夹在业务和技术之间。一方面要承接业务的需求,一方面要对接技术将需求落地。

因为前段时间刚搞定一个大需求,技术团队也连续加班很长时间了,这又来一个紧急需求,搞得整个团队非常抗拒。

在需求评审会上,他在上面讲,底下参会的研发要么玩手机、要么盯着电脑做自己的事,完全把 PRD 评审会当成一个休闲场合。

他问研发是否都理解了,其他人都说没问题,之后把完整的 PRD 文档发给他们就行。

他以为自己都讲清楚了,可过后实际在做的时候又是各种问题,要么就是在原本估计的时间内做不完。

实际情况是,评审会就是走个过场,开发的时候都是照着 PRD 做。很多问题都是在做的过程中发现,他说自己就像个救火队员一样到处灭火。

这种感觉让他非常不好,问怎么搞?

上面这个场景可能很多人都遇到过,研发不配合,自己没权利,干得很心累。

想好好干吧,队友不给力。找领导帮忙吧,又怕领导觉得自己无能,且队友会觉得你在告状。

可以说,到处为难。

在我看来,即便是面对研发,作为产品经理也得搞清楚他们的需求是什么。

首先,不知道为什么而做,这是很多人对工作产生抗拒心理的原因之一

就好比一个需求,在没有任何背景信息的情况下,研发只会把它当做一个任务去做。做好做坏不重要,做完就行。

相反,如果这个任务能和公司的业务关联起来,这个任务能体现在产品的用户价值和商业价值上,那就完全不一样了。

所以,一个需求除了功能逻辑之外,还应该有业务逻辑、价值衡量、数据结果,这是给一个任务赋予意义的做法。

以前我说过一个例子,在电商产品结算模块新增一个自动选券的功能,能带来同品类订单转化率提升 x%,按照交易额折算,就是通过一个功能带来的实实在在的业务结果。

每一个需求、每一个功能,都应该有逻辑支撑、有数据支撑,这样的需求才不会被拒绝

其次,产品经理之所以觉得自己容易被技术忽悠,大部分情况下都是无法对需求进行技术层面的判断。

说白了,在一个信息不对称的情况下,你怎么能获得最客观真实的反馈呢?

说到这肯定会有人问了,那产品经理是不是需要学技术呢?我还是那个观点,产品经理不需要学会如何编程,但你得知道程序实现的原理是什么。

这里也提供一个方法给你们,任何一个技术概念,在现实生活中都能找到对标帮助你理解。

比如,很多人对「数据结构」这个概念不理解,也不知道为啥一个看起来简单的功能变化会导致底层数据结构发生改变。

此时,你只需要把数据结构和房屋结构联系起来就可以建立起这种对标。

假设一栋已经修完的 10 层楼房想对第 3 层进行大改,你觉得是只需要把第 3 层拆了呢,还是需要从第 10 层开始逐层往下拆?

很显然,第 3 层的结构直接影响了上层的所有结构和承重设计,所以要改第 3 层的结构,就得从第 10 层往下拆。这就是为什么一个看似很简单的功能修改可能会涉及很大研发工作量的原因。

对技术的理解可以通过平时工作中的案例积累,比如你要判断某一个功能的研发工作量,就可以用之前做过的类似需求来参考。如果你想判断某个需求是否可行,也可以从已有的案例里去找对比。

总之,如果你掌握的信息和研发越接近,那你被忽悠对抗的概率就越低。说白了,谁也不那么容易和一个同行瞎扯。

如果遇上不配合的研发,要么给足信息,让任务变成有意义的事;要么变得专业,自己能对实施方案进行评估。

有问题不可怕,问题来的时候多想办法解决就行。

飞鲸投研从多维度分析,整理了一份《成长50》的名单,可以关注同名公众号:"飞鲸投研":feijingtouyan,进行领取(点击复制)

该文观点仅代表作者本人,飞鲸投研系信息发布平台

/阅读下一篇/

如何炒短线,巧跟庄?

热门推荐