未来产品迭代（是把起家打天下的产品重构一次）

编辑导语：对于产品经理来说，很多人都会经历从0到1的过程，而比这个过程更难的，是把起家打天下的产品重构一次本文作者分享了一个已经运转了七年的系统的重构过程，一起来看一下吧，我来为大家讲解一下关于未来产品迭代?跟着小编一起来看一看吧!

未来产品迭代

编辑导语：对于产品经理来说，很多人都会经历从0到1的过程，而比这个过程更难的，是把起家打天下的产品重构一次。本文作者分享了一个已经运转了七年的系统的重构过程，一起来看一下吧。

对于产品经理而言，很多人会经历从0到1的过程，尤其是在创业公司，如果是初创期，业务形态还很迷茫，需要从0到1；或者是新开启一条业务线或产品线，同样需要从0到1。

于我而言，从0到1的过程并不陌生，甚至积攒了一些经验。但今天想和大家分享的，是在从0到1之后，甚至这个起家打天下的产品已经发展了七八年的基础上，去重构，去给它赋予新的生命。

一、为什么要重构

要重构的这个产品表现出来的是PC客户端的形式，当然与此配套的还有两个不同角色的App端。同一个业务在不同的客户端给用户提供服务，这很常见，比如微信和微信电脑版，钉钉和钉钉电脑版。

不同于钉钉和微信在一推出就同时配备了不同端的服务，要重构的这个PC客户端其实属于公司里起家的一个产品，早年刚刚开始创业时，公司里的技术合伙人用C 的技术写出了这套系统，也正是这套系统，让它赢得了大量用户，巩固了发展的根基。

但是随着业务的发展，当前的PC客户端已经越来越不能满足更新迭代的需要，就类似于我们所说的“现阶段的主要矛盾是人民日益增长的物质文化需要同落后的社会生产之间的矛盾”。

虽然是起家的产品，但之前逻辑和技术写成的系统已经远远落后于App端的更新迭代，再加上早期开发这个平台的技术人员有的已经离开，仍还在的技术合伙人目前的精力更多在于对外联络，业务繁忙，很难抽出身来再改代码。

那放弃PC端，主营App端行不行呢，也不行。目前PC端的主要用户群体都是一些VIP级别的，占比很大。用App的可能是个人，用PC的更多是组织，日常办公中使用PC的情况更多，而且从数据来看，PC端在某些方面的人均数据是App端的几倍。

既不能舍弃，也无法继续延展，同时又有不断更新迭代的需求和紧迫感，那么唯一的方式就是重构。用新的技术框架重构现有的这套系统，让其具有很强的延展性，不论从性能还是后期更新来说，都可以有很强的全新生命力。

二、漫长的重构路

产品从0到1去做其实不难，无非是前期的方向和探索路径需要把控。而如今要重构一个7年的业务系统，就算照葫芦画瓢，也难以面面俱到。经过7年的发展，表面上看起来平平无奇的系统，其实里面包含着无数的业务逻辑和需求点。

听说在我之前有好几位产品人员接手这项工作，但重构都没做起来，我不知道这条路是否能在我这走通，但当时觉得既然这是一项必须要做的事情，一直前进就好。不求有功但求无过，没那么想赢，只是不想输。

如今回想这个过程，我觉得下面这些阶段共同构成了期间的坎坷和波折。好在一直坚持没放弃，圆满完成重构，并实现了旧版用户升级新版的更新换代，解决了这个存在许久的难题，于我自己而言也很欣慰。因此将一路走来的感触和思考分享给大家。

1. 业务庞大复杂，难以一次穷尽

前面也说过，已经运转了7年的系统，里面的业务逻辑千丝万缕。不论是刚入公司的我，还是已经加入有一些年头的其他同事，从技术到产品再到运营，都不了解其中的业务全貌。

刚接手时，领导跟我说是之前的页面样式搞得不太满意，需要重做一套，其他内容都是完备的。于是我用2天的时间比对现有旧版系统，把全部的页面原型都画了出来，至于其中的逻辑和需求点，有一位业务同事和我配合，我们一起完善。

