B端簡單的任務(wù)管理模塊的搭建
筆者分享了搭建一個基礎(chǔ)的任務(wù)協(xié)同模塊中重要的部分和細(xì)節(jié)點(diǎn),具體可分為三個部分。讓我們來看看吧。
這段時間主要做了一件事情,重新改善了我們公司的產(chǎn)品中的一個任務(wù)協(xié)同模塊。當(dāng)然這個模塊并沒有像teambition這么龐大的以項(xiàng)目為主體的任務(wù)協(xié)同系統(tǒng),而是類似于今目標(biāo)、銷售易下的一個子模塊應(yīng)用。這個模塊雖然看似簡單,但是我在實(shí)際設(shè)計(jì)的時候,還是踩了不少的坑,需求方案總共經(jīng)過了兩次大改。到現(xiàn)在整體的框架已經(jīng)完成。
因此這篇文章的主要目的是對這段時間的一個復(fù)盤總結(jié),講一講我認(rèn)為在搭建一個基礎(chǔ)的任務(wù)協(xié)同模塊中重要的部分和細(xì)節(jié)點(diǎn)。
1. 構(gòu)成任務(wù)的成員
先從實(shí)際的場景出發(fā),在實(shí)際的工作中場景中任務(wù)形式會根據(jù)不同公司不同部門,任務(wù)形式會千差萬別。總結(jié)起來,大致有以下幾個場景。
場景一:發(fā)起人直接分配任務(wù)給責(zé)任人,并且發(fā)起人能夠?qū)崟r查看任務(wù)進(jìn)度和完成情況。
場景二:發(fā)起人發(fā)起任務(wù)給自己,即責(zé)任人是自己,但是需要一定的其他人員有查閱的權(quán)限。
場景三:發(fā)起人帶上級或者他人進(jìn)行發(fā)起,需要這個上級有查閱的權(quán)限。
1.1 發(fā)起人、責(zé)任人和參與人
在這三個場景中,發(fā)起人和責(zé)任人之間的關(guān)系有可能是上下級關(guān)系,也有可能是同部門的同事,或者發(fā)起人和責(zé)任人。在我們原先的產(chǎn)品任務(wù)模塊的發(fā)起的權(quán)限邏輯中,發(fā)起人在創(chuàng)建任務(wù)的時候能夠選擇責(zé)任人只能是自己或者直接下屬。但是這樣的設(shè)定太過死板并且是不符合實(shí)際的場景的。
這是任務(wù)模塊的第一個細(xì)節(jié)點(diǎn),即一個發(fā)起人在整個產(chǎn)品中是有其對應(yīng)的一個角色權(quán)限的,那么其在發(fā)起的時候能夠選擇的責(zé)任人是能夠在什么范圍內(nèi)進(jìn)行選擇呢?
回到場景,顯然發(fā)起人能夠選擇的責(zé)任人范圍應(yīng)該是能夠在全公司內(nèi)進(jìn)行選擇。要特別說明的是,這是在沒有項(xiàng)目組功能前提下。
再次回到場景,我們會發(fā)現(xiàn)實(shí)際的任務(wù)中并不常常是一個責(zé)任人在執(zhí)行完成任務(wù),往往是多個人員共同執(zhí)行一個任務(wù)。比如一個大掃除的任務(wù),往往是多個人共同完成拖地這個任務(wù)。
那么我們設(shè)計(jì)成可以選擇多個責(zé)任人可不可以?
答案是不行,我認(rèn)為原因有兩點(diǎn):
第一點(diǎn),設(shè)定成多個責(zé)任人之后,那么之后在分配任務(wù)相關(guān)的編輯權(quán)限時候,只能授予相同的權(quán)限,那么問題來了,如果擁有相應(yīng)權(quán)限的責(zé)任人到達(dá)一定數(shù)量很容易導(dǎo)致,任務(wù)進(jìn)度更新、狀態(tài)變更的混亂。
第二點(diǎn),多個責(zé)任人的設(shè)計(jì),會導(dǎo)致其他人找任務(wù)相關(guān)人員的時候找不到需要的人員,在界定責(zé)任的時候也容易造成混亂,這不符合這一模塊提高效率的需求目的。
那么為了解決這個問題,就需要另外增加一個“參與人”的選項(xiàng)。參與人類似一個弱化的,權(quán)限更低的“責(zé)任人”,因此與責(zé)任人一樣,發(fā)起人能夠在全公司的范圍內(nèi)進(jìn)行選擇,更重要的是能夠多選。因此,發(fā)起人、責(zé)任人和參與人三者構(gòu)成了任務(wù)核心。當(dāng)然參與人是不強(qiáng)制選擇的。
圖1.1明道云任務(wù)新增窗口
1.2 增加其他任務(wù)成員
在我們原先的任務(wù)管理模塊中,還有一個“審批人”的角色,這個角色在我們原原先的設(shè)計(jì)當(dāng)中有三個作用。
- 對任務(wù)發(fā)起進(jìn)行同意/退回。
- 對任務(wù)取消進(jìn)行同意/退回。
- 對任務(wù)的完成進(jìn)行同意/退回。
在分析競品的過程中我發(fā)現(xiàn),今目標(biāo)存在著這樣的一個角色。
圖1.2發(fā)起人對已完成的任務(wù)進(jìn)行審核
這個角色是由發(fā)起人重合的的,在責(zé)任人點(diǎn)擊完成任務(wù)之后,會有發(fā)起人對任務(wù)的完成情況進(jìn)行審核,是通過/不通過。
但是我們原先這樣的設(shè)計(jì)不僅笨重,而且會讓任務(wù)流程顯得太過于像一個工作流程。而今目標(biāo)雖然有審批人這個角色,但是因?yàn)槠涔δ芎唵危⑶遗c發(fā)起人重合,所以并沒有太過笨重。
圖1.3存在審批的任務(wù)主流程
在我們分析過后,我們認(rèn)為應(yīng)該直接刪除審批人這個角色和審批功能。不僅是出于讓任務(wù)更“輕”的目的。而是我們的產(chǎn)品面對企業(yè)是施工企業(yè),我們已經(jīng)有專門的模塊放置眾多詳細(xì)且復(fù)雜工作流程。不需要在這個模塊中與之重合.
圖1.4無審批的任務(wù)主流程
刪去了審批這個節(jié)點(diǎn)之后,任務(wù)流顯得十分清晰(不包含取消和修改)。
1.3 其他任務(wù)信息
任務(wù)其他信息內(nèi)容填寫,就是一些比較基本的東西,比如任務(wù)的名稱、任務(wù)內(nèi)容、任務(wù)重要級別、任務(wù)日期等等。
一個比較細(xì)節(jié)的地方在于,在新增的時候,會希望能夠給用戶一個足夠簡單直接內(nèi)容填寫。這是因?yàn)橐粋€任務(wù)的創(chuàng)建的時候,通常細(xì)節(jié)的部分并不一定已經(jīng)決定的十分清晰,同時創(chuàng)建任務(wù)越是簡單,用能夠降低用戶使用這個功能的成本,是符合任務(wù)管理提高效率的核心需求的。
圖1.5teambition任務(wù)新增
Teambition在創(chuàng)建任務(wù)的時候只要輸入任務(wù)主題,就能夠創(chuàng)建,甚至責(zé)任人都能在任務(wù)發(fā)起之后進(jìn)行選擇或是等人認(rèn)領(lǐng)。
這是一點(diǎn)交互的細(xì)節(jié),畢竟一個OA軟件的核心目標(biāo)之一就是提高效率,如果這個任務(wù)協(xié)同模塊顯得十分繁雜的話,也就失去一個原來的意義。
2. 任務(wù)狀態(tài)
任務(wù)有三種基本的狀態(tài):進(jìn)行中、已完成、已取消。
首先要說明的是任務(wù)狀態(tài)的是由兩個方面決定的。
第一,組成任務(wù)成員有哪些。比如上文如果增加了審批人。那么任務(wù)狀態(tài)至少需要增加一個“待審批”狀態(tài)。
第二,由是否增加“同意/拒絕”這個功能決定。比如,今目標(biāo)在發(fā)起任務(wù)之后,任務(wù)達(dá)到責(zé)任人手中時,需要責(zé)任人點(diǎn)擊同意才能。這樣就衍生出了兩個狀態(tài)。未同意/拒絕之前的“待接受”和拒絕之后的“已拒絕”。
我個人不同意增加多個任務(wù)狀態(tài),從“時間延遲”這個點(diǎn)考慮,每多加一個狀態(tài),就會讓“時間延遲”延長。想一想,要是最后審批人一直忘記審批,是不是任務(wù)就一直處于待審批的狀態(tài)了。
3. 角色權(quán)限
權(quán)限總的可以分為三種:任務(wù)取消、任務(wù)修改、任務(wù)完成、任務(wù)查閱。
我們先看看今目標(biāo)和明道云的權(quán)限怎么分配。
圖3.1今目標(biāo)和明道云的任務(wù)權(quán)限分配
可以看到相比于今目標(biāo),明道云的任務(wù)權(quán)限分配的更加廣泛一些。我們改善后的任務(wù)模塊是與今目標(biāo)一致,但是沒有審批和同意這個功能。對于角色權(quán)限的分配這一塊,基本上跳不出這個框架,在實(shí)際設(shè)計(jì)過程中還是要根據(jù)所面對的企業(yè)用戶來衡量設(shè)定。
4. 總結(jié)
在設(shè)定任務(wù)管理這個模塊中的時候,還是不能忘記B端產(chǎn)品中重要的角色權(quán)限和流程準(zhǔn)確的特點(diǎn)。
因此思考的時候,先確定任務(wù)成員,繼而在確定任務(wù)狀態(tài)和角色權(quán)限。要記住梳理完成之后,一定要重新在將各個流程過一遍。對于一些細(xì)節(jié),比如任務(wù)提醒,任務(wù)不同狀態(tài)下,各個成員所能決定的權(quán)限等等。都要準(zhǔn)確的定義下來。
作者:十一筆產(chǎn)品路上的新人,微信公眾號:產(chǎn)品汪的個人修養(yǎng)。我會定期發(fā)布自己的產(chǎn)品感想,渴望與你一起交流。
本文由 @ 十一筆 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可,禁止轉(zhuǎn)載
題圖來自Unsplash,基于CC0協(xié)議
關(guān)于「2.任務(wù)狀態(tài)-增加“同意/拒絕”功能」有一點(diǎn)想法:進(jìn)入到審批狀態(tài),代表責(zé)任轉(zhuǎn)移到審批人角色上,如果沒有審批狀態(tài),執(zhí)行人將有質(zhì)量問題的交付物直接流轉(zhuǎn)到下一個環(huán)節(jié),容易造成執(zhí)行人背鍋的情況;至于審批人忘記審批的場景,可以通過提醒機(jī)制來解決(自動提醒或其他角色手動提醒)。