產(chǎn)品設(shè)計 | 對任務(wù)、項目管理設(shè)計的理解
項目管理,任務(wù)管理是一個已經(jīng)被各個產(chǎn)品玩爛了的概念,但是玩爛了并不意味著玩好了~即便是目前的網(wǎng)絡(luò)上充斥著各式各樣的這類工具,每個工具都有著自己的側(cè)重點,但是如果想要拿來去套上我司的場景來用,似乎都顯的很乏力~為啥~用戶場景太多太復(fù)雜~簡單的玩不轉(zhuǎn),復(fù)雜的又難用~
那要怎么搞?!
在做這部分之前,我們多次走訪了核心用戶,聽他們對產(chǎn)品的設(shè)想,對產(chǎn)品的需求,設(shè)計方案更是一改再改,但是似乎總有一些場景讓我們的設(shè)計無法應(yīng)對,總有一些場景我們無法去滿足~很頭疼~
現(xiàn)在回想過來,我們當(dāng)時陷入了一個為了解決單個問題而設(shè)計的誤區(qū),針對用戶的問題一個一個去解決,是不會形成一套完整有效的方案的。
沒有全局的視角~永遠不能解決核心的問題。
靈感
Phabricator
當(dāng)Phabricator引入到公司后,這種新式的玩法刺激了很多人的神經(jīng),大家開始研究它與其他工具的不同,能夠讓facebook用來作任務(wù)管理的軟件,絕對不會只是因為它能夠跟git、代碼關(guān)聯(lián)這么簡單~
個人認為Phabricator之所以能夠玩轉(zhuǎn),是因為它將任務(wù)與項目進行了解耦,很多工具對于任務(wù)的認知,認為任務(wù)必須依托于項目而存在,總要有一個space去承載它。殊不知,這本身就是一個很強烈的綁定。在phabricator中,任務(wù)不在需要這種強烈的綁定,任務(wù)與項目變成了同級關(guān)系,中間只是一個簡單的類似于tag的簡單關(guān)聯(lián),并且隨時可以解開。這樣任務(wù)就變成了一個單體,用戶不需要奔走于各個項目之間來看自己的任務(wù),只需要在任務(wù)頁面,就可以掌握這些任務(wù)的歸屬。
Redmine
我們團隊一直在用Redmine,雖然在用戶體驗方面,很多同學(xué)都有吐槽,但是redmine在任務(wù)管理上的設(shè)計,充分說明了它對任務(wù)這個名詞的理解。用過Redmine的同學(xué)都知道,Redmine里面最常見的兩個對象:項目和issue。所有的一切都是issue,無論你是需求、是任務(wù)、是bug~Redmine只認為這是issue的一個屬性,僅此而已,可以去更改,可以去變化,但是內(nèi)容還是那個樣子。
Redmine提供的另外一個很有效的設(shè)計,就是父子產(chǎn)品和父子任務(wù)的概念,市面上很多項目管理的工具都將沒有對這部分概念做過多的介入,因為一旦有了父子級,產(chǎn)品界面的展示、父子之間的繼承、產(chǎn)品中的各類配置都將明顯的提升產(chǎn)品的復(fù)雜度,尤其是大部分產(chǎn)品中,任務(wù)與項目都是有著強烈的綁定關(guān)系,這樣會更加限制任務(wù)的創(chuàng)建,用戶查看任務(wù)的視角將會變的更加跳躍。
發(fā)現(xiàn)
結(jié)合這兩個產(chǎn)品對于項目、任務(wù)管理的理解,以及分析了諸如Teambition、Worktile、trello~等任務(wù)、項目的管理工具,結(jié)合我司特有的用戶場景,我們發(fā)現(xiàn):
- 解耦任務(wù)與項目之間的關(guān)系很重要。
- 同時我們也發(fā)現(xiàn),所謂的任務(wù)、需求、缺陷等等只不過是任務(wù)的一個屬性,我們無需去限制用戶提交的是什么,用戶可以根據(jù)自己的定義來確定它的類別。
- 在項目與任務(wù)的層級上,添加一層父子關(guān)系可以更有益于用戶對于項目和任務(wù)的分類和擴展,也更能符合我們用戶的使用場景。
- 標(biāo)簽是一個有效的分組工具,我們曾經(jīng)嘗試讓用戶自己去分組管理自己的任務(wù)、項目,但是發(fā)現(xiàn)很多場景下,任務(wù)可能需要出現(xiàn)在多個分組中,常見的分組模式無法滿足這些需求。但是分組、分類這種管理方式又存在其特有的便利性,這時我們引入了標(biāo)簽,標(biāo)簽可以看成是一個很輕量級的分組方式,同時其帶來的可讀性并不比分組來的差,擴展性反而更強。
設(shè)計
任務(wù)部分
綜合上述結(jié)論,我們對任務(wù)做了如下的設(shè)計:
- 輕量化任務(wù)的創(chuàng)建過程,給任務(wù)賦予更多的屬性類型,例如需求、缺陷,讓任務(wù)面向的用戶群更加廣。
- 解耦任務(wù)與項目的關(guān)系,任務(wù)可以不依賴于任何項目、任何產(chǎn)品而存在。同時,任務(wù)又可以關(guān)聯(lián)到多個產(chǎn)品和多個項目。
- 任務(wù)可以拆解成多個子任務(wù),為了避免層級關(guān)系過于復(fù)雜,我們只保留但是一層父子關(guān)系,子任務(wù)默認繼承父任務(wù)的部分屬性。
- 允許任務(wù)添加標(biāo)簽,打標(biāo)簽的操作完全放開給用戶。
- 在展示上,我們一改長久以來“列表”對于工具類產(chǎn)品的統(tǒng)治,采用新的item方式展示任務(wù)列表以及父子級的展示效果。
- 色彩上,通過顏色來區(qū)分任務(wù)的不同類型(當(dāng)然顏色是參照我們自己的規(guī)范來確定的)。雖然標(biāo)簽可以通過不同顏色來表示,但是為了保證界面的整潔度,對于標(biāo)簽我們?nèi)坎捎幂p量的方式處理。
項目部分
對于項目而言,除了在展示上面繼承了任務(wù)的設(shè)計之外,我們還對項目進行了如下的設(shè)計:
- 我們認為項目只是一個任務(wù)的容器,用來更好的聚合、管理任務(wù),并向管理層反饋項目的進度等等。所以項目沒有過多的狀態(tài)點,open、close足矣~
- 我們依然認為,項目是公司內(nèi)部進行開發(fā)協(xié)同的最常見的方式,所以項目的創(chuàng)建跟任務(wù)同級,且更加輕量。同時,為了避免大小項目同級泛濫的情況,我們提供一級父子關(guān)系,讓用戶更清晰的管理自己項目之間的關(guān)系。?
- 在項目管理的多數(shù)工具中,我們都發(fā)現(xiàn)了看板的功能,其便利性和可視性都得到了大部分用戶的認可。這類視圖可以給管理者一個很好的感知,感知到當(dāng)前項目的進展,然后根據(jù)進展來協(xié)調(diào)資源等。這里,我們除了提供了一些必要的篩選,還將任務(wù)的狀態(tài)與看板做了結(jié)合(當(dāng)然,非強制的),拖拽任務(wù)的同時更改掉任務(wù)的狀態(tài)。
其他
當(dāng)然,上述的設(shè)計點大部分面向普通用戶,對于一些高級功能的設(shè)計,比如自定義字段的定義和使用,比如高級查詢以及搜索條件的保存,比如看板的隱藏與顯示等等,我們將這些高級功能進行了必要的隱藏。對于高級用戶而言,這些功能將會提供定制化的便利性,從而實現(xiàn)他們對于產(chǎn)品的要求。
產(chǎn)品總結(jié)
所以,將對項目、任務(wù)的設(shè)計進行總結(jié),項目管理應(yīng)該具有的特點:
- 輕量:任務(wù)、項目將會已非常簡單快捷的方式創(chuàng)建,不會有任何高不可攀的用戶門檻。
- 解耦:任務(wù)不再與項目強制綁定,他們之間的關(guān)系不再是上下級之間的包含,而變成了同級之間的關(guān)聯(lián)。
- 可見:我們將會看到一個層級明確,結(jié)構(gòu)清晰的項目或任務(wù)的列表,將會通過面板來實現(xiàn)任務(wù)狀態(tài)的展現(xiàn)以及項目進度的把控。
- 擴展性強:沒有傳統(tǒng)意義上的分組,沒有特殊的定制化功能,通過標(biāo)簽來實現(xiàn)對任務(wù)的分類,通過自定義字段來滿足不同用戶定制化的需要。
通過這些特點,賦予用戶更多的可玩性,讓任務(wù)管理與后續(xù)的開發(fā)流程不在強制綁定,讓各類用戶更加專注自己的工作。
個人感觸
- 靈活,是讓用戶能夠通過我們提供的功能,形成自己的使用習(xí)慣,就像是樂高積木一樣,我們提供多種素材,怎么玩,看用戶自己,我們需要保證的,就是用戶在玩的過程中,不會因為產(chǎn)品的限制而玩不下去,不會因為產(chǎn)品的用戶體驗而放棄這個玩具。
- 不失準(zhǔn)則,是在滿足大部分用戶的場景下,減少定制功能的產(chǎn)出,功能只要產(chǎn)出,就需要在產(chǎn)品中占據(jù)一定的位置,而這些定制功能,并不能夠給大部分用戶帶來便利,相反,如果放在界面中,甚至?xí)鹈曰蟮男Ч?,這就需要我們?nèi)允刈约旱脑O(shè)計準(zhǔn)則,在兩者不可兼顧的情況下,遵循二八原則,產(chǎn)品,并不是為了所有人設(shè)計的。
靈活而不失準(zhǔn)則,與諸位奮斗在需求海洋中的設(shè)計師共勉~
本文由 @fengyunzyl?原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理?,未經(jīng)許可,禁止轉(zhuǎn)載。
- 目前還沒評論,等你發(fā)揮!