近半年多以來一直在做重構(gòu)的項(xiàng)目，從運(yùn)營后臺重構(gòu)，到中臺passport重構(gòu)，最后換了家公司繼續(xù)做純C端的前臺頁面重構(gòu)。踩過很多很多坑，積攢了挺多經(jīng)驗(yàn)，總結(jié)出來準(zhǔn)備產(chǎn)出一篇文章。

主要總結(jié)重構(gòu)項(xiàng)目的前期準(zhǔn)備，前期準(zhǔn)備工作是產(chǎn)品經(jīng)理應(yīng)該投入時間最多的階段，包括了需求調(diào)研、數(shù)據(jù)分析、老系統(tǒng)/老版本邏輯梳理、重構(gòu)版本邏輯定義等等。甚至前期準(zhǔn)備工作決定了重構(gòu)項(xiàng)目的質(zhì)量以及重構(gòu)后的用戶滿意度，本文將各種場景下重構(gòu)項(xiàng)目必不可少的準(zhǔn)備工作抽象出來，以實(shí)例進(jìn)行拆解。

文章較長，其實(shí)濃縮出來也就一張圖，下面所有內(nèi)容都是對這張圖的注釋：

一、評估重構(gòu)價值

關(guān)于重構(gòu)項(xiàng)目，本人有一個核心觀念：重構(gòu)項(xiàng)目一定是在填歷史遺留的坑。當(dāng)老板發(fā)現(xiàn)系統(tǒng)不足以支撐業(yè)務(wù)發(fā)展，或者嚴(yán)重阻礙業(yè)務(wù)發(fā)展時，“重構(gòu)”的需求就開始從中高層醞釀起來。

比如之前規(guī)劃后臺時沒有一個好的架構(gòu)師，沒有預(yù)想到后面的業(yè)務(wù)發(fā)展和業(yè)務(wù)形態(tài)變化，十幾個運(yùn)營后臺堆起來，運(yùn)營操作一個流程需要頻繁切換多個后臺才能完成，這時候運(yùn)營的老大會噴設(shè)計這些亂七八糟后臺的人，同時也會提出“統(tǒng)一運(yùn)營后臺”的需求，具體需求為：“所有運(yùn)營操作集成到一個后臺，流程能簡化的全部簡化。”

需求就這么一句話，拆解起來就得看具體有多少后臺了（產(chǎn)品背鍋原因之一：業(yè)務(wù)側(cè)需求不明確，一句話需求）。如果說只有三五個分別控制不同模塊的后臺，并且不太復(fù)雜，建議不要重構(gòu)，而是應(yīng)該在做第六個后臺時候考慮到后面的業(yè)務(wù)發(fā)展場景，做一個高擴(kuò)展性的后臺，然后再陸續(xù)將前五個容納到這個后臺來。如果有十幾個后臺，并且其中耦合了大量的交叉邏輯，那么只有重構(gòu)一條路可走。

（產(chǎn)品也不易，背鍋且珍惜）

“重構(gòu)”需求大多是自上而下的需求，管理層出于對各種原因的考慮，提出重構(gòu)的需求。作為基層產(chǎn)品經(jīng)理，需要有自己的判斷，到底是“重構(gòu)”更好還是“優(yōu)化”更佳。

評估重構(gòu)價值需要先明確重構(gòu)的原因，一般而言重構(gòu)只有以下四類原因：

