程序员和产品撕X,程序员属于什么行为?

开发经常老是和产品各种撕X不问产品背后的设计原因,这种事情,我想每一个产品人员或多或少都经历过吧,那么问题来了,开发这种行为艺术属于什么思维呢?以及该如何制止他们不这么做呢?
阅读全文
请先 登录 后评论
  • 0 关注
  • 0 收藏 60 浏览
  • 略问用户 提出于 2020-09-26 14:09:25

9 个回答

xxxxxa

image.png

先挑刺楼主原文:“以及该如何制止他们不这么做呢?”,这里明显是双重否定成肯定了,因为楼主不会想要程序员继续跟产品撕逼。

“挑刺”是产品经理被打的【标签】之一,程序员幸苦写的代码,提交测试,产品站出来一顿BB,两个最常见的场景:

           场景1:产品说逻辑不对,实现的跟自己“想”的不一样。

           问题原因:产品没有梳理好逻辑、或者、开发之前没有做好充分必要沟通,导致研发返工;

          场景2:需求变更,工期不变,导致研发重复工作,加班。

          问题原因:由于XX原因,在任何一个阶段都有可能“改需求”,所有的改动不一定研发都能理解,关键还不调整工期,要求不能延期等 ,换成谁都不会爽吧。

以上两个原因都会导致研发工作量的增加,研发为了不增加自己的工作量,就会跟产品撕逼呗(PS:有很多优秀的研发人员,会自己主动找产品聊需求,提高工作效率,不存在撕逼),换个思维来看,别人总是给你增加工作量,你也不乐意呗。

总结,侵犯了别人的利益,别人就会不爽,甚至发生冲突,这时候需要冷静思考,从共同的利益点出发,循循善诱吧。

请先 登录 后评论
xxxxxa

一切原因的始末来源于:利益

产品由于对需求方对承诺以及自己对自己产品对承诺,对产品要做成什么样,自己心里有个预期,同理,程序也有自己对预期:这事大概要做多久,要怎么做,是不是还能加上我最近新学的技能等等但

预期叫预期,总是不能完美实现的,过程中总会有风险。

由于产品一开始没想清楚导致需求变更,程序可能需要返工、加班,这时候撕逼程序其实是不在乎你变更后的需求是有多合理,而是你给我造成了负担

同理,程序没有按照PRD开发导致出错,产品肯定不爽,程序觉得那也没啥大不了,说白了大家的目标不一样

所以说产品和程序没啥好撕逼的,最好的是大家确认共同的目标,培养程序的质量交互精神,同时产品也要不断细化自己的PRD,多想想再做,提升自己的专业度,当程序都敬佩你的时候,当你们真的是一个team 在做项目的时候,你们就没啥好撕逼的了

请先 登录 后评论
xxxxxa

产品VS技术撕,emmm…个人经验来讲,很少遇到这种激励的场面。偶尔开发提出疑问,也不算撕,更多是希望得到解答。我RP好?遇到的都是非常不错的小哥哥小姐姐?一般开撕的都是相互刷锅的部门。

回到产品和技术本身来说这件事,产品讲解需求的时候,最好把背景,目的,价值先将给开发听,其次也要实现预想各种开发会问的问题。当技术提出问题的时候能当面解释清楚,当面解释不清楚可以告诉开发,稍后回复。

以上基本能解决80%的问题。还有20%的可能,就要看产品是偶尔被个别开发怼,还是群起而攻之了,如果偶尔个别,有可能是开发本身的性格原因,凡事探个究竟。如果经常性发生这种事,说明产品在开发面前没有任何威信可言,这个是长期的累积结果,需要从自身找找问题了。

请先 登录 后评论
xxxxxa

所有问题的根源要看背后的逻辑是什么?这种情况存在,但也不普遍。存在的原因是 开发如果遇到自认为不合理的产品就很难办,一方面是自身的问题,一方面是PM的问题。

请先 登录 后评论
xxxxxa

他们了解清楚背后的设计逻辑应该是好事吧?这样他们做出的功能会更全面,很多时候我们想不到的坑,他们可能提前就预防了,换句话说,他们的提问可以让我们对需求的思考更全面。并且当出现问题时,他们也经常能给我一些思考方向,能让我们更快的解决问题。

作为后台产品经理,我觉得程序员们对我逻辑思维能力的锻炼与提升帮助非常大。

请先 登录 后评论
xxxxxa

不问背后的原因,那能不能在评审会议时就把为什么这么做,怎么做,做了预计可以得到什么都说明一下?这样他们还有什么理由不做?

总之,听我的,结果我负责,听你的,出事你来背

请先 登录 后评论
xxxxxa

开发和测试如果对需求有异议多数会明确挑战一下,确认清楚了应该不会存在撕X的问题,线下搞好搞好关系,毕竟产品是背锅部门,项目弄不好第一个被喷的也就是产品

请先 登录 后评论
xxxxxa

你应该问问产品,前期迭代评审逻辑是否讲清楚了。

和开发撕或者被开发撕都是及不专业的行为,找到矛盾症结,化解矛盾,粘合团队也是产品的职责。

请先 登录 后评论
xxxxxa

只能说,双方都不专业。

请先 登录 后评论