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

產品經理一定要經歷完整的從0~n才能在產品設計方法上比較游刃有余嗎？這個想法還是太天真了。重構產品的方法與從0~1區別非常大，難度與挑戰也遠高于0~1。下面這篇文章作者就結合自己的經歷，對產品重構做了梳理總結，想要了解產品重構的小伙伴趕緊來看看哦。

一、背景

曾經一度簡單的認為產品經理一定要經歷完整的從0~n才能在產品設計方法上比較游刃有余，后來經過一年多對一個產品重構后，發現以前的認知還是天真了，重構產品的方法與從0~1區別非常大，難度與挑戰也遠高于0~1，相信無論是做過還是正在做產品重構的同學，一定深有體會，這篇文章就結合自己的經歷，對產品重構做個梳理總結。

我所重構的這個內部系統，在接手前已經做了一年左右，曾經的模式都是業務方一句話需求直接提到開發團隊，然后各個開發根據自己的理解哼哧哼哧做兩個星期，無論能不能用，好不好用，因為公司強制要求都在無奈使用，過程中也埋下無數坑，以致于用戶使用起來痛苦萬分，體驗極差，領導對這個現狀也不太滿意。

經過一年多的改造和優化，我們的北極星指標–用戶滿意度（NPS）提升了49%，也達成了我們的預期目標，今天就把這個過程中總結出的方法、經驗教訓分享出來。

本文側重講解重構步驟方法，涉及部分細節就不在此展開過多了。

二、重構的方式

重構一般有三種方式

1. 推倒重來：在原系統基礎上重新開發，僅保留數據庫等基礎內容，上層代碼重新開發；
2. 另起爐灶：原系統保持運行，另起新項目，重新做個新系統替換，做數據遷移；
3. 運行中改造：保持現有系統持續、穩定運行，同時對所需模塊持續改造，直至達成目標

這里對這三種方式做個對比：

方式一是在原系統打算或已經廢棄的時候才適用，而這種情況其實比較少，更多時候，我們所面臨的重構場景是在方式二、三中選擇。

從業務方和領導們的角度，通常傾向方式三，因為風險更小，感覺上成本更低，但實際上如果需要改造的模塊較多，方式三的成本其實更高，因為有很多兼容、填坑、還技術債的事情；而從產研的角度，通常傾向方式二，因為不用考慮過多的歷史包袱，處理起來更方便，如果需改造內容多，綜合成本也更小。

至于最終選擇哪種，就得結合實際情況來判斷了。不過很明顯方式三的挑戰會更大，對產品經理的要求也更高，后面的內容，將基于方式三總結。

三、重構步驟

1. 前期調研

（1）內容

業務調研

所有的調研都是先從業務開始，在這部分的調研中，我們需要了解兩部分：

1. 業務所在行業的通用玩法，知道行業內一般都是怎么運作的，有行業認識；
2. 公司的整體業務流程、業務特色、形成的歷史淵源，其中要特別注意公司與行業的不同之處，一旦忽略就容易在后面改造中照搬行業玩法，導致與實際業務需求不符。

這兩部分學習、調研的內容是相互促進的，通過觀察公司業務運作可以更好的理解行業做法的含義，通過將行業玩法作為參考系可以發現公司當前所處位置及優劣。

用戶調研

首先需要了解有哪些用戶在使用現有系統，通過提煉用戶差異性，將用戶從多個維度進行分群（后面細聊如何做B端用戶分群），然后就能找出對應群體中一些典型用戶，通過一對一訪談深度了解他們使用系統的目的、路徑、痛點、期望

不過一對一訪談效率還是比較低，所以需要增加問卷等方式，大批量收集用戶目前的需求、槽點

（2）目的

1. 從業務方、領導層、用戶各方充分了解為什么要進行重構
2. 對現有系統情況做一個整體的摸排，初步形成較為全面的認識

（3）輸出

• 公司業務流程
• 公司業務特色總結，形成文檔記錄
• 各角色用例圖
• 用戶調研報告。包含用戶體驗地圖
• 用戶問題/需求池

2. 舊邏輯梳理

（1）內容

對系統現有主體邏輯進行梳理，包括系統主流程、產品架構、產品結構、功能模塊、功能點等。

由于還沒到具體模塊的改造，所以有些細節暫時可以不用太深入，等到改造到那塊時再梳理即可，一方面因為有些細節即使提前了解了，時間長了到后面可能也忘了，另一方面是可能由于文檔缺失或更新不及時，已經沒有人能記得很清楚了，需要開發通過代碼看出原有邏輯，所以細節梳理需要耗費巨大的時間、人力成本，影響前期進展。

（2）目的

