軟體 RFP 怎麼寫？老闆版需求書範本與 30 條必備欄位 checklist

「我給工程師的需求就一句話：做一個跟 OO 一樣的系統。結果報價單上一個功能 8 萬，整套打包要 320 萬，我看不懂他到底算了什麼，也不敢殺價，因為怕殺到自己想要的東西。」

這是上個月一位做傳產二代轉型的老闆來找我們時開頭講的話。他不是個案。台灣老闆找外包做軟體最常踩的坑，第一名永遠是同一個——規格寫得太鬆。鬆到工程師可以隨意解讀、隨意加價、最後驗收時你拿不出任何標準說「這個沒做到」。

Project Management Institute 的 Pulse of the Profession 統計裡，52% 的專案都會出現 scope creep（需求蔓延），IT 專案這個比例更高，Standish Group CHAOS 報告 說超過 70% 的軟體專案都被需求變更追著跑，平均超支 27%。背後的根因不複雜：你給工程師的其實是一段心情，而沒有真正的 RFP（Request for Proposal，需求建議書）。心情可以變，工程師的工時不能。一旦進度走到一半你說「這個我以為應該包含」，外包商的回應會非常一致——「規格沒寫，要加錢。」

這篇是寫給找外包做軟體的老闆看的：你不會寫 code，也不需要學寫 code。你需要的是一份能讓工程師沒辦法亂解讀、能讓你拿去找三家報價而比較得出來、能在驗收時保護自己的需求書。下面拆成五個部分：為什麼 RFP 能省你錢、一份完整 RFP 該長什麼樣、必備欄位 checklist、撰寫流程、以及常見的 RFP 寫作陷阱。

如果你正在從零開始評估整個軟體外包路徑，建議先看一次這篇全景文：老闆指南：從 0 到上線打造會賺錢軟體產品的完整路線圖，把 RFP 放在「找外包」與「報價判讀」兩階段之間，會比較清楚這份文件在整個流程的位置。

為什麼花一週寫 RFP 比想像中划算

先講結論：寫 RFP 的時間，是整個專案 ROI 最高的一段。

業界 RFP 撰寫的觀察與公開數據顯示，花一個下午把需求寫清楚的老闆，後來拿到的報價往往比沒寫 RFP 的同行少 25-40% 左右。原因很簡單——當你的需求是模糊的，外包商會把不確定性的成本打進報價。一個會員系統，需求清楚是 12 萬，需求模糊是 20 萬，差的那 8 萬，主要來自他必須留 buffer 應付你之後說「啊我以為還包含 OO」。模糊需求看起來省事，本質卻是預先答應加價。

更實際的好處有三個。第一，你可以同時找三家以上比價。沒有 RFP 就沒有比較基準，每家報的東西都不一樣，你只能憑感覺挑。第二，你在驗收時有依據。RFP 上寫了「會員可上傳大頭照」，做不出來就是沒交付，工程師沒辦法跟你扯「規格沒寫」。第三，後期需求變更可以用契約處理，不會變成感情問題——多做的功能用「變更單」走流程，加錢加時間，而不是你拜託他、他賣你人情、最後關係破裂。

把這件事換個角度想——RFP 是你跟工程師之間的合約附件，不是給工程師看的「願望清單」。願望清單越美越糟糕，因為你會拿到一份美麗但落不了地的報價。RFP 越具體越貴的東西越能殺價，因為對方知道你看得懂，不能含糊。

怎麼拿著一份 RFP 去要到合理報價，並且看懂同一個功能 8 萬與 80 萬到底差在哪？建議搭配這篇看：APP 開發報價 8 萬 vs 80 萬差在哪？哪些功能該砍、哪些絕不能省。把那篇的功能對照表跟這篇的 RFP 模板擺在一起填，你會發現自己 30 分鐘內就能判斷哪家報價是合理區間、哪家在唬。

一份合格的軟體 RFP 該包含哪些章節

先看完整骨架，再逐節拆解。國際上比較主流的軟體 RFP 模板，例如 Saigon Technology、SPD Technology、Intellisoft 等公司公開的版本，章節大同小異，差別只在排序與細節深度。把它們的共同元素整理成適合台灣中小企業的版本，會是下面這 12 個章節：

