每个产品人的思维、眼界、嗅觉、执行力都是不一样的，而同样，产品的市场体量、承载的公司战略也不是一成不变的。当架构不能满足业务发展需求时，重构就变得不可避免。但是重构往往又影响巨大，很多时候甚至几个月无法开发新的功能。
怎样才能高效的重构又不影响业务呢？
上文我们已经系统的阐述了 产品重构的原因和必然 ，现在要解决的问题是，既然重构无可避免，如何才能确保重构后的产品符合预期，更重要的是不会引发新的问题。
事实是，重构往往并不成功，有幸经历过几次各种规模的重构，成功凤毛麟角，失败才是常规，甚至不得不再次启用旧的业务系统。
那么，怎样才能高效的重构又不影响业务呢？哪些问题可以放心大胆的修改，哪些则需要小心改良，怎样才能避免造成更大的不良反应呢？
01、评估产品重构的时机
有的时候，前任之所以是前任总有他的缘由，接盘填坑的难度给人的感觉并不亚于重建的难度。但即便如此，贸贸然的重构也并不见得是好的办法，而最可怕的重构是为了和前任撇清关系，想要出业绩出风头的“冲动型”重构。
他们往往简单的把当前出现的问题归结为前任的不够努力和逻辑不清，实际上前者很可能只是因为对各种不可控因素如成本紧缺、资源进展缺乏足够的协调和推动之下的情急之举，又或者当时的业务不太明朗，相关的决策本身也是一种权宜之计。
每一个产品经理都梦想自己能够主导一个产品的诞生，但适当的压抑自己的“创造欲望”，本就是一种职场生存技能。多年前，我在这个上面就栽了一个大跟头，一个并不复杂的产品被整成了大杂烩，实在忍不住骂了娘，然后决心重构，一个人从底层架构开始重新规划树立整个产品的定义和业务场景逻辑，并且重新输出了整个产品的交互设计和原型。
事实证明，这不是高明的做法。
理智的做法是避免KPI导向，切忌以“政治正确”为驱动，而是回归到产品价值本身，弄清楚当前问题的根本原因。花费更长的时间去了解和认识产品，调查业务瓶颈，查看用户反馈，摸清企业战略和产品的生命周期到了哪一阶段，再针对产品出现的问题，分清哪些是产品本身问题，哪些是技术问题，哪些是业务问题。
当你能够在一个新的环境站稳脚跟，熟悉整个上下游的工作链条，并对业务有一个全局的认识，才可以去考虑全局性的重构系统。同时，所有的重构工作并非单指产品的功能，还包括业务、技术、售后等一系列的配套措施是否认可，是否能够对当前的问题和未来达成一致。
02、搞清楚是业务问题还是产品问题
在你决心开启重构之前，建议再温习一遍产品的价值公式。同理，重构也需要构建一个新的价值公式。
重构的价值＝新系统的新价值+旧系统的迁移成本
如果这个公式能画上等号，那么恭喜你，你目前面临的问题值得通过重构来解决，接下去的事情就顺理成章了，你只需要进一步诊断到底是什么原因会导致目前的困境即可，否则还是改良派的做法更靠谱。
对于一款产品来说，业务问题是最先需要解决的，因为产品核心价值追根揭底还是商业价值的体现。如果业务逻辑跟不上用户行为，衍生功能解决不了用户需求，平台体验和技术实现再好也无济于事。一旦出现这种无法满足业务需求的问题，就不是简单的对产品进行重构了，而是需要重新评估业务机会是否符合组织的方向，是否有相应的资源和技术储备。
想要解决业务问题，必先要解决商业模式的问题，只有确保业务逻辑上具备可行性的产品才会有可发展的路径。
其次，必须要清醒的认识到当前产品本身的问题对用户需求的满足程度。如果用户的强需求没有满足，潜在性需求没有挖掘，而弱需求、伪需求拖沓了资源占用了页面，则产品的重构往往就是上上之选。
只是这个时候的重构，还可能涉及到相关资源、产品理念的重构，而非单纯的产品架构和功能的重构。一定要在技术和配套资源方面得到一定的投入，才能真正推动产品的重构。单纯依赖产品端的一腔热血是不能从根本上解决问题的。
如确认属于产品本身的问题，仍需要解决很多问题才可以启动重构，否则还是做温和的改良可能是更为恰当。这是几个需要你冷静回答：
1、这个功能/逻辑的作用到底是什么
搞清楚业务场景，充分了解当时产品做功能/逻辑的思路可以有效避免踩坑
2、为什么要做这个功能/逻辑
很多时候，一个产品功能除了用户需求，还有公司的需求，弄清楚产品决策依据和源头能够让你更充分的理解产品
3、这个功能/逻辑有没有对其他功能产生影响
隐藏的问题往往会成为一个大坑
第三，技术问题也往往导致产品重构的导火索。相信很多PM经常遇到开发说“xxx数据就是这样改不了”，“这个数据以前没有，现在获取不了”这种问题。一旦发现产品在数据源采集、技术架构选型等底层系统问题，重构也是必然的。
但技术架构引发的产品重构，本身就属于蛮有挑战性的问题，技术的选型和架构首先源自对业务机会、业务规模的评估，势必决定了在产品的不同阶段，所采用的技术先天性存在瓶颈，必然随着业务的发展来扩大投入。权衡成本和投入问题很可能超越PM的权责范围。
03、老产品的重构方案
很多PM由于缺乏架构思维，很容易就会把一个产品演变成各种功能的堆砌，什么功能都提供了，但需要的时候得自己去找，这种大杂烩的系统在后台产品领域是非常普遍的。很多时候既然各方谁也没法说服谁，那就各自都来一份，自己玩自己的，PM的妥协最终让一款产品变成四不像。
所以，重构的第一件事是梳理业务和架构。必须要想清楚到底是从功能模块来设计产品，还是从业务场景和工作流来设计产品。结合本人实际操盘的各种重构项目，建议从这8个阶段来缓步推进重构的落地。
1、场景识别
本人一向反对产品的功能化，PM最忌讳的就是这个产品有什么功能，因为它会让我们只见树木不见森林。只有能够有效识别到高价值的场景，这个产品才具有真正的竞争力。在做系统重构的时候，撇开简单的功能才能摸准用户的诉求，才能解决掉优先级的问题。
以此前我负责的一个会议平板为例。原有的产品由于没有产品线的概念，只能盲目的持续堆砌功能使得整个产品越来越臃肿，耦合度过高导致维护成本高企，版本迭代困难，甚至演化到各个模块的工作职责划分都成为难题。
这种情况，首先就需要搞明白这个产品到底要去满足那些核心场景的诉求，从而推动产品整改的持续优化和迭代。
2、流程再造
流程是什么？产品是不是直接把线下业务过程直接搬到线上？这是很多PM犯的有一个错误，他们不能有效的去优化线下业务过程，更无法引导用户采用新流程来提升效率。特别是一些B端产品在这方面特别突出，这种产品看上去符合用户的业务现实，但它缺乏足够的张力，无法应对未来的业务变化。
多年前主导的一个O2O服务平台，则是一个流程再造的典型案例。通过把核心业务进行抽象后，我们找到了支撑整个复杂的业务的关键支撑点，然后大胆的削减了一些不必要的流程后，使得整个系统的效率极大的提升，系统的耦合度变得更为柔性，具备了快速的业务扩展能力，后期的整个平台的搭建变成了搭积木游戏一样便捷。
3、 业务估算
业务估算的目的是为了技术选型做准备。应该说，没有一个技术选型能通用所有业务，有些架构很先进但可能成本高，有些成本可控但扩展不足。所以，一定要科学预估未来一定时间内的业务发展速度和规模，才能选用一个符合业务现实的技术方案。切忌好高骛远，当技术与业务不同步的时候，除了带来不必要的风险还带来额外的成本开销。
4、 风险策略
主要考虑以下几点：
重构复杂度是多少，是否需要分期迭代进行？技术储备是否满足需求？重构后的主要使用场景是否发生变化，操作逻辑是否合理，用户认知是否能够延续和适应，是否带来额外的成本开销？有没有预备和可替代方案是什么？
5、指标跟踪
重构后，达到什么样的数据才算合格？如何评估成功的成败？产品经理需要清楚的是通过重构，给用户带来了多大的价值，这些价值如何被量化，以及是否能够带来新的收益点。没有指标评估的重构，往往难以完整落地。切忌用主观感受来替代指标评估，比如一个信息检索功能能够提高效率，就应该数字化为管理效率提升了30% 这种可直接感知的数据。
