产品与研发相处之道

　 
　　方才一个开发经理和兄弟项目组的产品经理怼起来了。事情大概是，两边对接，那边希望我们出一个接口，而我们这边实际上是两个完全不同的实体概念，开发经理觉得应该提供两个基础接口，合成一个不科学。
　　吵得难分难解，我则狗在一边不说话，希望他们最后能自行解决。结果还是被抓到，锅，你说到底要咋整……
　　之前则有一对更合不来的项目经理和产品经理，来找我分别聊，“这项目经理是不是管太多了……”，“这产品经理是不是管太多了……”。矛盾日积月累，最后公开化，群里国骂都出来了，公司只好做了调离处理。　
　　触景生情，聊聊产品经理与研发……
 
一、产品与研发的前世今生


　　这类冲突往往爆发于，研发的leader与产品经理之间。冲突发生的概率与这个研发leader的资历背景严重相关。如果你们公司招聘研发经理时，JD的职位是项目经理，那冲突的概率则更是会大大提高。

• 　　项目经理
  

　　虽然缩写都是PM。但比较资深的从业人看到PM，多数首先想到的应该是项目经理。 在前移动互联网时代，一个一般规模的软件团队第一负责人通常是项目经理。
　　彼时承担画原型，传达需求的人员，被称为需求分析师。产品经理这个词还很少被提及。
　　项目经理的职责方面，可以通俗理解为项目负责人（区别于狭义的项目经理），负责对接客户，理解需求，领导项目研发，测试，交付整套流程。（我面试过的研发项目经理，居然还有负责要账催款要账的 -_-|| ）。
　　因为对项目全权负责，责任重大的同时，权利也相应比较大。包含，项目预算的制定，需求的确定，人员考核等。需求分析师通常属于项目经理领导，被项目经理考核，而且交付效果如何，项目经理是第一背锅人，需求编写自然要听项目经理的。
　　可以看出早些年对软件项目项目经理的素质要求还是很全面的。

• 　　产品经理
  

　　随着互联网（主要是移动互联网的兴起），做“产品类型的项目”的项目比做“定制类型的项目”要前途远大光明的多。于是，做产品类“项目”的机会大大增加，进而产品经理这个概念开始被广泛提及，一本《人人都是产品经理》更是火遍大江南北。
　　产品经理的职责，侧重于产品的设计规划。相当于拆分了之前项目经理做需求分析部分工作的职责，产品设计的好坏，需求是否合理，是不是卖的出去，用户是否满意，这些类型的锅，理论上从项目经理转移到了产品经理头上。
　　此时画原型，传达需求的人员，也会被叫做产品经理，或者产品助理。
　　但是，现实中受规模限制，顶着产品经理的Title，能实际承担产品经理的工作，自主为产品设计，和推广效果负责的产品经理还是很少的。
　　一二十人的软件公司大把，本小利薄，倾全力打造的一，两个产品，不可能你说咋做就咋做，往往老板才是那个真正的产品经理。
 
　　由此可见，现在的产品经理，多数在之前的项目经理眼中，就是他曾经治下的需求分析员，所以公司如果设有产品经理，那就最好不要用“项目经理”的Title招研发负责人了……
 
二、为何而怼

　　大家都知道，美国在中东搞事情，是为了石油！
　　而我们作为科技行业从业者，无意义的冲突也应该尽量避免，损人也不利己。但凡冲突，总要为点儿啥，不该只凭个人好恶或非要争个高低。工作中还是应该理性经济一点，少动感情 :-)。
　　然鹅，据我观察，很多怼产品的研发人员都不清楚自己怼的目的诉求，怼的毫无说服力；而产品经理也不理解自己为啥被怼，被怼的很懵逼。

• 　　需求不合理
  

