導(dǎo)語：工作1-3年的產(chǎn)品經(jīng)理，在沒有任何重構(gòu)經(jīng)驗的團隊中，如何獨立操盤一次業(yè)務(wù)系統(tǒng)的全流程重構(gòu)？希望本文能提供給在系統(tǒng)重構(gòu)啟動期的你一些參考思路。

一、重構(gòu)背景

1. 系統(tǒng)和用戶

1）系統(tǒng)簡介

本次重構(gòu)的系統(tǒng)，是一個風(fēng)控大數(shù)據(jù)測試系統(tǒng)，通過線上化操作實現(xiàn)多種數(shù)據(jù)產(chǎn)品、模型的批量調(diào)用，并可為客戶提供數(shù)據(jù)分析報告，同時也為我司風(fēng)控人員提供建模數(shù)據(jù)的支持。

該系統(tǒng)的特點是小眾且晦澀，與多個系統(tǒng)有交互。

包括上游CRM等多個業(yè)務(wù)系統(tǒng)有信息交互、還有下游與BI、建模平臺等多個數(shù)據(jù)系統(tǒng)有數(shù)據(jù)交互，最重要的是底層還與數(shù)據(jù)產(chǎn)品API接口有核心的調(diào)用交互。

如果不了解公司核心業(yè)務(wù)邏輯，不了解公司的數(shù)據(jù)產(chǎn)品，將很難hold住這個系統(tǒng)。

我是在負責(zé)舊系統(tǒng)1個月后，確切得知該系統(tǒng)計劃進行重構(gòu)，雖然在這之前自己已經(jīng)負責(zé)過幾個有相關(guān)性的業(yè)務(wù)系統(tǒng)了，但是還是花了很長時間摸清了這個系統(tǒng)的全部邏輯。

2）用戶特點

值得一提的是，這個系統(tǒng)是少見的有“多視角用戶”的情況，有客戶和分析師兩種角色，兩種登錄賬號類型，可分別從內(nèi)網(wǎng)和外網(wǎng)登錄，部分數(shù)據(jù)權(quán)限是兩邊互通的，但功能權(quán)限是隔離的。

由于客戶方的存量賬號龐大且用戶操作高頻，故系統(tǒng)重構(gòu)必須將客戶端和風(fēng)控端的重構(gòu)分成兩部分，即在一段時間內(nèi)新舊系統(tǒng)將會并行，而客戶和分析師都是無感知的。

上面這個方案是在設(shè)計中期修改的，部門的領(lǐng)導(dǎo)也給了很多建議，這里也是本次重構(gòu)計劃中的難點之一。

2. 重構(gòu)原因

1）內(nèi)因

老系統(tǒng)是公司成立初期最早的一批系統(tǒng)，系統(tǒng)沒有前端，只靠著一個后端python開發(fā)維護著，可想而知系統(tǒng)的頁面有多原始。

老系統(tǒng)對數(shù)據(jù)測試量級有明顯的天花板，效率分配不合理，資源利用率低，造成任務(wù)等待多、進度慢等問題。

領(lǐng)導(dǎo)層希望新系統(tǒng)能更換java語言，從而提升系統(tǒng)的性能。

2）外因

與多數(shù)需要被重構(gòu)的系統(tǒng)類似，重構(gòu)前的老系統(tǒng)往往都有以下令用戶“忍無可忍”的地方：

• 賬號權(quán)限體系復(fù)雜，有局限性，新用戶學(xué)習(xí)成本高
• 功能設(shè)計過于保守，異常頻出，用戶反饋糟糕
• 頁面與交互落后，操作信息不清晰，用戶體驗差

因此，本次重構(gòu)是由內(nèi)到外的重構(gòu)，從核心的底層性能到用戶有感知功能流程進行的整體重塑。

新系統(tǒng)重構(gòu)內(nèi)容包括：技術(shù)性能提升、權(quán)限體系重塑、功能流程改造、用戶體驗提升、新功能擴展等5個方面。

技術(shù)性能提升和業(yè)務(wù)流程改造因每個系統(tǒng)都不盡相同，這里我們暫不討論，后面主要聊聊產(chǎn)品重構(gòu)的思路以及各個節(jié)點需要經(jīng)歷什么，以便大家舉一反三，在前期心中有底。

3. 團隊歷時

參與整個項目主要的開發(fā)測試成員有5位，均沒有系統(tǒng)重構(gòu)的相關(guān)經(jīng)驗。

