0°

从打架事件看,产品汪与程序猿的矛盾和获得的启示

产品经理王梓任+++从打架事件看,产品汪与程序猿的矛盾和获得的启示+++2018-08-07+++http://www.woshipm.com/pmd/1214230.html

写这篇文章不是为了凑热闹,更不是为产品经理辩驳,最主要目的是分析问题、分享见解和受到的启发。

目录导航:

一、我对此事件的看法

1. 对事件真实性甄别的必要性

2. 对事件本身和两位主角的看法

二、我对程序员和产品经理之间行业矛盾的见解

三、我们从这个事件中能得到的启示

1. 职场处事方面

2. “需求-开发”流程和规范性方面

最开始看到这个事件,是在8月3号。讲真,当时的兴趣点是凑热闹,对于主角是程序员和产品经理并未留心。

3号当天,微博上、新闻上、各种微信群里都出来了,群消息、朋友发给我的消息内容多是对程序员和产品经理关系的调侃(其实更多的是对产品经理),才感觉不是我在凑热闹,而是我被凑热闹了。

4号在知乎上被邀请回答问题(对此事做评论)时,发现这个事件已经有250多万次浏览量了,而且点赞量最高的评论多是暗讽风格或直接对行业问题诟病的,我觉得,有必要发表几点拙见。

即使事情是假的,也从侧面反映出一个问题:程序员和产品经理间的茅盾是客观存在的行业问题。

为什么呢?

如果行业中不存在这种矛盾,假新闻很难被人相信并传播。

写这篇文章不是为了凑热闹,更不是为产品经理辩驳,最主要目的是分析问题、分享见解和受到的启发。

二、我对此事件的看法

对于这个事件,我的思路如图:

在此表达自己的主观意见:

  1. 事件的真实性甄别的必要性;
  2. 站在中立的角度表达对打架事件的看法。

1. 事件的真实性甄别的必要性

如果此事件内容全部是真实的,即:是平安的打架事件&主角是产品经理和程序员&手机壳颜色识别的需求引起的打架,那么有必要去评论、去思考。因为从这个反面教材中我们能够得到对程序员、对产品经理的岗位认知,更能够对今后的职场处事原则有很大的正面启发。

但是,如果事件内容是假的,那么经过微信群、朋友圈、微博等各种文章的渲染后,我们很容易由于这个事件对程序员、对产品经理日常工作产生错误认知,进而是不合理的评论、误解或嘲讽。

热闹是凑了,但对两位主角是伤害,同时也会给外行人留下“程序员容易动怒,产品经理总是提混蛋或无知的需求”的印象,实际中不是这样的我可以说,程序员绝大部分很好沟通、不会轻易怼人,同时产品经理也不是这么强势和混蛋的。

结论:假消息造成的不仅是对当事人的负面影响,同时也会让外行人对这个行业、这两个岗位的人及他们之间的关系形成错误认识,进而是误导更多的人产生认知偏差。

因此,如果热闹看够了,对新闻/消息产生质疑是有必要的。

2. 站在中立的角度表达对打架事件的看法

假设、假设、假设,事件内容全部真实,完全就事论事,我的看法有这么几点:

(1) 对这个事件本身

这个事件暴露出程序员和产品经理之间的沟通问题值得深思和反省,在下面第三大点我专门给出了自己的见解。

(2)对两位主角的看法:动手打架,两人都不对

不良后果有:

  1. 自己被开除,在网上出名后,后面找工作多少会有障碍 —— 对自己和家庭;
  2. 自己所在的外包公司也会受到牵连,可能会被甲方责难或罚款,这又牵扯到钱的问题了 —— 对自己所在公司;
  3. 对甲方的声誉有负面影响,若不良影响再继续扩大,接着就可能影响到股票和业务了。打架本身并不会极其严重,但打架发生的环境会引发严重的后果。

(3)我对这位产品经理的看法

① 流程不规范

正常的流程,如我上面的图示中“是”的步骤那样才合理,哪有产品经理直接找具体实现的程序员直接要求实现某功能的!假设产品经理已经完成了该有的可行性评估、调研等环节,提需求的时候,也应当有正式的通知(例如:文档或邮件),任务由程序员的领导确认或知悉,而不是两个人直接互相沟通和确认需求。

有些产品经理认为前期搞那么多评估是浪费成本,我认为这是胡说,至少技术可行性确认该有吧?评估不做,一旦进入开发,耗费了大量人力、财力后发现不对劲再推倒重来的传统方式更应该摒弃。

也有产品经理认为可以直接先开发,快速上线后根据反馈再迅速改,也就是“小步快跑、快速迭代”,纠正一下,小步快跑、快速迭代本身没错。但再小的步,可行性评估要做、书面需求要有、开发人员的领导要知悉。

② 沟通方式有待改进

即使是程序员直接沟通发生了不快,下一步应当找各自或对方的领导,当着有决定权的领导讲清楚,共同决定做与不做、如何做。

(4)我对这位程序员的看法

当发生沟通障碍时,建议第一时间把事情向上抛,找领导协调,技术领导一般都会站在程序员立场去调解难题的。