• 用戶變了：之前產(chǎn)品的用戶畫像與現(xiàn)在的用戶畫像發(fā)生了較大的變化，用戶屬性也發(fā)生了改變，新用戶不斷涌入，老用戶流失嚴(yán)重。這種場景下領(lǐng)導(dǎo)層可能會放棄部分老用戶，專耕新用戶，針對新用戶屬性進(jìn)行重構(gòu)/大改版的產(chǎn)品設(shè)計。
• 需求變了：一般內(nèi)部系統(tǒng)的重構(gòu)都?xì)w結(jié)于此原因，之前需求都實(shí)現(xiàn)了，只是擴(kuò)展性不夠，考慮的場景不夠多，現(xiàn)在用起來非常不方便，阻礙了業(yè)務(wù)發(fā)展，因此需求從原來的“可用”升級到“便捷地用”。
• 目標(biāo)變了：不同產(chǎn)品在不同階段有不同目標(biāo)，產(chǎn)品生命周期更迭中自然伴隨著目標(biāo)的變化，可能前期主要提升用戶體驗(yàn)，做大流量，中期又以變現(xiàn)為目標(biāo)，后期開始做留存和老用戶召回，或者做品牌升級。往往在產(chǎn)品生命周期后期容易出現(xiàn)重構(gòu)的需求，試圖用重構(gòu)版本賦予產(chǎn)品新的生命周期。
• 環(huán)境變了：這個環(huán)境包括技術(shù)環(huán)境和市場環(huán)境。技術(shù)革新帶來新的想象空間，迫切期望使用新技術(shù)打造新產(chǎn)品來沖擊市場。市場之前青睞的某種產(chǎn)品形態(tài)，現(xiàn)在已經(jīng)落伍了，需要重新定位產(chǎn)品來跟上時代的步伐。這兩種場景下的重構(gòu)需求往往需要謹(jǐn)慎，到底是“重構(gòu)”還是“新做”一個產(chǎn)品？

還有一種常見的原因：年久失修。不管用戶還在不在，領(lǐng)導(dǎo)層決心再撿起來做的話，老代碼老邏輯的維護(hù)成本遠(yuǎn)高于重構(gòu)一番。此時請一定好好善待那些不離不棄的老用戶，他們很可能因?yàn)橹貥?gòu)沒有契合他們的習(xí)慣就走掉了，臨走前還要噴你一頓：“改的什么玩意兒！”。

(改版后的B站-UI&布局整體調(diào)整)

根據(jù)重構(gòu)原因，評估重構(gòu)能夠帶來的價值，同時評估正常迭代能帶來的價值，當(dāng)“重構(gòu)價值>迭代價值”時，“重構(gòu)”需求才能接手，否則可能就是“瞎重構(gòu)”，或者重構(gòu)完了也沒人愿意用。

那么如何評估重構(gòu)價值？

這是一個需要量化的多維度指標(biāo)，可能是節(jié)省了運(yùn)營多少人天的工時，可能是提升了用戶留存，可能是提高了某個核心指標(biāo)等等。在這些重構(gòu)帶來好處的維度指標(biāo)中，選擇最為核心的一點(diǎn)或者亮點(diǎn)，作為重構(gòu)的核心目標(biāo)。

例如統(tǒng)一運(yùn)營后臺，核心目標(biāo)就是節(jié)省運(yùn)營工時；統(tǒng)一中臺化服務(wù)，就是節(jié)省前臺開發(fā)工時；C端產(chǎn)品重構(gòu)，就是為了拉升某個核心指標(biāo)。

二、重構(gòu)前期準(zhǔn)備

作為產(chǎn)品經(jīng)理，在做“重構(gòu)”項(xiàng)目時，其實(shí)最重要的就兩個詞：梳理和定義，梳理舊的邏輯，定義新的邏輯。無論是后臺、中臺還是前臺相關(guān)的重構(gòu)，基本上大同小異，都可以按照下面的方法去操作。

其中，后臺和中臺大多數(shù)還是給公司內(nèi)部人使用，重構(gòu)得不是很好還有機(jī)會繼續(xù)迭代優(yōu)化，而前臺ToC的產(chǎn)品重構(gòu)，做得不好可能就得承擔(dān)用戶血噴甚至流失的壓力，同時前臺的重構(gòu)一定會涉及到后臺或中臺的調(diào)整。因此，本文以重構(gòu)壓力和產(chǎn)品發(fā)揮空間最大的ToC前臺為例進(jìn)行說明。

