首页 > 其他分享 >产品与研发相处之道

产品与研发相处之道

时间:2023-01-11 08:44:30浏览次数:39  
标签:需求 项目经理 经理 相处 研发 之道 人员 产品

  

  方才一个开发经理和兄弟项目组的产品经理怼起来了。事情大概是,两边对接,那边希望我们出一个接口,而我们这边实际上是两个完全不同的实体概念,开发经理觉得应该提供两个基础接口,合成一个不科学。

  吵得难分难解,我则狗在一边不说话,希望他们最后能自行解决。结果还是被抓到,锅,你说到底要咋整……

  之前则有一对更合不来的项目经理和产品经理,来找我分别聊,“这项目经理是不是管太多了……”,“这产品经理是不是管太多了……”。矛盾日积月累,最后公开化,群里国骂都出来了,公司只好做了调离处理。 

  触景生情,聊聊产品经理与研发……

 

一、产品与研发的前世今生


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

  •   项目经理

  虽然缩写都是PM。但比较资深的从业人看到PM,多数首先想到的应该是项目经理。 在前移动互联网时代,一个一般规模的软件团队第一负责人通常是项目经理。

  彼时承担画原型,传达需求的人员,被称为需求分析师。产品经理这个词还很少被提及。

  项目经理的职责方面,可以通俗理解为项目负责人(区别于狭义的项目经理),负责对接客户,理解需求,领导项目研发,测试,交付整套流程。(我面试过的研发项目经理,居然还有负责要账催款要账的 -_-|| )。

  因为对项目全权负责,责任重大的同时,权利也相应比较大。包含,项目预算的制定,需求的确定,人员考核等。需求分析师通常属于项目经理领导,被项目经理考核,而且交付效果如何,项目经理是第一背锅人,需求编写自然要听项目经理的。

  可以看出早些年对软件项目项目经理的素质要求还是很全面的。

  •   产品经理

  随着互联网(主要是移动互联网的兴起),做“产品类型的项目”的项目比做“定制类型的项目”要前途远大光明的多。于是,做产品类“项目”的机会大大增加,进而产品经理这个概念开始被广泛提及,一本《人人都是产品经理》更是火遍大江南北。

  产品经理的职责,侧重于产品的设计规划。相当于拆分了之前项目经理做需求分析部分工作的职责,产品设计的好坏,需求是否合理,是不是卖的出去,用户是否满意,这些类型的锅,理论上从项目经理转移到了产品经理头上。

  此时画原型,传达需求的人员,也会被叫做产品经理,或者产品助理。

  但是,现实中受规模限制,顶着产品经理的Title,能实际承担产品经理的工作,自主为产品设计,和推广效果负责的产品经理还是很少的。

  一二十人的软件公司大把,本小利薄,倾全力打造的一,两个产品,不可能你说咋做就咋做,往往老板才是那个真正的产品经理。

 

  由此可见,现在的产品经理,多数在之前的项目经理眼中,就是他曾经治下的需求分析员,所以公司如果设有产品经理,那就最好不要用“项目经理”的Title招研发负责人了……

 

