Soking 來信：任務步驟分析不是流程介紹，而是模組化思考

哈囉，朋友

在規劃產品服務的過程中，使用者流程（ Userflow ）的任務設計是相當重要的工作項目，然而任務設計的顆粒度該如何拿捏，一直是相當難說清楚的事情。

糟糕的任務步驟描述，可能會如流水帳一般缺乏重點，例如：

煎蛋餅：取出蛋餅皮→鍋子開火預熱→倒油→煎餅皮→準備蛋→把蛋攪拌均勻→預煎的蛋餅翻面→蛋餅起鍋→倒入蛋液→放上蛋餅→蛋餅翻面→摺疊蛋餅→起鍋→剪裁成適合入口大小→完成

上述這類任務步驟的描述方式，充滿了瑣碎的細節，乍看之下似乎是一份詳實的記錄，但對於觀看者來說很常迷失在細節中，不容易掌握整體。

我們重新整理一次這個煎蛋餅的任務：

上面流水帳記錄用了十五個步驟來描述，經過整理其實只需要四個步驟即可歸納出煎蛋餅這個任務的重點。

問題在於，我們該如何切割出適當顆粒度大小的任務步驟呢？

有三個參考原則可以幫助你做出很好的判斷：

▋任務分析原則一：可獨立 ▋

如果有一個任務你必須與其他角色合作才能完成，那這個任務至少可以拆解成好幾個小任務。

例如你今天要申請加入某個社團，需要填寫申請單並且通過審核才能加入。

那麼這個任務就不僅僅是「加入社團」就結束，而是需要 A 填寫申請單，然後 B 審核，才能夠完成「加入社團」的整件事情，因此至少需要兩個任務才能描述清楚。

可獨立原則的判斷重點在於角色，一個任務過程如果需要依賴他人才能完成，就必須拆分成幾個適當的小任務各自描述角色應該完成的行為。

如果你在任務步驟描述中沒辦法交代這個任務達成的驗收標準，那這個步驟描述是沒有意義的，因為你沒辦法判斷是否達成。

可交付的原則可以很好的幫助你評估「一個任務步驟」應該包含的顆粒度大小。

有些任務步驟看似複雜，然而你如果只完成部分，對整體任務進度來說是沒有推進的意義。

以煎蛋餅任務的描述為例，我們再複習一次流水帳版本：

如果你只拿出了餅皮就結束行動，從整個煎蛋餅的任務角度來看，材料只蒐集了一半。例如你是廚房中負責備料的人，而你只拿餅皮給負責煎台的人，對方是沒有辦法繼續任務的。

因此從煎蛋餅的整體任務目的來看，必須要湊齊所有的食材（餅皮與蛋），一起交付出去，對於後續的任務流程來說才有辦法推進。

即使你為了拿這個餅皮找遍了冰箱、出去採買、與五十個殺手搏鬥、被狗追，只要缺少了蛋，從煎蛋餅的任務目的來看，任務的進度就會卡住。

可交付原則幫助你從整體目的來明確的定義任務進度，而不是被眼花撩亂的行為細節蒙蔽。

如果你今天的任務是要從家裡移動到公司，那麼走路、騎腳踏車、騎機車、開車、搭捷運等等選擇，都可以滿足這個任務的要求，只是你會付出不同程度的代價。

可置換原則在產品服務規模化的過程相當重要，它讓你的產品服務具備更大的彈性、承受風險以及發展空間。

例如你在電商購買東西，在「收貨」這個任務上，你可能選擇超商取貨，或者直接宅配到家，這些方案可能滿足不同用戶的情境需求，因此能擴充服務的彈性。

只要「收貨」這個任務可以被明確的模組化，順利銜接整體服務的前後步驟，持續擴充不同的收貨方式，也就能符合不同階段商業模式發展的需求。

如果你在評估可置換原則的時候發現了困難，例如某一個任務或工序只能由特定的人或工具來處理，這通常也是你的產品服務發展的瓶頸。

換句話說，只要你的產品服務某一流程綁定在特定的人或工具上，如果某一天這個特定的人消失，或是該工具沒有人能夠提供或維護，你的產品服務也就會跟著瓦解。

在軟體產業來說，可能是過度依附於某個大型服務的生態系，例如以前過度仰賴臉書的遊戲公司。

或者過度仰賴 Google 地圖、LINE chatbot 的某個 API，當這些被你視為基礎建設的服務改變了使用規則，你的產品服務就危在旦夕。

對於不同產業的產品服務來說，仰賴單一供應商的風險也非常清楚。

即使在產品的發展初期不得不仰賴特定的對象，但是如果能在任務步驟分析的時候就適度的抽象化，保留可置換的空間，你還是有機會尋求不同的解決方案來抵消產品服務斷炊的風險。

以上三個原則分享給你，希望能幫助你更好的判斷任務步驟分析該如何模組化思考。

by Soking