產(chǎn)品確定要進(jìn)行重構(gòu)之后，立即新建兩個文檔，一個調(diào)研文檔，用來輔助產(chǎn)品設(shè)計，一個需求文檔，逐漸更新為最終輸出的PRD。同時，需要督促開發(fā)也新建技術(shù)文檔，對核心重構(gòu)內(nèi)容進(jìn)行技術(shù)調(diào)研，對于初步明確的大方向提前做好技術(shù)準(zhǔn)備，減少開發(fā)說“這個實(shí)現(xiàn)不了”的概率。

調(diào)研文檔必須包含的六個版塊：舊版拆解、數(shù)據(jù)分析、用戶畫像、競品分析、需求池、重構(gòu)目標(biāo)。六塊少了任何一部分，我認(rèn)為都會對產(chǎn)品方案的制定產(chǎn)生影響，也會對最終的重構(gòu)效果產(chǎn)生影響。

1. 舊版拆解

無論舊版是不是你做的，只要是重構(gòu)，一定要詳細(xì)拆解舊版，拆得越細(xì)越好。一般重構(gòu)項(xiàng)目，可參考的歷史文檔都非常有限，即使有文檔也最好自己親自細(xì)細(xì)體驗(yàn)。拆解舊版最終要產(chǎn)出的四個東西：頁面結(jié)構(gòu)圖、前臺與中后臺交互的流程圖、交互說明文檔（關(guān)系到后面的繼承性產(chǎn)品設(shè)計）和特殊處理說明。

• 頁面結(jié)構(gòu)圖并不難，屬于產(chǎn)品基本功，列出結(jié)構(gòu)才能明確重構(gòu)范圍具體到哪些頁面和哪些細(xì)小的點(diǎn)，顆粒度越細(xì)越好。
• 信息交互的流程圖是拆解的核心，產(chǎn)品的功力體現(xiàn)在這一步。理想的產(chǎn)出流程圖需覆蓋用戶操作行為的每一步請求與中后臺的信息交互，這需要產(chǎn)品知道目前老版頁面所調(diào)的所有接口、調(diào)用順序、接口限制條件（能有接口文檔最佳）等等。這里最好找個后端開發(fā)協(xié)助一起，理清了所有的接口才能確定哪些接口復(fù)用，哪些需要改造，后續(xù)產(chǎn)品方案需要新增哪些接口，后端開發(fā)也能更加清晰評估自己的開發(fā)量和開發(fā)難度。
• 交互說明文檔：常聽到的“反人類的設(shè)計”基本都是罵交互，重構(gòu)項(xiàng)目的舊版拆解中，需要記錄舊版核心流程上的所有交互操作，比如提交按鈕、翻頁器、提示框、無限加載、手勢動作、隱藏和露出等。在之后的數(shù)據(jù)分析中來決斷哪些交互行為一定要保留或者只能微調(diào)，因?yàn)檫@些強(qiáng)用戶習(xí)慣的操作一時間很難改變，只能在后續(xù)的迭代中陸續(xù)微調(diào)。比如：習(xí)慣了手指左滑翻頁，或者翻頁器翻頁，改版成上滑無限加載，絕對找噴。
• 特殊處理說明：舊版的特殊處理不一定完全能拆解出來，因?yàn)橛械奶厥馓幚砗茈y看出來。這些特殊處理都是代碼寫死的邏輯，最好能分析出為什么做特殊處理，不是懶就是有特殊的限制原因，提醒你這里有坑需謹(jǐn)慎，重構(gòu)版本就盡量減少特殊處理的邏輯。

（虎撲M站改版前后對比）

2. 數(shù)據(jù)分析

曾經(jīng)一位開發(fā)對我提的老版本加上埋點(diǎn)的需求不以為然，認(rèn)為都要重構(gòu)的東西了，沒必要在老版本上面加埋點(diǎn)。我列了三條理由說服了開發(fā)加埋點(diǎn)：