2. 历史遗留填坑，逐条复核完善

页面有了之后，我们开始填补业务规则，找到了之前产品人员遗留下来的文档内容，最开始以为可以直接用，但仔细看过后，觉得里面的内容能用的很少。一方面是很多地方缺乏对应规则，另一方面有内容的地方也描述不畅，难以理解。

我和搭配的业务同事开玩笑说，我俩是填坑爬坡小姐妹。因为历史遗留下来的坑太大了，之前有内容但不适用的地方我们还可以调整优化，但前提是真正明白其中的逻辑，你懂了才能清晰的阐述出来，然后给研发和测试同学讲解。

还有一些是之前内容缺失，我们非常茫然。很多时候只能用App端一个个去试去看，然后反推当前的逻辑。App有两个角色版本，PC则涵盖两者角色更为综合。而且这些年App端一直在更新迭代，PC已经停滞很久，如今想一步赶上，难度可想而知。

3. 雏形查漏补缺，注释规则纠结

经过了令人头秃的逐条复核及填坑，我们认为一个雏形已经出来了，因此想和研发测试同学讲解一下，这个过程也是查漏补缺的一环。因为有的研发测试进入公司时间比较久，对于其中的一些内容逻辑可能了解多一点。

这个过程中，每个人的性格就凸显出来了。负责此事的技术负责人一直以来态度都还比较好，在我刚接手这个事情的时候，他还跟我说之前的产品人员弄得乱七八糟而且讲不清楚，导致重构进行不下去。同时也说深知此事复杂，不要太担心，慢慢来。

在第一次的讲解开会中，登录页面两个框就被一位测试同学纠结了两小时。我以为这是最简单的模块，因为一般登录注册这种已经很成熟的功能基本都不会有太多问题，但在这里是完完全全的从0到1。

当天晚上我的领导喊我一起下班，路上还安慰我很多，同时表示不必对此太在意。其实于我而言还好，因为我知道这件事情不会因为个别人的原因就中断，遇山开路，遇水搭桥，总之就是要把事情做成。

4. 确定进入研发，漫长跟进答疑

按照流程，需求讲完之后大家都没有问题，那就可以进入UI页面的设计了，当UI同学设计完全套页面后，排期进入研发。原以为进入研发后可以松一口气，但我们还是高兴得太早了。

一方面是业务规则内容太多，讲解的时候大家理解不透彻，在做的时候才发现疑问。另一方面可能当时确实存在一些地方的疏漏或者跟App不一致的地方，于是在研发和测试的过程中，疑问此起彼伏，进入漫长跟进答疑期。

其实这也是好事，相当于又查漏补缺了一遍，使其更全面更严谨。毕竟参与其中的每个人之前都没经历过，也不知道原来是怎样，所以有疑问一起沟通。遇见问题解决问题，事情才能继续推进。

5. 问题层出不穷，细节点滴更新

之前就是因为做的时候没有任何文档资料留存，导致我们在重构时两眼一抹黑，于是这次非常重视资料留存，每一个小变动确定后都会同步更新在原型需求文档中。由于测试同学可能早就写好了测试用例，因此在需求的开头也要有明确的变更记录，日期及内容等。

那个阶段我感觉自己就像一台答疑的机器，坐在工位上，每天都有研发测试同学过来问，有时候还会排队，我拿不准的就要钉钉业务同学，也就是当时的一起填坑小姐妹，我们共同给研发答疑解惑，然后把最新的内容记录留存，wiki有时候一天更新好多遍。

在最后测试阶段，大家每天都一起开会过不确定的问题，测试日日发问题，细节点滴有时长达几十个，我们第二天商议后给出答案，滚动式前进，一位产品经理，一位业务同学和二十多个研发测试，团队的力量是无穷的。

6. 新版初次试水，收集试用反馈

当新版开发完成，经历了测试验收之后，我们觉得终于可以让用户试用的时候，小范围线下找了一些用户进行试用，以便收集使用反馈。