不需要每一節都寫得像政府標案那樣厚——一般中小企業 8-15 頁就夠了。Saigon Technology 在他們的 RFP 模板指南 裡也明確建議過：超過 20 頁就太厚（除附件外），外包商會看不完，導致他們回的提案也跟著抓不到重點。重點是該寫的不能漏，跟頁數無關。

功能需求要寫到多細：一條規格的「夠細」標準

這是老闆寫 RFP 最常卡關的地方——「我又不是 PM，要寫多細才不算外行？」

教你一個簡單判準：一條功能要寫到工程師看完，能直接估出工時，而你看完，能在驗收時直接打勾。如果工程師看完還要再問你三個問題，太鬆；如果你看完不知道做完算不算數，也太鬆。下面用「會員登入」這個最簡單的功能舉例，你會看到從 0 到 100 分的差別：

一般情境寫到 90 分就夠了。100 分留給有合規要求的特殊產業。要記住的是——RFP 不是替工程師做設計，是把你心裡的標準明確寫下來。例如「忘記密碼用 Email 還是簡訊」、「登入失效時間是 1 天還是 30 天」、「能不能用 Google 登入」，這些對工程師來說選哪個都能做，但工時和費用不同；不寫清楚，他會挑最便宜的方式做、然後讓你在驗收時感到困惑。

RFP 必備欄位 checklist：寫之前先檢查這 30 條

把上面 12 個章節展開成可勾選清單，老闆可以直接拿去逐條打勾，看自己的 RFP 還缺什麼。任何一條沒寫，都是日後被加價的破口。

第二期、第三期 in/out 的劃分非常重要。Standish Group CHAOS 報告 顯示大型專案成功率不到 10%，中小型專案成功率拉到 28-58%——把專案切小是已驗證有效的策略。RFP 的目的是把「第一期最少要做的」鎖定，其他的留到第二期再寫一份新的 RFP。

關於合約陷阱、付款節點、源碼歸屬的更深入拆解，恆遠在這篇有寫過完整 9 條避雷 checklist：找外包做 APP / 軟體前必踩的 9 個雷：真實故事、避雷 checklist 與維運條款怎麼看。RFP 寫不清會被加價這件事，背後的合約條款怎麼設計才能保護你，那篇講得最完整。

從零寫到一份 RFP 的標準流程：5 個步驟

把「寫 RFP」這件事拆成 5 個動作，每個動作給你一個半天到一天的時間，整份文件 5-7 個工作天可以完成。流程圖如下：

Step 1：盤點商業目標，不是盤點功能

先別急著列功能。先回答 3 個問題：

• 做這個系統是為了解決什麼商業問題？（例：客服一個月被同樣的問題問 200 次）
• 成功的標準是什麼？（例：上線後 6 個月內客服重複問題減少 60%）
• 如果不做會怎樣？（例：客服人力要再加 2 人，年薪 100 萬）

這三個答案會貫穿整份 RFP，也會決定你後面該砍哪些功能。一個常見的誤區是——老闆把「想要的功能」當「要解決的問題」。例如「我想要一個客服機器人」是功能；「我想減少客服重複回答的時間」是問題。前者只能用一種方法解，後者可能用 FAQ 頁、知識庫、自動回覆都能解，且成本差三倍。

Step 2：列功能清單，並打 P0 / P1 / P2

列出所有你想到的功能（不要刪減，盡量寫），然後逐條打標籤：

• P0：第一期沒這個功能系統就不能用（如登入、商品瀏覽、結帳）
• P1：第一期有的話更好，沒有也能上線（如優惠券、收藏功能）
• P2：第二期再做，第一期完全砍掉（如推薦演算法、AI 客服）

打完標籤之後，RFP 第一版只送 P0。P1 列在「未來擴充」一節中提一下，P2 完全不寫。為什麼？因為老闆最常輸在「全都想要」——拿著一份 50 條功能的 RFP 找外包，沒人能在你的預算內做完，最後不是砍時程就是砍品質。

Step 3：定非功能與技術限制

這一節最常被忽略，但卻最影響報價。把下面這幾項列清楚：

