中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

近半年多以來一直在做重構的項目，從運營后臺重構，到中臺passport重構，最后換了家公司繼續做純C端的前臺頁面重構。踩過很多很多坑，積攢了挺多經驗，總結出來準備產出一篇文章。

主要總結重構項目的前期準備，前期準備工作是產品經理應該投入時間最多的階段，包括了需求調研、數據分析、老系統/老版本邏輯梳理、重構版本邏輯定義等等。甚至前期準備工作決定了重構項目的質量以及重構后的用戶滿意度，本文將各種場景下重構項目必不可少的準備工作抽象出來，以實例進行拆解。

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

一、評估重構價值

關于重構項目，本人有一個核心觀念：重構項目一定是在填歷史遺留的坑。當老板發現系統不足以支撐業務發展，或者嚴重阻礙業務發展時，“重構”的需求就開始從中高層醞釀起來。

比如之前規劃后臺時沒有一個好的架構師，沒有預想到后面的業務發展和業務形態變化，十幾個運營后臺堆起來，運營操作一個流程需要頻繁切換多個后臺才能完成，這時候運營的老大會噴設計這些亂七八糟后臺的人，同時也會提出“統一運營后臺”的需求，具體需求為：“所有運營操作集成到一個后臺，流程能簡化的全部簡化?！?/p>

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

（產品也不易，背鍋且珍惜）

“重構”需求大多是自上而下的需求，管理層出于對各種原因的考慮，提出重構的需求。作為基層產品經理，需要有自己的判斷，到底是“重構”更好還是“優化”更佳。

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

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

還有一種常見的原因：年久失修。不管用戶還在不在，領導層決心再撿起來做的話，老代碼老邏輯的維護成本遠高于重構一番。此時請一定好好善待那些不離不棄的老用戶，他們很可能因為重構沒有契合他們的習慣就走掉了，臨走前還要噴你一頓：“改的什么玩意兒！”。

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

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

那么如何評估重構價值？

這是一個需要量化的多維度指標，可能是節省了運營多少人天的工時，可能是提升了用戶留存，可能是提高了某個核心指標等等。在這些重構帶來好處的維度指標中，選擇最為核心的一點或者亮點，作為重構的核心目標。

例如統一運營后臺，核心目標就是節省運營工時；統一中臺化服務，就是節省前臺開發工時；C端產品重構，就是為了拉升某個核心指標。

二、重構前期準備

作為產品經理，在做“重構”項目時，其實最重要的就兩個詞：梳理和定義，梳理舊的邏輯，定義新的邏輯。無論是后臺、中臺還是前臺相關的重構，基本上大同小異，都可以按照下面的方法去操作。

其中，后臺和中臺大多數還是給公司內部人使用，重構得不是很好還有機會繼續迭代優化，而前臺ToC的產品重構，做得不好可能就得承擔用戶血噴甚至流失的壓力，同時前臺的重構一定會涉及到后臺或中臺的調整。因此，本文以重構壓力和產品發揮空間最大的ToC前臺為例進行說明。

產品確定要進行重構之后，立即新建兩個文檔，一個調研文檔，用來輔助產品設計，一個需求文檔，逐漸更新為最終輸出的PRD。同時，需要督促開發也新建技術文檔，對核心重構內容進行技術調研，對于初步明確的大方向提前做好技術準備，減少開發說“這個實現不了”的概率。

調研文檔必須包含的六個版塊：舊版拆解、數據分析、用戶畫像、競品分析、需求池、重構目標。六塊少了任何一部分，我認為都會對產品方案的制定產生影響，也會對最終的重構效果產生影響。

1. 舊版拆解

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

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

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

2. 數據分析

曾經一位開發對我提的老版本加上埋點的需求不以為然，認為都要重構的東西了，沒必要在老版本上面加埋點。我列了三條理由說服了開發加埋點：

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

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

其次，分析功能點，假如數據分析發現用戶在上傳視頻的時候有5%的概率的失敗，失敗后又重新傳，那么新版斷點續傳的功能優先級很高，同時進一步分析失敗原因，新版要大幅降低這個值。

3. 用戶畫像

用戶畫像簡單說就是給用戶打標簽，用戶是男是女，喜歡什么東西，什么時候活躍，活躍時候都看了些什么。無論是在做什么項目，了解用戶畫像都很有必要?？赡茉谥貥嬳椖科陂g，產品經理不清楚用戶畫像也能很好地完成重構項目，但是了解用戶畫像的產品經理思考的深度和視野的廣度都遠甚于前者，換句話說：了解用戶畫像能讓產品經理逼格上升一個檔次。

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

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

