區塊 1 問完「為什麼做」、區塊 2 問完「給誰用」，區塊 3 問「做完怎麼算成功」。這題的標準答案，每次都長這樣：
「就希望大家都喜歡用、體驗變好啊。」
問題是「喜歡」跟「體驗變好」都量不到。上線三個月後主管問「這案子做得好不好」，回答「大家都很喜歡」會馬上接到下一題：喜歡的有幾個、跟上線前差多少。
區塊 3 的任務，是在需求階段就把這種感覺翻譯成一個上線後查得到的數字。
沒有數字的成功標準，實際上等於沒有標準。專案上線之後沒人說得準它成不成功，因為一開始就沒定義成功長什麼樣。常見的狀況是需求方PM 回去交代成效時手上沒有任何數據，只能說「大家反應還不錯」，接著就答不出「不錯是多不錯」。
這個數字的用途是事後驗證：當初的判斷有沒有做對、預期的價值有沒有真的發生。
這個數字也會回頭約束前面的區塊。如果目標是降低客服進線，區塊 4 的功能裡就該有自助查詢一類的設計；指標寫著要減少電話、功能卻沒有一項在處理這件事，兩邊就對不上。這種前後不一致鼠勾以在後面的區塊會抓出來。
區塊 3 拆成三個面向，順序是刻意排的，後一項要靠前一項的答案才問得下去：
第三個面向最容易被跳過，但它決定了「這個指標到底量不量得到」。等一下單獨講。
很多需求方PM 對「指標」這個詞沒有概念，直接問「你的北極星指標是什麼」通常問不出東西。所以鼠勾以不解釋指標的定義，改成問一個他熟悉的場景：
想像一下，這個專案做完而且做得很成功。你老闆問你「這個案子做得怎樣」，你會怎麼回他？
這個問法把抽象的「指標」換成他實際會遇到的情境：被老闆問成效。他不需要懂指標理論，只要想「我會怎麼回答」，答案就會帶出他真正在乎的東西。
如果還是講不出來，就給選項：
沒關係，通常專案成功會像這幾種情況，你看哪個最接近：
A. 很多人來使用，使用率高
B. 抱怨或客服電話變少了
C. 某個流程的處理時間變短
D. 其他（你直接說也可以）
這一樣是 Day 10 的情境選項，讓他從清單裡挑，而不是憑空想。
The Success 是挑戰機制很常出手的地方，因為「感覺」型的答案實在太多。
最後一個「基準線」的挑戰特別重要。只有目標、沒有起點的數字無法驗證：「提升 50%」可能是從 2% 到 3%，也可能是從 40% 到 60%，兩者的難度與意義差很多。鼠勾以會先追問「那現在是多少」，確定起點之後那個 50% 才有判斷依據。
「這個數字上線後從哪裡看」這個面向，需求方PM 幾乎不會主動想到，但它決定了整個指標成不成立。指標定得再漂亮，只要系統沒有在記錄這筆資料，上線後就查不到數字。
鼠勾以會把數據來源攤開來問：
剛剛說的那些數字，上線之後要從哪裡看得到？
A. 系統後台直接有統計（像登入次數、操作完成數）
B. 需要另外做一個報表或儀表板
C. 要跟其他部門要資料（像客服中心的通話記錄）
D. 目前不知道怎麼看（先記待確認）
如果答案是 B 或 C，那就牽出一個工時問題：報表要不要算在第一版做？跟別的部門要資料要不要先談好窗口？這些不在這裡問清楚，上線後才發現「指標量不到」，整個成功標準就形同虛設。
跟前面的區塊一樣，數字真的想不出來時鼠勾以不會硬逼，會回一句「這個先記下來，之後跟相關的人確認就好」，把它放進待確認清單。
只有量測方式這一項它會多提醒一次：上線前要先確定怎麼量，否則功能上線之後仍然無法判斷成效，這份成功標準就沒有作用。留白可以，但要留在清單上、有人負責追。
區塊 3 做的事，是把「希望大家都喜歡用」拆成「成功的樣子、具體數字、量測方式」三塊：用「老闆會怎麼問你成效」這個問法破冰，再用挑戰擋掉「會滿意」「品牌提升」這類量不到的答案，並追問出每個數字的基準線。其中「這個數字從哪裡看」最容易被跳過，也最直接影響指標能不能成立。
Day 15 進到區塊 4「The What」：當使用者把想到的功能一口氣全倒出來時，怎麼幫他分出「第一版非做不可」跟「以後再說」，以及怎麼把「這次不做的事」也好好寫下來。
這是 iThome 鐵人賽系列文章。明天見。
iThome鐵人賽
看影片追技術