• 產(chǎn)品：1人
• 后端：2人
• 前端：1人
• 測試：1人

備注：UI 屬于公共資源，設(shè)計了初版系統(tǒng)界面。

除去技術(shù)底層的重構(gòu)時間，產(chǎn)品參與重建新系統(tǒng)的時間大概是7個月，完成了內(nèi)部用戶使用端的重構(gòu)和用戶遷移。

• 前期調(diào)研：2周
• 原型設(shè)計+公開評審：2周
• 開發(fā)v1.0版本：1月
• 功能補全+新功能開發(fā)：3月
• 數(shù)據(jù)同步+新舊系統(tǒng)并行：1月
• 內(nèi)部用戶完全遷移：1月

二、規(guī)劃與安排

對于整個重構(gòu)項目，按用戶使用端分了兩期：一期遷移內(nèi)部用戶至新系統(tǒng)，二期遷移外部客戶至新系統(tǒng)（二期啟動時間定在一期任務(wù)全部完成并穩(wěn)定運行3個月之后再開始）。

對于一期計劃我們定了目標(biāo)，分三步走：

1. 第一步：完成v1.0 MVP版本的上線
2. 第二步：接入更多接口和完善更多功能
3. 第三步：新舊系統(tǒng)數(shù)據(jù)同步和用戶遷移

這個系統(tǒng)內(nèi)部的業(yè)務(wù)源頭是任務(wù)申請，有兩個申請入口。一個是系統(tǒng)內(nèi)部的申請入口，一個是從CRM發(fā)起的客戶申請入口，考慮后者涉及外部系統(tǒng)，故不屬于最小化MVP的范圍。

因此第一步 v1.0 版本上線，我們的目標(biāo)，就是跑通一條完整的用戶使用路徑：即從內(nèi)部申請測試任務(wù)開始，到拿到正確的數(shù)據(jù)測試結(jié)果結(jié)束。

PS：界定MVP版本內(nèi)容是十分重要的，v1.0版本無需完美無缺，做到按時上線，后續(xù)能在用戶的反饋下不斷完善是最好的。如一開始就憋了很多大招，不僅拉長了開發(fā)測試的周期，還可能會在后續(xù)的用戶的檢驗中遭遇滑鐵盧，對上線的內(nèi)容進行修改，實在不值。

三、重構(gòu)的全流程

1. 業(yè)務(wù)梳理

作為產(chǎn)品經(jīng)理，如果你接到了重構(gòu)系統(tǒng)的任務(wù)，你需要在盡可能短的時間內(nèi)摸清系統(tǒng)的全部邏輯，除了頁面能看到的邏輯，還需要去了解很多頁面看不到的邏輯。

此外，還要把上下游系統(tǒng)的功能交互和數(shù)據(jù)交互全部理解和走通，知道數(shù)據(jù)是從哪里來，到哪去。

由于老系統(tǒng)年代久遠，歷經(jīng)多個產(chǎn)品和研發(fā)、很多功能的邏輯沒有很明確的文檔留存。

如你跟你的開發(fā)都是新接手系統(tǒng)沒多久，就收到的系統(tǒng)重構(gòu)的任務(wù)。作為產(chǎn)品，你可以帶著你梳理的問題和初步假設(shè)去找研發(fā)，一起查詢了解問題部分的代碼邏輯，從而驗證自己的猜想，同時對齊你們的認知。

這個階段，要盡可能地打通對舊系統(tǒng)認知的盲區(qū)，就像解剖一樣，讓舊系統(tǒng)的骨架和筋脈在腦海中有清晰的認識。

與設(shè)計新系統(tǒng)不同，重構(gòu)系統(tǒng)對兼容性要求高，你需要辯證的去思考每個模塊可優(yōu)化的幅度和上限，在對原始功能、周邊系統(tǒng)、用戶習(xí)慣等多方兼顧的情況下，給出最優(yōu)解。

因此，前期業(yè)務(wù)梳理時考慮的全面很重要，尤其是有流程改造時，我們不能只想到好的一面，也需要想到這次改變可能存在的風(fēng)險和弊端是什么。

2. 用戶調(diào)研

除了你自己發(fā)現(xiàn)的要去改造的地方，真實的用戶需求是肯定要傾聽的。

用戶調(diào)研部分這里我采用了三種方式獲取信息：

1. 日常問題收集
2. 核心用戶訪談
3. 開放問卷調(diào)查

1）日常問題收集

