需求盤點該問什麼問題？

四個：這件事多久做一次、做錯的代價是什麼、資料現在在哪裡、不做會怎樣。問「想要什麼功能」得到的是一張清單，而清單上的每一項看起來都該做，所以排不出順序；問這四題得到的是重複次數、錯誤成本與資料完整度，那才排得出來。

需求分成哪幾類？驗收方式一樣嗎？

三類，而且驗收標準必須不一樣：省時間的需求，驗的是省下多少；少出錯的需求，驗的是錯誤率有沒有下降；看得見的需求，驗的是原本要問人才知道的事，現在打開一個地方就看得到。用同一套標準驗三種需求，最後會變成什麼都沒驗到。

分階段，而且每一段都要小到能單獨驗收，也小到不做也不會卡住下一段。這個條件比「先做哪一段」更重要：能單獨退場的階段，做錯了只賠那一段；環環相扣的階段，任何一段卡住整條路就停了。

當那件事一個月只發生一次、當現在的做法沒有人抱怨、當你還沒辦法說出「做完之後哪個數字會變」。這幾種情況我們會直接建議不要做。賣一套用不到的系統，對雙方都不划算。

需求列成一張功能清單，就沒辦法排序，因為每一項看起來都該做。這篇講我們實際用的四個盤點問題、需求的三種類型，以及什麼時候該建議客戶不要做系統。

規劃最常見的失敗，不是需求列得不夠多，而是列成了一張功能清單。

功能清單有一個致命的性質：它沒辦法排序。因為每一項單獨看起來都該做。等到要決定先做哪一段，唯一剩下的判準就是誰講話比較大聲，或哪一項展示起來比較好看。

所以我們的盤點不從功能開始。

每一件事都問同樣四題。問的是現況，不是期待。

問題	它決定了什麼
這件事現在是誰在做？	答不出具體的人，就表示流程還沒定下來。這時候做系統是把混亂寫成程式碼。
他一次花多久、多久做一次？	時間乘上頻率，才是真正的成本。一次三小時但一年兩次，通常不值得。
做錯的後果是什麼？	決定要不要留人工確認關卡。錯了會賠錢的環節，自動化只做到草稿為止。
做完之後資料去哪裡？	答案是「存在某個人的電腦裡」的時候，你找到的通常是下一段真正的瓶頸。

第一題最有價值，因為它最常問不出答案。一個沒有主人的流程，做成系統之後也不會有主人。

把盤點結果分成三類。這一步是為了避免用錯的標準去驗收，這是我們看過最常見的浪費。

類型	它在解什麼	驗收要看什麼	常見的誤判
省時間	重複、規則明確的作業	原本固定被吃掉的那幾小時有沒有消失，而且沒有人需要記得去跑它	用「功能有沒有做出來」驗收，結果功能都在，人還是照舊手動做
防錯	出錯代價高、但不常發生的環節	錯誤有沒有在造成損失前被攔下來	期待它同時省時間，於是嫌它多一道手續
帶生意	讓詢問進得來、也接得住	詢問量與後續轉換，而且要看得夠久	上線一個月就判定沒效。這類的觀察期是幾個月，不是幾週

分類的好處是它會擋掉一種對話：「這個系統到底有沒有用？」沒有分類的時候，這句話沒有答案。分類之後，它會變成三個各自有標準的問題。

有了時間乘頻率，順序通常就自己浮出來了。我們的判準只有一句：先做重複次數高、而且做錯代價也高的那一段。

有一個五家門店的早餐店加盟主就是這樣。一開始講的是「想要一個報表系統」。四題問完才發現，真正被吃掉的時間不在看報表，而在每個月要逐店登入後台、把格式不一樣的報表一份份匯出來再人工併表，麻煩到得外聘會計來做。

真正該自動化的是資料進來的那一段，不是產出報表那一段。這件事在功能清單上看不出來，因為沒有人會把「登入後台匯出檔案」寫成一項功能。

這一節通常不受歡迎，但它替雙方省下最多錢。

流程每週都還在變的時候。 系統會把流程固定下來，這正是它的價值，但也表示流程本身要先穩。還在調整的東西寫成程式碼，改一次的成本比改一張 Excel 高得多。

只有一個人用，而且一週用一次的時候。 這種需求用現成工具或一份講清楚的文件解決就好。為它做系統，維護成本會超過它省下的時間。

真正的問題是沒有人負責的時候。 這是最容易被誤診的一種。看起來像是「缺一套系統」，實際上是缺一個負責的人。這時候交付系統，三個月後它會安靜地沒人用。

我們寧可在報價前講這些，也不想交付一套沒人打開的東西。

排好順序之後，交付方式只有一個原則：一次只交付一段，而且每一段都要能單獨退場。

具體是三件事。第一，每一段都小到能單獨驗收。用上面那張表的標準，不是用「做完了沒」。第二，每一段都有並行期，舊做法照跑，直到新的被證明可靠才收掉；並行期間會多一點重複作業，那是刻意付出的成本，換的是任何一段出問題都能立刻退回去。

第三，每一段都要能停在那裡。如果做完第一段發現效益不如預期，那就停，前面的投入不會因為沒做第二段而失效。

能單獨退場，是分階段唯一真正的價值。做不到這件事的「分階段」，只是把一次大爆炸拆成好幾次小爆炸。

如果你正在評估要不要做、或者手上已經有一份列不完的需求清單，免費需求診斷可以先把它變成一個有順序的東西。判斷下來不該做系統的，我們也會直接說。