1. 改版效果需要用數(shù)據(jù)說話，新版本會加埋點(diǎn)，會有數(shù)據(jù)，但是老版本沒有，那么核心的數(shù)據(jù)指標(biāo)無法對比，也就無法衡量改版是否成功；
2. 我對ABC功能點(diǎn)存在一些想法，想直接砍掉其中某些功能，或者對一些功能做一個較為大的改動，想要了解老版本這個功能點(diǎn)目前的用戶使用情況，如果很少人用，直接砍掉，新版你們開發(fā)也省事兒（說話的時候也要站在開發(fā)的角度思考）；
3. 我們的用戶長什么樣我們現(xiàn)在都不清楚，不加埋點(diǎn)來看的話，改版就是“瞎撞”。我需要知道較為清晰的用戶畫像，至少知道誰在用我們產(chǎn)品，才好制定合理的產(chǎn)品方案，才不會給你們開發(fā)提需求，每個需求點(diǎn)都有理有據(jù)。

用實(shí)例進(jìn)一步解釋這三條理由，假如知乎文章發(fā)布頁重構(gòu)，首先確定一個核心數(shù)據(jù)指標(biāo)，假定為發(fā)布成功率。那么需要知道老版本的這個數(shù)據(jù)是多少，重構(gòu)版本與此對比來看改版效果（這里還需要限制約束條件：在發(fā)帖頁平均UV波動不超過5%的前提下）。

其次，分析功能點(diǎn)，假如數(shù)據(jù)分析發(fā)現(xiàn)用戶在上傳視頻的時候有5%的概率的失敗，失敗后又重新傳，那么新版斷點(diǎn)續(xù)傳的功能優(yōu)先級很高，同時進(jìn)一步分析失敗原因，新版要大幅降低這個值。

3. 用戶畫像

用戶畫像簡單說就是給用戶打標(biāo)簽，用戶是男是女，喜歡什么東西，什么時候活躍，活躍時候都看了些什么。無論是在做什么項(xiàng)目，了解用戶畫像都很有必要。可能在重構(gòu)項(xiàng)目期間，產(chǎn)品經(jīng)理不清楚用戶畫像也能很好地完成重構(gòu)項(xiàng)目，但是了解用戶畫像的產(chǎn)品經(jīng)理思考的深度和視野的廣度都遠(yuǎn)甚于前者，換句話說：了解用戶畫像能讓產(chǎn)品經(jīng)理逼格上升一個檔次。

曾經(jīng)有一位前輩看過我寫的需求文檔之后，給我提出了一些指導(dǎo)建議，其中有一條是：“可以在需求文檔或者其他地方專門寫一個部分——幫助運(yùn)營做得更好”。

前輩的意思是產(chǎn)品在進(jìn)行方案設(shè)計時候，也應(yīng)該站在運(yùn)營的角度去思考，如何能夠幫助運(yùn)營更好地開展工作或者提高效率。隨著經(jīng)驗(yàn)的積累和閱歷的增長，發(fā)現(xiàn)不僅是站在運(yùn)營的角度，還需要站在更多人的角度以及更高層次的視野去看待產(chǎn)品設(shè)計。

這里的提升就不得不清晰地了解用戶畫像，因?yàn)橛脩舢嬒裰饕δ苡兴膫€：精準(zhǔn)營銷、廣告投放、個性化推薦、輔助產(chǎn)品設(shè)計。在做產(chǎn)品設(shè)計的時候，如果能將前面三者都思考在內(nèi)，雖然做出來的東西可能差別不大，但是境界和視野的差距可見一斑。

將用戶畫像運(yùn)用得最好的一個產(chǎn)品我認(rèn)為是虎撲，用戶畫像非常清晰：20-35歲的男性，以大學(xué)生和上班族為主，喜歡籃球，熱愛運(yùn)動，喜歡以實(shí)力論英雄。這樣的用戶被定義為“直男”。圍繞“直男”做球鞋球衣廣告投放、做蔡徐坤相關(guān)內(nèi)容營銷、推薦評分投票帖等?；涞漠a(chǎn)品體驗(yàn)并不算好，但是圍繞“直男”的運(yùn)營做得在國內(nèi)確實(shí)無出其右。

