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

本文是一個PaaS平臺設計的一個復盤，筆者結合了實際的設計過程一一分享。

一、背景

PaaS平臺，公司內部產品線的名稱。PaaS平臺即服務，我的理解差不多就是“中臺”，只是在叫法上有所不同。平臺能力覆蓋范圍很廣，這個需求只是其中UI框架層部分。

批量操作功能web端已有，本次只是mobile端的能力拉平。需求來源于多個業務需求，比如，審批流程中的批量同意、批量拒絕，工單流程中的批量簽名等等。

二、開始設計

1. 批量的入口放在哪里？

最初，我的想法是將入口放于頁面右上角的更多按鈕里（下圖方案一）。

但是，這個想法很快遭到了PM的反對，因為右上角的位置目前在代碼層面配置了普通按鈕，如果要將批量的入口選在這里，意味著技術上的改動會很大。而且平臺型產品在設計上有一個普遍的原則需要遵守，那就是組件和組件在迭代時應互相不干擾。

企業級軟件滿足客戶定制化的需求，就像是用積木去拼一個樂高城堡，不能因為需要多一個積木，就把之前的破壞掉重新做，那產品就有可能在無休止的返工改舊功能。當然這一定不是絕對的，但在批量入口的選擇上，還不足以耗費這么大的成本。

右上角的入口不行了之后，又去調研了一些競品。本著不隱藏便于找到的初衷，又設計了多個入口方案，最后A/B測試，選了右下角的懸浮按鈕。

多種入口的設計方案

2. 全選的上限是多少？

1. WEB端可以批量處理的上限是1000條，移動端本身“窗口唯一”的特性決定了它不具備處理這么多數據的的場景；
2. 列表頁目前采用的是分頁加載，全選的話，希望能做到選中的是所有列表條目，而不只有已加載出來的，這一點是要和研發明確確認的，萬幸的是可以做到。

3. 數據處理量大的話該怎么辦？

數據批量處理的操作不同決定了所需耗時，批量關注和批量轉移數據耗時肯定差別很大的。

那在移動端進行數據的大批量處理場景是否存在呢，也許做業務線需求的時候你需要考慮，但是在做平臺需求的時候，do it，因為你猜不到用戶會怎么用這么功能。功能本身是無屬性的，但我們在設計的時候，這是一個需要考慮的異常情況，需要給出解決辦法，至少要確定用戶不會玩崩你的系統。

（和研發同事討論，暫定50條以上定義為大數據。小于50，數據由前端處理，走同步，大于等于50，數據由后端處理，走異步）。

那問題就來了，異步開始處理的提醒，過程中數據處理的隊列，完成后如何通知，一個異步隊列存在時是否還允許第二個隊列同時存在，隊列里數據有幾種狀態，隊列中時是否能離開、離開后回來是什么狀態……

抱著這些問題，與PM和研發多次溝通確定方案，因為判斷的節點過多，我做了一份流程圖：

流程圖1.0

流程圖1.0完成之后，看起來太過于復雜和繁瑣，不清晰，又優化了流程圖2.0版本，感覺好了很多：

流程圖2.0

4. 把所有的特殊情況都考慮上，那這個流程的閉環該是什么樣？

根據已有的流程圖和組件規范，結合批量的需求，輸出了頁面的常規流程和考慮上特殊情況的全流程：

常規流程及交互說明

全流程

三、最后

至此，項目進入研發階段，等待產品驗證。

復盤了一下之前做業務線需求的過程，兩者在思考方式和關注點上還是有挺大差別的：

• 權限的考慮：業務需求基本都需要多問一句：分權限嗎，而平臺需求是不考慮權限的；
• 場景：業務需求有比較明確的使用場景，而平臺需求則需要在多種業務場景里提煉出一個流程來，更多的是要做到通用；
• 驗證環節：業務需求設計完成之后，需要對著最開始的需求點一一比對，查漏補缺。而 平臺需求則需要把多種業務場景嵌入流程中，校驗是否做到了通用。

以上，謝謝閱讀！

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

題圖來自Unsplash，基于CC0協議。