從無到有：任務狀態與工作流的設計思路
不管是專案協作還是處理事務，都會包含著一些基本的業務流程。如何有效地將專案有條不紊的進行，不妨瞭解一下任務狀態與工作流的設計思路。
一、概述
無論你的公司是採用郵件還是專案管理工具進行專案協作，處理工作都會包含著一些基本的流程——從想法的提出到最終交付物的產出，或是計劃的擱置。我們把這些任務所處生命週期的節點稱為【任務狀態】，而任務在狀態之間的流轉稱為【工作流】。
那麼，關於任務狀態和工作流的設計過程中，我們還有哪些思考和選擇？請看下文。
二、為什麼引入【任務狀態型別】？
Worktile7.0引入了【任務狀態】的概念，並且支援自定義，也就是說客戶可以根據自己的實際工作場景配置任務狀態。
但是，這回帶來一個問題：如果對每一個任務狀態都加以區分，那麼在報表、統計等環節（例如統計任務的延期率），將極大的增加配置的複雜度。
實際工作中，我們會意識到：進行中的狀態，可以有“設計中”“開發中”等自定義任務狀態，但是其本質都是已開始但未完成的狀態。所以，雖然客戶自定義的任務狀態千變萬化，但他們必屬於三種基本【任務狀態型別】，即 ：未開始／進行中／已完成。
如圖1所示：開發和銷售任務的狀態有很多，但是都屬於三種任務狀態型別。
圖1:以開發和銷售的任務狀態為例
【任務狀態】體現在展示層面，而【任務狀態型別】則體現在資料層面。例如，在【配置報表】的過程中，如果我們對狀態進行統計和篩選的話，篩選值的設定將限於三種基本任務狀態型別。
三、為什麼預設任務狀態是必選？
任務狀態和任務流代表的是工作的流程，所以任務狀態不能為空，我們必須設定預設任務狀態——也就是定義一個新建任務，它的初始狀態是什麼。
在任務狀態設定的過程中， 我們必須選定一個狀態為預設狀態。
例如推送型別的任務，其初始狀態為【未開始】。
圖2：【狀態設定】介面
四、任務狀態管理是統一還是分散？
在第一篇設計思考中，我們曾提到中庸化的思維。所以，我們並沒有選擇給每個任務型別設定自己的任務狀態庫。但是，任務狀態有兩個特點：
- 任務狀態與任務型別相關，它本身就是一種分組形式；
- 任務狀態的數量不會特別多。
綜上，我們最終選了統一管理的形式，通過【狀態管理】統一增刪改，配置任務型別的時候呼叫即可。
圖3: 從【狀態管理】中進行選擇任務狀態進行配置
五、工作流如何構成
介紹完任務的狀態，我們可以開始介紹任務狀態之間的流轉——即工作流了。
在此之前，我們以Worktile運營同學推送文章為例幫助讀者有一個基本認知。一個推送型別的任務，建立之後的預設狀態為“未開始”，通過一系列流程和動作，最終流轉到“已釋出”的狀態。未開始不能直接到“已釋出”，這與現實工作的流程不符，而設計中的狀態則可以。
推送任務的工作流如圖4所示：
圖4:運營推送任務的工作流
一個完整的工作流由以下基本元素構成：
- 轉化名稱： 幫助成員理解該轉換的含義
- 起始狀態： 工作流的初始狀態
- 目標狀態： 工作流的最終狀態
- 流程條件： 對此流程進行操作的許可權條件
- 動作設定： 工作流轉後發生的動作
要設定一個工作流，我們需要明確這些元素（流程條件和動作設定不是必須）。
要合理配置工作流，我們需要注意以下兩點：
- 工作流是單向的； 工作流的起始狀態和目標狀態決定了這個工作流，所以當二者互換位置之後，就成了一個新的工作流。所以說工作流是單向的，如果我們需要一個反向工作流，則需要重新新增。
- 工作流與任務型別的對應關係； 同一個任務型別對應多個工作流，而一個工作流只對應唯一的任務型別。
結語
不同專案中的不同型別事情，會有不同的執行流程。如果缺乏有效的專案管理工具，哪怕專案干係人都清楚專案流程，但是在專案的執行、回顧和優化過程中，仍會面臨諸多困難。
同時，缺少一種承載物，任務執行中或多或少地都會帶有“人情”因素，導致執行不力。
#專欄作家#
袁林，人人都是產品經理專欄作家。分享SaaS運營和企業管理／協作／辦公的相關知識
本文原創釋出於人人都是產品經理。未經許可，禁止轉載。
題圖來自 Pexels ，基於 CC0 協議