（知乎的用戶畫像-來自：https://zhuanlan.zhihu.com/p/59935630）

4. 競品分析

這也是產(chǎn)品經(jīng)理的基本功，在此不做詳細(xì)描述，但是提醒兩點(diǎn)：

避免沒有結(jié)論的功能點(diǎn)羅列：這是最常見的競品分析誤區(qū)，一定要有自己的分析結(jié)論，競品在做什么——他們?yōu)槭裁催@么做——我在做什么——我應(yīng)該怎么做。

不要只關(guān)注頁面結(jié)構(gòu)和前端交互，多注意一些細(xì)節(jié)和隱藏功能。比如知乎的文章發(fā)布頁，上傳圖片可以選擇本地，還可以直接復(fù)制圖片到編輯器中，而復(fù)制進(jìn)去的圖片是直接上傳云端的，展示出來的就是知乎域下的圖片，而虎撲的發(fā)帖頁編輯器中復(fù)制圖片是直接base64解析的原圖地址，并未執(zhí)行上傳云端操作。

5. 需求池

在體驗(yàn)老版本的時候經(jīng)常會發(fā)現(xiàn)一些問題，記錄下來，可能是一些功能bug，可能是一些細(xì)節(jié)的紕漏，甚至可能是一些提示文案等。但是僅自己體驗(yàn)后記錄的需求遠(yuǎn)遠(yuǎn)不夠，一定會存在很多遺漏的點(diǎn)，以下有三條經(jīng)驗(yàn)可供參考：

1. 公司內(nèi)部發(fā)起調(diào)研，經(jīng)常使用老版本的公司內(nèi)部人員會給出很多優(yōu)化建議；
2. 對用戶發(fā)起調(diào)研，邀請一批高活躍用戶拉群或者面聊（沙龍形式），或者用廣撒網(wǎng)的形式發(fā)調(diào)研問卷；
3. 需求方的想法和建議，需求方可能是領(lǐng)導(dǎo)或者高層，溝通前做好功課，這一步很有必要，避免出現(xiàn)重構(gòu)產(chǎn)出與需求方預(yù)期相差太遠(yuǎn)的問題。

需求池建立后開始做篩選工作，第一步先篩出來接受的需求，有些不合理的需求直接pass。在接受的需求池中，標(biāo)注好每一條的優(yōu)先級，以及解決方案，按照優(yōu)先級制定重構(gòu)版本需求范圍和重構(gòu)后迭代版本的迭代規(guī)劃，而解決方案則落實(shí)到需求文檔中。

下圖為一個較大重構(gòu)項(xiàng)目的原始需求池，未經(jīng)篩選和標(biāo)注優(yōu)先級，小圓圈內(nèi)的數(shù)字代表需求條數(shù)。

（某重構(gòu)項(xiàng)目搜集的需求池）

6. 重構(gòu)目標(biāo)

重構(gòu)目標(biāo)不是將產(chǎn)品做出來，而是數(shù)據(jù)層面達(dá)到怎樣的水平。重構(gòu)目標(biāo)需要具體可量化，而不是模糊的“提升用戶體驗(yàn)”。

【反面示例】

改版目標(biāo)：通過改版內(nèi)容詳情頁，提升用戶體驗(yàn)，給用戶更好的閱讀體驗(yàn)。

目標(biāo)解讀：首先不夠具體，“提升用戶體驗(yàn)”范圍太大，其次沒有量化，“更好的閱讀體驗(yàn)”如何用數(shù)據(jù)衡量？

【正面示例】

改版目標(biāo)：通過改版內(nèi)容詳情頁，在詳情頁訪問UV波動不超過5%的前提下，將PV/UV提升10%

目標(biāo)解讀：明確了改版后重點(diǎn)看的數(shù)據(jù)指標(biāo)PV/UV，反應(yīng)單個用戶對于內(nèi)容的沉浸程度。有約束條件：新版總體UV相較老版波動不超過5%。因此，針對這個目標(biāo)設(shè)計內(nèi)容詳情頁，可以考慮增加詳情頁里面的關(guān)聯(lián)內(nèi)容推薦、優(yōu)化互動模式和通知提醒等，以達(dá)到新版讓用戶更多地訪問到內(nèi)容詳情頁。

