遇到不配合的研发，怎么搞？

遇到不配合的研发，怎么搞？

原创 唐韧 唐韧 昨天

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

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

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

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

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

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

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

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

这种感觉让他非常不好，问怎么搞？

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

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

可以说，到处为难。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

最后，之前有读者反馈说想系统学习一下数据分析相关的知识，这里推荐一个拉勾推出的提升数据基础知识、工具方法、实战能力的学习资料。

比较建议对数据无感的同学以及缺乏基础技术认知的同学学习。

这里面既包括了数据基础知识，也包括了 Python、MySQL、Tableau 等工具使用，同时也囊括了一些数据挖掘、分析、可视化的真实案例讲解。

下面是一份学习大纲，同时也是一份比较全面的知识手册和学习清单，你也可以保存下来查漏补缺。

图片

之前我也推荐过拉勾的一些学习资料，他们在这方面的口碑还不错。

第一，所有实战项目都来自大厂一线，模拟即实战。

第二，他们做招聘起家，背靠企业资源比较多，学完后有直接内推福利，还有就业协议保障。

我找拉勾的朋友要来了详细的内容介绍，扫描下方二维码或点击「阅读原文」即可了解，同时还能获得一些免费的学习资料。

图片

希望能帮到你们。

图片

················· 唐韧出品 ·················

安可时刻

周末时间看了下滴滴、每日优鲜、零氪科技的招股书，对这几个行业的认知加深还是有些帮助的。

让我惊叹的是，2014 年的时候零氪科技的创始人曾经来同为创业公司的我们那取经，我还和他介绍过我们的业务。7 年后，人家要 IPO 了，物是人非。

今天，与 63720 位读者一起见证彼此成长

后台回复“w”，可加我个人微信

推荐阅读

大厂入局，这个需求真的很痛！

员工提前吃饭被开除，这公司真奇葩！

阅读原文

阅读 4120

写下你的留言

精选留言

if

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

只提加班，不提加班对应的福利，是个员工都会有抗拒的心理

秋冬春夏洵属可敬

感觉故事中的场景，是业务不断的提需求，但开发们加班加厌了，这时候确实应该人事或管理层出面，要么给好既定收益，要么完善好相关福利制度并执行

单纯的靠讲道理感觉是不够了，因为即便讲的再清楚，听得人不愿意做，也白瞎

江东之喵

我看是产品揽了太多活，研发干不完。

KY

产品经理学会的第一件事，砍需求

Mr.Burn

两肋插刀

Hank.

三个方面吧

1.需求价值是不是足够大，如果本身价值不大，而只是业务一厢情愿，那产品有必要拒绝这个需求，或者告诉业务正常排期。

2.对应加班的意义要说出来，是福利？是绩效？要让开发同学明白做这个事情对他们来说收益是什么。

3.平时人际关系也要打理好，产品作为团队的领导者，如果关键时刻你的团队不愿意和你站在一起，那确实需要反思一下。

玉🦔

前段时间发现到一个点，就是一定要让研发懂现在的业务目标，并且邀请他参与到原型设计里来。原型就要带着设计开发一起看，听取他们的想法。我感觉开发似乎并不排斥这个事情，并且对我认真听取他建议的态度感觉很好，毕竟我也是想真心为他们减少不必要的工作量😊

故夏酌仙

早上收到条消息，有个功能研发一致意见不做 异地的打不到他们 气死了

不凑活

没有一顿烧烤解决不了的，如果不行那就两顿

🍊胖墩儿橙

我们研发觉得，做完就不能改了……

----------------------------
本文由新墨整理并发布。转载来自互联网，若侵权则删除！
新墨科技-帮助客户在竞争中胜出！APP开发|小程序开发|微信开发|IOT开发|物联网开发|游戏开发|网站开发|商城开发|教育系统开发

新墨官网地址：http://www.sinmore.cn/
新墨APP开发：http://www.sinmore.cn/app
新墨案例：http://www.sinmore.cn/case
新墨小程序开发：http://www.sinmore.cn/xcx
新墨物联网开发：http://www.sinmore.cn/iot
新墨教育系统开发：http://www.sinmore.cn/education
新墨商城系统开发：http://www.sinmore.cn/eBusiness
新墨商城区块链开发：http://www.sinmore.cn/blockChain