文章来源：Kevin改变世界的点滴（id：Kevingbsjddd）作者：Kevin
原文链接：产品经理推翻重做，为什么这么难？
产品经理加入到新团队后，几乎都会做一件一样的事情。
“推翻重做”
起因有下面3点
老产品框架无法支撑新需求feature功能
老业务方式被割舍，但新业务又有部分重合老业务流程。
推翻重建并不是从0到1，而是在别人的1或10上从0开始。
有了这个前置条件后，困难就会大很多。
最近PMTalk3.0正在迭代上架，团队也在思考如何在最低成本、最少资源下完成这个版本计划。
借此聊聊推翻重建为什么这么困难？
难点1：技术重构也是产品推翻重做
以PMTalk产品经理社区为例，在最早期我们选择了开源系统搭建社区。
后面进入到自主研发后，因为衔接开源系统，所以起初前端技术选择了JQ的方案实现，后台也因为开发资源限制采用的PHP。
因为在开发速度上，web产品形态在PHP的开发会比JAVA快
一些Java可以做的事情Php做不了或者说要借助另外的工具才可以做，要但就开发网站这个事情来说，Php确实是要比Java效率高，尤其是相对简单的项目。
首先，Java的架构要比Php复杂，先不说各种开发框架，Jsp和Class文件要分开吧，连接数据库要用ORM吧，要比对各种常用开源包的版本吧，http服务器下层要servlet容器吧。而Php架构就非常简单，理论上写好Php文件，往http服务器里一放就可以，读写mysql数据库也几乎不需要任何额外工具。至于MVC，开发严谨的项目Php和Java两者都需要。
由此一切以业务优先、功能线上，就逐渐为产品的后续研发埋下了技术祸根，但这几乎是每个创业团队都会面临的。
技术的推翻重构同样也属于产品推翻重构。尤其在后台的技术方案重构后面向用户体验的感知上几乎没有区别，但技术重构同样耗费从0到1的开发时间。
技术重构即代表了之前的产品设计方案已不能满足现有的业务。比如PMTalk后台1.0只能统计到用户信息，但统计不到业务数据（文章、付费订单），后台重构是一个好的开发方案。
难点2：功能的推翻重构
功能即使相同，但重构后的难点是要保留先前的功能，同时要延展出新的功能feature。
PMTalk的首页改版不下10次，除了技术的结构变化重构，还有增加了体验报告、应用问答的新功能。
▲ 产品首页
互联网产品的首页，是和用户见面频率最高、累计最长的页面。好比在街上路过看到女生，对方的脸庞和身材外形是第一映像。
新功能的加入，就意味着会有新业务、新逻辑。曾经只做瀑布流展示的文章列表，变成了要想办法做多个功能入口的聚合合集页面。
▲ 新版本推翻重做要兼容老版本
在软件开发领域里，都有一个叫做：“向下兼容”的说法。指的是新版本要兼容老版本功能、业务数据，否则就会造成用户体验断层。
产品经理在这里的难点集中在了解老版本下旧业务、旧功能。最快速的方法当然是找到之前负责该功能的老产品同事、或开发人员了解项目情况。
但实际上花时间最多的是熟悉之前的需求文档、项目材料。
有的系统可能不像PMTalk业务非常简单，可能已经有存在2-3年，光系统的研发人员都有上百人。
可想要推翻重构的难度之大......
推翻重效果不一定更好
推翻重做，较多的场景也出现在团队尝试新的方向或商业模式探索。
因为业务都在一个探索的过程，所以产品研发上即使花时间在1个月或几个月后，可能达到的增长效果并不如意。
▲ 产品的不同时期，就可能需要多次重构
所以产品团队在推翻重做的产品需求方案之前建立好有力依据、或较为具体明确的方向。
为什么能这样做就会更好，从可观数据、用户规律、竞品、行业动态等多维度去思考。
离开了上面的5w（how\what\where\when\why)产品经理的人很容易在团队内部迷失方向，尤其是在从0到1。没有明显的商业模式或增值业务时候。
所以在面试求职的时候观察公司的规模、效益，是比较能在这方面少走坑。
站在产品新人上来说，多做从0到1的项目也有助于迅速的打好基础，熟悉各个端、常见的功能模块设计方法和逻辑。
综上，从技术架构、产品兼容、新版本效果待验证3个维度上，你可以看到产品团队或产品经理要想推翻重构，除非项目有迅速增长、或系统功能性问题，是很难的。
有时候，老项目暂停、或废弃。将以前能复用的、能捡漏的功能、技术支持使用，是我们看到最常见的所谓“推翻重构“
心态上要学会习惯这类场景，并不是所以产品都是可以一直迭代下去的。没有团队可以考虑到业务的1个月、3个月、1年的变化。
调整好心态，继续从0出发。才会让产品方案设计的推翻不会那么难！
人生不可以推翻重构，但产品却可以！从无数次的产品重构积累出下次的成功。
HAO-AD