這張表不是標準答案——是給你一個寫作時的 anchor。實際填寫時請依產業特性調整。

Step 4：寫驗收標準與時程

驗收標準是 RFP 中最能保護自己但 90% 老闆會漏寫的部分。每條 P0 功能至少要對應一條可測試的驗收標準。例如：「會員登入」對應「以 5 個測試帳號連續登入登出 10 次，皆能正常進入個人頁，且 token 不過期」。沒有可測標準，驗收會變成你跟工程師感性對話。

時程則建議切成 4 個里程碑，每個里程碑對應一筆付款。比例典型是 25% / 25% / 25% / 25%——簽約付一筆、Demo 過付一筆、UAT 通過付一筆、正式上線並穩定 14 天付一筆。關於分階段付款的具體執行細節，這篇有完整模板：MVP 不是把功能砍少：找外包做 MVP 的 4 階段付款與驗收節點完整指南。

Step 5：內部 review + 預算定錨

寫完之後，找公司裡兩個人 review：

1. 業務主管 / 第一線使用者：他會幫你抓出規格與實際工作流程的落差
2. 對軟體稍有概念的人（不一定要工程師）：請他標註哪些地方寫得太模糊，他要再問才懂

最後一步是預算定錨——給一個區間，例如「100-180 萬」。你以為不講預算可以拿到便宜報價？正好相反。 不講預算的 RFP，外包商會用最高規格估給你看，然後等你嫌貴再砍規格。給了預算上限，他會主動幫你在預算內排優先順序，這對你有利得多。

拿著 RFP 去比價：3-5 家提案怎麼挑

RFP 寫好後，不要只發給一家。建議發 3-5 家，回收期定 15-20 個工作天（Saigon Technology 的研究指出，少於 10 天會收到大量罐頭提案，超過一個月則會有外包商失去耐性）。提案回來後，用一張表格做比較：

這張表是建議起點——你可以根據自己的痛點調整權重。例如品牌官網重視「設計感」，企業內部系統重視「資安/合規」，電商系統重視「金流串接經驗」。

評選之前，建議先做一輪資格篩選，篩掉沒做過類似規模、公司成立不滿 3 年、團隊不到 5 人的廠商（除非你預算很低、能接受高風險）。怎麼從基本資料判斷一家軟體開發公司可不可信，如何選軟體開發公司？7 個評估標準 + 合約必看條款 這篇有完整的 7 點評估表，你可以拿去當資格初篩的 checklist。

外部資源：可參考的公開 RFP 範本

如果你想看更多範例，下面是兩個適合台灣老闆參考的公開資源：

• 經濟部資料服務開放平台：政府機關資訊採購建議書徵求文件參考範本（Word 檔，章節最完整，但對中小企業偏厚重，建議當骨架用就好）
• 國發會：如何撰寫政府機關資訊採購案件之建議書徵求文件（PDF，撰寫指南，把 RFP 為什麼這樣寫的邏輯講得很清楚）

這兩份是政府版本，章節較多、用字偏正式，民間中小企業可以裁掉採購法、評選委員會等與你無關的章節，留下「需求書」核心結構即可。

常見的 RFP 寫作陷阱與 5 個 lean startup 心法

陷阱 1：把 RFP 當許願池

把所有腦中想得到的功能塞進去，然後問外包商：「全部做完多少錢？」這種 RFP 會收到一份「答案是 800 萬，做 12 個月」的提案，然後你會嚇到，回來砍規格，砍到外包商失去做這個案子的動力。

正確做法：用 lean startup 思維，先問「最小可上線版本」是什麼。例如電商：能上架商品、能加入購物車、能結帳、能查訂單，就足以驗證「會不會有人買」。優惠券、會員等級、推薦演算法、AI 客服——全部第二期再說。先把第一版做出來、有人用了、開始有訂單了，第二版的需求自然會浮現，而且會比你現在腦補的更精準。

陷阱 2：把競品當規格

「我要做一個跟蝦皮一樣的電商 / 跟 LINE 一樣的聊天 / 跟 Uber 一樣的派單」——這類描述對工程師來說是負擔不是規格。蝦皮背後是上千名工程師十年的累積，沒有外包商會白送你一套。

