上一篇我們先從一個很工程師的問題開始：當使用者遇到錯誤時，我們要怎麼知道發生了什麼。
Error Tracking 可以幫我們找到程式壞掉的地方。不過，把 Error 修完、讓功能照規格執行之後，還有另一個不太一樣的問題：
功能可以正常使用，使用者就算成功了嗎？
假設我們正在做一個電商網站，商品頁面上有聊天室，讓使用者可以向其他買家詢問商品。
如果要替這個功能做 Event Tracking，可能很自然會想到：
甚至現在把需求交給 Coding Agent，請它「幫聊天室加入關鍵事件追蹤」，大概也能自己找到類似的地方埋 Event。
接著我們可以算：多少人打開聊天室、多少人發出訊息、發出訊息的人最後有多少完成購買。
這些資料都可能有用。
但有一件事情還是不知道：
「發出訊息」真的是使用者成功嗎？
一名使用者可能完全沒有發言，只是看了其他人的討論，就得到足夠資訊完成判斷；另一名使用者可能連續問了五個問題，卻一直沒有人回答。
如果只看 Event，第二個人甚至會顯得更加活躍。但顯然不能因此說他的體驗比較成功。
問題出在我們一開始就從「聊天室這個功能要怎麼量」開始想，卻還沒先回答使用者為什麼需要它。
這時候可以借用 Jobs to be Done（JTBD） 的概念。
JTBD 的核心想法是，使用者在某個情境下會「雇用」一個產品或解法，幫助自己完成某個 Job、取得某種進展。
例如，一個人使用悠遊卡，通常不是因為他想「使用一張感應卡」，而是因為搭捷運時不想每次重新買票。
聊天室也一樣。
使用者不是來商品頁完成「使用聊天室」這個任務。他可能真正想做的是：
在決定購買以前，取得足夠資訊，判斷這個商品到底適不適合自己。
聊天室只是目前產品提供的一種 Solution。
這個差別看起來不大，但會直接影響我們之後怎麼開發、怎麼量，甚至怎麼判斷這個功能有沒有存在的必要。
假設有一天發現大部分使用者根本不會聊天，第一個反應可能是改善聊天室入口、增加通知，想辦法提高使用率。
但如果真正的 Job 是「取得可信的購買資訊」，也可能有其他解法：把相似使用者的評論整理得更好、提供商品比較、顯示常見問題，甚至根本不需要讓買家即時對話。
這時候我們就不再只能問「怎麼讓聊天室被更多人使用」，而可以問：
有沒有更好的方式幫使用者完成原本的 Job？
JTBD 有很多不同的表達方式。這個系列裡，我們先用比較容易直接拿來討論產品的 Job Story：
When [situation], I want to [motivation], so I can [expected outcome].
中文可以寫成：
當我……時，我想要……，以便……。
回到聊天室，可以得到：
當我考慮購買一項商品時，我想要知道真實買家的想法，以便判斷這項商品是否真的符合我的需求。
這裡最重要的地方反而是：聊天室消失了。
如果寫成：
當我在商品頁時，我想要打開聊天室詢問其他買家，以便決定要不要購買。
看起來也符合格式，但其實只是把既有 Solution 填進 Job Story，最後仍然只能得到「把聊天室做好」這個答案。
另一方面，Job 也不能寫得太大。
像是：
當我購物時，我想買到適合自己的東西，以便過更好的生活。
雖然很難說它是錯的，但範圍大到幾乎無法協助我們判斷商品頁應該做什麼。
所以一個比較實用的 Job Story，通常需要落在中間：不綁定既有 Solution，但又具體到足以描述使用者當下想取得的進展。
前面的聊天室案例，就把情境限制在「正在考慮一項商品」，把想取得的進展限制在「取得真實買家的資訊，完成購買判斷」。
這樣即使最後 Solution 改變，Job 仍然成立。
理解 Job 並不是要工程師取代 PM、Designer 或 Researcher，自己決定產品應該做什麼。
比較實際的價值是，當我們拿到一項需求時，可以多問一層：
這個功能希望幫使用者完成什麼？
這個問題會影響很多工程上的選擇。
例如我們原本以為聊天室一定需要即時更新、已讀狀態與完整通知系統；但如果使用者只是希望在購買前快速得到一兩個可信回答，也許需求根本不需要長成另一套 Messenger。
反過來，如果真正重要的是取得答案的速度，那麼只把留言功能做出來，卻沒有處理「有人會不會回答」，也可能只是完成了功能，沒有完成產品問題。
這也是產品工程和單純把 Ticket 做完之間很重要的差別之一：我們不只確認程式有沒有照規格運作，也會確認規格背後真正想達成的是什麼。
不過，到這裡還有一個很現實的問題。
「成功判斷商品是否符合需求」仍然太抽象了。我們不可能在程式碼裡直接送出：
posthog.capture('judgement_success')
因為程式並不知道使用者腦中是不是已經完成判斷。
所以在開始規劃 Event 以前，下一步還要把這個抽象 Goal 轉成真的能被觀察到的 Signal，以及可以計算的 Metric。
下一篇就從這裡繼續。
如果你願意花 30 秒留下回饋，我會用這些意見來調整後續文章：分享你的意見
iThome鐵人賽
看影片追技術