产物与研发相处之道

　
              

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

           　　这类辩论往往发作于，研发的leader与产物司理之间。辩论发生的概率与这个研发leader的资历配景严重相关。如果你们公司招聘研发司理时，JD的职位是项目司理，那辩论的概率则更是会大大进步。
  

• 　　项目司理
  

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

• 　　产物司理
  

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

           
              

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

• 　　需求不合理
  

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

• 　　实现不了
  

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

• 　 实现成本高　　
  

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

• 这不属于产物需求
  

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

• 任意加需求
  

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

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

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

           

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

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

• 先说断，后不乱
  

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

• 　　就这样被你征服
  

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

• 　　相助生，分则死　　
  

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

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。