大厂的产品经理是怎样迭代的（3岁产品经理关于重构系统的心路历程）

编辑导语：本文将以3岁产品经理的视角，针对作者经历过的某系统的重构过程，展开一次心路历程的梳理和分享。从无到1.0版本的上线，从不知如何下手到那就冲吧……

一、项目概况介绍

本次重构的系统是“计费系统”，顾名思义是用来计算费用或者计算数量的系统，此系统的定位是根据客户请求数据产品的接口情况来完成计算客户账单的流程。

这里具体是哪个系统不重要，换个别的系统都一样样的，除此之外，要完成出账单的任务，需要诸多脚本在背后支撑，这部分属于技术层面的工作，本文不做过多的阐述。

二、重构原因

1. 客户计费需求光怪陆离

简单来说，客户想要的计费需求如今是千奇百怪，亦或是公司的商务为了能够给客户创造一些让利空间，研究出了一些奇特的计费想法，然而当前的系统并不能够非常灵活且快速地满足这类需求，所以一部分特殊计费的要求都是人工通过临时写一些sql语句或者定制化的脚本来实现的。

但是这种解决方案显然不够高效且风险性较高；另一方面，公司想把这部分的业务管理的更加规范化，进而提出让我们必须通过系统化的功能来实现特殊计费业务的要求。

2. 祖传代码表结构设计不够合理

原计费系统当初了赶项目进度，在底层架构设计以及表结构设计上不够合理，这就导致后期的改造成本和维护成本都比较高，经常是研发人员一边吐槽一边改，所以既然业务方有新的需求，刚好基于这次机会将代码进行重构，也便于经后的管理。

3. 合适的契机更换计费脚本

说起这个原因，其实也是为了间接性地解决另外一个问题，那就是当前采用跑账单数据的是shell脚本，研发人员对于shell脚本不是特别擅长，并且在我们使用过程中shell脚本报错频率有些高，导致我们的账单数据会存在计费不够完全准确的情况。

其实很早之前就想过替换成spark脚本，但是替换脚本这件事事关重大，且日常的业务需求的开发任务也非常重，此问题一直没能得到解决，说到这里作为产品经理的我也有些惭愧，应该更早地为这个问题争取时间和资源，好在这次终于有了这样一个时机去解决，也算是抓住机会去改变吧。

在跟业务方多次沟通后，最终确认了通过开发新系统-结算平台来解决当下的问题，在这之前我们确实是在“改造原计费系统”还是“开发新系统”中进行衡量和抉择，考虑的因素无非是时间成本和开发成本。

二者的优劣也很明显，如果是改造原系统，可以直接开始新需求的开发工作，必然是最快且成本最低的方式，但同时会错失重构的机会，业务方也不会给比较长的时间来让我们有时间做重构的工作；如果是打算从头开始做新系统，当然需要的资源较多、耗时较长，但是这样就能够把整个系统的架构进行重新设计，从长远来看自然是件好事。

三、项目整体规划

既然确定了以新系统的方式来完成此次任务，那在最开始产品经理需要规划好项目整体的一个排期进度。在确定排期前，首先要明确以下几点：

1. 重构内容包含哪些？

• 当前系统主流程业务中哪些逻辑和功能需要调整
• 原有的哪些表结构设计需要调整
• 与其他的系统之间的交互是否需要调整
• 新旧系统在并行期间的数据该如何处理
• 新业务新功能的设计方案

在梳理这块内容时，产品经理需要认真仔细的确认清楚当前系统中每个功能点，是否需要进行调整，最好是将原有功能列出一个比较完整的清单，这样不易于遗漏一些小的功能点的改造，若是需要调整，则在清单内标注好方便后续的跟踪。

而我本人在进行这项工作时，疏忽了这点，可能是觉得对于原系统过于了解，就想当然的以为这些点都在脑子里，这就导致在开需求评审时，发现遗漏了细节，好在研发人员是比较熟悉系统的，能够及时补充避免了一些问题。

2. 优先级排序如何确定？