和老版本相比，新版本优化了一些样式，很多用户反馈白色太刺眼，字号小看不清等。是我们低估了习惯的力量，老版本再陈旧，用户已经用好几年了，早已习惯了其中的风格样式，虽然我们在重构中也一直遵循原来的基调，只是稍微优化了一些样式而已。

7. 继续优化调整，惨遭更新滑坡

当时重构完的版本号是5000，由于试用的用户反馈比较普遍，以防开启升级后引发更多用户反馈，因此我们进行了优化后，让这些用户试用5001版本，之后暂无反馈。

原以为解决了上述试用反馈后，已经可以了，但事实证明，我们还是想得太过简单了，当5001的升级灰度开启后，客服那里收到了大量用户电话，因此不得不关闭升级。此次反馈的问题集中在两方面：显示问题和系统问题。显示问题相对好解决一些，但系统问题有可能和用户自己的电脑有关。

8. 派出研发亲临，现场解决问题

由于PC端的用户都是一些VIP级别，因此这次情况出现后，大家商议远程解决不了的，可以让研发同学去到用户那里进行现场支持一下，帮他们顺利升级，同时也可以亲临了解一下用户的使用情况，收集一些使用问题，放在后续版本优化更新。

9. 新版功能迭代，版本逐渐累积

与此同时新的业务叠加，虽然App和PC分属于不同的端，但一些影响较大的方面还是要保持一致。自从重构完成之后，每次新的需求，PC 和App终于可以同步了，我们相继做了后续的版本。

但是由于首次升级问题一直没解决，所以版本出现了累积叠加。虽然用户没有使用感知到，但另一条线的更新迭代一直没停，从最开始的5000走到了5010、5020。

10. 技术聚焦修复，测试没有资源

技术同学用全新的技术重构，外加繁杂的业务逻辑，有时会引起卡顿，用户反馈比较普遍，因此也一直在全力解决问题。当技术优化好之前的问题，我们以为让测试简单看下就可以继续升级了，但事情远远没有结束。

新的问题就像打地鼠一样层出不穷，无意中发现了软件崩溃，让这个系统不得不再进行一遍深度的测试，而与此同时，测试人员又因为其他紧急事项的穿插分配不出资源。最快的抽出时间也得2-3周以后，因此这段时间只能等待，技术也有了一点空档期继续钻研。

11. 漫长等待过后，新版终于下水

当测试人员终于抽出身来并且验证没问题后，新版终于可以再次下水了。在此之前我们做了很多准备，结果都遭受打击，因此这一次也依旧保持谨慎，并不可预知结果，也对最坏的结果做好了准备。

12. 疑难杂症迸发，技术加班专攻

这次的升级由于有了前车之鉴，因此十分谨慎。本来想再找一些用户试用，但由于之前的不良体验，不好找到试点用户，所以只是小小地灰度开启一下升级。开启之后出现了一个比较突出的问题，所以及时关闭了。

技术同学对这个问题集中攻破，当时询问进展时，我问今天能搞好吗，他说看情况吧，也许就在一瞬间，也许明天加个大班，说实话技术同学确实辛苦，幸亏一直都在顶住。第二天下午，收到了技术反馈的已解决，同时更新替换了新包。

13. 新版更新稳定，计划老版升新

功夫不负有心人，这一次新版用户升级新版本没有太多反馈，在新版升级完成并运行稳定一周多之后，我们计划开启老版本升级。

其实很早之前大家就一起确定过整体升级计划，一致的意见都是新版运行无问题后再开启对老版本升级新版本的操作。此外，旧版本的升级需要根据配置情况有节奏的逐步放量。

14. 连续八次放量，次次如履薄冰

老版本系统由于使用年头已久，用户对于电脑也没有太多要求，基本能正常使用即可。而此次新版本产品能否在配置低的电脑上顺利运行，技术人员心里也摸不准，因此计划先取个中间点，放入50人定向升级，没问题后再对中间点以上逐步升级。

