項(xiàng)目復(fù)盤(pán):PaaS平臺(tái)需求的批量操作功能

13 評(píng)論 18177 瀏覽 126 收藏 7 分鐘

本文是一個(gè)PaaS平臺(tái)設(shè)計(jì)的一個(gè)復(fù)盤(pán),筆者結(jié)合了實(shí)際的設(shè)計(jì)過(guò)程一一分享。

一、背景

PaaS平臺(tái),公司內(nèi)部產(chǎn)品線的名稱(chēng)。PaaS平臺(tái)即服務(wù),我的理解差不多就是“中臺(tái)”,只是在叫法上有所不同。平臺(tái)能力覆蓋范圍很廣,這個(gè)需求只是其中UI框架層部分。

批量操作功能web端已有,本次只是mobile端的能力拉平。需求來(lái)源于多個(gè)業(yè)務(wù)需求,比如,審批流程中的批量同意、批量拒絕,工單流程中的批量簽名等等。

二、開(kāi)始設(shè)計(jì)

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

最初,我的想法是將入口放于頁(yè)面右上角的更多按鈕里(下圖方案一)。

但是,這個(gè)想法很快遭到了PM的反對(duì),因?yàn)橛疑辖堑奈恢媚壳霸诖a層面配置了普通按鈕,如果要將批量的入口選在這里,意味著技術(shù)上的改動(dòng)會(huì)很大。而且平臺(tái)型產(chǎn)品在設(shè)計(jì)上有一個(gè)普遍的原則需要遵守,那就是組件和組件在迭代時(shí)應(yīng)互相不干擾。

企業(yè)級(jí)軟件滿(mǎn)足客戶(hù)定制化的需求,就像是用積木去拼一個(gè)樂(lè)高城堡,不能因?yàn)樾枰嘁粋€(gè)積木,就把之前的破壞掉重新做,那產(chǎn)品就有可能在無(wú)休止的返工改舊功能。當(dāng)然這一定不是絕對(duì)的,但在批量入口的選擇上,還不足以耗費(fèi)這么大的成本。

右上角的入口不行了之后,又去調(diào)研了一些競(jìng)品。本著不隱藏便于找到的初衷,又設(shè)計(jì)了多個(gè)入口方案,最后A/B測(cè)試,選了右下角的懸浮按鈕。

多種入口的設(shè)計(jì)方案

2. 全選的上限是多少?

  1. WEB端可以批量處理的上限是1000條,移動(dòng)端本身“窗口唯一”的特性決定了它不具備處理這么多數(shù)據(jù)的的場(chǎng)景;
  2. 列表頁(yè)目前采用的是分頁(yè)加載,全選的話,希望能做到選中的是所有列表?xiàng)l目,而不只有已加載出來(lái)的,這一點(diǎn)是要和研發(fā)明確確認(rèn)的,萬(wàn)幸的是可以做到。

3. 數(shù)據(jù)處理量大的話該怎么辦?

數(shù)據(jù)批量處理的操作不同決定了所需耗時(shí),批量關(guān)注和批量轉(zhuǎn)移數(shù)據(jù)耗時(shí)肯定差別很大的。

那在移動(dòng)端進(jìn)行數(shù)據(jù)的大批量處理場(chǎng)景是否存在呢,也許做業(yè)務(wù)線需求的時(shí)候你需要考慮,但是在做平臺(tái)需求的時(shí)候,do it,因?yàn)槟悴虏坏接脩?hù)會(huì)怎么用這么功能。功能本身是無(wú)屬性的,但我們?cè)谠O(shè)計(jì)的時(shí)候,這是一個(gè)需要考慮的異常情況,需要給出解決辦法,至少要確定用戶(hù)不會(huì)玩崩你的系統(tǒng)。

(和研發(fā)同事討論,暫定50條以上定義為大數(shù)據(jù)。小于50,數(shù)據(jù)由前端處理,走同步,大于等于50,數(shù)據(jù)由后端處理,走異步)。