總之，在一些目標(biāo)導(dǎo)向的公司，有一個清晰的重構(gòu)目標(biāo)，有利于產(chǎn)品的設(shè)計，也容易出成果。如果能再增加一些行業(yè)數(shù)據(jù)或者競品數(shù)據(jù)進(jìn)行對標(biāo)，那么在寫績效總結(jié)的時候絕對是一大亮點(diǎn)。

完成了以上調(diào)研文檔的六個步驟，再來看需求文檔其實(shí)就已經(jīng)很清晰了。按照各自業(yè)務(wù)場景和調(diào)研文檔的結(jié)論進(jìn)行設(shè)計，在前面調(diào)研文檔很清晰的情況下，需求文檔的撰寫應(yīng)該是相對水到渠成的事情。可以在調(diào)研文檔進(jìn)行的同時將已經(jīng)明確的改版方案細(xì)節(jié)列在需求文檔中，不斷擴(kuò)充和積累之后，需求文檔也相對趨于完善。

唯一要注意的一點(diǎn)：繼承性產(chǎn)品設(shè)計，千萬不能一次性大幅改變用戶的操作習(xí)慣，否則后果自負(fù)。

三、中期策略

“重構(gòu)”項(xiàng)目產(chǎn)品經(jīng)理的工作70%的精力在前期的梳理與定義，需求評審?fù)瓿珊缶完懤m(xù)跟進(jìn)視覺稿、開發(fā)和測試，有不明確的地方相關(guān)方會再來找你確認(rèn)，如果你文檔夠細(xì)，評審夠清晰，這種不明確的詢問就會相對較少。

在項(xiàng)目開發(fā)中，其實(shí)產(chǎn)品經(jīng)理很多時候還會兼任項(xiàng)目經(jīng)理的職責(zé)，一般而言總會出現(xiàn)一些臨時需求和緊急需求需要占用開發(fā)資源，如果影響項(xiàng)目進(jìn)展的話，這時候產(chǎn)品經(jīng)理需要做出權(quán)衡，哪些是一定要在DDL前完成，哪些可以先灰度后再迭代加上，合理把控好整體的項(xiàng)目節(jié)奏。

在開發(fā)提測之后，我認(rèn)為項(xiàng)目才開始進(jìn)入到中期，中期主要講究策略，如何讓用戶更自然和更樂意地接受新版的策略。

我個人總結(jié)的策略分為三部分：灰度策略、選擇頁策略、溝通策略?？傮w思路為灰度放量進(jìn)到選擇頁，選擇頁篩出愿意體驗(yàn)新版的用戶，對反饋強(qiáng)烈的用戶拉群溝通。

1. 灰度策略

灰度的目的是為了降低產(chǎn)品BUG風(fēng)險，試驗(yàn)新版本和新交互的用戶反饋，在數(shù)據(jù)層面上對新版功能、性能、穩(wěn)定性、兼容性等指標(biāo)進(jìn)行評價，在灰度期間不斷迭代優(yōu)化新版，以達(dá)到較為完善的用戶體驗(yàn)后全量上線。

灰度上線策略可以很簡單，但是一般發(fā)布會比較復(fù)雜，產(chǎn)品經(jīng)理可以在定義合適的灰度策略之后與開發(fā)溝通是否可行，若不可行可調(diào)整為怎樣的策略。

最常見的兩個灰度策略大類就是定量和定時間，定量為篩選一部分屬性的用戶進(jìn)入新版本或者直接設(shè)置前x萬的訪問進(jìn)到新版（注意爬蟲的量），定時間則是簡單粗暴地開放某個時間段訪問全部進(jìn)到新版。在新版的設(shè)計中需要增加“返回原版”的入口，支持用戶手動回到舊版。

示例：

