2023年B端產(chǎn)品經(jīng)理如何操盤系統(tǒng)重構(gòu)

B端產(chǎn)品經(jīng)理，如何操盤系統(tǒng)重構(gòu)一、重構(gòu)背景

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

1）系統(tǒng)簡介

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

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

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

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

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

2）用戶特點(diǎn)

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

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

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

2.重構(gòu)緣由

1）內(nèi)因

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

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

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

2）外因

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

賬號權(quán)限體系簡單，有局限性，新用戶學(xué)習(xí)成本高功能設(shè)計(jì)過于保守，特別頻出，用戶反饋糟糕頁面與交互落后，操作信息不清楚，用戶體驗(yàn)差因此，本次重構(gòu)是由內(nèi)到外的重構(gòu)，從核心的底層性能到用戶有感知功能流程進(jìn)行的整體重塑。

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

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

3.團(tuán)隊(duì)歷時(shí)

參加整個(gè)項(xiàng)目主要的開發(fā)測試成員有5位，均沒有系統(tǒng)重構(gòu)的相關(guān)閱歷。

產(chǎn)品：1人后端：2人前端：1人測試：1人備注：UI屬于公共資源，設(shè)計(jì)了初版系統(tǒng)界面。

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

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

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

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

第一步：完成v1.0MVP版本的上線其次步：接入更多接口和完善更多功能第三步：新舊系統(tǒng)數(shù)據(jù)同步和用戶遷移這個(gè)系統(tǒng)內(nèi)部的業(yè)務(wù)源頭是任務(wù)申請，有兩個(gè)申請入口。一個(gè)是系統(tǒng)內(nèi)部的申請入口，一個(gè)是從CRM發(fā)起的客戶申請入口，考慮后者涉及外部系統(tǒng)，故不屬于最小化MVP的范圍。

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

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

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

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

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

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

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

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

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

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

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

2.用戶調(diào)研

除了你自己發(fā)覺的要去改造的地方，真實(shí)的用戶需求是確定要傾聽的。

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

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

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

在舊系統(tǒng)維護(hù)期間，每天都許多用戶來找我問問題，如：進(jìn)行中的任務(wù)消失特別、操作哪里走不通報(bào)錯了、或是不知怎么操作的詢問問題。

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

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

2）核心用戶訪談

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

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

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

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

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

收集問卷反饋。

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

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

獵取全量信息最快捷的方式，便利查漏補(bǔ)缺用戶增加參加感，自己的看法也可以被接受讓用戶提前知情，后期更好做用戶普及的推廣問卷作為一種高效的信息收集渠道，不用就虧大了，它可以短時(shí)間獵取到全部用戶的對新系統(tǒng)的全部期望，從而可以按相同問題消失的頻率建立新需求開發(fā)的優(yōu)先級，如高頻問題可以優(yōu)先排期解決。

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

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

新系統(tǒng)的原型需要花費(fèi)較長時(shí)間來完成，建議在開頭畫原型之前，可以借助流程圖梳理規(guī)律，防止跑偏，或沉迷細(xì)節(jié)耽擱進(jìn)度，保證你的思維的連貫性，因此效率也會更高。

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

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

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

1）上線前

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

在前期盡可能多跟你的研發(fā)團(tuán)隊(duì)溝通對業(yè)務(wù)的看法，設(shè)計(jì)初衷是什么、盼望解決什么問題，讓研發(fā)在開發(fā)過程中更多理解業(yè)務(wù)，削減因理解偏差消失的bug。

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

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

2）上線后

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

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

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

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

供應(yīng)更快的觸達(dá)方式（如：免權(quán)限申請）供應(yīng)用戶關(guān)懷的試用福利（我這里是供應(yīng)了肯定測試量級給用戶）小窗口邀請用戶（我私聊了80+以上的用戶，邀請?bào)w驗(yàn)新系統(tǒng)，并附上系統(tǒng)說明書）當(dāng)然在這段時(shí)間，你需要一邊關(guān)注用戶反饋，一邊規(guī)劃后續(xù)的任務(wù)，隨時(shí)把控時(shí)間和進(jìn)度。

5.功能迭代如何選擇

可能大家都盼望，新系統(tǒng)等把舊系統(tǒng)全部的功能都補(bǔ)齊了，再開頭加用戶提的新功能。

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

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

最好的方法就是平衡舊功能與新功能的開發(fā)進(jìn)度，前提要確定新功能的消失不會與未上線的舊功能有前后挨次的嵌套。

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

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

這個(gè)功能本身與舊功能的沒有必要的嵌套規(guī)律，上線用戶的反饋特別好，驗(yàn)證了之前的預(yù)期。這種新舊功能交替開發(fā)的思路，大家可以多思索下。

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

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

然而，你無法避開問題的消失。

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

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

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

對問題有包涵心（消失問題不重要，重要的是如何解決和避開問題的發(fā)生）對開發(fā)有信念（與你的開發(fā)站在同一立場上，消失線上bug先賜予解決問題的信任）對用戶有急躁（第一時(shí)間安撫用戶，懇切賠禮并說明解決時(shí)間）我記得一個(gè)導(dǎo)演說過一句話：這個(gè)的片子假如勝利了，那肯定是大家的功勞；假如失敗了，那肯定是我的責(zé)任。

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

而問題沖突的消失，會更加放大你在這些狀況的心態(tài)和應(yīng)對力量，要有大局意識，關(guān)建時(shí)候擔(dān)起項(xiàng)目負(fù)責(zé)人的責(zé)任，你的團(tuán)隊(duì)成員才會更加信服你。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

舊系統(tǒng)同步新系統(tǒng)時(shí)要遵循最大化原則。即新系統(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)操作，同時(shí)近期產(chǎn)生的數(shù)據(jù)也能新系統(tǒng)都能查到，可以算是“無縫連接”，不會給用戶造成來回切系統(tǒng)的困擾。

PS：在正式切換的前期要考慮更多的特別狀況和應(yīng)對機(jī)制。如：在正式上線前，我們實(shí)行了一段時(shí)間的手動切換，在驗(yàn)證沒有問題后才打算上線切換。又如：當(dāng)特別狀況消失時(shí)，可手動將新系統(tǒng)的任務(wù)推回舊系統(tǒng)等等。

8.小結(jié)

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

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

四、共享和展望

1.印