當我們把一個功能實作出來，也透過功能旗標和灰度發布來避免功能影響到太多人。然而當功能上線後，我們就可以把開發票關掉，然後趕往下一個任務嗎？
系列一開始我們講到 Job Story 來說明關注使用者的成功，也介紹到我們可以捕捉信號來確認使用者是否成功。正如絕大多數軟體都不會期待完全沒有錯誤，我們也不能期待功能一次就可以讓使用者成功，因此我們需要不斷的改進。
但如何評估改動帶來的影響呢？使用之前說到的產品分析 Product Analytics 來檢驗指標變化固然是種方法，卻可能不太完整。
像是正好功能發布時有促銷，因此指標有明顯的變化，這時候我們可能對於功能帶來的影響就難以給予太多信心。
另一方面，產品工程師也不僅僅是等待 PM 拋出開發需求，正如先前所說，產品工程師的任務是打造產品的每一個環節，以及促使產品成功的關鍵因素。因此，產品工程師也需要具備探索改進方向並進行驗證的技能。
在產品管理中，有一個概念叫做「假設驅動開發」（Hypothesis-Driven Development, HDD）。
它和一般需求開發最大的差異，並不是把 User Story 換成另一種格式，而是先承認一件事：我們提出的解法不一定有效。
例如有人提出：「商品頁面應該加入聊天室。」
如果把它當成需求，接下來很容易直接進入聊天室要支援哪些功能、訊息怎麼儲存、通知怎麼做。但回到前面的 Job Story，使用者真正遇到的問題是「做出交易決策前，不清楚產品是否滿足需求」。聊天室只是我們目前想到的一種解法。
因此，在開始實作之前，可以先把這個需求改寫成一個假設。
Thoughtworks 在介紹 HDD 時使用的寫法很簡單：
We believe <this capability>
Will result in <this outcome>
We will know we have succeeded when <we see a measurable signal>
套到前面的例子，大致可以寫成：
我們相信：
讓正在考慮購買的使用者可以向其他買家詢問商品資訊，
會讓他們更容易取得做出交易決策需要的資訊。
如果這個假設成立，
我們應該可以在先前 GSM 定義的 Signal 中看到變化。
這裡特別把「做什麼功能」、「希望使用者發生什麼改變」與「準備怎麼觀察」拆開，是因為三者很容易被混在一起。
例如聊天室使用率很高，只能說明很多人用了聊天室，不能直接證明它有幫助使用者完成原本的 Job。反過來，如果聊天室使用率不高，也不能只靠這個數字判斷功能一定沒有價值，因為它可能只對原本就有疑問的那一小部分使用者有用。
甚至連購買率也不一定能單獨代表成功。前面在 JTBD 的例子裡，我們關注的是「做出交易決策」，使用者取得足夠資訊後決定不買，也可能是一個成功完成的 Job。因此實際要觀察哪些 Signal，仍然要回到前面 GSM 對 Goal 的定義。
這也是 HDD 比「功能做完後看看數字有沒有變」多出來的一個重要步驟：在開發之前，就先決定我們期待看到什麼。
Thoughtworks 也特別提到，判斷成功的 Signal 應該在測試之前先定義，避免看到結果之後才挑一個對自己有利的方式解釋。
舉例來說，如果功能上線後聊天室使用率很高，但和交易決策有關的 Signal 完全沒有變化，我們至少可以知道「使用者願意使用聊天室」和「聊天室有沒有解決原本的問題」是兩件事情。
如果幾乎沒有人打開聊天室，則又是另一種結果。這時候我們甚至還沒有足夠證據判斷聊天室能不能幫助決策，因為使用者根本沒有接觸到它。可能是入口不明顯，也可能是使用者本來就沒有這個需求，需要回頭確認原本的假設。
這些結果都不是單純的成功或失敗，而是在告訴我們原本的推論哪一段可能有問題。下一輪就可以依照這些資訊調整解法，甚至重新檢查一開始對使用者問題的理解。
提到「驗證假設」，很容易直接想到 Experiment，但假設其實可以在寫完功能之前就開始驗證。
如果現在連「使用者是不是因為缺少其他買家的資訊而難以做決策」都還不確定，那麼直接花時間完成聊天室，再拿兩個版本做 A/B Test，可能已經投入太多成本。
這時可以先利用現有的 Product Analytics 看行為、透過 Survey 詢問使用者，或者進行訪談。也可能先做很小的 Prototype，確認使用者遇到問題時是不是真的會想向其他買家詢問。
這些方法取得的證據不同，但目的相同：在繼續投入之前，先確認目前的理解有沒有足夠依據。
等到我們對問題本身比較有信心，而且真的實作了一個解法，接下來才會遇到另一個問題：
功能上線後指標變好了，真的是這個功能造成的嗎？
如果只是比較發布前後的數字，促銷、季節、流量來源，甚至使用者組成本身都可能同時發生變化。這也是上一篇使用 Feature Flag 控制發布後，下一步很自然會遇到的問題。
下一篇，我們就來使用 PostHog 的 Experiment，把不同版本分配給使用者，再看看如何評估兩個版本之間的差異。
如果你願意花 30 秒留下回饋，我會用這些意見來調整後續文章：分享你的意見
iThome鐵人賽
看影片追技術