　　当研发人员说出这句话的时候。通常代表，以研发人员的经验，产品提出的需求，比较稀有另类。这其实可以理解为建设性意见。产品经理应该首先审视自己的需求，是否逻辑合理，是否有更好的解决方案，心态开放，不要过于坚持做自己，一路走到黑。
　　如果确认没问题，产品应该向研发人员阐明设计初衷，研发能认可则皆大欢喜，如果实在谈不拢，产品经理的大招就是。“我对产品的定义负责，锅也是我背，所以只要逻辑没有矛盾，技术可以实现，大家按我的方案来做就好。”
　　而在研发人员的角度，如前所述，如果公司设置了产品经理职位，产品的定义职责应当就不是研发人员背锅了。本着“谁背锅，谁负责”，责权对应的一般原则。产品对所有需求有最终决定权，未来用户打上门来，也是打产品，不会打你的。
　　如果需求没有逻辑上的问题，合理性由产品最终决策，研发人员顶多“友情”的提示下，“按你说的来， 那以后有问题，@你哦”。

• 　　实现不了
  

　　如果研发人员怼出“实现不了”时，这可以算是研发人员的大招了。但作为产品经理也不要轻言放弃，产品经理要评估下你所提需求的实际难度以及必要性，然后决定是否坚持需要实现。
　　如果决定坚持需要实现，常见的回怼策略是。“那竞品XXX 和 XXX都实现了，这个功能很常见啊，不然我们PK不过他们啊”。 如果最终谈不拢，那就说“要不你向研发领导反馈下，看公司有没有其他大牛有相关经验，或者请示下是不是需要招聘这方面的专门人才”，都是很上的了台面的说辞。
　　而从研发人员角度出发，“实现不了”，这个措辞应当谨慎使用。这其实就是直接承认我不行（男人一般不能说不行）o(*￣︶￣*)o。所以在这么怼之前，务必考虑清楚，“实现不了”这件事情如果放在桌面上讨论时，理由是不是充分，是不是合理，会不会显得自己太不行：-）。

• 　  实现成本高　　
  

　　对于实现成本较高的需求，球其实主要在产品经理这边。相当于研发人员已经给你预警了，实现这项功能预算很高，你要想清楚要不要做，做不做你定。主要是会对产品形成一定的心理压力。
　　此时产品无非是，慎重思考，选择坚持或者放弃，切忌说“这个功能我觉得很简单啊，一天搞定。”这类，YOU CAN YOU UP的引战的话。如果坚持要做，那么理由应当充分，以便研发搞出一个天价预算放在桌面上评审时，你能够说服大家功能有必要做。
　　研发人员从成本角度提出疑问，应当实事求是，注意理由的充分及合理性。如果是人手一个的功能，到你这里需要一个特别不美丽的价格，研发人员要能经受得住其他人的挑战。
　　这里研发人员应该坚守的底线是，复杂的功能自然对应于更长的周期，更高的预算。只要好功能而不给好价钱（资源）的行为，就是压榨，应该严正抗议，据理力怼。同时要避免自我设限，稍微复杂或欠缺经验的功能就打退堂鼓，给产品经理施加压力。

•      这不属于产品需求
  

　　产品经理应当注意，不要无意义的越界。如果不是必要的需求规格，不要写在产品需求中，可以交给研发去自行实现，这样会更加的其乐融融。
　　例如如果你需要一个好吃的苹果，而颜色无所谓的话，就不必要定义我要一个“红色”的苹果，因为也许研发实现成蓝色会更加的方便快捷。否则，研发会觉得你管的太宽。每一个明确定义的需求都应当围绕解决原始需求，有所依据。如果研发的同学问你既然你需要一个好吃的苹果，那为啥一定要红色的，你应该有合理解释，而不是……人家就是想要
　　同时研发的同学应该认识到，所有需求都可以写入产品需求，写入产品需求的内容，都是由产品经理背锅。例如客户需要一个网站，产品需求要求，后端用Java，前端用Vue+ElementUI，研发的同学可能认为这不属于产品应该管的事情。
　　然而，如果产品经理给出的解释是，客户明确指令要用这样的语言框架实现，因为客户有自己的研发团队，只熟悉这些相关语言技术，后期他们会接手维护，这些要求是写在商务合同里的。那么显然这是一个非常合理的产品需求，并不是多管闲事。即便他没有合理解释，写到产品需求里，你可以质疑，但如果产品经理坚持，只要给钱（认可提供相应的资源，周期），你还是要想办法实现，毕竟他是为成本背锅的人。

