從無到有:任務狀態與工作流的設計思路

2 評論 21473 瀏覽 126 收藏 7 分鐘

不管是項目協作還是處理事務,都會包含著一些基本的業務流程。如何有效地將項目有條不紊的進行,不妨了解一下任務狀態與工作流的設計思路。

一、概述

無論你的公司是采用郵件還是項目管理工具進行項目協作,處理工作都會包含著一些基本的流程——從想法的提出到最終交付物的產出,或是計劃的擱置。我們把這些任務所處生命周期的節點稱為【任務狀態】,而任務在狀態之間的流轉稱為【工作流】。

那么,關于任務狀態和工作流的設計過程中,我們還有哪些思考和選擇?請看下文。

二、為什么引入【任務狀態類型】?

Worktile7.0引入了【任務狀態】的概念,并且支持自定義,也就是說客戶可以根據自己的實際工作場景配置任務狀態。

但是,這回帶來一個問題:如果對每一個任務狀態都加以區分,那么在報表、統計等環節(例如統計任務的延期率),將極大的增加配置的復雜度。

實際工作中,我們會意識到:進行中的狀態,可以有“設計中”“開發中”等自定義任務狀態,但是其本質都是已開始但未完成的狀態。所以,雖然客戶自定義的任務狀態千變萬化,但他們必屬于三種基本【任務狀態類型】,即:未開始/進行中/已完成。

如圖1所示:開發和銷售任務的狀態有很多,但是都屬于三種任務狀態類型。

圖1:以開發和銷售的任務狀態為例

【任務狀態】體現在展示層面,而【任務狀態類型】則體現在數據層面。例如,在【配置報表】的過程中,如果我們對狀態進行統計和篩選的話,篩選值的設定將限于三種基本任務狀態類型。

三、為什么默認任務狀態是必選?

任務狀態和任務流代表的是工作的流程,所以任務狀態不能為空,我們必須設置默認任務狀態——也就是定義一個新建任務,它的初始狀態是什么。

在任務狀態設置的過程中,我們必須選定一個狀態為默認狀態。

例如推送類型的任務,其初始狀態為【未開始】。

圖2:【狀態設置】界面

四、任務狀態管理是統一還是分散?

在第一篇設計思考中,我們曾提到中庸化的思維。所以,我們并沒有選擇給每個任務類型設置自己的任務狀態庫。但是,任務狀態有兩個特點:

  1. 任務狀態與任務類型相關,它本身就是一種分組形式;
  2. 任務狀態的數量不會特別多。

綜上,我們最終選了統一管理的形式,通過【狀態管理】統一增刪改,配置任務類型的時候調用即可。

圖3: 從【狀態管理】中進行選擇任務狀態進行配置

五、工作流如何構成

介紹完任務的狀態,我們可以開始介紹任務狀態之間的流轉——即工作流了。

在此之前,我們以Worktile運營同學推送文章為例幫助讀者有一個基本認知。一個推送類型的任務,創建之后的默認狀態為“未開始”,通過一系列流程和動作,最終流轉到“已發布”的狀態。未開始不能直接到“已發布”,這與現實工作的流程不符,而設計中的狀態則可以。

推送任務的工作流如圖4所示:

圖4:運營推送任務的工作流

一個完整的工作流由以下基本元素構成:

  • 轉化名稱:幫助成員理解該轉換的含義
  • 起始狀態:工作流的初始狀態
  • 目標狀態:工作流的最終狀態
  • 流程條件:對此流程進行操作的權限條件
  • 動作設置:工作流轉后發生的動作

要設置一個工作流,我們需要明確這些元素(流程條件和動作設置不是必須)。

要合理配置工作流,我們需要注意以下兩點:

  1. 工作流是單向的;工作流的起始狀態和目標狀態決定了這個工作流,所以當二者互換位置之后,就成了一個新的工作流。所以說工作流是單向的,如果我們需要一個反向工作流,則需要重新添加。
  2. 工作流與任務類型的對應關系;同一個任務類型對應多個工作流,而一個工作流只對應唯一的任務類型。

結語

不同項目中的不同類型事情,會有不同的執行流程。如果缺乏有效的項目管理工具,哪怕項目干系人都清楚項目流程,但是在項目的執行、回顧和優化過程中,仍會面臨諸多困難。

同時,缺少一種承載物,任務執行中或多或少地都會帶有“人情”因素,導致執行不力。

#專欄作家#

袁林,人人都是產品經理專欄作家。分享SaaS運營和企業管理/協作/辦公的相關知識

本文原創發布于人人都是產品經理。未經許可,禁止轉載。

題圖來自 Pexels ,基于 CC0 協議

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. @@@@@@@@

    回復