需求還沒講清楚，先問「這要做多久」的人，相信各位開發團隊都有碰過。

有一次需求才開口三句，對方就接：「這個簡單啦，兩天可以吧？」我當下沒答話，因為我知道接下來會發生什麼事。等真的開工，發現要串一支外部驗證 API、要處理三種失敗情境、後台還得加一個審核介面，最後做了快三週。可是「兩天」這個數字已經被記在某張排程表上了，從那天起，每次進度會議都在解釋為什麼還沒好。

那個「兩天」沒有經過任何估算，但它一旦被記進排程表，效力就跟正式估算一樣。

所以鼠勾以在最後產出 PRD 的時候，會附一段工時初估。它不是要取代工程團隊的精算，做不到也不該做。它的任務只有一個：在需求單位送案之前，給他們一個有依據的量級感，避免會議上直接用「應該還好吧」定出時程。

得先講白：這終究是很粗的初估。同一個功能，換一組人力、換一套熟悉度不同的工具、換一個預算規模，做出來的天數可能差一截。它算不到這些，也不打算算。它想做的只是給開發一個起跑點，一個能站著往下談的初估值，而不是最終答案。

為什麼是需求方PM 看的估算，不是工程的排程

這個分野定了整套框架的調性。

工程團隊內部排程，追求的是準。每個人手上有幾天、誰擋在誰前面、哪段卡 code review，那是另一個世界的事，鼠勾以管不到，也不該插手。

可是需求方PM 在送案前需要的東西不一樣。他們要的是「我這個需求大概是兩週的量還是兩個月的量」，好回頭跟自己主管報、跟其他單位喬時程。給他們一個精確到 0.5 人天的數字，反而是害他們，因為那個精確度是假的，需求都還沒定案哪來的精算。

所以這個估算從頭到尾都站在需求方PM 那一側：寧可給範圍不給單點，寧可保守不要樂觀。它算出來的數字，需求方PM 可以拿去規劃，但不該拿去壓開發。

三根支柱：複雜度、角色、Buffer

拆開來看，估算就三件事疊起來。

複雜度：先把功能分級

每個功能先落到一個複雜度級距。判斷標準是工程師會關心的那些訊號，不是需求方PM 嘴上說的難易：

有幾條捷徑可以快速拉級：流程圖節點超過五個，至少中等；碰到外部 API 回呼，至少複雜；動到金流或個資，至少複雜；要做資料遷移或向下相容，直接高複雜。這幾條都是踩過坑才寫進去的，每一條背後都有一個「當初以為簡單」的故事。

角色：一個功能不是只有寫程式

需求方PM 最常漏掉的，是一個功能落地要動到的不只工程師。設計要出稿、前端要刻畫面、後端要寫邏輯跟測試、PM/SA 要協調驗收。鼠勾以把估出來的工時按角色比例攤開，後端含測試通常占最大塊，因為測試工作量是真的會吃時間，尤其例外情境一多。

這裡也留了調整空間。純前端的改版，前端占比往上拉、後端往下降；純後端的批次作業反過來。如果使用者主動提了團隊狀況，像「我們這組都很資深」或「有新人要帶」，才會套一個能力係數微調，平常一律用一般水準算，不主動追問。

Buffer：最重要、也最常被誤會的一塊

這是整套框架的核心，也是我設計時想最久的地方。

技術估算算完，不會直接吐給需求方PM。它會先上浮一段，把那些不會寫在功能清單裡、但一定會發生的成本吃進去：溝通來回、環境設定、code review、部署、那些「欸這邊跟我想的不一樣」的當場修正。功能數量多到一定程度，再加一段整合測試的 Buffer，因為功能各自做完不等於兜在一起會動。

為什麼 Buffer 要藏起來

我擔心的是，需求方PM 會這樣：技術估 10 天、上浮 30%、所以 13 天，這串算式攤在他們面前，第一反應就是「那這 30% 是不是可以砍？我們時間很趕。」於是 Buffer 變成談判桌上的籌碼，被一刀剁掉，剩下的數字就是那個沒有任何餘裕的技術估，跟喊出來的「兩天」沒兩樣了。

Buffer 的用意是保護開發，留一段空間吸收那些一定會發生、但寫不進功能清單的成本。把它攤開來秀，等於把這層保護拆給別人砍。

所以後來改成只給最終數字，而且是範圍。需求方PM 看到的是「這個需求規劃上抓 12 到 16 人天」，看不到中間怎麼疊上去的。這不是藏私，這個數字本來就該整包看待，拆開來每一塊都會變成被砍價的對象。需求單位真正需要知道的是「我要留多少時間」，至於「你怎麼算出來的」其實沒那麼重要。

畫面上大概長這樣：

工時初估（僅供規劃參考）

預估總工時：12 到 16 人天

影響工時的關鍵因素：

• 需串接一支會員驗證 API。
• 例外情境較多，測試工作量大。

提醒：此為規劃用估算，建議與 IT PM 及開發團隊進一步確認。

還有一個容易被忽略的提醒，鼠勾以每次都會補：這個數字只含開發時間。單據簽核、SIT、UAT、變更審查、上線觀察，全都不在裡面。這些環節牽涉到多個部門開單、審核、協助，實際要花多久得另外評估，鼠勾以現在還估不到，後續版本會升級把這段也納進來，初版先聚焦開發時間。我看過太多人把「開發 15 天」直接當成「15 天後上線」，等到簽核流程卡了兩週才發現落差。開發完成之後還有一整段流程要跑。

信心度：讓估算誠實地承認自己不準

最後一塊是信心度，它解決的是「這個數字我能信幾分」。

鼠勾以怎麼知道自己估得準不準？它看需求被問得多完整。前面八個區塊問下來，如果該確認的都確認了、待確認清單見底，那這個估算的地基就穩，信心度標高。如果使用者一路跳題、半數欄位都還懸著，那估出來的東西就只能當量級參考，信心度標低，並且白紙黑字寫上「不建議據此排程」。

需求不清楚的時候，硬給一個漂亮的單一數字才是不負責任。明明訊息不足卻假裝算得準，那是把風險偷偷塞給需求方PM。標一個「低信心度」，反而是逼著大家回頭把需求補齊再來談時程，這才是這個工具想做的事。

信心度高、中、低，對應的是估算範圍要放多寬。越沒把握，範圍拉越開，數字自己就會告訴你「現在還不到拍板的時候」。

老實說，這套估法我自己也還不敢說有多準。複雜度級距、角色比例、Buffer 那些係數，都是我跟 AI 一來一回討論出來的版本，再拿實際功能回推、湊出一組看起來合理的數字。它現在比較像一個有依據的起點，不是經過驗證的公式。我的打算是讓它跑一段時間，蒐集每個需求實際做下來花了多久，再回頭拿真實數據去校正這些係數。估算這種東西，本來就要靠真實的落差去餵，才會一版比一版準。

把這三根支柱疊起來，再蓋上一層不外顯的 Buffer、標上一個對應的信心度，那個「最少 X 到最多 Y 人天」就有了出處。它的精確度有限，但每一段都說得出依據，在送案前的階段夠用。

到這裡，PRD 該有的東西都齊了：流程圖、欄位、驗收、工時。問題是這份文件最後要交出去，而流程圖是用 Mermaid 寫的純文字，貼進 Word 就是一坨程式碼。明天聊怎麼把 Mermaid 自動轉成圖、塞進 Word，還有圖轉壞的時候那條 fallback 怎麼接。

這是 iThome 鐵人賽系列文章。明天見。