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

產(chǎn)品經(jīng)理面對用戶時，總想把最優(yōu)的體驗帶給他，幫他滿足一切的想法。但往往體驗和性能不能兼得，特別是當(dāng)數(shù)據(jù)量大時，面對開發(fā)，產(chǎn)品經(jīng)理又想把這個功能簡化到性能最好。

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

01 性能問題的起因

系統(tǒng)性能差有很多原因：框架設(shè)計不合理，查詢邏輯不合理，服務(wù)器容量太小…

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

1. 數(shù)據(jù)量過大

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

2. 接口數(shù)過多

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

我常常會聽到開發(fā)向我抱怨，你不要在這個頁面上加字段，加業(yè)務(wù)了，現(xiàn)在性能就已經(jīng)很差了，我怕抗不住。

我當(dāng)然還是以業(yè)務(wù)優(yōu)先，其他可以做的總原則就是：控量。

02 三個小方法

1. 分批處理

當(dāng)一次請求獲取的數(shù)據(jù)量很大的時候，我們可以采用分批的方式，表現(xiàn)在頁面上就是這2種。

（1）范圍設(shè)定

在業(yè)務(wù)總列表，特別是統(tǒng)計報表，這些數(shù)據(jù)量比較大的頁面，建議把篩選的默認(rèn)選項加上，比如說狀態(tài)值，時間范圍。這樣一下子縮小了查詢范圍，過濾條件越多，速度就越快。

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

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

特別是新產(chǎn)品，用戶用的時間比較短，數(shù)據(jù)量還不多，一次性查出所有數(shù)據(jù)也沒有出現(xiàn)過問題，產(chǎn)品經(jīng)理往往會忽視這個問題。但過了1年，2年，甚至更長的時間時，當(dāng)初這個坑可能就要后來人填了。所以還是建議，不管是什么系統(tǒng)，這個范圍一定要定義好，避免哪一天突然出現(xiàn)奔潰。

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

（2）分頁加載

分頁這個詞，產(chǎn)品經(jīng)理也是非常熟悉的，幾乎每個列表都會用到。

關(guān)于每頁應(yīng)該加載幾條數(shù)據(jù)，常常會引起爭議——如果一頁上面數(shù)據(jù)太少，那用戶可能會翻上好幾頁才能找到想要的那條；如果數(shù)據(jù)太多，又會導(dǎo)致頁面過長，上下滑動查看不方便。

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

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

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

C端比較常見的分頁方式是瀑布流式，向上滑動時自動加載下一屏的內(nèi)容，這種在B端產(chǎn)品中比較少見，B端產(chǎn)品通常采用的是點擊觸發(fā)式，因為數(shù)據(jù)量大很多。最常采用的是上面那種分頁器，也有一些會采用下面的這種按鈕形式。

2. 信息量控制

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

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

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

從產(chǎn)品經(jīng)理的角度來說，這樣分類能使得信息層級更加的清晰，但分得過細(xì)也會導(dǎo)致用戶填寫信息時需要不停的切換tab，降低效率。我們可以在不影響用戶體驗的情況下，適當(dāng)?shù)陌研畔⑦M行歸類和拆分。

另一方面，開發(fā)在看到我們產(chǎn)品文檔上的信息時，在開發(fā)時會對一些數(shù)據(jù)進行預(yù)處理，比如說工作臺上面的數(shù)據(jù)匯總。今日預(yù)約，今日到訪的數(shù)量總計都是先在統(tǒng)計中心匯總的，不是實時去業(yè)務(wù)模塊拉取數(shù)據(jù)，然后加總。

3. 分步處理

這一個方法用到的地方不是很多，目前我們就在統(tǒng)計報表導(dǎo)出這塊用到。

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

這背后其實有2步，開發(fā)先把要導(dǎo)出的數(shù)據(jù)匯總，生成在一個Excel表里面，然后下載下來。如果數(shù)據(jù)量很大，那2步同時進行的數(shù)據(jù)流就會很大，可能引起性能問題。

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

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

03 總結(jié)

SaaS系統(tǒng)性能差的問題，實際上產(chǎn)品經(jīng)理能幫到的忙是有限的，往往技術(shù)原因占比更大。但我們可以通過分批處理、信息量控制、分步處理這3種小方法，提前給開發(fā)控量，減少性能風(fēng)險，也減少開發(fā)過程中的方案調(diào)整。你學(xué)會了嗎？

#專欄作家#

司馬特小隊，訂閱號：司馬特小分隊，人人都是產(chǎn)品經(jīng)理專欄作家。8年+互聯(lián)網(wǎng)資深產(chǎn)品經(jīng)驗，多年B端產(chǎn)品管理經(jīng)驗。具有多個從0到1的大型B端產(chǎn)品的孵化、重構(gòu)、迭代經(jīng)驗；主要教授產(chǎn)業(yè)互聯(lián)網(wǎng)產(chǎn)品相關(guān)的硬核知識點。

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

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