本文作者依據自己項目實踐的具體案例，分享了任務管理産品的設計全過程以及具體思路，供大家一同參考和學習。

“效率”這個詞在工作中出現的頻率有多高，我相信大家也都了解，大多數效率低下的情況大多數是因為沒有合理的計劃和任務分配。

那麼如何提高單位時間完成的工作量，提高工作效率？

這就是任務管理工具的目的所在。

在清楚地知道目标之後，我不能夠馬上把原型、文檔全部安排上，更重要的是我需要先理解“任務管理”的業務含義。

在20世紀初，科學管理的方法由美國人弗裡德裡克·溫斯羅·泰勒提出，他詳細為記錄每個工作的步驟及所需時間，設計出最有效的工作方法，并對每個工作制定一定的工作标準量，歸劃為一個标準的工作流程：将人的動作與時間，以最經濟的方式達成最高的生産量。而泰勒在科學管理理論中所倡導的管理方法其實就是現在的任務管理法。

一、産品整體設計

在對任務管理有一個初步的理解之後，就可以開始發散思維了。

所以我可以使用思維導圖先把我理解的任務管理工具搭出來，之後再慢慢進行調整。

我先搭建一個MVP，在實際開發之前我需要有一個最低成本的試錯方案。

但是在思考一下以上關于任務的架構來說，這樣的設計未免太過簡陋了，如果我們自己團隊搭建一個系統自己使用的話也還湊合，如果要把這當成一個市面上的産品推廣出去肯定是沒法正常使用的。

二、産品定位

在清楚業務之後，我們需要先解決一些問題：

1. 我們的産品能解決用戶什麼需求？

那我們要怎麼做才能get到用戶的痛點呢？

我們先假設用戶需要一款工具提高他們的工作效率，我們都知道工作效率=工作量÷工作時間，在工作量不變的情況下，節約了工作時間，那工作效率就提上去了。

那麼有什麼情況會導緻時間的浪費呢？

1. 工作沒有形成流程，工作雜亂無章，缺少團隊配合；
2. 工作沒有計劃。所謂磨刀不誤砍柴工，研究顯示每天花10分鐘時間制定工作計劃，可以節約2小時的工作時間；
3. 在任務分配不當的情況下，缺少靈活調整機制，導緻問題一直擱置直到無法解決的處境。

所以我們的産品需要做的就是幫助用戶節約工作時間，提高工作效率，同樣的，企業也能夠節約人力成本。

2. 我們的産品面向怎樣的用戶群體？

基于第一個問題，我們把産品用戶定位于服務互聯網中小企業。

首先，選擇中小企業的原因主要是因為我們就大型企業調查顯示，大型企業對人員管理、任務管理基本有自己的一套流程，他們更趨向于定制化并且很多已經搭建了自己的管理工具，所以就我們團隊本身的開發資源和大型企業的獲客成本考慮，我們至少在初始階段暫時pass了大型企業的情況。

其次，任務管理在很多行業都是行得通的，我們選擇從互聯網入手有兩個原因：

第一，B端的産品相對于C端需要更多的學習成本，與之相對應，互聯網公司的學習氛圍是高于其它傳統公司的；

第二，互聯網開發流程，從需求的提出到項目的上線，在開發過程中所運用的模式和任務管理的模式是相匹配的。

3. 對比市面上的競品，我們有什麼優勢或劣勢？

先說優勢，我們公司除了我們團隊之外還有很多其它項目的開發團隊，就是說我們可以先在公司内部推廣，在産品疊代成熟之後才走向市場，相當于說我們是自帶種子用戶的。

并且，公司在發展過程中積累的資源可以為産品帶來一些價值。

再說劣勢，現在市面上已經有成熟的産品，作為晚輩，我們肯定不能太過造次，也造不了什麼次，我們肯定沒辦法一開始就在功能層面上和競品硬剛，而且就單單任務管理我們也沒辦法和其它産品競争的。

所以，我們計劃增加産品的可擴展性，并以任務管理為核心将其它工具引入我們的産品，目的在于以低成本效率工具作為切入點進入市場。當然了，必須先把核心功能做好。

三、系統框架

B端産品的整體設計講究體系性和結構性，我們可以采用先總後分的形式，先考慮大體的功能再慢慢填充細節。基于産品定位，重新梳理一下思維導圖。

我們可以發現産品的藍圖已經豐滿了一些，在設計任務管理工具的時候不要隻把目光局限在這個點上，我們可以多考慮一些其它方面，像基礎功能、項目管理都是根據核心功能任務管理衍生出來的。

在把框架搭好之後，我們就可以先對核心功能開始細節設計。

四、産品細節設計

在系統框架定下來之後，接下來的工作就是基于産品藍圖，逐一分析業務細節，設計産品的具體功能。

這時候就如同建造一棟房子，我們已經把房子的地基打好了，鋼筋水泥也安排上了，怎麼讓這個房子看起來更美觀、住起來更舒服就是現在該做的事情。

