「DAY15」分析流程痛點與故事板：三大法則

幫助筆者更快速的理清接下來所要講的內容，所以筆者引用架構並加以改良更適合數位轉型場景

筆者近期拜讀了[WEB API設計原則-API與為服務傳遞價值之道]，深有感觸，其中第四章-產生活動與步驟內容所講的思維和概念，可以幫助筆者更快速的理清接下來所要講的內容，所以筆者引用架構並加以改良更適合數位轉型場景。

軟體開發者總是花費大量的時間在擊習，學習那些他們未知的東西，遠其他工作截然不同，因為我們的每一次總是我們的第一次（儘管在外人看來都是在敲鍵盤）。

—Alberto Brandolini

傳統紙本流程的痛點

過去的我們，以在學校單位來講，假定一份公文需要經過5個處室、7個人過簽核(這算少了)，先不論是否有神秘力量讓公文消失的問題，光是要跨處室轉運來講，這就是一個大工程，如果一個處室下午收發一次公文，是不是一天只能過一個處室，再加上有可能承辦人休假開會等等問題，平均一份公文在一個人身上，要押上1-3天的時間，

第一法-ADDR流程

ADDR流程，包含對齊、定義、設計、優化，

將活動解構成步驟

第二法-JTBD

Jobs To Be Done,JTBD（需要完成的工作），是由一位哈佛商學院教授 Clayton Christensen 所提出的觀念，是在建構產品或服務時，那些已明確知道必須完成的事。透過深入了解人們在特定情境下所需完成的工作或任務，用戶有那些問題、解決間題需要完成哪些事項，以及解決間題之上的整體目標等等的課題，企業可以更好地滿足這些需求，從而提供更有價值的解決方案。

從流程規劃的角度看，應用JTBD方法如下：

1. 識別主要任務： 確定用戶尋求流程規劃的情境，如業務擴張、效率問題等。
2. 定義目標： 明確客戶希望實現的目標，如提高生產力、降低成本。
3. 分析現況： 瞭解用戶在流程規劃中的挑戰，以及目前可能的方法。
4. 創建解決方案： 根據主要任務和目標，制定改進方案，如引入新工具或自動化流程。
5. 測試和優化： 實施方案後監測效果，並根據反饋調整，提供更有價值的解決方案。

JTBD中的JOB「工作」不單單指傳統意義上的工作，還包括工作的目標和成果。這些工作可以是全新的、待處理的，也可以是已存在的、或者用戶不滿意的。在這個理論中，從零到有的元素，能夠使產品滿足用戶需求的所有要素，都可以被視為「工作」。

克里斯坦森（Christensen）表示產品不僅僅需要滿足功能需求，還應考慮用戶的整體體驗以及社會因素。這裡所謂的體驗不僅僅指硬性功能，更關注用戶在使用過程中所感受到的愉悅和滿意。換言之，除了基本功能，產品也應設計為讓用戶感到舒適、輕鬆，而非困惑和緊張。有時候，我們需要思考如何讓用戶在使用產品時心情愉悅。

對於一般用戶而言，他們並不關心技術細節，如流程邏輯、服務架構、無服務器計算、框架等。他們關心的是，誰能幫助他們解決問題，最終實現他們的目標和需求。

第三法-工作故事

在JTBD理論的背景下，Alan Klement提出了工作故事的概念，成為我們定義「工作要完成的任務」的有力工具。透過工作故事，我們能夠更加著眼於目標和用戶，並為其提供服務。此外，工作故事還可以用於編寫測試腳本。然而，請注意，在工作故事中不要包含技術細節，而應專注於了解需求。在ADDR中，我們廣泛運用工作故事，為我們提供了需求的使用場景。其簡潔而完整的格式能準確地記錄用戶的需求，讓我們輕鬆識別出用戶真正的痛點，並將其反映到流程設計中。

工作故事（Job Story）主要分為三個部分，「當（When）」、「我想要（I want to）」和「所以我可以（So I can）」：

1. 當（When）： 描述觸發用戶符合條件的事件，何時呼叫啟動流程。
2. 我想要（I want to）： 描述用戶需要的「能力」，這些能力決定了流程設計能為用戶做什麼，以及用戶可以以何種方式得到期望的結果。
3. 所以我可以（So I can）： 描述用戶期望的結果（成果），當事件和能力同時發生時，用戶對結果的預期。這部分也可用作API的驗收標準。

三大心法與camunda是流程改善的關鍵密鑰

當我們了解傳統方式的痛點以及期望達到的效果，我們可以透過ADDR流程、JTBD、工作故事，先了解使用者需要甚麼開始，一路到事件的邊緣定義，而後產生正確的步驟與參數，再藉由camunda圖像化的流程設計，打造出解決方案以及解決事件的引擎。

明天我們來了解流程事件設計

如果有任何問題，歡迎在下方留言！！ 筆者頭一回寫技術文，如果內容有誤，或者內容的呈現上有所缺陷，如果您願意，歡迎在下方留言給我呦～～

anything.best

這是我的部落格，歡迎點擊閱覽喔～～會不定期更新文章