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

2017-04-21 11:13:00

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

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

小编表示隔着工位都能感受到程序员哥哥的怨念23333

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

果不其然，有产品经理跳出来讲：每个产品经理都梦想着自己去主导一个产品的诞生，当然不希望“喜当爹”。

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

程序员哥哥这下子“愤怒”了：妈的，难道老子就乐意“喜当爹”了？？？

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

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

一、“上一任产品经理做得确实烂，不然怎么成了上一任了？”

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

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

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

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

“找别人的错，总是要容易些”

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

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

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

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

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

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

匿名用户

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

三、“产品经理要为了产品价值提升，不计手段”

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

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

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

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

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

四、“接手新产品，首先得知道这产品的目标是啥，之后再决定改不改”

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

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

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

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

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

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

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

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

@你隔壁老王优酷土豆产品狗

我从来没这个冲动，接手新产品，首先就得知道这产品的目标是啥，之后再决定改不改，怎么改。二话不说直接改，即恶心了别人也恶心了自己。

@飞翔的小鱼儿某大数据公司产品经理

每一个产品人都应该有一种觉悟：懂得站在前人的肩膀上。虽说产品很多时候讲究颠覆，但颠覆也是一点点的积累、调整致更优解，等到市场发展度、用户认可度、产品成熟度三者协调一致才能取得颠覆的效果。

所以对于这个问题，我们先定义重做的概念，我把他分为两种：

界面布局、交互、或者个别页面逻辑重做
产品核心功能定位，包括：用户需求、使用场景等定位不清的重做。

其次，我们可以把两种选择定位到两种改进方向：

改良派——优化
革命派——颠覆。

1）使用场景

两种方向需要不同的场景下使用

a、优化：产品方向没根本问题，用户需求把握较准确，使用场景定位较准确，以上这些产品的核心定位只要不存在偏差就不需要第二种重做；其次业务流程、界面、交互等存在不明确的情况，需要重做

b、颠覆：经分析、沟通，产品定位不明、用户需求偏移，必须要求第二种的重做，重新规划顶层设计；另一种是界面、业务流程等交互效果不好，可以考虑改版，但首先考虑是否可以只需要调整局部就能修复。

2）产品经理心里诉求

导致产品经理重做产品有几个方面

a、产品更优化。前产品经理确实没能完成很好的完成产品设计，这个时候包括以上的两种情况：产品定位和产品交互。

b、理念不合，且成本不高，这个时候经常发生在产品设计中途换人的情况，产品只走到市场调研或者策划阶段，改动成本小，可以承受。

综上来说，对我来说产品拿到手并不会存在强迫症的重做。而是拿到手先实际分析产品状态，并结合公司整体规划和个人理念，确定定位的准确性；其次在交互层面都是可以调整优化，如果整体界面、交互效果很差，再考虑重做。

五、“每个产品经理都梦想着自己去主导一个产品的诞生，当然不希望喜当爹”

@蛋总温商贷高级产品经理

做产品也有2年多了，有自己0-1主推的项目也有接手前任留下的半成品的经历。因为我是从事后端产品的，我且从后端产品去讨论楼主的这个问题。

首先，接手别人的半成品后第一个想法是推翻，而不是在基础上去迭代的产品经理是有，但是绝对不会是主流，因为考虑到重建成本，一般的产品经理都不会这么干。

第二，即时有这个想法，那么一定是前任留下的太坑，而接盘的人感觉填坑的难度不亚于重建的难度。说个例子，做后台产品的，很害怕接手半成品的后台，因为对于后台来说，本身逻辑性就会相对复杂，涉及到的流程和数据交互也会比较多，而且对于后台的设计思路太多太多，有的人会根据工作流去设计，有的人会根据实际功能模块去进行设计，你还需要花很多时间去摸清楚，前任产品经理是怎么想的。然后这个后台的逻辑是否有漏洞，是否你之后的改动会对前面的设计产生很大的影响，这个都是很费时间的。所以有的产品，可能一接手第一想法就是直接推翻。

第三，就是产品经理都有自己创造的欲望，这个和产品经理的岗位的特殊性有关，每个产品经理都梦想着自己去主导一个产品的诞生，当然不希望“喜当爹”。

最后，我最近也接手了一个十分之重型的后台系统，功能很全，设计的工作流繁多，但是由于是技术自己搭建的，没有从易用性，操作流程顺畅的角度去考虑，整个后台让人看起来就是一个大杂烩，什么都给你了，就是需要你自己去找。说实话，我刚接到也是要骂娘的，但是产品人的一大high点不就是去变腐朽为神奇么？享受这个过程。

匿名用户

不做点事情，如何证明自己的价值？说个搞笑的，我原公司某任CTO来了公司一个月，产品各种崩溃闪退都找不出来原因，就跟老板说咱UI太丑了，重新设计吧，然后高薪站设计师换了一套UI，以示自己还是能做点事情的。

六、“旧产品无论有多少傻X的地方都有存在的理由”

@鬼谷知乎商业产品经理

首先一刀切就是个不懂的问题，什么叫产品经理喜欢推翻重建；问题怎么能这么提？如果问题是：题主为什么喜欢同性？这不就直接给你先把帽子给扣上了？先问是不是再说为什么！

首先重构的肯定是原来的架构不支持现在的业务才需要重构，而不是为了重构而重构，为了重构而重构老板工程师非搞死你；而且重构的工作量比修修补补的工作量要大很多；而且做出来不一定比现在的好；所以重构的前提一定是现在的架构无法支撑业务才需要，我们自己有时候也会重构部分业务和代码；而优化叠加才是常态，谁没事干一天重头设计整个系统架构。

@机灵的稻草人河良医帮产品经理

记住一句话：存在即合理，旧产品无论有多少你认为傻X的地方都是有他存在的理由，上来就想全部推翻的，只有一种可能：没仔细的去思考之前产品的价值。推翻重建一套新的，填坑就够你填一年半载的。喜欢这样做的产品，一定不是一个好产品。