1. 流程

任務管理流程方面有兩種設計思路：

一種是系統默認配置流程，用戶直接使用就可以，優點是減少用戶自助配置流程産生的學習成本，缺點是系統的靈活性降低，用戶個性化流程的需求無法達到滿足；

另一種是用戶自助配置流程，優缺點和第一種方法的相反。

在項目前期，我們優先選擇了第一種設計思路，原因如下：

1. 在項目上線初期，我們不希望用戶一進系統就被一堆複雜的概念和流程逼走，而是用輕量化的設計和簡易的操作流程把用戶留住，盡量降低用戶的學習成本；
2. 自定義流程的開發成本遠遠大于系統默認流程的開發成本；
3. 我們将用戶定位在互聯網中小企業，因為他們的開發流程相對簡單，系統默認流程配置就可以滿足用戶的需求。

在需求調研初期，我們先了解用戶在開發過程中所涉及到的角色，主要包括項目經理、産品經理、開發人員、測試人員、UI設計師等。

比如項目經理需要給開發人員分配任務，産品經理需要把需求告訴測試人員，我們發現不同的角色在流程中可能處在一個相同的節點，所以我們可以根據不同的場景把角色稍加整合并将任務分為四個節點，分别為任務創建人、任務處理人、任務審核人、任務結束。

這樣的話，我們就可以處理一下這些節點的關系，比如任務創建人分配任務給任務處理人，任務處理人完成任務之後把任務給到任務審核人審核，任務審核人審核通過之後任務結束。

在把主流程确定下來之後，就可以确定其它子流程了。

2. 權限

設置權限的目的是為了明确任務管理工具的“管理”功能，而且管理者和被管理者應該擁有不同的權限設置。

不過，一個管理者對應多個被管理者的情況很常見，多個管理者對應多個被管理者的情況也是存在的，所以在管理者前面我們設置了超級管理員，超級管理員隻能有一個，擁有系統中的所有權限。

在最開始設計權限控制的時候，我們沒有把權限控制的範圍縮到最小，而且采用了“項目總監”、“項目經理”、“産品經理”這樣的名稱來進行權限設置，這就導緻了權限被多次分割，不同的角色的權限重疊程度高，這就是設計事故了。

後來整合不同角色的權限還不得不多花了一些時間，也更加明白了權限的控制是為了用戶更好地使用工具，切忌在設計初期就制定多個不同維度的權限區分導緻用戶權限混亂。

3. 字段

字段和我們的業務挂鈎，在對業務的提煉中，我們可以知道在提交任務的時候，我們要知道“這是個什麼任務？這個任務應該由誰來完成？”所以，任務名稱和任務處理人是必不可少的，是提交任務的必填項，但這還不足以完整地诠釋任務的含義。

4. 計劃時間

大家都知道，制定工作計劃的重要性是毋庸置疑的，沒有計劃的工作就想拿着一把鈍刀砍柴，雜亂的工作内容會讓我們不知道應該在什麼時間點做什麼事情。

所以，計劃時間對于任務來說是重要的，管理者可以根據計劃時間判斷被管理者的工作情況。

5. 優先級

每個人的工作時間都是有限的，但是為什麼别人能夠在相同的時間内獲得比較多的工作成果呢？

在時間管理理論中一個核心的點就是四象限法則，這個法則把要做的事情按照緊急、不緊急、重要、不重要的排列組合分為四個象限，包含緊急且重要的事情、緊急不重要的事情、重要不緊急的事情、不緊急不重要的事情。

我們将四象限法則加入我們的系統，并将其濃縮為急、高、中、低四個優先級。

項目成員在工作時可以根據實際情況确定工作的重點，優先處理相對較急的任務，這樣的話，即使工作時間有限也可以在工作中生産最大的價值。

6. 任務狀态

“這個任務是待解決還是待審核”，任務狀态可以給管理者和被管理者一個反饋的作用，表明這個任務還沒有結束，還需要有人去處理或者審核這個任務。

7. 任務類型

同類的工作放在一起做可以大大減少工作時長、提高工作效率。反之，雜亂無序的工作任務再加上突發的情況，很有可能讓我們感到頭大并且削減我們的工作熱情。

我們将不同類型的任務加以區分，不管這個任務是處理BUG還是分析需求，這都是對任務的分類，方便任務的處理人對不同類型的任務進行統一處理。

五、從0到1之後

在産品設計完成、開發完成、産品上線、産品開始推廣之後，我們面臨越來越多的問題、越來越多的需求、越來越多的挑戰，這時候我們才發現這隻是我們邁出的第一步，前面的道路如何我們未曾知曉，等到走過了自然也就知道了。

作者：yoge，MadPecker産品經理。

本文由 @yoge 原創發布于人人都是産品經理，未經許可，禁止轉載

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

,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!

查看全部