这个过程我们自身的感受就是在危险的边缘疯狂（惊心）试探，每一次都如履薄冰，不知道这一批放量的用户中是否会出现那个不可能的点。除了早已明确的XP系统不能运行新版本外，win7，win8，win10以及对应的4G、2G、1.5G内存都成为了反复斟酌的界限。

15. 每日统计数据，时刻观察进展

这个过程中基本的节奏就是先试探性放入一批用户进行定向升级，然后过几小时、半天、一天等看这一批里已经升上去的人数，如果人数过半并且无大规模反馈，那悬着的心基本可以稍稍放下。

我们的应对措施是如果出现大规模用户反馈，那就要停止升级，然后针对性解决问题。旧升新的这个过程从头到尾进行了8个批次，人数从30、50、100、200不等，如果中间点的用户已经全部升级没问题，那么中间点之上的基本可以稍微大胆一点多放些人数。

16. 客服前线坚守，技术远程支持

研发同学根据条件删选出用户放入定向升级后，如果用户有使用问题，就会给客服打电话。我们既定的流程是，客服接到用户反馈时除了提供录屏，还要留存其QQ号，然后技术同学远程进行支持。

这其中有80%的问题通过远程都得到了解决，很多用户对于自己使用的电脑不了解，安装很多莫名其妙的软件，然后在新版本安装后遇到各种问题。15%的问题确实存在优化空间，技术同学针对性优化后，反馈日益减少。

还有剩下的5%，大概十余个用户比较顽固，就喜欢用老版本，即便客服告知老版本以后不会再继续更新，新版本的使用问题可以反馈出来，但用户依然坚持用回老版本，无奈之下只能将其从定向升级名单中删除，好在和总人数相比，这一部分人数微乎其微。

17. 最后一波放完，此事终于完满

经过之前发生过的用户集中反馈问题，后面每次放完之后，如果没有动静，内心都会有点忐忑，最开始是负责开发及远程支持的同学询问看看数据升上去多少了。我开玩笑说“看不到反馈心发慌啊，拿捏一下暴风雨是这波没有，还是正在来的路上”，他说“啥也逃不过你的火眼金睛”。

到后面，我们每次商议完这一批选的人数，都像接力棒一样大家各自站好位置。因为人数很多，每次不能太多也不能太少，如果触及到了一个新的临界点，那么通常会很小心翼翼。当还剩最后几十人的时候，感觉终于能看见曙光了。

当最后一波放完之后，对于升级的操作已全部完成了，接下来如果再有用户反馈，那就技术远程支持，好在接下来的几天，也没有太多用户反馈，只有零星的出现。这里面还有另一条线就是负责开发和远程支持的这位同学再过几天就要离职，这属于最后一班岗。

虽然即便他离开之后也会有其他同学接手此项工作，但从最开始的重构开始，他一直是主力人员，他开玩笑地说我们要榨干他最后的价值，我们说把PC扶上马之后你也就圆满离开而无憾了。

三、新生命新思路

当重构这件事完成之后，原有的PC系统终于具备了全新的生命力，作为起家打天下的产品，终于不用再落后于App端，而是可以延展出无限可能。前期重构的忙碌也在无形中拼凑出它原有的业务全貌，这个过程也让我逐步加深了对它的了解以及对业务的思考。

其实做产品到一定阶段后，就会知道表层具象的产品只是躯壳，内在的业务逻辑和商业模式才是一款产品得以发展和延续的根本和源泉，甚至是一家公司得以立足于市场并持续发展的根基。如何能在更深的层面撬动甚至联动，要持续进行观察分析和思考。

四、经历后的感悟

如今回顾这个过程，不算是太艰难的爬坡，可能是已经走过，所以并非坚不可破。于我而言是一次全新的体验，这其中有边界的延展，有了解的加深，有焦头烂额的繁忙，亦有对此事报以必成的勇气和决心。不论从事还是从人的角度，都让我有一些新的体会和感悟。

1. 事

