産品經理面對用戶時，總想把最優的體驗帶給他，幫他滿足一切的想法。但往往體驗和性能不能兼得，特别是當數據量大時，面對開發，産品經理又想把這個功能簡化到性能最好。

所以，如何平衡好用戶需求和性能之間的矛盾呢？本文會教給大家3個産品經理常用的小技能，既不影響用戶體驗，又能規避不少性能差的問題。

系統性能差有很多原因：框架設計不合理，查詢邏輯不合理，服務器容量太小…

我們可能會覺得這是開發的事情，我們無能為力。但其實除了技術方面的原因，下面這2個客觀原因是我們很容易想到的，我們也能針對這2個原因采取力所能及的措施。

1. 數據量過大

這個很好理解。比如說我是餐廳老闆，我查今天的營業收入明細和查一年的，查出來的數據量是不一樣的。反映到系統上就是數據量越多，查詢時間就會越長。當數據量大到一定程度的時候，頁面就一直處于加載中，卡死了。

2. 接口數過多

我們表面上看一個頁面，這個頁面上面的字段是固定的，在一起的。但實際上開發實現的時候，會分開來存儲字段信息。當這個頁面加載出來時，他會有很多的接口去不同的數據庫表裡請求數據。所以當一個頁面上的字段越多，涉及的模塊越多的時候，加載就可能越慢，甚至可能奔潰。

我常常會聽到開發向我抱怨，你不要在這個頁面上加字段，加業務了，現在性能就已經很差了，我怕抗不住。

我當然還是以業務優先，其他可以做的總原則就是：控量。

1. 分批處理

當一次請求獲取的數據量很大的時候，我們可以采用分批的方式，表現在頁面上就是這2種。

（1）範圍設定

在業務總列表，特别是統計報表，這些數據量比較大的頁面，建議把篩選的默認選項加上，比如說狀态值，時間範圍。這樣一下子縮小了查詢範圍，過濾條件越多，速度就越快。

如何設定這些默認值？當然是根據業務來定的。比如說商家訂單列表，首先查最近7天待發貨的，因為這是商家需要首要處理的。在收費日報處，時間篩選默認今日；業績提成報表處，時間篩選默認當月，因為工資一般是月結的。

總的來說，以時間為過濾條件是用的最多的，那就産生了另一個問題：時間跨度最長是多少呢？我能一次性查用戶使用系統以來的全部數據，還是不超過1年的，或者不超過3個月的？這個需要産品經理來預估數據量。

特别是新産品，用戶用的時間比較短，數據量還不多，一次性查出所有數據也沒有出現過問題，産品經理往往會忽視這個問題。但過了1年，2年，甚至更長的時間時，當初這個坑可能就要後來人填了。所以還是建議，不管是什麼系統，這個範圍一定要定義好，避免哪一天突然出現奔潰。

前端的組件有很多種，這種左側帶快速時間選擇的控件就很适合。雖然用戶更喜歡直接點叉号清空篩選項，但這個用戶使用起來也還算方便。

（2）分頁加載

分頁這個詞，産品經理也是非常熟悉的，幾乎每個列表都會用到。

關于每頁應該加載幾條數據，常常會引起争議——如果一頁上面數據太少，那用戶可能會翻上好幾頁才能找到想要的那條；如果數據太多，又會導緻頁面過長，上下滑動查看不方便。

一般來說，會以數據1-2屏左右為界限來劃分，可能是10條，可能是15或者20條。

更加人性化的是這種可選每頁條數的分頁控件。12條是1屏，也就是說1-3屏，用戶可以根據自己的習慣來選擇。

我比較推薦這種，雖然這個比一刀切的分頁法實現複雜一點，但更加符合用戶的需求，能提升很多用戶體驗。

C端比較常見的分頁方式是瀑布流式，向上滑動時自動加載下一屏的内容，這種在B端産品中比較少見，B端産品通常采用的是點擊觸發式，因為數據量大很多。最常采用的是上面那種分頁器，也有一些會采用下面的這種按鈕形式。

2. 信息量控制

我們上面說到引起性能問題的第二個原因：一個頁面上接口數量過多。那我們可以做的就是，控制一頁上的信息量，即字段數量，以及與主業務相關聯的輔業務數量。用語文老師教我們的寫作思路來說，就是：每一段要有核心思想，善于分段講述。

比如這是一張兒童的生長發育評測表，分成了2級，一級從4大方面來評測，在每個方面，又會再進行下一步的細分。比如基本看護裡面還會分飲食内容評估，睡眠評估等。

從開發的角度來說，這樣的分類是很好的。每個頁面上的信息量越少，他們的接口壓力就越小。

從産品經理的角度來說，這樣分類能使得信息層級更加的清晰，但分得過細也會導緻用戶填寫信息時需要不停的切換tab，降低效率。我們可以在不影響用戶體驗的情況下，适當的把信息進行歸類和拆分。

另一方面，開發在看到我們産品文檔上的信息時，在開發時會對一些數據進行預處理，比如說工作台上面的數據彙總。今日預約，今日到訪的數量總計都是先在統計中心彙總的，不是實時去業務模塊拉取數據，然後加總。

3. 分步處理

這一個方法用到的地方不是很多，目前我們就在統計報表導出這塊用到。

平常我們在網頁上點擊下載按鈕，會在底部看到這樣的下載條。

這背後其實有2步，開發先把要導出的數據彙總，生成在一個Excel表裡面，然後下載下來。如果數據量很大，那2步同時進行的數據流就會很大，可能引起性能問題。

我們的做法是，把這2步進行拆分，先生成Excel表，然後讓用戶手動下載。開發也會把這個分步操作稱為”長鍊路解耦“。鍊路越短，查詢速度就越快。

長鍊路解耦可能會引起用戶體驗的不好，因為中間需要手動觸發進行下一個鍊路，但在導出數據這種非高頻場景下，是個性價比很高的方式。

SaaS系統性能差的問題，實際上産品經理能幫到的忙是有限的，往往技術原因占比更大。但我們可以通過分批處理、信息量控制、分步處理這3種小方法，提前給開發控量，減少性能風險，也減少開發過程中的方案調整。你學會了嗎？

作者：司馬特小隊，訂閱号：司馬特小分隊，專注B端産品

本文由 @司馬特小隊 原創發布于人人都是産品經理，未經許可，禁止轉載

題圖來自 Unsplash，基于 CC0 協議

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!