正確做法：把「跟 OO 一樣」拆成 10-20 條具體規格。如果你說不出 10 條，代表你還沒想清楚自己要什麼，先回去做市場驗證，別急著寫 RFP。

陷阱 3：規格太細到變成 PM 工作

反過來的極端——老闆寫到連按鈕的圓角弧度都規定。這樣外包商會收很高的「客戶配合費」，因為他知道做這種客戶會卡在每一個小細節上。

正確做法：規格寫到「使用者要能做到 X」就好，不要規定「怎麼做到 X」。例如：「使用者要能上傳 5 張以內的商品照片」是好規格；「使用者點擊紫色按鈕，跳出 Modal 視窗，再從電腦中選照片」是過度規範。讓專業的人做專業的事，你只把要的結果講清楚。

陷阱 4：忽略非功能需求

功能寫得很細，效能、資安、合規完全沒提。結果系統做完，10 個人同時用就掛了。

正確做法：至少寫四件事——同時在線多少人、頁面要在幾秒內開、要不要符合個資法 / GDPR、資料保留多久。這四件事對工時與成本影響很大，外包商必須知道才能正確估算。

陷阱 5：沒寫「不做什麼」

只寫了 in scope，沒寫 out of scope。結果驗收時雙方爭執——你以為包含「會員可以匯出全部訂單為 Excel」，外包商說那是另外的功能要加錢。

正確做法：把容易被誤會「應該包含」的功能明確列為 out of scope。常見的有：資料匯入/匯出、舊資料移轉、SEO 優化、第三方整合、客製化報表、多語系。這些不寫清楚，60% 會變成爭議點。

如果不想自己寫：找顧問代寫 RFP 划得來嗎

回到這篇文章的初衷——RFP 是省錢工具，不是文書工作。

自己寫的成本是 5-7 個工作天的時間（含內部 review）。找顧問代寫的市場行情大約 3-15 萬（看專案規模）。乍看之下自己寫便宜，但有兩個情境適合外包給顧問：

• 你完全沒有軟體背景，前後想過幾個月還是寫不出 P0/P1/P2，怕拖延整個專案
• 你的專案規模超過 200 萬，預期會找 5 家以上比價，自己寫沒辦法在所有家拿到可比較的提案

這兩種情境之外，自己寫一定划得來——你會在過程中對自己要做的東西理解更深，後續跟外包商的溝通會順得多。

如果你需要的是一份「能比價、能驗收、能保護自己」的 RFP，但又不想花一週從零寫起，恆遠數位行銷有提供 RFP 撰寫顧問服務——我們會用一場 90 分鐘的訪談把你的商業目標與功能優先順序拆出來，三個工作天交一份可直接發出去的 RFP，並陪你一起評選提案。詳細可以看 恆遠的服務頁與案件諮詢。

RFP 撰寫常見問題

把 RFP 當成你的第一份外包合約附件

再回到開頭那位老闆。後來他花了一週時間，照著上面 12 章節的骨架寫出 11 頁的 RFP，發給 4 家外包商，最後拿到的報價區間是 95-160 萬——比他原本被報的 320 萬，省了一半以上。更重要的是，他在驗收時心裡有底，每一條功能都對應到 RFP 上的某一行字，不再有「我以為應該包含」的恐慌。

RFP 是老闆做軟體外包的第一份保命文件。寫得好不好，決定了你接下來 3-12 個月會輕鬆還是痛苦、預算會省下還是爆炸、產品會落地還是難產。投資一週寫好它，後面省下的可能是百萬等級的成本與壓力。

如果你已經寫好 RFP 但還拿不準該找誰、或是想要恆遠陪你一起 review 一輪，可以從 恆遠的服務諮詢頁 開案，第一次免費的 30 分鐘諮詢能幫你抓出最關鍵的 3 個風險點。

整個外包流程的全景圖（市場驗證 → 找外包 → MVP → 報價判讀 → 階梯驗證 → 冷啟動 30 天）建議再回頭看一次主軸文：老闆指南：從 0 到上線打造會賺錢軟體產品的完整路線圖。RFP 是這條路上的第二個關卡，跨過去之後路會順很多。