這一步的目的是為了對系統現有功能、邏輯有整體認知，便于后續對比業務需求，發現全局性、架構上、偏底層的一些問題。

（3）輸出

• 產品主流程圖
• 產品架構圖
• 產品結構圖（腦圖）
• 通過表格整體的各模塊功能邏輯清單

3. 對比分析

（1）內容

通過對比業務實際需求與現有規則的差異，發現、挖掘出系統現存的一些問題，明確后續需改造的內容。

（2）目的

很多同學在對現有系統做重構時，需改造內容的信息來源是調研結果或自我感受，但從我的經歷來看，這些信息還不夠，主要原因有兩個：

1. 很多調研內容用戶無法告知你應該怎么做，相當大比例的問題是普通用戶意識不到的，用戶反饋由于自身的很多局限，認識不夠全面，同時也認識不到系統底層問題，更多的還只是一些交互、視覺層面的問題；
2. 很多看起來不合理的邏輯，其實是符合業務特點和要求的，也有其特殊背景，只有最適合你的業務需求的才是好的設計。

這就是專門對比業務需求與現有規則差異的目的。

（3）輸出

補充用戶問題/需求池。通過對比發現的系統現存問題清單，與前面調研結果進行合并在一張表里

4. 問題/需求整理與分層

（1）內容

問題/需求整理

通過前面的調研、分析，我們就有了一份用戶問題/需求池，內容非常多，這就需要對這份問題/需求池進行整理。

• 按功能模塊歸納
• 將重復問題/需求合并
• 將明顯不合理問題/需求刪除

問題/需求分層

除了將這些問題/需求按模塊劃分，還要對它們進行提煉總結，然后將這些問題按數據層–模型層–領域（業務邏輯）層–交互層–UI層五個層次進行分層

1. UI層：純視覺問題，如icon語義、顏色、樣式問題等；
2. 交互層：頁面交互上的問題，常見的如菜單結構、操作控件；
3. 領域層：各種業務邏輯問題；
4. 模型層：底層模型設計相關，如原設計不合理，與業務需求不匹配，擴展性差
5. 數據層：常見如數據混亂，不統一、來源不一致等

（2）目的

問題/需求的整理是大多同學都會做的，就不做過多解釋，但分層則是很多同學沒有意識到，其實非常重要的事情，接下來就說一下為什么要對問題/需求進行分層？

當我們面對大量的問題、需求時，往往會是一臉懵逼、茫然無措的狀態，主要有兩個原因：

1. 問題太多，不知道從何下手，先從哪里開始；
2. 當我們深入這些問題/需求會發現，很多問題/需求都是相互依賴的，由于是對現有系統改造，很多功能已經成型，當我們選定一塊內容時，往往牽扯其他很多部分，一類是橫向關聯，即模塊與模塊間的關聯影響，另一種是縱向關聯，即表面上是交互問題，但很可能會涉及業務邏輯層、甚至模型層的改動。

而我們在對已有系統改造時，很容易出現影響面評估不足導致線上bug的情況，所以除了將問題/需求從橫向功能上整理歸類，還要從縱向涉及層次劃分，這樣可以更好的分析出關聯影響面，另外，不同層次的問題改動成本、策略、方法、時間差異很大，對我們后面優先級評估也有較大影響，所以需要有縱向劃分。

（3）輸出

整理分類后的用戶問題/需求反饋清單

5. 明確重構目標與指標

（1）內容

重構不是為了改而改，需要有目標的改，改造的范圍、最終希望達成的結果，如何衡量，都是在改之前要考慮清楚的問題。

明確了目標，就需要定義相應的指標進行量化評估，包括評估最終結果的全局指標和評估每塊功能的功能指標，以便有數據支撐。

根據明確的指標，需要做好前期數據收集工作，提前做好埋點等，才能對比優化前后的結果。

（2）輸出

數據指標定義：

6. 分析優先級

（1）內容

對用戶問題/需求整理后，就要分析優先級，確定改造重構的先后順序，主要從四個方面綜合評估：

1. 價值收益。在看重構價值時，需要同時看短期和長期兩方面，短期收益大（如交互體驗上吐槽較多的問題）和長久的事情（如模型、數據層的動作）需要同時做，不要完全擱置某一類；
2. 依賴關系。根據依賴關系，一方面可以明確先后順序，另一方面對于依賴過多的內容，尤其底層的改動，需要多花時間好好分析、好好討論；
3. 改造成本。需要根據成本評估ROI
4. 資源支撐。

（2）輸出

用戶問題/需求反饋清單中的優先級結論

7. 模塊調研

（1）內容