try{//沟通} catch{//不愉快} finally{//找领导反馈};或者throw new Exception(“这我搞不了!”)都行啊!(PS:开个玩笑)。

(5)或许还有我们不知道的

最后,我们只从新闻上看到了事件的开头和结果,开头是“平安的产品经理和程序员因为手机壳颜色识别的需求引起了打架”,结果是一段视频和处罚通报:

至于中间两人还经历了什么,我们不知道。会不会,这个需求本身不能实现只是导火索,而引起动手的却是其他原因呢?

因此,即使打架发生了,也不应把事件的起因认定为“无理取闹的提需求”,因为我们并没有了解到事件的全部,甚至连确认过事件的真实性都没有。

三、我对程序员和产品经理之间行业矛盾的见解

这个矛盾客观存在,不仅是程序员与产品经理,早在产品经理岗位火之前,行业中时常被调侃的对象是程序员和测试工程师,还有前端程序员和后端程序员。

难道现在程序员和测试工程师之间矛盾好转了吗?

并没有,依然是吵闹不断,只是产品经理盖过了测试工程师的风头。

为什么能盖过呢?

  • 原因一是行业中始终存在操作不规范、业务不熟、沟通能力不足的产品经理,毕竟新人始终存在,这是客观因素;
  • 原因二是产品经理的岗位性质就是动手少(动脑多)、提需求多的;
  • 原因三(主要原因)是提出的大部分需求都很容易引起争辩甚至激怒程序员的。

虽然岗位性质就注定两个岗位不和,那有解决办法吗?当然有。

① 若是产品主导/运营主导/市场主导型公司,这个问题解决起来更容易,毕竟开发人员的发言权是不足的,但弊端同样有 —— 即产品/运营/市场总会提出不专业或天马行空的想法给开发人员,不仅不切合实际,开发完后推倒重来、浪费人力财力的情况自然增多。

那矛盾怎么解决呢?

由于做与不做的决定权几乎都在产品/运营/市场手里,所以他们的专业能力非常高才可以,上游做正确的事,引导下游正确地做事,有了良好的成效和用户反馈,矛盾自然化解。

为什么有些公司对产品经理、运营人员要求那么高,知道原因了吧?

② 若是技术型主导的公司,或者是技术和产品/运营/市场不分高下的公司,这两类公司实在太多太多了。那这个矛盾处理的关键就靠两个字:“情商”。

这里不仅要求产品人员的能力高,更要求懂很多职场处事技巧、懂一点点开发技术原理。职场处事原则例如经常与开发、测试的同事聊天,偶尔买点下午茶一起吃,遇到直接冲突想办法化解情绪层面的问题,耐心听完再接着就事论事,解决不了不要直接争论,马上转向找领导、向上抛。

如果能力不高例如专业技能不足,一旦做了错误的产品决定、浪费了开发资源,接着就是被程序员抱怨;若能力够足但不会“处关系”,一样是工作难以推进。

总结:矛盾解决办法最主要是产品人员要有足够的职场处事、沟通协调能力,二是产品人员专业能力强,能够引导正确的产品走向,三是开发人员应适当理解产品经理的处境。

自己身边的真人真事:一个朋友,产品人员,很少玩游戏,不懂开发技术,金融专业知识还是进公司后才现学的,在产品经理基本技能还不错的情况下,凭借另一点顺利开展的工作——他在手机上下载了王者荣耀自己试着玩多个人物,之后午休时与开发的同事们一起玩,聊工作前掺杂聊聊游戏,还不错吧。他说,玩这个游戏的主要目的是跟同事们有话聊,其次是娱乐。

四、我们从这个事件中能得到的启示

1. 职场处事方面

  • ① 最高的水平是关系处理的融洽,压根没有不愉快发生,产品经理首先应多学职场处事技巧,其次才是专业技能。
  • ② 若由于个人不会处理关系、不擅长沟通,办法是有争执时控制自己的情绪,不要轻易动怒,再大的怒火,先想想后果。

沟通 = 70%情绪 + 30%的内容,发生不理智的争辩时,不良情绪就占据绝大部分了。

这里的关键点:沟通不畅时,立即停止两人私下交流甚至是争辩,因为对解决问题毫无意义,结果往往是越交流越糟糕,应该直接抛出问题、向上找领导调解,把对方的领导和其他相关人员拉到一起,一同决定。

2. “需求-开发”流程和规范性方面

根据我上面的第一张图,如果流程走的规范,会引起激烈争辩的事情基本不会发生在程序员和产品经理之间。

那还有其他方面的需求用不着这么规范的流程,或者必须程序员和产品经理直接沟通的问题怎么办?

若是产品经理,应自己先做足可行性评估,这不是为程序员做的,而是为产品和需求本身做的。这些工作到位后,找程序员先讲明目的、再讲此需求的积极意义和评估结果,走到这里应该可以说服大部分程序员了。如果仍然沟通不畅,就找他的领导协调,依然推不动,就找自己的领导,一起去找程序员的领导沟通。

若是程序员,遇到产品经理直接提的需求,可以表示质疑,要求对方讲清楚需求的目的、意义和评估结果。若他讲不清楚,可以拒绝并反馈给自己的老大有这个事,让老大决定。若产品经理说的让自己折服,那也要反馈给老大,让老大来安排开发排期。

最后:实际工作中产品经理总会提出让人啼笑皆非甚至无理取闹的需求,这个不争的事实是我们产品人员需要不断改进的地方,共勉。

 

本文由 @产品经理王梓任 原创发布于人人都是产品经理。未经许可,禁止转载

题图来自 Pexels,基于 CC0 协议

本站声明:网站内容来源于网络,如有侵权,请联系我们,我们将及时处理

「点点赞赏,手留余香」

    还没有人赞赏,快来当第一个赞赏的人吧!
0 条回复 A 作者 M 管理员
    所有的伟大,都源于一个勇敢的开始!
欢迎您,新朋友,感谢参与互动!欢迎您 {{author}},您在本站有{{commentsCount}}条评论