确定了原有功能需要改造的内容后，接下来需要考虑此次在新系统中的要实现的新增的功能与原功能在开发中的优先级排序。

这一点蛮重要的，因为不一定要先把原功能全部开发完之后再进行新功能，当然对于本次重构的系统而言，新功能的使用是强依赖于一部分原功能的。

没错，只是强依赖于一部分原有功能，也就意味着我们并非需要在最后阶段在开始新功能的开发。

我为什么会提到这一点，因为这一点对于整体的排期优先级的顺序影响比较大。

大家可以想想，在我们实际工作中其实开发时间是非常紧张的，而我们的需求方也是急于看到一些成果的，原有功能的重构自然不是他们最关心的点，所以我们也要比较聪明地把重要的东西往前提。

也就是说当我们的把必须的原有的主流程开发完后，就直接上手开始新功能，这样能够把需求方最想看到的东西尽可能早点完成，那剩下的其余功能我们就按照正常的系统迭代节奏进行即可，否则，很可能一直处于被需求方催进度的被动状态。因此重构过程中的优先级排序是需要好好考虑的事情。

3. 开发任务该如何拆解呢？

总体的优先级确认后，我们需要将开发任务进行拆解。在此过程中可以先按照阶段拆解，明确每一阶段的主要目标是什么，进而就能知道在这一阶段中需要完成哪些开发任务。

而一个阶段内的开发任务也需要进一步拆解，此时可以根据功能模块划分，比如一个菜单栏内包含了列表展示、详情展示、编辑、导出以及一系列的子功能，我们也需要定义一个优先级，决定先做哪些子功能。

最后就是将划分好的各阶段确定出开发完成时间，也就是提测时间，进而排期成多个版本进行分批上线，以上的过程是需要产品和研发共同敲定的，至于上线时间需要同测试人员一起进行评估。

图为本人当时绘制的排期表，可适当参考

四、敲定新功能的设计方案

前面已经提到过了，本次系统的重构主要分为了两部分，原有功能的重新搭建和开发新功能支持新的业务需求。

后半部分才是这次重构工作中最重要的内容，也是“业务方爸爸们”最在意的工作，但在实际工作中，我们是先敲定了新功能的业务需求和实现方案，再考虑新系统的整体规划方案的，那这里也由此可见我上面所提到的排期时考虑功能优先级的重要性。

关于新功能的设计方案，这里不会展开来讲，原因也很简单，此方案是根据公司的实际业务情况出发和落脚的，因此非常定制化。

那我想说的其实是另外一点，产品经理在设计新方案时，不仅仅是需要站在支持业务实现系统化的层面，还要考虑高层领导想要达成的其他潜在目标。

比如，管理制者之所以发起这样的新项目，一方面是为了提高运整体的运营的效率，另一方面呢的其实是想降低研发人员替换时所产生的较高的替换成本，因为当前系统在支持业务工作时，有很多场景是需要研发人员临时写sql来获取结果的，这样的工作对人的依赖性很大，一旦出现人员变动，对业务的工作影响是比较大的。

如果一开始没有想到这一点，那么可能就会像我一样，在设计功能时会忽略掉一些点，导致方案被一否再否，经过了多次的调整才得到了业务和领导层一致的通过。

五、项目进度跟踪

当进入了实际的产品开发阶段后，产品经理需要时刻关注和跟踪项目进度，这样可及时发现是否有延期风险。

根据排期规划我们拆分出了4个阶段的上线版本，大概历时4个月，涉及3.5个后端人员和1个前端人员。同时我针对每一阶段的版本拆分出了每个研发人员按周的计划进度，每到周四下午我会与每个人确认本周的实际进度，是否可以按时完成，若是有其他原因导致延误，则需要立马定原因，解决延期问题，同时也要提防是否还会出现相同的状况。

图为本人当时绘制的进度跟踪表，比较粗简可适当参考