第一步的調研，主要是為了形成整體認知，還沒深入到具體模塊的細節中，當我們確定要重構的內容及優先級后，再對具體要改造的內容有針對性的做用戶、競品調研，就會更有收獲，集中精力琢磨透一塊內容，用戶的痛點有哪些，使用的場景有哪些，同時看看其他競品的針對這些問題的處理方式，也可以稱為功能調研。

（2）輸出

• 對應場景用戶調研結論
• 對應功能競品調研結論

8. 制定、實施優化方案

接下來就是根據規劃的優先級來逐步改造優化了。

無論是一個產品還是模塊的重構，這個流程方法都是通用的

四、感悟

最后從產品設計和心態分享幾點在重構中體會比較深的感悟。

1. 產品設計

（1）敬畏用戶習慣

重構需要改很多內容，當涉及到交互層，需要改變用戶原有的使用習慣時，一定要三思而后行，首先要考慮的是能否保留用戶的使用習慣，哪怕這個習慣不那么符合規范，與通用做法不太一樣，也要首先考慮保留，其實很多交互方式沒有對錯之分，只有是否合適之分，用戶用得舒服才叫合適。

如果實在需要改，就要好好考慮如何延續系統的風格，過渡更平緩，怎么更好的告知。

用戶習慣不是僅僅“考慮過”就足夠了，是真的需要敬畏的心態面對，否則用戶會用中華國粹回敬你。

（2）不可避免的“浪費”

為了節約成本，我們大多希望一步，盡量減少后面的反復變動，不過產品重構有時候會出現一些不得不做的“浪費”，主要有兩個原因：

1. 為了讓用戶、數據平穩過渡，有時會增加一段過渡期，這段過渡期可能是臨時方案，等后面時機成熟會再變化；
2. 因為是在進行中改造，所以有時需要兼容新舊兩套邏輯，從而增加額外成本

（3）用戶價值=（新體驗-舊體驗）-替換成本-感知門檻

所有產品動作根本上都是用戶價值驅動的，俞軍老師的用戶價值公式大家應該都很清楚了，在這個公式的基礎上我在后面增加了一個【感知門檻】，即用戶感知到你新體驗帶來價值的門檻有多高，門檻越低，帶來的價值越大。

可能俞軍老師已經把【感知門檻】算到【替換成本】里了，這里我單獨列出來，目的是想強調這部分，因為有時候會出現自己感動自己的情況，覺得我們做了一個非常棒的優化，用戶這群白眼狼怎么就不領情呢，原因可能你這個優化確實很好，但用戶沒感知到。

（4）隨時可回滾

沒有人能保證每一次改動都是向好的，哪怕不出bug，可能由于有的場景沒考慮到導致新功能產生負面影響，所以從功能上要保證隨時可回滾，從數據上每次數據庫刷數據前有備份。

功能回滾基于現在的代碼管理能力大多都具備，只要分支與需求關聯比較規范，不過數據庫備份是容易忽略的，所以要特別提醒服務端同學，做大改造需要刷數據前，做好數據備份以便數據回滾。

（5）小細節能有大回報

產品重構很多是用戶使用太痛苦，而改變這種痛苦不一定都是要做大的變動才能讓用戶減輕痛苦，很多細節優化能有大的回報，例如增加最近使用、操作記憶等。

2. 心態

（1）重構是對產品能力淬火的絕佳機會，而不是火坑

接手一個前人留下的產品，是很多同學極不情愿的事情，就覺得是一個大火坑，都不知道怎么下手，都希望自己可以從0~1做一款產品，挖的坑讓后面的人填。

我最開始的心態也是如此，但隨著一年多的重構，會發現這其實不是火坑，而是對你產品能力二次打磨的火爐，當你深度長時間跟進后，你會對用戶、場景、業務這幾個詞的理解更深。

（2）鍛煉大心臟

產品重構確實很容易變成吃力不討好的事情，你會隨時受到多方的壓力：

• 用戶會噴你。因為改了用戶習慣被噴，因為加了些“亂七八糟”的被噴，因為不被理解被噴，總之有各種理由；
• 前人留下的坑。你永遠都不知道下個坑會在哪里，測試也回歸不到，等到線上用戶發現，就成了線上事故；
• 上級壓力與用戶適應節奏矛盾。上級希望在短時間內看到變化，但其實這比從0~1花的時間要更長，除了各種挑戰外，更重要的是要給用戶適應的時間，不適合在短時間做大幅度的變動，而這種矛盾難以調和；
• 不確定的風險。你也不知道這個版本的改造、優化上去能不能被用戶接受，最終能否拿到你要的結果。

你需要同時面對更多的壓力，所以調整好心態，鍛煉大心臟才能更面對各種質疑和壓力。