收集日常工作中用戶反饋的系統(tǒng)問題，將問題歸納出來，分析高頻問題是不是可以通過改變產(chǎn)品設(shè)計來避免。

在舊系統(tǒng)維護期間，每天都很多用戶來找我問問題，如：進行中的任務(wù)出現(xiàn)異常、操作哪里走不通報錯了、或是不知怎么操作的咨詢問題。

這些一部分是產(chǎn)品架構(gòu)設(shè)計的問題，一部分是產(chǎn)品交互設(shè)計的問題。一般這種情況都是反復(fù)出現(xiàn)的，如：今天A反饋給你了，你去找研發(fā)解決下；明天B反饋給你，你去找研發(fā)再解決下。

高頻的問題背后就是一個急需解決和重塑的核心痛點，這里雖然沒有被用戶明確提出來，甚至用戶已經(jīng)習(xí)慣了這種“理所當(dāng)然”的操作。但作為產(chǎn)品，你是需要清晰地認識到這里就是最有價值的需求點，也是顛覆老系統(tǒng)產(chǎn)品架構(gòu)的突破點。

2）核心用戶訪談

針對部分核心用戶和業(yè)務(wù)方領(lǐng)導(dǎo)，約時間坐在一起聊一聊。

面對核心用戶，可以針對用戶遇到的問題有更深層次的了解，另外這也是一個很好的機會用于方案初步的溝通，可以問問他們對于你的改造思路有什么看法建議，這對于你在設(shè)計中優(yōu)先級的把控很重要，看看自己和用戶最關(guān)注的重點有沒有偏差。

此外，與業(yè)務(wù)方領(lǐng)導(dǎo)也是有必要坐在一起聊一聊的，畢竟系統(tǒng)重構(gòu)不僅僅是你們自己的事，也關(guān)乎于業(yè)務(wù)方工作效率的提升。你需要讓對方領(lǐng)導(dǎo)知道你的重構(gòu)計劃，能為他們來怎樣的增益？最重要的，是當(dāng)你無法判斷某種方案是否可行時，對方領(lǐng)導(dǎo)可以起到拍板的作用。

簡單來講一句話：多溝通，沒壞處。

3）開放問卷調(diào)查

收集問卷反饋。

經(jīng)過上述的日常問題收集和核心用戶訪談，你能基本了解重構(gòu)中需要改造的地方。

在此情況下我收集的問卷，80%的反饋已經(jīng)在我預(yù)料之中了，但是我仍然建議大家要做這一步，原因有3點：

1. 獲取全量信息最快捷的方式，方便查漏補缺
2. 用戶增強參與感，自己的意見也可以被采納
3. 讓用戶提前知情，后期更好做用戶普及的推廣

問卷作為一種高效的信息收集渠道，不用就虧大了，它可以短時間獲取到所有用戶的對新系統(tǒng)的所有期望，從而可以按相同問題出現(xiàn)的頻率建立新需求開發(fā)的優(yōu)先級，如高頻問題可以優(yōu)先排期解決。

同時也可以讓用戶有一個心理預(yù)期，知道在不久的將來將使用新的系統(tǒng)，這樣像是提前打好招呼一樣，用戶在后期試用新系統(tǒng)的也會有更多的積極性。

3. 原型設(shè)計與評審

新系統(tǒng)的原型需要花費較長時間來完成，建議在開始畫原型之前，可以借助流程圖梳理邏輯，防止跑偏，或沉迷細節(jié)耽誤進度，保證你的思維的連貫性，因此效率也會更高。

此外建議第一版原型要更加認真對待，頁面布局、顏色，交互路徑等，能交代清楚就別一筆帶過。因為大多數(shù)情況，在正式開發(fā)前，都會拉一個大型評審會，邀請兩方領(lǐng)導(dǎo)和用戶代表共同參加，一個拿的出手的原型圖能為你在評審會上增加更多的信心。

建議在評審時，除了拿出設(shè)計方案和原型圖，還要提前準(zhǔn)備好Q&A，也就是針對聽眾最關(guān)注的的地方，提前寫好問題和解決方法，為自己爭取更多的主動性，也會讓對方對你感到放心。

4. 首發(fā)版本上線前后

1）上線前

經(jīng)過了專家原型評審，就可以進行后續(xù)正常的開發(fā)評審了。

在前期盡可能多跟你的研發(fā)團隊溝通對業(yè)務(wù)的看法，設(shè)計初衷是什么、希望解決什么問題，讓研發(fā)在開發(fā)過程中更多理解業(yè)務(wù)，減少因理解偏差出現(xiàn)的bug。