任何事情，规划起来可以很宏大很抽象，可以夸夸其谈赋予很多表层的东西，但真正要实现，需要的是脚踏实地勤勤恳恳的付出。如果没有亲身体验躬身向前，永远不会知道其中的千丝万缕，这也是干活的执行者和不干活的领导者之间经常会有的代沟。

就像我们常说世界上没有什么感同身受，你不是当事人不是掌舵者不是驾驶位置上的人，说什么都会很轻松，可唯有经历过才会懂。真要想把事情做成，唯有坚忍耐烦。当两个角色集于一身的时候，就是我常说的，需要你既能跳出来，又能扎进去。

事情在进行的过程中或者稍有困境，最不缺的就是悲观失望甚至看衰的声音出现，放弃容易，坚持才难。在这个过程中有时候可能你自己都不知道前景如何，但只要踏实认真努力前进，遇山开路遇水搭桥，必能柳暗花明又一村。坚持到最后，一览众山小。

2. 人

不得不说，人是做事成败的很重要一个因素。我们往往说天时地利人和，不论大事还是小事，其实都需要这三个因素。当大家都迷茫时，你能拎清主线规划一条路，当遇到困难时，各个角色的人首当其冲，有时候是你给他们信心，有时是他们给你信心。

那位升级后远程支持的同学，一直也是研发过程中的主力人员。他很早就计划年中离开北京回家乡了，但是升级开启后为了能及时支持，临走前连续两个周末都来公司加班。最后那次他说：还是不放心，过来看着点吧，这可能是我为公司加的最后一次班了。

团队的力量不可忽视，另外就是很多人没有绝对的性格，前面我说的那位测试同学最开始讲解时常常让会议进行不下去，当时大家心里都会有些想法。后面接触多一些可能觉得也释然了，很多时候他也有好的一面。事无绝对，人也是，始终相信人性本善。

3. 己

反思这个过程中的自己，其实成长也很多。从最开始的迷茫，到投入，到坚定，到坚守，再到最后的回望。这可能是我经历最长的一次产品周期，也是之前从未遇到的情况。看到重构后的产品能够开花结果走上正轨，我内心很欣慰。

从最开始只是单纯接到这项工作，并不知道里面的坑有多大，内容多复杂，那时候我的领导也不知道。可一旦接手做起来就是抱着把这件事做成的态度和决心，不论中间千难万险，都想办法去应对，遇到问题解决问题，也就这样走下来了。

在重构的产品开发过程中，常有人问我，如果新版做出来用户不用怎么办？其实那时候我也不知道怎么办，但唯一可以肯定的是，新版必定要取代老版，否则无法前进和迭代。这一预言在放量升级的过程中也出现了苗头。

刚开始有一部分用户反馈很大，强烈要求退回老版本，这也是前面所说的习惯的力量。虽然我们升级的原则是只要电脑配置支持新版本运行，就不建议退回老版，但依然有十余个用户是升级钉子户，不好沟通，那就只能退回老版。

这个现象我觉得像极了《跨越鸿沟》一书中所阐述的新技术采纳生命周期，当一项新技术出现时，有创新者，早期使用者，早期大众，晚期大众，同样也会有落后者。如今来看，我们的路径和这个曲线是如此吻合。

当监测旧升新的人数已经超过80%时，我就知道此事已经基本平稳，剩下的只是收尾。用户在逐渐接受采纳，我们跨越了鸿沟断层。最难的时刻过去了。

成事带来的满足和欣慰是精神之旅的纪念品，并不是非得需要外界有形的肯定和赞赏，那是你内心深处和自己的一个交代，事了拂衣去，深藏身与名，就是这种感觉。

未来的一切还要继续，希望自己可以更加淡定从容，面对未知的一切。

一起加油，共勉！

#专栏作家#

慕斯姑娘，musiguniang，公众号：产品那些年，人人都是产品经理专栏作家，《产品经理成长进阶指南》作者。从消费互联网入行，现在产业互联网领域从事产品工作，擅长产品规划和落地。

本文原创发布于人人都是产品经理，未经许可，禁止转载。

题图来自Unsplash，基于 CC0 协议。