這里的提升就不得不清晰地了解用戶畫像，因為用戶畫像主要功能有四個：精準營銷、廣告投放、個性化推薦、輔助產品設計。在做產品設計的時候，如果能將前面三者都思考在內，雖然做出來的東西可能差別不大，但是境界和視野的差距可見一斑。

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

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

4. 競品分析

這也是產品經理的基本功，在此不做詳細描述，但是提醒兩點：

避免沒有結論的功能點羅列：這是最常見的競品分析誤區，一定要有自己的分析結論，競品在做什么——他們為什么這么做——我在做什么——我應該怎么做。

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

5. 需求池

在體驗老版本的時候經常會發現一些問題，記錄下來，可能是一些功能bug，可能是一些細節的紕漏，甚至可能是一些提示文案等。但是僅自己體驗后記錄的需求遠遠不夠，一定會存在很多遺漏的點，以下有三條經驗可供參考：

1. 公司內部發起調研，經常使用老版本的公司內部人員會給出很多優化建議；
2. 對用戶發起調研，邀請一批高活躍用戶拉群或者面聊（沙龍形式），或者用廣撒網的形式發調研問卷；
3. 需求方的想法和建議，需求方可能是領導或者高層，溝通前做好功課，這一步很有必要，避免出現重構產出與需求方預期相差太遠的問題。

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

下圖為一個較大重構項目的原始需求池，未經篩選和標注優先級，小圓圈內的數字代表需求條數。

（某重構項目搜集的需求池）

6. 重構目標

重構目標不是將產品做出來，而是數據層面達到怎樣的水平。重構目標需要具體可量化，而不是模糊的“提升用戶體驗”。

【反面示例】

改版目標：通過改版內容詳情頁，提升用戶體驗，給用戶更好的閱讀體驗。

目標解讀：首先不夠具體，“提升用戶體驗”范圍太大，其次沒有量化，“更好的閱讀體驗”如何用數據衡量？

【正面示例】

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

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

總之，在一些目標導向的公司，有一個清晰的重構目標，有利于產品的設計，也容易出成果。如果能再增加一些行業數據或者競品數據進行對標，那么在寫績效總結的時候絕對是一大亮點。

完成了以上調研文檔的六個步驟，再來看需求文檔其實就已經很清晰了。按照各自業務場景和調研文檔的結論進行設計，在前面調研文檔很清晰的情況下，需求文檔的撰寫應該是相對水到渠成的事情?？梢栽谡{研文檔進行的同時將已經明確的改版方案細節列在需求文檔中，不斷擴充和積累之后，需求文檔也相對趨于完善。

唯一要注意的一點：繼承性產品設計，千萬不能一次性大幅改變用戶的操作習慣，否則后果自負。

三、中期策略

“重構”項目產品經理的工作70%的精力在前期的梳理與定義，需求評審完成后就陸續跟進視覺稿、開發和測試，有不明確的地方相關方會再來找你確認，如果你文檔夠細，評審夠清晰，這種不明確的詢問就會相對較少。

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

在開發提測之后，我認為項目才開始進入到中期，中期主要講究策略，如何讓用戶更自然和更樂意地接受新版的策略。

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

1. 灰度策略

灰度的目的是為了降低產品BUG風險，試驗新版本和新交互的用戶反饋，在數據層面上對新版功能、性能、穩定性、兼容性等指標進行評價，在灰度期間不斷迭代優化新版，以達到較為完善的用戶體驗后全量上線。

灰度上線策略可以很簡單，但是一般發布會比較復雜，產品經理可以在定義合適的灰度策略之后與開發溝通是否可行，若不可行可調整為怎樣的策略。

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

示例：

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

2. 選擇頁策略

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

（虎撲M站在進行灰度時的中間頁）

3. 溝通策略

溝通是產品經理的強項技能之一，不僅對內對接開發設計測試等，對外對接用戶也應該展現很強的溝通能力。

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

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

四、后期跟進

中期灰度發布，逐步迭代完善后趨近于最終的產品形態，接著就可以全量替換上線了。其實到這里產品經理針對這個項目的核心工作基本上已經結束了，但是好產品永遠是打磨出來的。

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

大多數情況隨著項目結束，產品趨于穩定，同時又有新的項目接手，根本無暇顧及已經全量上線的新版本。

這無關痛癢，但是有心的產品會把自己做的每一個項目做到盡善盡美，將每一個可以優化的點記錄下來，在后面當開發有空閑時間時安插需求，當開發看到一個用心做產品的伙伴，不會拒絕的。

作者：全導，微信公眾號：零向度（lingxiangdu）

本文由 @全導 原創發布于人人都是產品經理。未經許可，禁止轉載

題圖來自 Unsplash ，基于 CC0 協議