整個開發(fā)過程一般需要1月以上的時間，這段時間產(chǎn)品經(jīng)理要做好項目進度管理的工作，至少做到按周統(tǒng)計進度，開進度會議。

如果這個項目高層領(lǐng)導(dǎo)比較關(guān)注，要定期發(fā)郵件給高層領(lǐng)導(dǎo)同步進度。

2）上線后

這里的上線可以分為兩種：內(nèi)測版上線、對外正式版上線。

內(nèi)測版上線流程走通后，可以邀請幾位種子用戶來體驗新系統(tǒng)，待用戶驗證核心流程跑通無誤后，可以對外宣布正式版上線了。

正式上線后，是1-2個月的試用階段，這個這段期間你需要讓更多的用戶試用新系統(tǒng)，及時暴露各種意想不到的問題，并快速進行迭代修復(fù)。

不過，用戶此時還在舊系統(tǒng)的使用習(xí)慣中，如何讓大家更多地試用新系統(tǒng)呢？這里我使用了三個小技巧：

1. 提供更快的觸達方式（如：免權(quán)限申請）
2. 提供用戶關(guān)心的試用福利（我這里是提供了一定測試量級給用戶）
3. 小窗口邀請用戶（我私聊了80+以上的用戶，邀請體驗新系統(tǒng)，并附上系統(tǒng)說明書）

當(dāng)然在這段時間，你需要一邊關(guān)注用戶反饋，一邊規(guī)劃后續(xù)的任務(wù)，隨時把控時間和進度。

5. 功能迭代如何抉擇

可能大家都希望，新系統(tǒng)等把舊系統(tǒng)所有的功能都補齊了，再開始加用戶提的新功能。

起初我也這么想，但發(fā)現(xiàn)想要吸引用戶的關(guān)注，新功能效果最好。人都有好奇心，如果發(fā)現(xiàn)你有跟之前不一樣的新東西，會更加想去體驗和嘗試。

這一點，也是我與領(lǐng)導(dǎo)溝通后被點撥到的。

最好的辦法就是平衡舊功能與新功能的開發(fā)進度，前提要確定新功能的出現(xiàn)不會與未上線的舊功能有前后順序的嵌套。

比如這次我在重構(gòu)時，考慮到我的用戶群體為各個地區(qū)的多個風(fēng)控團隊，大家通常以組為單位去對接客戶。而老系統(tǒng)任務(wù)申請只能屬于一個人，小組成員無法合作。

在新系統(tǒng)中，我就在首發(fā)版本上線的第二個月加了「小組管理」的功能，組內(nèi)成員互相都可以看到彼此的任務(wù)，也可以共享自己的工單數(shù)量，不光實現(xiàn)了組內(nèi)任務(wù)靈活流轉(zhuǎn)，還實現(xiàn)了各團隊負責(zé)人對團隊內(nèi)部成員工作量和工作內(nèi)容的統(tǒng)計和把控。

這個功能本身與舊功能的沒有必要的嵌套邏輯，上線用戶的反饋非常好，驗證了之前的預(yù)期。這種新舊功能交替開發(fā)的思路，大家可以多思考下。

6. 過程中出了問題怎么辦

一般重構(gòu)的系統(tǒng)上線后，都會收到用戶較好的反饋，畢竟舊系統(tǒng)年久失修，新的系統(tǒng)會讓人眼前一亮。這時候，產(chǎn)品經(jīng)理容易沉浸在對新系統(tǒng)盡善盡美的幻想中，希望新系統(tǒng)的口碑一直保持完美，不允許有任何瑕疵。

然而，你無法避免問題的出現(xiàn)。

在新系統(tǒng)上線后的這段時間，確實是系統(tǒng)相對最不穩(wěn)定的時期，需要不斷發(fā)現(xiàn)問題，修改問題。

作為產(chǎn)品經(jīng)理，要學(xué)會理解新事物發(fā)展的規(guī)律，把解決問題和如何避免后續(xù)問題的發(fā)生放在思考的第一位。

下面三點，是我在走了一些彎路之后才明白的道理：

1. 對問題有包容心（出現(xiàn)問題不重要，重要的是如何解決和避免問題的發(fā)生）
2. 對開發(fā)有信心（與你的開發(fā)站在同一立場上，出現(xiàn)線上bug先給予解決問題的信任）
3. 對用戶有耐心（第一時間安撫用戶，誠懇道歉并說明解決時間）

