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

上次寫了一篇文章，從用戶需求、 報表設計這兩個方面簡單地介紹了一下管理系統的報表設計的大致框架。但其實關于報表，除了框架，填充框架的細節也很重要。所以在項目填坑的過程中，文章也來填坑了。這篇文章會著重于報表設計中的那些需要注意的細節點。

報表權限

報表是各類數據的匯總和可視化，展示著公司運營、財務、業績、人員的重要數據。在一定程度上，報表是公司的“重要機密”。所以報表并不是誰都能看得到的，報表需要設置查看權限。

和業績有關的運營報表一般只有老板或管理層才有權限查看；涉及到錢的財務報表更甚，大部分只有老板、經理、財務三個角色可以查看；而最普通的角色，比如：公寓管理系統的管家，有權限查看的報表應該只有個人的業績了。

所以在設計報表的時候，首先應該確定好，系統里哪些角色/職位能查看這個報表。

在梳理PRD的時候，首先應該配置好該報表模塊的查看權限。當然不同系統的權限配置方式會有不同，有些系統為了省事，直接讓開發配置好，權限固定下來。

比如說：報表模塊只能【經理】這個角色才能查看，那需要開發在邏輯上進行固定：只要系統角色是【經理】的就能查看報表。這樣的話，使用系統的運營商就不用費心了。到時候需要改的時候，直接讓開發修改。當然，在實際使用中，修改的頻率并不是很高。

但是有的運營商想要權限配置更靈活一些，同時還希望自己能夠配置權限。那這個時候，誰查看報表那就是運營商自己來配置了。當然一開始會根據業務給出一個默認配置，但是運營商能夠自己進行編輯。

舉個例子：如果運營商想讓店長也能看報表，那他在店長的可查看模塊下勾選【報表】就好了。配置靈活，也減少了軟件開發商的維護成本。

數據類別

報表的數據主要分為：歷史數據和實時數據。

歷史數據主要是查詢歷史時間的數據，數據是靜止的。系統的統計報表都是歷史數據，數據大部分是不變的，但后臺會有定時任務拉取更新數據，基本上是一天更新一次。

而實時數據不一樣，實時數據是時刻都在變動的。大部分使用實時數據的表格是用來監控需要實時觀察的數據，比如說：電量設備監控表、降雨量監控等等。當然，對于實時監控數據，用戶會更習慣看監控圖，因為監控圖更直觀明了。

但是如果關注具體數據的話，表格還是有必要的。實時數據表格一般沒有時間選擇，用戶看到的數據就是當下的最新數據。但是實時更新的話，數據壓力也很大，更多的會根據數據上報系統幾分鐘更新一次。

實時監控數據表

實時監控數據圖

數據操作

考慮了數據本身，還需要考慮用戶能對數據做哪些操作。最常見的操作當然是增、刪、改、查。查詢數據已經在上一篇文章中講過了，剩下的新增、刪除、修改，則需要根據用戶需要和圖表性質增加功能。

當然還有一些小功能，比如說數據的排序，除了默認的排序外，用戶也有根據自己要求進行排序的需求。還有則就是分頁和頁面展示數據條數的選擇等等，在設計的時候都要考慮到。

數據查詢壓力

在報表模塊，最讓人害怕的就是數據查詢壓力。有可能你辛辛苦苦設計好、測試完成、然后上線了，最后這個模塊崩掉了，用不了，這就很讓人絕望了。

一般來說，這有可能會是因為查詢人數多、查詢次數過于頻繁，還有可能和數據的存儲方式有關。如果查詢人數多、查詢次數過于頻繁而導致的數據壓力大，那么這時候就需要對數據查詢進行限制。

如果是歷史數據，則需要限制數據查詢時間，在選擇時間的邏輯上增加限制。比如說：時間選擇最早只能選擇兩年前到當天的數據。這樣的話，在數據上的數量上限制了可查詢的數據，減小了查詢壓力。而實時數據的限制則會更甚，大多是【今天】、【昨天】、【最近3天】、【最近7天】，更遠也只是【最近1個月】。

當然如果是數據存儲方式所導致數據查詢壓力大，那可能需要改變數據的存儲方式。歷史數據當然是存在數據庫里的，數據是比較穩定的。但實時數據則不是，實時數據則沒辦法存在數據庫了，它是直接從數據上報系統中拉取數是實時更新的。

同時，從數據量上來比較，歷史數據是一天上報一次，數據量比較少，而實時數據則是每隔幾分鐘上報一次，數據量十分巨大，對存儲壓力和查詢壓力來說，都是一個不小的挑戰。

如果遇上實時數據表格上線后崩掉了的情況，可以嘗試和后端溝通，能不能去掉一些增加數據查詢壓力的功能，比如：表格里的手動數據排序功能，或者改變一下數據的存儲方式，采用更穩定的數據存儲。那如果技術方便沒辦法解決，那可能需要產品自己思考改變方案，采用其他方案來滿足需求。

導出報表

雖然上一篇文章也提到導出報表，但只是簡單地帶過。其實導出報表功能看起來雖小，但其實內里也是有點復雜。數據導出分為同步和異步兩種。大部分我們導數據都是同步導出，點擊導出，然后就直接下載到本地了。

但是如果數據量大，數據導出時間較長的話，在設計報表導出時還是需要選擇異步導出。創建的導出任務會展示在【導出任務】里，用戶可以查看導出進度，導出完成后即可下載到本地。

對于有些用戶來說，同步導出會讓人感覺到直接、“快”，而異步導出會讓人感覺“慢”且麻煩。但是異步導出其實會更穩定。而且如果導出時間過長的話，同步導出會給人一種“卡死”了的感覺，而異步導出由于會展示進度，所以用戶體驗會更好。采取哪種導出方式，根據數據的實際情況來就好。

此外，在導出任務欄里的設計還有一個細節。例如：排序和歷史任務。排序一般都是創建時間由近及遠，但是我們系統反人類的一個點是由遠及近（無奈攤手）。還有一個歷史任務的查看，我們系統還有一個槽點是，只要是這個員工賬號在系統中創建的導出任務都會展示在導出任務欄中。（What？難道不應該是我在這個頁面創建的導出任務才會顯示在這個頁面的導出任務里么？）

我能在所有頁面的導出任務里看到在所有頁面的導出任務，非常大一統的感覺。希望大家在做設計的時候，記得避免這兩個坑。

以上這些就是報表設計的第二篇，相對于簡單地第一篇，這篇更注重于一些關于數據的細節。兩篇結合起來，應該可以算是一篇較完整的報表設計了。

希望大家能夠早點脫坑，設計出滿意的報表。

相關閱讀

后臺統計報表如何設計？

#專欄作家#

異彩，微信公眾號：一只蝸牛慢慢跑，人人都是產品經理專欄作家。從事房產管理系統的產品工作，關注To C產品的交互設計、運營、結構設計和商業模式。在成為一名優秀的產品人的路上努力前行。

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

題圖來自Unsplash，基于CC0協議