二、为何而怼

  大家都知道,美国在中东搞事情,是为了石油!

  而我们作为科技行业从业者,无意义的冲突也应该尽量避免,损人也不利己。但凡冲突,总要为点儿啥,不该只凭个人好恶或非要争个高低。工作中还是应该理性经济一点,少动感情 :-)。

  然鹅,据我观察,很多怼产品的研发人员都不清楚自己怼的目的诉求,怼的毫无说服力;而产品经理也不理解自己为啥被怼,被怼的很懵逼。

  •   需求不合理

  当研发人员说出这句话的时候。通常代表,以研发人员的经验,产品提出的需求,比较稀有另类。这其实可以理解为建设性意见。产品经理应该首先审视自己的需求,是否逻辑合理,是否有更好的解决方案,心态开放,不要过于坚持做自己,一路走到黑。

  如果确认没问题,产品应该向研发人员阐明设计初衷,研发能认可则皆大欢喜,如果实在谈不拢,产品经理的大招就是。“我对产品的定义负责,锅也是我背,所以只要逻辑没有矛盾,技术可以实现,大家按我的方案来做就好。”

  而在研发人员的角度,如前所述,如果公司设置了产品经理职位,产品的定义职责应当就不是研发人员背锅了。本着“谁背锅,谁负责”,责权对应的一般原则。产品对所有需求有最终决定权,未来用户打上门来,也是打产品,不会打你的。

  如果需求没有逻辑上的问题,合理性由产品最终决策,研发人员顶多“友情”的提示下,“按你说的来, 那以后有问题,@你哦”。

  •   实现不了

  如果研发人员怼出“实现不了”时,这可以算是研发人员的大招了。但作为产品经理也不要轻言放弃,产品经理要评估下你所提需求的实际难度以及必要性,然后决定是否坚持需要实现。

  如果决定坚持需要实现,常见的回怼策略是。“那竞品XXX 和 XXX都实现了,这个功能很常见啊,不然我们PK不过他们啊”。 如果最终谈不拢,那就说“要不你向研发领导反馈下,看公司有没有其他大牛有相关经验,或者请示下是不是需要招聘这方面的专门人才”,都是很上的了台面的说辞。

  而从研发人员角度出发,“实现不了”,这个措辞应当谨慎使用。这其实就是直接承认我不行(男人一般不能说不行)o(* ̄︶ ̄*)o。所以在这么怼之前,务必考虑清楚,“实现不了”这件事情如果放在桌面上讨论时,理由是不是充分,是不是合理,会不会显得自己太不行:-)。

  •    实现成本高  

  对于实现成本较高的需求,球其实主要在产品经理这边。相当于研发人员已经给你预警了,实现这项功能预算很高,你要想清楚要不要做,做不做你定。主要是会对产品形成一定的心理压力。

  此时产品无非是,慎重思考,选择坚持或者放弃,切忌说“这个功能我觉得很简单啊,一天搞定。”这类,YOU CAN YOU UP的引战的话。如果坚持要做,那么理由应当充分,以便研发搞出一个天价预算放在桌面上评审时,你能够说服大家功能有必要做。

  研发人员从成本角度提出疑问,应当实事求是,注意理由的充分及合理性。如果是人手一个的功能,到你这里需要一个特别不美丽的价格,研发人员要能经受得住其他人的挑战。

  这里研发人员应该坚守的底线是,复杂的功能自然对应于更长的周期,更高的预算。只要好功能而不给好价钱(资源)的行为,就是压榨,应该严正抗议,据理力怼。同时要避免自我设限,稍微复杂或欠缺经验的功能就打退堂鼓,给产品经理施加压力。

  •      这不属于产品需求

  产品经理应当注意,不要无意义的越界。如果不是必要的需求规格,不要写在产品需求中,可以交给研发去自行实现,这样会更加的其乐融融。

  例如如果你需要一个好吃的苹果,而颜色无所谓的话,就不必要定义我要一个“红色”的苹果,因为也许研发实现成蓝色会更加的方便快捷。否则,研发会觉得你管的太宽。每一个明确定义的需求都应当围绕解决原始需求,有所依据。如果研发的同学问你既然你需要一个好吃的苹果,那为啥一定要红色的,你应该有合理解释,而不是……人家就是想要

  同时研发的同学应该认识到,所有需求都可以写入产品需求,写入产品需求的内容,都是由产品经理背锅。例如客户需要一个网站,产品需求要求,后端用Java,前端用Vue+ElementUI,研发的同学可能认为这不属于产品应该管的事情。

  然而,如果产品经理给出的解释是,客户明确指令要用这样的语言框架实现,因为客户有自己的研发团队,只熟悉这些相关语言技术,后期他们会接手维护,这些要求是写在商务合同里的。那么显然这是一个非常合理的产品需求,并不是多管闲事。即便他没有合理解释,写到产品需求里,你可以质疑,但如果产品经理坚持,只要给钱(认可提供相应的资源,周期),你还是要想办法实现,毕竟他是为成本背锅的人。

  •      随便加需求

  如果因为需求错漏,而变更的需求,作为产品经理,认错态度要诚恳,让研发的同学原谅你,从而避免他们把延期交付,因为你搞错变更了需求的锅非常讲道理的甩给你:-)。

  如果增加需求是客户要求,无法推挡,那么你要向外向上管理,告诉客户或者管理者,新的需求对应新的设计,开发,测试成本。不要让,研发的同事义务劳动(只干活,不提供相应资源)。

  而研发的同学要心胸开阔,人非圣贤,需求的错漏,客户也好,老板也好,产品也好,难免斟酌后发现新的错漏,或者有更紧急的事项插入,对变化要持开放的心态。当然如果,只加事儿,不加预算,那还是要用力怼的。

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

  产品经理要理解,用心做出来的东西没人用,确实很伤研发的心,如果是加班生产的那就更伤心:-)。如果是产品经理自己琢磨出来的,那还是低调做人,有错就认。如果是外部或上级压力,那就后续尽量做好对上/外,管理,与研发同一战线,劝他们三思后行,同时,锅可以适当甩给他们;-)。

  研发的角度看,做的东西,就像自己的娃,希望他有个好归宿的心情可以理解。但冷酷点说,谁都希望一次做好做对,而且浪费和试错的成本,主要还是老板来承担了,上班就是出卖劳动力,只要薪水按约定付了,也没啥好说的,不必太玻璃心。既然雇你来上班就不可能然你闲着,其他的手艺人,哪个不是,你说咋整就咋整,活儿多多益善,给钱就行:-)。

 