• 灰度策略示例：每天新增前3萬用戶訪問到新的首頁（爬蟲會爬去2萬，實(shí)際每天灰度1萬用戶），先持續(xù)7天看效果，灰度期間迭代節(jié)奏為一周一個版本，將用戶集中反饋的問題迅速解決掉。
• 灰度實(shí)現(xiàn)示例：后端下發(fā)cookie判斷是否切換到新版本，cookie字段為A，下發(fā)cookie后重定向當(dāng)前頁面。前端確保新版和老版的JS和CSS路徑?jīng)]有問題。運(yùn)維通過cookie進(jìn)行新老版本機(jī)器切換，如果cookie有A字段，且A字段為1時（1代表新版，0代表舊版），轉(zhuǎn)發(fā)到新版的服務(wù)上。

2. 選擇頁策略

多數(shù)用戶相對比較排斥改版/重構(gòu)，會影響他們本身的使用習(xí)慣。選擇頁策略則是在灰度策略之后，給命中灰度策略的用戶展示中間頁，在中間頁給用戶說明改版的原因和改版功能點(diǎn)，讓用戶自主選擇體驗(yàn)新版還是回到原版。

（虎撲M站在進(jìn)行灰度時的中間頁）

3. 溝通策略

溝通是產(chǎn)品經(jīng)理的強(qiáng)項(xiàng)技能之一，不僅對內(nèi)對接開發(fā)設(shè)計測試等，對外對接用戶也應(yīng)該展現(xiàn)很強(qiáng)的溝通能力。

重構(gòu)/改版一定會遇到用戶側(cè)的阻力，改版不當(dāng)很可能用戶就再也不見了?；叶壬暇€后一定要做好用戶反饋搜集，可以考慮在新版懸浮一個新版反饋的入口?；叶绕陂g就是不斷迭代的過程，將用戶反饋的點(diǎn)列表記錄，制定解決方案，排定優(yōu)先級。

重構(gòu)/改版后有人噴是好事兒，說明還有用戶在用，對產(chǎn)品還有期待。真正可怕的是改版后用戶一聲不吭地直接走了。對于愿意反饋的用戶可以考慮聯(lián)系用戶，拉群溝通，沒有什么問題是溝通無法解決的，只要把用戶真心放在第一位，尊重用戶的反饋，改版阻力會大大減少。甚至可以考慮對一些忠實(shí)用戶做認(rèn)證標(biāo)簽，比如”熱心XX“，這對于忠實(shí)用戶是一個非常有效的激勵。

四、后期跟進(jìn)

中期灰度發(fā)布，逐步迭代完善后趨近于最終的產(chǎn)品形態(tài)，接著就可以全量替換上線了。其實(shí)到這里產(chǎn)品經(jīng)理針對這個項(xiàng)目的核心工作基本上已經(jīng)結(jié)束了，但是好產(chǎn)品永遠(yuǎn)是打磨出來的。

以全量上線的版本為x.0版本，持續(xù)關(guān)注數(shù)據(jù)和可優(yōu)化的點(diǎn)，積攢一段時間后再進(jìn)行迭代優(yōu)化。這個時候的產(chǎn)品相對比較穩(wěn)定，可以使用A/B測試、MVT測試等方法打磨產(chǎn)品。前端對于加載性能優(yōu)化，后端對于響應(yīng)速度升級等，都是在迭代過程中可以重點(diǎn)去提升的方面。

大多數(shù)情況隨著項(xiàng)目結(jié)束，產(chǎn)品趨于穩(wěn)定，同時又有新的項(xiàng)目接手，根本無暇顧及已經(jīng)全量上線的新版本。

這無關(guān)痛癢，但是有心的產(chǎn)品會把自己做的每一個項(xiàng)目做到盡善盡美，將每一個可以優(yōu)化的點(diǎn)記錄下來，在后面當(dāng)開發(fā)有空閑時間時安插需求，當(dāng)開發(fā)看到一個用心做產(chǎn)品的伙伴，不會拒絕的。

作者：全導(dǎo)，微信公眾號：零向度（lingxiangdu）

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

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