撰寫產品需求文件 PRD 必備的技能：任務步驟分析

任務步驟分析的底層邏輯就是系統思考

在撰寫產品需求文件 PRD 之前，我們會先進行需求訪談。

在這個過程中，你會需要一個相當好用的技能「任務步驟分析」。

透過任務步驟分析，你可以將商業需求如何實現的業務邏輯進行分解。

用最適合的顆粒度來敘述使用者流程（ Userflow ）。

任務步驟分析是我從特殊教育的行為改變技術中的「錯誤歷程分析」學習到的概念，幫助我依據人類行為的原理來評估解決方案，而不是根據我自己的主觀喜好。

運用任務步驟分析這個能力的過程，需要同時連動幾個核心概念，這對於產品經理以及 UX 設計師尤為重要，包括：

• 以終為始來定義目標
• 將大目標拆解為小目標
• 模組化思考

這些內隱知識可以說是系統思考的底層邏輯。

你必須從事物運作的表徵之中分辨出某一個流程的核心目的。
並且分離出這個核心目的是由哪些元素所構成，並且必須理解元素與元素之間的關係。
並且再進一步思考如何抽換元素，並且保證核心目的與元素關係之間不被破壞。

因此我們也可以這麼理解，任務步驟分析的本質就是「分解因果關係」。

在我們開始設計產品服務之前，分解事物的元素有助於我們辨認手上的素材。
畢竟如果我們只拿到蛋，是沒辦法變出蛋炒飯的。

但如果我們沒搞懂蛋炒飯的原料最低限度需要蛋跟飯，就開始執行任務。
最後會發現時間都浪費在重作以及中斷任務想辦法蒐集食材上。

我很喜歡一本關於數據分析的書《如何衡量萬事萬物》，因此我也想厚著臉皮說，如何分解萬事萬物可以說是產品經理與 UX 設計師很重要的超能力。

在分解事物的過程，你會觀察到「事物之間組成的因果關係」。

為什麼熱水加上咖啡粉，就會萃取出我們在喝的黑色液體？

為什麼你的時間跟我的時間媒合在一起，就會出現我們一起相約的時間？

為什麼你得做出一連串正確的選擇，才能得到滿意的結果？

任務步驟分析讓我們觀察現有的事物如何運作，先抓出為什麼要做這件事情的粽子頭，再順藤摸瓜的釐清有哪些階段性因素，組合起來成為了我們想要的結果。

​

在產品開發的環境中，我們經常面臨不確定性，而不確定性的原因，就是我們無法掌握明確的因果關係，因此我們設想的解決方案無法妥善的面對需求與變動。

​

當我們能看懂別人為何能夠成功運作某項事物，同時也會找出這件事情的門檻，以及這件事情牽連的要素。
這些是別人經過一連串取捨得到的結果。

如果我們看不懂別人如何取捨才做出決定，就盲目的跟隨別人的決策結果。
那就像是沒有檢測過的器官移植，我們不知道會產生哪些排斥反應以及後遺症。

​

如何分解萬事萬物之間的因果關係，我認為既是基礎入門就該學習的能力，也是深入掌握特定領域知識可以應用一輩子的能力。

任務步驟分析不是流水帳

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

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

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

如果運用任務步驟分析的概念，重新整理一次這個煎蛋餅的任務流程如下：

1. 預備材料：餅皮、蛋液
2. 預煎餅皮：餅皮兩面煎至微焦黃，起鍋備用
3. 組合：將蛋液入鍋，覆蓋上餅皮，雙面煎至微焦
4. 起鍋：將蛋餅摺疊，剪裁成適合入口大小

​

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

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

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

1. 可獨立：依賴別人才能完成的，不是明確的任務
2. 可交付：每一個完整的任務都會有明確成果
3. 可置換：每個任務都是一個問題，同一個問題可以有不同的解決方案

​

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

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

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

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

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

​

▋任務分析原則二：可交付 ▋

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

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

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

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

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

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

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

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

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

​

▋任務分析原則三：可置換 ▋

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

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

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

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

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

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

在軟體產業來說，可能是過度依附於某個大型服務的生態系，例如以前過度仰賴臉書的遊戲公司。
或者過度仰賴 Google 地圖、LINE chatbot 的某個 API，當這些被你視為基礎建設的服務改變了使用規則，你的產品服務就危在旦夕。

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

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

​

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