那問(wèn)題就來(lái)了,異步開(kāi)始處理的提醒,過(guò)程中數(shù)據(jù)處理的隊(duì)列,完成后如何通知,一個(gè)異步隊(duì)列存在時(shí)是否還允許第二個(gè)隊(duì)列同時(shí)存在,隊(duì)列里數(shù)據(jù)有幾種狀態(tài),隊(duì)列中時(shí)是否能離開(kāi)、離開(kāi)后回來(lái)是什么狀態(tài)……

抱著這些問(wèn)題,與PM和研發(fā)多次溝通確定方案,因?yàn)榕袛嗟墓?jié)點(diǎn)過(guò)多,我做了一份流程圖:

流程圖1.0

流程圖1.0完成之后,看起來(lái)太過(guò)于復(fù)雜和繁瑣,不清晰,又優(yōu)化了流程圖2.0版本,感覺(jué)好了很多:

流程圖2.0

4. 把所有的特殊情況都考慮上,那這個(gè)流程的閉環(huán)該是什么樣?

根據(jù)已有的流程圖和組件規(guī)范,結(jié)合批量的需求,輸出了頁(yè)面的常規(guī)流程和考慮上特殊情況的全流程:

常規(guī)流程及交互說(shuō)明

全流程

三、最后

至此,項(xiàng)目進(jìn)入研發(fā)階段,等待產(chǎn)品驗(yàn)證。

復(fù)盤(pán)了一下之前做業(yè)務(wù)線需求的過(guò)程,兩者在思考方式和關(guān)注點(diǎn)上還是有挺大差別的:

  • 權(quán)限的考慮:業(yè)務(wù)需求基本都需要多問(wèn)一句:分權(quán)限嗎,而平臺(tái)需求是不考慮權(quán)限的;
  • 場(chǎng)景:業(yè)務(wù)需求有比較明確的使用場(chǎng)景,而平臺(tái)需求則需要在多種業(yè)務(wù)場(chǎng)景里提煉出一個(gè)流程來(lái),更多的是要做到通用;
  • 驗(yàn)證環(huán)節(jié):業(yè)務(wù)需求設(shè)計(jì)完成之后,需要對(duì)著最開(kāi)始的需求點(diǎn)一一比對(duì),查漏補(bǔ)缺。而 平臺(tái)需求則需要把多種業(yè)務(wù)場(chǎng)景嵌入流程中,校驗(yàn)是否做到了通用。

以上,謝謝閱讀!

 

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

題圖來(lái)自Unsplash,基于CC0協(xié)議。

更多精彩內(nèi)容,請(qǐng)關(guān)注人人都是產(chǎn)品經(jīng)理微信公眾號(hào)或下載App
評(píng)論
評(píng)論請(qǐng)登錄
  1. 畫(huà)的真好,怎么做到這么整齊的

    來(lái)自山東 回復(fù)
    1. Axure的網(wǎng)格功能打開(kāi),加熟能生巧 ?

      來(lái)自北京 回復(fù)
  2. 泰國(guó) 新加坡 印度尼西亞
    咖喱 肉骨茶 印尼九層塔

    來(lái)自北京 回復(fù)
    1. ? ?

      來(lái)自北京 回復(fù)
  3. 小爪子挺快啊

    來(lái)自北京 回復(fù)
  4. 重新上傳圖片了,這次清晰了 ?? ??

    來(lái)自北京 回復(fù)
    1. 反正我是看不清,想看清楚重點(diǎn),沒(méi)看清

      來(lái)自江蘇 回復(fù)
  5. 發(fā)現(xiàn)這個(gè)應(yīng)用里的圖片就沒(méi)清晰過(guò)

    回復(fù)
  6. 來(lái)人,把朕的放大鏡拿來(lái)

    來(lái)自福建 回復(fù)
  7. 這圖是故意不給看清楚的么,湖的我犯暈

    來(lái)自廣東 回復(fù)
    1. 同問(wèn) ??

      來(lái)自陜西 回復(fù)
    2. 好像不能重新上傳圖片了
      我是從公眾號(hào)里直接導(dǎo)過(guò)來(lái)的,公眾號(hào)手機(jī)上能差不多看清楚 ?

      來(lái)自北京 回復(fù)
  8. 好同志

    來(lái)自上海 回復(fù)