如何做一个不挨揍的产品狗?
身为产品经理,要怎么合理的跟程序员提需求呢?要怎么去处理才能很好的化解产品与技术的矛盾,而避免挨揍呢?
最近一个视频火遍了整个朋友圈,某公司的产品经理和程序员大打出手,据说背后原因竟是产品经理要求用户App的主题颜色能根据手机壳自动调整,可能是程序员觉得这个要求太过分了,于是一言不合打了起来。
产品狗和程序猿打架,谁会赢?真是看热闹的不怕事大!
作为产品经理的我,也觉得这个需求有点过分,但是也不至于就为这打起来啊,你看看其他团队人家开始寻找解决方案了。
尼玛,厉害!你咋不分析手机附近的光谱呢?
很佩服这个老哥给的解决方案,一个字:牛逼,两个字:真牛逼!
你咋不直接人工智能呢?如果你是程序员给出这个方案,在佩服你智商的同时,估计也要挨打了,还是下面的老哥给的方案靠谱啊
龙哥一句话,让整个空气都静止了,对啊,抛开需求的合理性,如果可以这样做那不就简单了。但是你如果碰到很轴的产品经理怎么办?
人家明明说的“根据手机壳的颜色自动调整APP主题颜色”,是自动调整!给你说三遍,是自动调整!怎么办?还能怎么办,揍他!!!(作为产品经理的我,都忍不住要揍他了,还是回去好好反思下你的需求吧!)
我本身程序员出身,做到技术总监,后来由于业务的需要,不得不做产品和运营。有过技术和产品的双重经历,我能深刻的体会到技术和产品的矛盾,也更了解如何去化解这个矛盾。
1、需求分析和描述不到位
程序员在流程的最下游
如上图所示,程序员处在流程的最底端,产品经理跟客户/用户/领导沟通的需求,最后传递到程序员这里,有可能变了味道。如果产品经理把握不好,可能最终结果跟客户想要的完全不一样。等到最终客户/用户/领导勃然大怒的时候,矛盾可能就激发了。
如何解决?
简单,一个杯垫搞定!尼玛,你咋不放把水果刀呢?
产品经理首先要了解业务,才能更好的理解需求。如果需求来自客户,那么一定要明确这个需求不是最终可用的需求,一定要做需求分析,帮客户梳理这个需求,弄清楚客户提这个需求的最终目的是什么?
客户的需求如果是“我要一批更快的马!”,也许他的目的不是要一匹马,而是更快的交通工具。产品经理一定不是客户的传话筒,他一定要将客户需求转变为产品需求或者系统需求。
2、产品需求经常变动
再变别跳楼啊,拿刀去砍他!
由于产品经理经常改动需求,导致程序员不得不把做好的东西重新再做,结果可想而知。有时候程序员加班加点刚做完的东西,产品经理说需求变动了,不能这么做,严重的时候连核心模块都完全大变样。就一直这样改完做,做完改,无限循环下去。
但是产品经理也有怨言,需求变化是正常的啊,老板的想法经常变,客户的需求经常变,我有什么办法?
产品经理必须掌握需求管理
需求变化从某种意义上来说是好事,有变化说明有进展或者有改进,我们不能避免需求变化,但是作为产品经理我们要学会控制需求,对需求进行有效的管理。
首先我们要做需求的合理性讨论,在这个阶段如果能让技术参与,发表意见,让他们感到被尊重,对于后期的需求支持是很有帮助的,切莫自己二话不说拍脑袋!确定需求必须要改变以后,我们要合理的管理这个变化。
产品经理必须得有版本的概念,当前已经开发的版本内尽量不发生变化,把新的变化规划到下一版本;如果实在必须要在当前版本需要变化,那就和技术沟通工作量和计划变更。
要么延长上线时间,要么替换其他需求任务,让需求的变化不影响技术的工作量和计划,技术又怎么能给你打架呢?
当然,由于老板的行政命令和对客户的承诺,你无法更改计划,那怎么办呢?
还是和程序员做朋友,做兄弟吧,如此也许一顿饭就搞定啦。
3、产品狗不懂程序猿
遇到一个像我这样很懂技术的产品经理不容易(有点超自恋O(∩_∩)O),程序员经常听到的一句话就是——“这么简单的功能为什么要这么长时间?”
这样的话令很多程序员恼火,是最能激发与产品经理矛盾的导火索。因为你不懂技术,你就和程序猿没有共同的话题,你就很难站在对方角度上去看这个问题,你也无法掌控程序猿对工作量的评估是否合理,总是以为他在骗你,如果是这样的状态,又怎么能不产生矛盾呢?
从技术转到产品的人,本身对技术了解,可以更好的跟程序员沟通想法,但是一定注意,千万不要反客为主,不要干涉技术。之前就碰到一个曾经做过技术的产品经理,对于技术的方案评头论足,甚至指导技术,搞的技术很郁闷,摔了一句:“既然你这么牛逼,你自己做好了”。
对于不懂技术的产品经理来说,建议要去了解一下基本的技术知识,不需要太深,但是要知道概念,知道大致的使用场景。别整出像“你是用Java还是SQL开发”,“Hodoop比你用Java开发好吧”等这样的概念性的错误,让程序员鄙视,啥都不懂,你还怎么质疑人家评估的工作量啊!
高山流水,知音难觅!知音不成,至少我懂!只有懂对方,才能在一个频道上沟通。
为了做一个不想挨揍的产品狗,一定要不断修炼上面说的一些能力。当然作为一个曾经的程序员,现在虽做产品但依然领导技术团队的我,也有必要给我们的程序员弟弟们点建议:
- 做好需求变化的准备,不要排斥变化。要提高代码的扩展性和维护性,用不变的架构应对变化的需求。
- 对需求理解透彻在开始写代码,要多和产品经理确认!我们经常碰到最后开发出来的跟产品经理想要的不一样,就是因为没有理解需求,或者理解有误,就开始做了。
- 评估工作量和计划时,一定要预留修改bug及其他突发事件的时间,给自己的工作留有余地。
#专栏作家#
菜根乱谭,微信公众号:CGLT_TAN,人人都是产品经理专栏作家。经历程序员、技术总监等技术岗位,现在从事掌上医讯的产品运营和公司发展。关注医疗,早教领域,擅长技术应用型产品的设计和运营。
本文原创发布于人人都是产品经理。未经许可,禁止转载
题图来自 Pixabay,基于 CC0 协议
同为产品,其实我也很想吐槽这个PM的想法。。。这个需求真心觉得没有必要,为什么总是脑袋一热就让人家做一个比较复杂的功能,有那么多闲心不妨反思下必要的功能,看看能不能继续优化
😎 产品经理招聘条件之一:没有挨过打的优先。^_^
乱七八糟写的什么玩意
就这水平
就不要写了
浪费别人时间
特此强调,本文为事件评论主题文章,附带个人感想,只为调侃,不求深度,不喜勿喷!
内容与标题挂钩不是很大
为什么挨揍的一定是产品?
我觉得 打到最后 受伤的应该是程序员。PM身体好不好我不知道,大部分程序猿的身体都不怎么好
纯属扯淡,