认识达内从这里开始

认真做教育专心促就业

程序员为什么都容易“喜当爹”（上）

发布：互联网
来源：互联网
时间：2017-04-19 15:10

    前段时间我司程序员在PMCAFF社区里提出了这样一个问题:

    当产品经理接手旧的产品的时候,分析过一遍产品后,第一冲动似乎都是推翻重建,为什么这种状况会频繁的出现呢?

    小编表示隔着工位都能感受到程序员哥哥的怨念23333青岛IT培训班

    转念一想,一个程序员在产品经理社区里提出这样的问题,不是搞事情吗?不怕被打吗?

    果不其然,有产品经理跳出来讲:每个产品经理都梦想着自己去主导一个产品的诞生,当然不希望"喜当爹".

    这位产品经理real耿直,他的完整版回答见后文

    程序员哥哥这下子"愤怒"了:妈的,难道老子就乐意"喜当爹"了???

    一场大战争就此爆发,目前,已经引来了近百位产品参战……

    我们选取了几位从业人员的答案,针对「做产品的时候接手旧产品,产品经理为什么喜欢推翻重建?」的问题,你是改良派还是革命派呢,欢迎留言讨论.

    "上一任产品经理做得确实烂,不然怎么成了上一任了?"

    车马银信天下网产品总监兼CEO

    1、上一任产品经理做得确实烂,不然怎么成了上一任了?这么烂的东西,不如推倒重建.

    2、上一任产品经理做得还行,但毕竟是另一个人做的,和新任的思路、风格都不同,现在既然新任接手了,就得按新任的思路、风格重来!反正,上一任已经走了,连辩论的机会都没有.这和房子卖了,不管原来的装修如何,新房主基本都会拆了重新装是一样道理.装出来很可能还不如以前,但是"现在我是房主,我就喜欢!"……

    3、喜欢重建产品的是产品经理?根据我的经验,设计、技术都爱这么干!每次换了设计、技术的头,几乎都会说"原来的设计理念落后!"、"原来的技术架构就有问题……".然后,重建了几个月,又产生了新的问题……

    "找别人的错,总是要容易些"

    vc嚼片杭州某医药互联网公司产品负责人

    找别人的错,总是要容易些;理解别人的套路,总是费点神.每个产品经理都认为自己是一个更聪明的孩子.

    克劳斯百年爱贝产品副总裁

    题主问题:产品经理为什么喜欢推翻重建产品?

    1、不是只有产品经理喜欢推翻重建,架构师也喜欢推翻重建(看了几眼之前的架构,懒得继续研究下去),程序员也喜欢推翻重写代码(瞄了几眼之前人写的代码,逻辑复杂,注释不明,看不下去).

    2、所以90%以上的原因是人的思维特性决定:自己设定(或者说构思的)永远比学习理解他人的结果来的简单.还有10%确实是之前的不好.

    匿名用户

    我日,还真被我碰见了,新来的财务结算产品,不到一周就说,这模块要完全重构,自己负责的那块就算了,连不是她自己负责的订单模块也动了这个心思!给的一句话就是,踩别人的坑不如踩自己的坑,如何破?

    "产品经理要为了产品价值提升,不计手段"

    残品经理Hardy 今日头条高级产品经理

    推翻重建,还用得着你么?

    我反对一上来就推翻重建,老的版本不管你觉得多不合理,都有他存在的理由.新来的产品经理要对每一个老产品抱有敬畏之心.就像中医理论它再荒谬,中药里还是有研究和检验的价值,我们可以废医验药.

    基于现有版本进行小幅优化,不断的观测数据,是最有可能找到症结所在的.重新搭建反而重置了所有的变量,打破了平衡,你无从知道做的更对了还是更错了.当你了解了大部分的问题原因之后,把所有的改善方案摆在领导面前,那就无所谓推翻还是继续改良,那只是手段,并不重要.重要的是让产品更好.

    另外,能化腐朽为神奇,也算是产品经理的本事之一,如果你永远觉得重建才能够实现乌托邦,那么你只能永远在重建之中循环.

    但我觉得产品经理一定要敢于突破现状,不要被现状框住,不怕推翻和革命,敢于面对质疑和挑战.一切为了产品价值提升,不计手段,不畏强权,这是我所提倡的.

    "接手新产品,首先得知道这产品的目标是啥,之后再决定改不改"

    cation YY Live产品经理,前网易云音乐PM

    不能这样说.每个产品人的思维、眼界、嗅觉、执行力都是不一样的,而同样,产品的市场体量、承载的公司战略也不是一成不变的.

    刚入行的产品人承受、适应能力比较初级,对不熟悉业务所遇见的不可控因素诸如成本紧缺、档期较紧这种问题处理能力较弱,情急下最常见的办法就是题主所说的推翻重建.把问题调整到可视可控范围内,但往往这样做会引起其他员工的不满和部门资源的不协调,上下层执行不一,观点没有统一战线.最后铁定会拖垮项目进度.

    稍微成熟一点的产品人首先在自我要求上会是产品输出导向,而非进度导向的.换言之,会花比较长时间去了解、再认识产品,调查业务瓶颈,查看用户反馈,摸清企业战略和产品的生命周期到了哪一阶段,再针对产品出现的问题,分清哪些是产品本身问题,哪些是技术问题,哪些是业务问题.

    对于一款产品来说,业务问题是最先需要解决的,因为产品核心在于商业价值,通过业务体现出来.如果业务逻辑跟不上用户行为,衍生功能解决不了用户需求,平台体验和技术实现再好也无济于事,这部分出现问题确实是需要大刀阔斧甚至重建的.

    其次产品本身问题介乎到用户需求的满足程度,如果是产品本身出现问题,有强需求未能满足,有潜需求没有挖掘,有弱需求拖沓资源,有伪需求占用成本,这些则要考虑需求实现的优先级,同时结合考虑公司战略层阶段等角度去考虑,这部分花时间去重建则是下下之策.

    最后便是技术问题,重建的可能性是最小的,但如果涉及到数据源、架构等基层系统问题需要重建的,成本是三者最大的.同样,也要考虑诸多因素.

总结,产品人刚接手一款产品,调整是必然的,重建则需要搞清楚是自身的问题还是产品的问题.反之,都是不负责任的.

更多青岛IT培训班相关资讯,请扫描下方二维码