|
|
导语：任务1-3年的产品经理，在没有任何重构教训的团队中，如何独立操盘一次业务零碎的全流程重构？但愿本文能提供应在零碎重构启动期的你一些参考思绪。
一、重构配景 1. 零碎和用户
1）零碎简介
本次重构的零碎，是一个风控大数据测试零碎，经过线上化操作完成多种数据产品、模型的批量调用，并可为客户提供数据剖析讲演，同时也为我司风控人员提供建模数据的反对。
该零碎的特征是小众且艰涩，与多个零碎有交互。
包罗下游CRM等多个业务零碎有信息交互、还有上游与BI、建模平台等多个数据零碎无数据交互，最首要的是底层还与数据产品API接口有中心的调用交互。
假如不理解公司中心业务逻辑，不理解公司的数据产品，将很难hold住这个零碎。
我是在担任旧零碎1个月后，切当得知该零碎方案进行重构，虽然在这以前本人曾经担任过几个有相干性的业务零碎了，然而仍是花了很长期摸清了这个零碎的整个逻辑。
2）用户特征
值得一提的是，这个零碎是少见的有“多视角用户”的状况，有客户和剖析师两种角色，两种登录账号类型，可分别从内网和外网登录，部份数据权限是两边互通的，但功用权限是隔离的。
因为客户方的存量账号宏大且用户操作高频，故零碎重构必需将客户端和风控真个重构分红两部份，即在一段时间内新旧零碎将会并行，而客户和剖析师都是无感知的。
下面这个计划是在设计中期修正的，部门的领导也给了得多倡议，这里也是本次重构方案中的难点之一。
2. 重构缘故
1）内因
老零碎是公司成立早期最先的一批零碎，零碎没有前端，只靠着一个后端python开发保护着，可想而知零碎的页面有多原始。
老零碎对数据测试量级有显著的天花板，效力调配分歧理，资源利用率低，形成工作等候多、进度慢等问题。
领导层但愿新零碎能改换java言语，从而晋升零碎的机能。
2）外因
与少数需求被重构的零碎相似，重构前的老零碎往往都有下列令用户“忍辱负重”之处：
账号权限体系繁杂，有局限性，新用户学习本钱高功用设计过于激进，异样频出，用户反馈蹩脚页面与交互后进，操作信息不明晰，用户体验差因此，本次重构是由内到外的重构，从中心的底层机能到用户有感知功用流程进行的总体重塑。
新零碎重构内容包罗：技术机能晋升、权限体系重塑、功用流程革新、用户体验晋升、新功用扩展等5个方面。
技术机能晋升和业务流程革新因每个零碎都不尽相反，这里咱们暂不探讨，前面次要聊聊产品重构的思绪以及各个节点需求阅历甚么，以便大家触类旁通，在后期心中有底。
3. 团队用时
参预全部名目次要的开发测试成员有5位，均没有零碎重构的相干教训。
产品：1人后端：2人前端：1人测试：1人备注：UI 属于公共资源，设计了第一版零碎界面。
除去技术底层的重构时间，产品参预重建新零碎的时间大略是7个月，实现了外部用户使用真个重构和用户迁徙。
后期调研：2周原型设计+地下评审：2周开发v1.0版本：1月功用补全+新功用开发：3月数据同步+新旧零碎并行：1月外部用户彻底迁徙：1月二、布局与支配关于全部重构名目，按用户使用端分了两期：一期迁徙外部用户至新零碎，二期迁徙内部客户至新零碎（二期启动时间定在一期工作整个实现并不乱运转3个月之后再开始）。
关于一期方案咱们定了指标，分三步走：
第一步：实现v1.0 MVP版本的上线第二步：接入更多接口和完美更多功用第三步：新旧零碎数据同步和用户迁徙这个零碎外部的业务源头是工作请求，有两个请求入口。一个是零碎外部的请求入口，一个是从CRM发动的客户请求入口，斟酌后者波及内部零碎，故不属于最小化MVP的规模。
因此第一步 v1.0 版本上线，咱们的指标，就是跑通一条残缺的用户使用门路：即从外部请求测试工作开始，到拿到正确的数据测试后果完结。
PS：界定MVP版本内容是非常首要的，v1.0版本无需白璧无瑕，做到定时上线，后续能在用户的反馈下不停完美是最佳的。如一开始就憋了得多大招，不只拉长了开发测试的周期，还可能会在后续的用户的检修中遭受滑铁卢，对上线的内容进行修正，真实不值。
三、重构的全流程 1. 业务梳理
作为产品经理，假如你接到了重构零碎的工作，你需求在尽量短的时间内摸清零碎的整个逻辑，除了页面能看到的逻辑，还需求去理解得多页面看不到的逻辑。
另外，还要把上上游零碎的功用交互和数据交互整个了解和走通，知道数据是从哪里来，到哪去。
因为老零碎年代长远，历经多个产品和研发、得多功用的逻辑没有很明白的文档留存。
如你跟你的开发都是新接手零碎没多久，就收到的零碎重构的工作。作为产品，你能够带着你梳理的问题和初步假定去找研发，一同查问理解问题部份的代码逻辑，从而验证本人的料想，同时对齐你们的认知。
这个阶段，要尽量地买通对旧零碎认知的盲区，就像解剖同样，让旧零碎的骨架和筋脉在脑海中有明晰的意识。
与设计新零碎不同，重构零碎对兼容性要求高，你需求辩证的去思考每个模块可优化的幅度和下限，在对原始功用、周边零碎、用户习气等多方统筹的状况下，给出最优解。
因此，后期业务梳理时斟酌的片面很首要，尤为是有流程革新时，咱们不克不及只想到好的一面，也需求想到这次改动可能存在的危险和弊病是甚么。
2. 用户调研
除了你本人发现的要去革新之处，真正的用户需要是确定要聆听的。
用户调研部份这里我采取了三种形式获得信息：
日常问题采集中心用户访谈凋谢问卷考察1）日常问题采集
采集日常任务顶用户反馈的零碎问题，将问题归结出来，剖析高频问题是否能够经过改动产品设计来防止。
在旧零碎保护期间，天天都得多用户来找我问问题，如：进行中的工作泛起异样、操作哪里走欠亨报错了、或是不知怎么操作的征询问题。
这些一部份是产品架构设计的问题，一部份是产品交互设计的问题。个别这类状况都是重复泛起的，如：明天A反馈给你了，你去找研发解决下；今天B反馈给你，你去找研发再解决下。
高频的问题面前就是一个急需解决和重塑的中心痛点，这里虽然没有被用户明白提出来，乃至用户曾经习气了这类“理所固然”的操作。但作为产品，你是需求明晰地意识到这里就是最有价值的需要点，也是推翻老零碎产品架构的冲破点。
2）中心用户访谈
针对部份中心用户和业务方领导，约时间坐在一同聊一聊。
面对中心用户，能够针对用户遇到的问题有更深档次的理解，此外这也是一个很好的时机用于计划初步的沟通，能够问问他们关于你的革新思绪有甚么看法倡议，这关于你在设计中优先级的把控很首要，看看本人和用户最关注的重点有无偏差。
另外，与业务方领导也是有须要坐在一同聊一聊的，毕竟零碎重构不单单是你们本人的事，也关乎于业务方任务效力的晋升。你需求让对方领导知道你的重构方案，能为他们来怎么样的增益？最首要的，是当你无奈判别某种计划是不是可行时，对方领导能够起到拍板的作用。
简略来说一句话：多沟通，没害处。
3）凋谢问卷考察
采集问卷反馈。
通过上述的日常问题采集和中心用户访谈，你能根本理解重构中需求革新之处。
在此状况下我采集的问卷，80%的反馈曾经在我预感之中了，然而我依然倡议大家要做这一步，缘故有3点：
获得全量信息最快捷的形式，便利查漏补缺用户加强参预感，本人的意见也能够被驳回让用户提前知情，前期更好做用户遍及的推行问卷作为一种高效的信息采集渠道，不必就亏大了，它能够短期获得到一切用户的对新零碎的一切冀望，从而能够按相反问题泛起的频率建设新需要开发的优先级，如高频问题能够优先排期解决。
同时也能够让用户有一个心思预期，知道在不久的未来将使用新的零碎，这样像是提前打好招呼同样，用户在前期试用新零碎的也会有更多的踊跃性。
3. 原型设计与评审
新零碎的原型需求破费较长期来实现，倡议在开始画原型以前，能够借助流程图梳理逻辑，避免跑偏，或沉浸细节耽搁进度，包管你的思惟的联贯性，因此效力也会更高。
另外倡议初版原型要更为当真看待，页面规划、色彩，交互门路等，能交待分明就别一笔带过。由于大少数状况，在正式开发前，都会拉一个大型评审会，约请两方领导和用户代表独特加入，一个拿的出手的原型图能为你在评审会上减少更多的决心。
倡议在评审时，除了拿出设计计划和原型图，还要提前筹备好Q&A，也就是针对听众最关注的之处，提前写好问题和解决办法，为本人争夺更多的被动性，也会让对方对你感到安心。
4. 首发版本上线先后
1）上线前
通过了专家原型评审，就能进行后续正常的开发评审了。
在后期尽量多跟你的研发团队沟通对业务的看法，设计初衷是甚么、但愿解决甚么问题，让研发在开发过程当中更多了解业务，增加因了解偏差泛起的bug。
全部开发进程个别需求1月以上的时间，这段时间产品经理要做好名目进度办理的任务，最少做到按周统计进度，开进度会议。
假如这个名目高层领导对比关注，要按期发邮件给高层领导同步进度。
2）上线后
这里的上线能够分为两种：内测版上线、对外正式版上线。
内测版上线流程走通后，能够约请几位种子用户来体验新零碎，待用户验证中心流程跑通无误后，能够对外宣告正式版上线了。
正式上线后，是1-2个月的试用阶段，这个这段期间你需求让更多的用户试用新零碎，及时袒露各种意想不到的问题，并疾速进行迭代修复。
不外，用户此时还在旧零碎的使用习气中，如何让大家更多地试用新零碎呢？这里我使用了三个小技能：
提供更快的触达形式（如：免权限请求）提供用户关怀的试用福利（我这里是提供了一定测试量级给用户）小窗口约请用户（我私聊了80+以上的用户，约请体验新零碎，并附上零碎仿单）固然在这段时间，你需求一边关注用户反馈，一边布局后续的工作，随时把控时间和进度。
5. 功用迭代如何决定
可能大家都但愿，新零碎等把旧零碎一切的功用都补齐了，再开始加用户提的新功用。
后来我也这么想，但发现想要吸援用户的关注，新功用成果最佳。人都有猎奇心，假如发现你有跟以前纷歧样的新货色，会更为想去体验和尝试。
这一点，也是我与领导沟通后被点拨到的。
最佳的方法就是均衡旧功用与新功用的开发进度，条件要肯定新功用的泛起不会与未上线的旧功用有先后程序的嵌套。
好比这次我在重构时，斟酌到我的用户群体为各个地域的多个风控团队，大家通常以组为单位去对接客户。而老零碎工作请求只能属于一集体，小组成员无奈协作。
在新零碎中，我就在首发版本上线的第二个月加了「小组办理」的功用，组内成员相互均可以看到彼此的工作，也能够同享本人的工复数量，不光完成了组内工作灵敏流转，还完成了各团队担任人对团队外部成员任务量和任务内容的统计和把控。
这个功用自身与旧功用的没有须要的嵌套逻辑，上线用户的反馈十分好，验证了以前的预期。这类新旧功用交替开发的思绪，大家能够多思考下。
6. 过程当中出了问题怎么办
个别重构的零碎上线后，都会收到用户较好的反馈，毕竟旧零碎年久失修，新的零碎会让人眼前一亮。这时候候，产品经理容易沉迷在对新零碎尽如人意的空想中，但愿新零碎的口碑始终放弃完善，不允许有任何瑕疵。
但是，你无奈防止问题的泛起。
在新零碎上线后的这段时间，的确是零碎相对于最不不乱的时代，需求不停发现问题，修正问题。
作为产品经理，要学会了解新事物开展的法则，把解决问题和如何防止后续问题的产生放在思考的第一名。
上面三点，是我在走了一些弯路之后才明确的情理：
对问题有容纳心（泛起问题不首要，首要的是如何解决和防止问题的产生）对开发有决心（与你的开发站在同一立场上，泛起线上bug先给予解决问题的信赖）对用户有耐烦（第一时间抚慰用户，诚心报歉并阐明解决时间）我记得一个导演说过一句话：这个的片子假如胜利了，那一定是大家的功勋；假如失败了，那一定是我的责任。
产品经理并非仅仅承当产品设计的任务，更多的还要斟酌团队协作、名目办理等需求考验软实力之处。
而问题矛盾的泛起，会更为缩小你在这些状况的心态和应答才能，要有大局认识，关建时分担起名目担任人的责任，你的团队成员才会更为服气你。
7. 数据同步和用户迁徙
新零碎根本功用都与旧零碎对齐了，是否就能将用户整个间接切到新零碎了？谜底是不是定的。
用户迁徙到新零碎，绝对不克不及一刀切，要采取安稳过渡的形式，逐渐交换。
由于老零碎的数据都是这段时间用户正在使用的，假如强迫切到甚么数据都没有的新零碎，用户不炸毛才怪。
况且，咱们这次名目分两期，一期的指标是，在内部客户无感知的状况下，外部用户曾经整个过渡到了新零碎。
可能你会问：内部和外部数据互通的部份该怎么办？如何包管以前在旧零碎运转的流程？
谜底就是——数据同步。
数据同步能够拆分为3部份：
账号同步——外部账号和内部账号由旧零碎同步至新零碎账号关联——新零碎的外部账号关联旧零碎的外部账号文件同步——新旧零碎发生的文件互相同步第一步，账号信息同步
因为内部客户账号创立的源头来自下游CRM零碎与旧零碎的用户创立，斟酌客户内部重构放在二期，故本期在此节点放弃内部客户账号创立源头不变，仅将客户账号、外部账号及相干信息同步至新零碎。
新零碎减少「客户账号/外部账号」模块，用于代替旧零碎后盾的用户列表。存量数据批量刷进来，增量数据放弃实时更新。
第二步，将新旧零碎的外部账号进行关联
因为用户都是同一集体，在注册新零碎后，他将具有新零碎和旧零碎两套账号。
所以，办理员要将同一个外部用户在新旧零碎的两个账号进行关联映照，包管下一步文件同步的稳步实行。
第三步，新旧零碎的文件互相同步
为完成内部客户无感知的外部用户迁徙，新旧零碎的文件同步十分首要，也是包管无感知成果的症结。
首先肯定同步规模，这里有一个最大化和最小化准则。
旧零碎同步新零碎时要遵守最大化准则。即新零碎要在将来代替旧零碎，将旧零碎发生的整个数据残缺地同步至新零碎，包管用户一切在旧零碎能查到的内容在新零碎也能查到。新零碎同步旧零碎要遵守最小化准则。即只同步还在旧零碎的内部客户需求看到的数据足够。假如彻底同步，不只占用资源，还可能让外部用户无奈脱离旧零碎。以上三步的实现，为后续的「用户迁徙」奠定了根底。
最初，用户迁徙
由于业务流程的缘故，需求客户参预的工作，都会从CRM请求。因此用户迁徙的最初一步，就是联结CRM将下游的工作从旧零碎切换至新零碎。由于后面曾经做好关联，所以CRM来的工作，都能在新零碎的已关联账号看到。
这样一来，用户天然就会被动移步至新零碎操作，同时近期发生的数据也能新零碎都能查到，能够算是“无缝连接”，不会给用户形成往返切零碎的困扰。
PS：在正式切换的后期要斟酌更多的异样状况和应答机制。如：在正式上线前，咱们采用了一段时间的手动切换，在验证没有问题后才抉择上线切换。又如：当异样状况泛起时，可手动将新零碎的工作推回旧零碎等等。
8. 小结
以上就是一期方案里一切波及重构的症结节点，可能不同业务不同零碎之间会有不同，不外中心思绪是相通的，都是遵守「安稳过渡」准则，尽量增加用户的学习本钱、升高用户的操作门坎，优化业务流程，晋升用户综合体验。
在用户迁徙至新零碎后，老零碎也不必当即关掉。给外部用户一段时间的顺应期，也能让外部用户将以前同步至老零碎的工作做完，这样会让用户对零碎更有平安感。
四、分享和瞻望 1. 印象最深的两件事
1）产品经理也能够看代码
过后筹备做自动生成风控剖析讲演，波及风控畛域专业常识，老零碎对这个功用无文档记载，我跟开发都不分明讲演中的数值、比率的生成逻辑是甚么。
独一能参考的就是老零碎用python写的长达数十页的代码，因为需求结合业务常识和风控常识去了解，就算开发本人看也有难题，所以我选择本人扒代码。
我过后也是想试试，万一能看懂了呢。前面通过当真的梳理，推导和验证，花了两地利间终于搞分明了这里的逻辑，前面给开发讲授的时分仍是颇有成绩感的。
2）不测播种的点赞
一次偶尔发现，本人的一篇wiki被点赞了得多次，包罗两个部门的VP和一些不意识的人。
这篇文档是我写的一个风控战略产品的业务逻辑简述，是别的部门在担任的平台，由于我的零碎行将接入战略产品接口，需求经过对方平台做调用直达，为了让我的研发能明确风控战略的业务原理，我写了一个科普性质的文档给他们看，便利他们了解。没想到最初居然被那末多人看过，有些被宠若惊。
2. 将来要做的事
当初一期重构的过程已接近序幕，这个名目曾经实现了较为繁杂的外部用户迁徙部份。完成了阶段指标，即：外部使用真个重构和外部用户的迁徙。
待零碎不乱运转3个月后，咱们方案开始二期的客户使用端重构和用户迁徙。
相对于外部重构，内部重构的难度会升高得多。由于内部客户的操作步骤较外部少了得多，不波及中心流程，且新零碎的框架曾经搭建实现，页面无需从新设计，只需改换部份功用便可。
后续斟酌的重点将是，“如何做到无感知或低感知的用户切换”这个点了。
等二期名目实现时，会再跟大家分享教训的，请大家期待。
作者：Fancy刘，现某金融科技公司B端产品经理。 |
|
注册会员