如何做好产研团队配合

一、概述

产品经理在开需求评审的时候，如果PRD考虑不全面，经常会被研发人员挑战，如果确实考虑欠周全，就需要改动PRD，这个的代价是很大的。一般来说，PRD定了就是定了，只能接受非常小的改动。需求评审被及时发现了，调整还算来得及，如果是到开发阶段或者测试阶段了才被发现，那就是资源的极度浪费，会降低整个团队的产出。

而正式做需求评审的时候，研发和测试人员就再次核对一下，这个需求评审会中的PRD跟之前讨论的东西是否一致就行了。

其实产品和研发要配合好，不只是在需求评审这块，还有很多的地方需要做好配合的，下面简单阐述一下。

二、研发人员接需求入口要统一

一般来说，公司的组织架构是有职能划分的，例如中后台的产品负责中后台的需求规划和管理，对应的中后台研发人员大部分情况下只负责实现【中后台这条线】的需求。研发人员接需求的入口，要保证只有一个：

那就是对应的业务线的产品经理。比如说，中后台研发人员只从中后台的产品经理接需求。
下面的这种情况一定要杜绝：

其他业务线的产品经理（例如会员线）或者运营人员或者开发人员越过中后台的产品经理直接找到对应的中后台开发谈【业务】需求。
本业务线内的研发人员到底在正在做什么或者将来会做什么，对应的业务线的产品经理一定要了如指掌，方便统一统筹，有利于保持节奏和保证研发人人员足够专注，进而达到高效产出。试想一下，如果研发人员随意答应了做某个需求，而产品经理不知道，势必会影响到本业务线内的需求开发，进而影响到整条业务线的产出。

因此本业务线内的产品和研发在【接需求】这块一定要【配合】好，对外就是一个整体，整体的去作业，这样才能有高效的产出。

三、【为什么/做什么】、【做什么/怎么做】

产品经理在做需求收集和整理后，会产生一份PRD，因此产品经理肯定是跟业务方对接完了，清楚的知道【为什么】要做这个东西，而随之产生PRD则是表示要【做什么】，需求评审的的过程，其实就是将【做什么】传达给开发人员，这个是两个角色之间的【交集】，但是这样做是不够的，做的更好的方式是：

产品经理将【为什么】清楚的告知给开发人员，而开发人员清楚的将【怎么做】告知产品经理，大家相互体谅，以求理解一致。
产品经理需要告知这个需求的【来龙去脉】是什么，是解决什么痛点，你当前有什么数据可以说明，或者说这个需求是为了哪个指标？用户增长、提高效率、GMV，还是用户体验等，要达到什么样的目标，如何用数据证明目标是否达成了。另外一定要将需求的【源头信息】准确的说出来，而不是说，产品经理出的需求其实跟需求源头要做的东西，其实不一致。

产品经理一定要非常清楚，一旦需求启动，那可是【一大波人】在干活，会有很多资源投入进去，如果连为什么以及做完后如何证明有效果都不清楚的话，是很难做到高效执行的，同时也没什么成就感。

而开发人员，接到需求后，也需要把技术成本告知给产品经理，例如说：

1、关键路径里好多还是PHP的，得做重构； 2、有很多历史数据需要迁移； 3、原本的系统架构不太好做这个事情； 4、上线风险高，得开发灰度程度； 5、原本的接口，性能不行，也得做优化； 6、这块得做全量回归测试；
把这些实际情况告知产品经理，共同商量一下方案。

四、产品往后延伸，研发往前延伸

【研发往前延伸】，意思就是说，研发需要参与到【需求收集】这个比较【靠前】的阶段里，无须等到需求很正式了，才去了解。像很多公司会开【业务方、产品经理、研发每月沟通】的会议，其实也是这个目的。尽量靠前的话，研发能提前有所准备和规划，同时也能真正的理解产品经理和业务方的压力，另外呢，研发也不会有【需求从天而降】的感觉，好像被突然袭击了一样。

【产品往后延伸】，意思是说，不要PRD一出完了，就不管了，产品经理一定要有一个意识：

PRD是你出的，这个产品整个过程到底顺不顺，跑的稳不稳定，是你一定要去关心的，【你就是不想这个产品出问题】，必须得有这个心态。
像产品上线后出了BUG了，有大故障了，产品经理一定要参与进去，尽量想办法一同解决，而不是只是问：什么时候修复好之类的，是哪个开发导致的呀。

这两个延伸都做好了，也会逐渐增加产品和研发这两个角色之间的信任，从而达到更加高效运转。

五、文化：只有我们，没有他们

本业务线内的，不管发生的事情是好事还是坏事，就是【我们】，我们做对了，我们做错了。做对了，有产出有业绩了，就是整条线做得好。做错了，就是整条线做的不好，那么就一起背锅，关起门来一起检讨。

六、小结

产品和研发本质上就是需要【配合】好的，因为这两个角色对公司来说，实在太关键了，一旦有出现不和谐的地方，影响面都是很大的。