三、相处之道

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

  产品经理要有劳动有价的认知,没有所谓简单的功能,必然被怼 YOU CAN  YOU UP。如果你提了复杂高大上的需求,增加或者变更了计划外的需求,那都需要研发的同学,撸起袖子,加油干,才能将你的需求,落地为功能实现。而你就应该与研发的同学站在同一战线,向外或向上管理,为研发的同学尽可能多背书,争取相应的资源(时间,预算)。切忌,用“我提的功能很简单,他们却要一年”来拆研发的台。 

  研发的同学应当在力所能及的范围内,多快好省地建设社会主义。复杂的功能,以及计划外的变更,在配套对应资源的情况下,不应该理解为压榨,应该理解为锻炼机会。永远做简单的增删改查,用最基本的控件,需求复杂点儿就不会做,做不了,如何成长为大牛?

  • 先说断,后不乱

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

  •   就这样被你征服

  二人互动也必然会分出强弱,征服对方,建立信任还是要凭借实力。

  产品经理要摆脱项目经理眼中,“就是个画图的战五渣”的固有成见,要秀出你对行业,对竞品的非凡理解,并一直带领大家走在正确的道路上,用户越来越多,评价越来越好,钱越赚越多。

  而研发人员则可以通过强大高效的研发能力,只有想不到,没有做不到,让产品经理信任你的技术能力,进而信任听取你的,成本预估,方案建议。

  •   合作生,分则死  

  产品经理决定了一个产品所可能达到的最高高度,而研发则决定一个产品所能达到的实际高度。产品经理与研发的冲突会导致,产品过度设计,项目成本虚高等内耗问题。最终导致项目很难多块好省的完成。

  最终项目不赚钱,老板也不可能分钱 ,两败俱伤。

  So,和气生财 ;-)

 

标签:需求,项目经理,经理,相处,研发,之道,人员,产品
From: https://www.cnblogs.com/uncleguo/p/17040419.html

相关文章