我記得一個導(dǎo)演說過一句話：這個的片子如果成功了，那一定是大家的功勞；如果失敗了，那一定是我的責(zé)任。

產(chǎn)品經(jīng)理并不是僅僅承擔(dān)產(chǎn)品設(shè)計的工作，更多的還要考慮團隊合作、項目管理等需要考驗軟實力的地方。

而問題矛盾的出現(xiàn)，會更加放大你在這些情況的心態(tài)和應(yīng)對能力，要有大局意識，關(guān)建時候擔(dān)起項目負責(zé)人的責(zé)任，你的團隊成員才會更加信服你。

7. 數(shù)據(jù)同步和用戶遷移

新系統(tǒng)基本功能都與舊系統(tǒng)對齊了，是不是就可以將用戶全部直接切到新系統(tǒng)了？答案是否定的。

用戶遷移到新系統(tǒng)，絕對不能一刀切，要采用平穩(wěn)過渡的方式，逐步替換。

因為老系統(tǒng)的數(shù)據(jù)都是這段時間用戶正在使用的，如果強制切到什么數(shù)據(jù)都沒有的新系統(tǒng)，用戶不炸毛才怪。

況且，我們這次項目分兩期，一期的目標(biāo)是，在外部客戶無感知的情況下，內(nèi)部用戶已經(jīng)全部過渡到了新系統(tǒng)。

可能你會問：外部和內(nèi)部數(shù)據(jù)互通的部分該怎么辦？如何保證之前在舊系統(tǒng)運行的流程？

答案就是——數(shù)據(jù)同步。

數(shù)據(jù)同步可以拆分為3部分：

1. 賬號同步——內(nèi)部賬號和外部賬號由舊系統(tǒng)同步至新系統(tǒng)
2. 賬號關(guān)聯(lián)——新系統(tǒng)的內(nèi)部賬號關(guān)聯(lián)舊系統(tǒng)的內(nèi)部賬號
3. 文件同步——新舊系統(tǒng)產(chǎn)生的文件相互同步

第一步，賬號信息同步

由于外部客戶賬號創(chuàng)建的源頭來自上游CRM系統(tǒng)與舊系統(tǒng)的用戶創(chuàng)建，考慮客戶外部重構(gòu)放在二期，故本期在此節(jié)點保持外部客戶賬號創(chuàng)建源頭不變，僅將客戶賬號、內(nèi)部賬號及相關(guān)信息同步至新系統(tǒng)。

新系統(tǒng)增加「客戶賬號/內(nèi)部賬號」模塊，用于替代舊系統(tǒng)后臺的用戶列表。存量數(shù)據(jù)批量刷進來，增量數(shù)據(jù)保持實時更新。

第二步，將新舊系統(tǒng)的內(nèi)部賬號進行關(guān)聯(lián)

由于用戶都是同一個人，在注冊新系統(tǒng)后，他將擁有新系統(tǒng)和舊系統(tǒng)兩套賬號。

所以，管理員要將同一個內(nèi)部用戶在新舊系統(tǒng)的兩個賬號進行關(guān)聯(lián)映射，保證下一步文件同步的穩(wěn)步實施。

第三步，新舊系統(tǒng)的文件相互同步

為實現(xiàn)外部客戶無感知的內(nèi)部用戶遷移，新舊系統(tǒng)的文件同步非常重要，也是保證無感知效果的關(guān)鍵。

首先確定同步范圍，這里有一個最大化和最小化原則。

• 舊系統(tǒng)同步新系統(tǒng)時要遵循最大化原則。即新系統(tǒng)要在未來替代舊系統(tǒng)，將舊系統(tǒng)產(chǎn)生的全部數(shù)據(jù)完整地同步至新系統(tǒng)，保證用戶所有在舊系統(tǒng)能查到的內(nèi)容在新系統(tǒng)也能查到。
• 新系統(tǒng)同步舊系統(tǒng)要遵循最小化原則。即只同步還在舊系統(tǒng)的外部客戶需要看到的數(shù)據(jù)足夠。如果完全同步，不僅占用資源，還可能讓內(nèi)部用戶無法脫離舊系統(tǒng)。

以上三步的完成，為后續(xù)的「用戶遷移」奠定了基礎(chǔ)。

最后，用戶遷移

因為業(yè)務(wù)流程的原因，需要客戶參與的任務(wù)，都會從CRM申請。因此用戶遷移的最后一步，就是聯(lián)合CRM將上游的任務(wù)從舊系統(tǒng)切換至新系統(tǒng)。因為前面已經(jīng)做好關(guān)聯(lián)，所以CRM來的任務(wù)，都能在新系統(tǒng)的已關(guān)聯(lián)賬號看到。

