你是在做產品,還是在做產品的搬運工?
編輯導讀:在進行數據業務類功能設計時,不同的產品經理可能有不同的設計方式,但是只有通過深挖業務邏輯進而實現業務功能才是一個真正的產品經理應有的方法。文章結合醫院排班的案例,對此展開了深入的闡述說明,與大家分享。
數據業務類功能設計
在產品經理日常工作中,難免會碰到一些數據業務類的功能設計,比如財務報表、績效考核等,這些業務既需要產品有一定的數據處理能力,有需要對業務有一定深度的了解。
但是即使是這樣,設計出來的產品也是有著不同傾向的,有的傾向于使用數據表格做業務,完成后導入即可,有的傾向于只導入基礎數據,業務邏輯通過產品進行實現,這在我看來是兩種截然不同的選擇,一種是做產品的搬運工,另一種才是真正的產品。
產品業務 VS Excel
對于數據業務類的功能設計,是深挖業務邏輯實現業務功能還是只是將產品作為一個信息中轉站,用Excel實現數據分析處理,然后導入系統進行數據信息的展示?我個人是較為傾向于前者的。
以一般的企業單位或者醫院等場所常見的值班為例,值班的業務場景在于某些需要在非正常工作時間有人值守,例如醫院值班室需要有護士24小時值班,它的細分場景很多,包括白班、中班、夜班、或者周內值班、周末值班、節假日值班等,而且這些細分場景時有交叉,比如周內白中夜三班倒、周末白夜兩班倒;
現在有兩種產品實現方案擺在眼前:
- 一種是調研業務場景、溝通業務需求,深究值班制度的背后邏輯,然后將業務及業務邏輯通過系統功能實現出來;
- 另一種是使用Excel表格制作值班計劃表,導入系統,系統僅提供信息分發及展示功能。
首先我們來分析一下第一種實現方式,深挖業務邏輯。
我們看一下關于值班的定義(該釋義來自于辭海之家),在辭典修訂版和辭典簡編版中關于值班的定義中,都有一個共同的詞語“輪流”,且根據我們日常生活中對于值班制度的實踐經驗來看,確實也是用的輪流方式,那么我們就可以得到關于值班制度的一個共性:就是輪流值班,即使是某個人一直負責值班,那么我們也可以理解為一個人輪流值班。
因為值班制度的存在,本身就是為了預防某些突發事件或者特殊情況而在需要勞動者在非常規工作時間下進行值守班次的,其報酬(一般稱為值班費、值班津貼等)標準要低于勞動者正常工作和加班情況下的勞動報酬,因此制度要合理穩定的執行下去的話,首要的前提就是公平值班,即輪流值班,否則引起勞動者心理不平衡就會導致值班制度的執行效果大打折扣。
而輪流方式在系統設計中我們可以通過設置值班順序去實現該功能(通常情況下手工制作的值班表也是按照值班順序進行排序的)。
如圖:
值班,值班,一方面是值,怎么去值,輪流去值,表示的是執行方式,另一方面是班,值的什么班,表示的是執行目標。接下來要確認的就是執行目標。
需要值班的班次根據業務場景的需要可細分為多種不同的班次,但是這些班次都有一個共同的特性,就是都是由時間段來劃分班次的,無論是白班夜班還是周內班和周末班都是以每天的某個時間段為一個班次的,那么我們是否可以通過設置班次的值班時間來控制這個過程?如圖:
通過設置班次名稱、班次時間(周內幾點到幾點、周末幾點到幾點)對班次進行約束,同時再綜合考慮請假、臨時調班、節假日是否值班、值班計劃調整后何時生效等情況加以調整,一個較為完整的值班設置低保真原型頁面就出來了:
點擊“預覽值班表”即可查看按照值班規則生成的值班表:
由此系統即可自動按照值班規則生成相應的值班計劃表了,再結合實際的開發過程和應用情況,對該功能做部分約束條件:
- 值班計劃表只生成當前月和下個月的值班排期,每個月自動更新一次計劃表(非值班記錄,值班記錄可以另行考慮);
- 當值班計劃發生改變時根據“生效日期”更新生效日期之后的值班計劃表;
- 自行調班的優先級大于系統排班的優先級,在一定時間內通過調班申請可以更新值班計劃表(比如可以提前1天發起調班申請)等等。
設置一次值班規則,在值班規則不變動的情況下基本可以不用考慮再次去制作值班表等信息,通過弱提醒發送信息給對應的值班人員,即可完成值班安排,省時省力省心。
第二種方式是通過EXCEL制作好接下來某個時間段的值班計劃表,導入系統中,系統僅執行信息分發及展示功能,待值班計劃快要到期時再由相應人員制作一份值班計劃表導入系統去完成值班表的更新。
這種方式的優點很明顯,開發簡單便捷,但是實際作用在哪里,是在信息分發和展示,而非值班安排,值班安排的業務是通過相應人員動腦思考,使用EXCEL這款產品的功能來實現的,做的是值班安排的產品,該產品的核心業務的實現卻是通過EXCEL來實現的,那么請問你做的是什么產品?
同時,這種方式的缺點也呼之欲出,產品最重要的功能是解決用戶需求,提升用戶體驗,用EXCEL把最主要的功能都做出來了,請問該方式做出來的產品解決了什么需求,用該產品和不用該產品的操作基本不變,該減少的工作量一點沒少,那如何靠該產品去說服用戶呢?
不可否認的是EXCEL這款數據工具產品功能的強大,但是對于數據業務類的功能設計并不僅僅在于數據,還在于業務,且重點是業務,數據的整理與分析其是為實現業務而服務的,不深究業務只停留在表面的數據是不可取的,這種舍本逐末的行為并不能給業務的進展帶來實質性的推動,因此,孰優孰劣,想必已見分曉了吧。
那么回到話題開始的地方,你是在做產品還是在做產品的搬運工?
本文由 @Sagittariu 原創發布于人人都是產品經理,未經作者許可,禁止轉載。
題圖來自Unsplash,基于CC0協議。
業務的不確定性,會讓這個系統死去活來..
產品的迭代就是為了解決這個問題,沒有一個系統可以百分之百的解決問題,但是一款良好的產品可以解決80%的問題,極大的提高工作效率,用戶是愿意用產品還是原來的方式?再通過迭代進行優化,可以解決90%的問題,用戶又會怎么去選擇?
SO,請你文章中描述清楚,按你文章中的思路做產品…客戶虐你千百遍..
可否賜教一二??我聽下您的高見
以此例來講,你覺得用什么思路去做產品好些呢?