•      随便加需求
  

　　如果因为需求错漏，而变更的需求，作为产品经理，认错态度要诚恳，让研发的同学原谅你，从而避免他们把延期交付，因为你搞错变更了需求的锅非常讲道理的甩给你:-)。
　　如果增加需求是客户要求，无法推挡，那么你要向外向上管理，告诉客户或者管理者，新的需求对应新的设计，开发，测试成本。不要让，研发的同事义务劳动（只干活，不提供相应资源）。
　　而研发的同学要心胸开阔，人非圣贤，需求的错漏，客户也好，老板也好，产品也好，难免斟酌后发现新的错漏，或者有更紧急的事项插入，对变化要持开放的心态。当然如果，只加事儿，不加预算，那还是要用力怼的。

•      之前非要做的，结果都没业务用
  

　　产品经理要理解，用心做出来的东西没人用，确实很伤研发的心，如果是加班生产的那就更伤心:-)。如果是产品经理自己琢磨出来的，那还是低调做人，有错就认。如果是外部或上级压力，那就后续尽量做好对上/外，管理，与研发同一战线，劝他们三思后行，同时，锅可以适当甩给他们;-)。
　　研发的角度看，做的东西，就像自己的娃，希望他有个好归宿的心情可以理解。但冷酷点说，谁都希望一次做好做对，而且浪费和试错的成本，主要还是老板来承担了，上班就是出卖劳动力，只要薪水按约定付了，也没啥好说的，不必太玻璃心。既然雇你来上班就不可能然你闲着，其他的手艺人，哪个不是，你说咋整就咋整，活儿多多益善，给钱就行:-)。
 
三、相处之道

• 只要钱到位，玻璃全干碎
  

　　产品经理要有劳动有价的认知，没有所谓简单的功能，必然被怼 YOU CAN  YOU UP。如果你提了复杂高大上的需求，增加或者变更了计划外的需求，那都需要研发的同学，撸起袖子，加油干，才能将你的需求，落地为功能实现。而你就应该与研发的同学站在同一战线，向外或向上管理，为研发的同学尽可能多背书，争取相应的资源（时间，预算）。切忌，用“我提的功能很简单，他们却要一年”来拆研发的台。 
　　研发的同学应当在力所能及的范围内，多快好省地建设社会主义。复杂的功能，以及计划外的变更，在配套对应资源的情况下，不应该理解为压榨，应该理解为锻炼机会。永远做简单的增删改查，用最基本的控件，需求复杂点儿就不会做，做不了，如何成长为大牛？

• 先说断，后不乱
  

　　组织要注意研发与产品经理间可能出现的矛盾，要注意宣贯研发经理与产品经理的职责定位。除了招聘，入职培训环节，在平时的一些争议解决中，也要讲职责，讲流程。绩效考核中，应当注意责权对应，谁背锅，谁决策。

• 　　就这样被你征服
  

　　二人互动也必然会分出强弱，征服对方，建立信任还是要凭借实力。
　　产品经理要摆脱项目经理眼中，“就是个画图的战五渣”的固有成见，要秀出你对行业，对竞品的非凡理解，并一直带领大家走在正确的道路上，用户越来越多，评价越来越好，钱越赚越多。
　　而研发人员则可以通过强大高效的研发能力，只有想不到，没有做不到，让产品经理信任你的技术能力，进而信任听取你的，成本预估，方案建议。

• 　　合作生，分则死　　
  

　　产品经理决定了一个产品所可能达到的最高高度，而研发则决定一个产品所能达到的实际高度。产品经理与研发的冲突会导致，产品过度设计，项目成本虚高等内耗问题。最终导致项目很难多块好省的完成。
　　最终项目不赚钱，老板也不可能分钱 ，两败俱伤。
　　So，和气生财 ;-)
 

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！