那实际中呢，我确实也犯了一些小错误，在最开始我们确定了一期的开发任务后，自认为大家都没有反馈问题那就是没有问题，因此在进入开发后的第一周我也就没有过多的关心进度情况，等到第二周时发现原定的进度已经不能再通过赶工的方式来弥补了，结果就只能是延期提测了三天。

好在及时跟测试人员进行了沟通，压缩了测试时间，这才能够在既定日期完成一期上线。当然这里也不提倡通过压缩测试时间来达到目标，只是一期上线功能较少，原评估的测试时间较长，确实是有可压缩的空间，才解决了延期问题。

六、第一阶段1.0.0版本上线

与大多数互联网公司一样，上线日是周二和周四，第一期的版本我们定的是周四，原本像这样的新系统，通常是可以不用等晚上再推包上线的，可是我们还是拖到了晚上7点多才开始准备上线。

也正如预想的一样，新系统上线问题百出，大概的原因主要是测试环境和生产环境配置不相同，以及又遇到了sre资源占用等问题，最后的结果就是直到晚上23:30左右才在生产环境部署成功。

那针对这一次的上线问题，我们下来也进行了复盘，从产品角度来看的话，当时确实是在上线验收前，我发现了一些问题，并且花了较多的时间进行了再次测试验证，结果是问题确实存在，但这也就直接导致直到晚上7点左右才开始推包。

其实针对这样的状况，在我看来产品经理可以果断一点，那就是带着问题先上线，因为第一期的上线，也并不会对外开放使用，主要是为了先跑通正式环境，如果是这样的话那天就不用熬到快12点了，这也是我这次学到的一次教训。

那另外一点经验教训是，像这样的新系统上线，其实可以先预上线一次，就是在原定的上线日的时间，提前一个上线日先“预热”一次，主要是解决环境部署或者预发和生产配置不一致等问题，等到正式上线就能避免这些问题。

图为与研发和测试复盘会议的总部，可适当参考

七、写到最后的小想法

如果对本次的重构工作进行个自我打分的话，我确实是不太满意的，只能给自己打6分，也就是刚及格的状态，这里主要有几点原因：

第一呢，我觉得自己还是过于保守不够勇敢。主要体现在不太敢于打破原来的一些逻辑和设计，在原有功能方面还是尽可能在“复刻”，一方面是出于用户习惯的考虑，另一方面是害怕如果进行改变带来的不确定的影响范围。

这可能与我本人的一些工作习惯和方式相关，更倾向于谨慎地完成工作，当然这一点也并非是完全有问题的，因为我确实需要考虑上面提到两个因素，但是也不应该就真的被吓住了。

假设下如果真的敢于突破，出了一些问题，又会怎样呢？影响范围和程度又会有多大呢？完全不可控了吗？其实实际上可能就真的还好，大不了被多骂几遍再改回去嘛，只要能掌控住风险大小，那就冲一把嘛~

第二呢，重构前的产品准备工作做的不够充分。也是体现在两方面，自身角度没能更加深入的去思考这次重构怎样能让系统和业务结合的更加顺畅和紧密，更像是火急火燎、慌慌张张的去完成一项紧急且重要的工作任务，“交好这个差”。

再就是前期的调研应该多花时间做做，而实际中这块确实被忽略了，如果说调研做的比较充分，前面没能深入思考的问题可能就迎刃而解了。

第三呢，产品经理争取资源和时间的能力真的也是需要好好培养和锻炼的。客观来讲，当时在接到重构系统任务时，我同时在负责另外一个庞大复杂的账务系统，日常的需求任务非常重，也是我们部门最核心的系统之一，单就负责这一个系统的时候我都蛮心力交瘁的。

所以这个时候公司让你同时负责多个系统时，要是没有很好的争取资源和时间的能力，估计就会像我一样，吭哧吭哧自己加班干活，两边都不敢耽误。虽然最后也能完成得让业务方和领导层基本满意，但是学到的东西就比较粗浅也很累人。

最后呢，希望以上的分享能给各位产品经理多多少少带来一起启发或者思考，能吸取我的一些经验教训，在产品路上大步前行不要怂！

本文由 @Joysaver