這樣一來，用戶自然就會主動移步至新系統(tǒng)操作，同時近期產(chǎn)生的數(shù)據(jù)也能新系統(tǒng)都能查到，可以算是“無縫銜接”，不會給用戶造成來回切系統(tǒng)的困擾。

PS：在正式切換的前期要考慮更多的異常情況和應(yīng)對機制。如：在正式上線前，我們采取了一段時間的手動切換，在驗證沒有問題后才決定上線切換。又如：當(dāng)異常情況出現(xiàn)時，可手動將新系統(tǒng)的任務(wù)推回舊系統(tǒng)等等。

8. 小結(jié)

以上就是一期計劃里所有涉及重構(gòu)的關(guān)鍵節(jié)點，可能不同業(yè)務(wù)不同系統(tǒng)之間會有不同，不過核心思路是相通的，都是遵循「平穩(wěn)過渡」原則，盡可能減少用戶的學(xué)習(xí)成本、降低用戶的操作門檻，優(yōu)化業(yè)務(wù)流程，提升用戶綜合體驗。

在用戶遷移至新系統(tǒng)后，老系統(tǒng)也不用立即關(guān)掉。給內(nèi)部用戶一段時間的適應(yīng)期，也能讓內(nèi)部用戶將之前同步至老系統(tǒng)的任務(wù)做完，這樣會讓用戶對系統(tǒng)更有安全感。

四、分享和展望

1. 印象最深的兩件事

1）產(chǎn)品經(jīng)理也可以看代碼

當(dāng)時準(zhǔn)備做自動生成風(fēng)控分析報告，涉及風(fēng)控領(lǐng)域?qū)I(yè)知識，老系統(tǒng)對這個功能無文檔記錄，我跟開發(fā)都不清楚報告中的數(shù)值、比率的生成邏輯是什么。

唯一能參考的就是老系統(tǒng)用python寫的長達數(shù)十頁的代碼，由于需要結(jié)合業(yè)務(wù)知識和風(fēng)控知識去理解，就算開發(fā)自己看也有困難，所以我選擇自己扒代碼。

我當(dāng)時也是想試試，萬一能看懂了呢。后面經(jīng)過認真的梳理，推導(dǎo)和驗證，花了兩天時間終于搞清楚了這里的邏輯，后面給開發(fā)講解的時候還是很有成就感的。

2）意外收獲的點贊

一次偶然發(fā)現(xiàn)，自己的一篇wiki被點贊了很多次，包括兩個部門的VP和一些不認識的人。

這篇文檔是我寫的一個風(fēng)控策略產(chǎn)品的業(yè)務(wù)邏輯簡述，是別的部門在負責(zé)的平臺，因為我的系統(tǒng)即將接入策略產(chǎn)品接口，需要通過對方平臺做調(diào)用中轉(zhuǎn)，為了讓我的研發(fā)能明白風(fēng)控策略的業(yè)務(wù)原理，我寫了一個科普性質(zhì)的文檔給他們看，方便他們理解。沒想到最后竟然被那么多人看過，有些受寵若驚。

2. 未來要做的事

現(xiàn)在一期重構(gòu)的進程已接近尾聲，這個項目已經(jīng)完成了較為復(fù)雜的內(nèi)部用戶遷移部分。實現(xiàn)了階段目標(biāo)，即：內(nèi)部使用端的重構(gòu)和內(nèi)部用戶的遷移。

待系統(tǒng)穩(wěn)定運行3個月后，我們計劃開始二期的客戶使用端重構(gòu)和用戶遷移。

相對內(nèi)部重構(gòu)，外部重構(gòu)的難度會降低很多。因為外部客戶的操作步驟較內(nèi)部少了很多，不涉及核心流程，且新系統(tǒng)的框架已經(jīng)搭建完成，頁面無需重新設(shè)計，只需更換部分功能即可。

后續(xù)考慮的重點將是，“如何做到無感知或低感知的用戶切換”這個點了。

等二期項目完成時，會再跟大家分享經(jīng)驗的，請大家期待。

作者：Fancy劉，現(xiàn)某金融科技公司B端產(chǎn)品經(jīng)理。

本文由@Fancy劉 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)許可，禁止轉(zhuǎn)載。

題圖來自 Unsplash，基于CC0協(xié)議。