軟體 RFP，也就是需求建議書，本來的用途是讓不同廠商變得可以互相比較。可是現實中大多數文件剛好起了反效果：它們把解決方案寫得夠細，細到把回答的空間綁死，卻偏偏漏掉了任何人報價時都會需要的那些資訊。結果就是五份報價，彼此差了一個數量級，形式上每一份都回應了需求，但沒有任何兩份在衡量同一件事。

常見的說法是廠商在打太極。偶爾確實如此。但更常見的情況是，文件要了一個從它本身內容根本推不出來的數字，於是每家廠商都用各自不同的假設去填補空白。假設不同，價格自然不同，這裡並沒有誠不誠實的問題。

判斷你的 RFP 是否有效的檢驗方式： 兩家不同的廠商讀完之後，能不能得出實質上相同的範圍？如果文件裡只寫了「使用者管理」，沒有說明有幾種角色、權限是否會依單筆資料而不同、是否需要串接既有的使用者目錄，那麼一家會報一週，另一家會報兩個月。兩家都在誠實作答。而你沒有辦法把它們放在一起比較。

為什麼功能清單是錯誤的起點

一份功能清單告訴廠商的是你做了什麼決定，而不是你需要什麼。這件事之所以重要，是因為那個決定本身可能就是錯的，而看出錯誤的人，在你規定的文件架構裡根本找不到地方把它講出來。

功能清單還會把真正推動成本的資訊藏起來。軟體的工時集中在那些麻煩的地方：要串接幾個外部系統，有多少既有資料需要轉移、這些資料有多乾淨，有幾種權限各不相同的使用者類型，以及需要滿足哪些法遵義務。一份功能清單可以寫得很長，長到好幾頁，卻一條都沒有提到上面這些。

替代做法不是把話講得含糊。準確描述問題，寫清楚哪些限制是真的動不了的，然後把做法本身的說明交給提案方去寫。你會收到不一樣的答案，而這些差異是有資訊量的，而不是雜訊。哪裡出現分歧，哪裡就是你接下來真正該討論的議題。

一份軟體 RFP 真正該寫的內容

業務問題，以及成功代表什麼。 現在發生的是什麼，本來應該發生什麼，以及你要用什麼來判斷這件事做成了。廠商會拿這一段去質疑範圍本身，而在這個階段，這是他們能替你做的最有價值的事。

規模與數量，用數字寫出來。 使用者數、交易筆數、資料筆數、預期成長。光是這一項，就能消掉報價落差中很大的一塊。

必須串接的系統，逐一點名，並註明每一個是否有完整文件的 API。一個沒有文件的舊系統串接，花的錢就可能超過其餘所有工作加起來的總和。

你已經有的資料。 有多少、放在哪裡、狀態如何。資料轉移幾乎在每個專案裡都是被低估得最嚴重的一項。

真正動不了的限制。 法規義務、指定的主機所在地、已經在用的身分驗證系統、挪不動的期限。請說明哪些是硬性條件、哪些只是偏好，因為廠商會對硬性條件做防禦性報價。

你不打算做的事。 把不在範圍內的東西明確寫出來，是壓低報價落差最便宜的方法之一。

你的預算區間。 藏著它並不會讓價格變低，只會換來一批依照誰也不知道的預算去裁切範圍的提案，接著還得重做一次。給出區間，廠商才能告訴你在這個區間裡究竟做得到什麼。各個價位分別買得到什麼，我們在客製化軟體開發成本指南裡寫清楚了。

能把廠商區分開來的問題

問題要少而精。下面這幾個問題，比一份一百列的法遵對照表能揭露的東西多得多。

你們會先做哪一部分，為什麼？ 先後順序會暴露對方到底理解了問題，還是只理解了這份文件。

這裡面風險最大的是什麼，你們打算怎麼把它降下來？ 能講出一個真實風險的廠商，比一個回報說沒有風險的廠商更值得信任。

具體是誰來做？ 姓名、資歷，以及他們投入多少比例的工時。寫提案的人不參與實作，是一種反覆出現的失望。

範圍變動時會怎麼處理？ 它一定會變。這個答案告訴你這段合作關係在壓力之下怎麼運作，而這比人天單價更重要。

你們需要我們配合什麼？ 專案失敗的原因裡，客戶端抽不出人至少和廠商能力不足一樣常見，肯把這句話說出口的廠商，是在描述現實而不是在賣東西。

結束之後哪些東西是我們的？ 程式碼、基礎架構、各種帳號、資料。這件事要在決標之前落成書面，而不是之後。

怎麼讀這些回覆

最便宜的報價通常反映的不是效率最高，而是對範圍最窄的一種解讀，而這個差額會在開工之後以變更申請的形式重新冒出來。

看看每家廠商把力氣花在哪裡。把篇幅花在系統串接與資料轉移上的提案，代表它明白難處在哪。把篇幅花在方法論和團隊合照上的提案，代表它根本沒有和問題正面接觸。

對方主動提出的反駁，應該當成好訊號。一家廠商說你範圍裡的某一部分其實沒必要做，或者說你提出的某個限制的代價大過它的價值，這正是你真正希望別人替你做的工作。什麼都點頭的廠商，看起來省事，合作起來更糟。

還要核對每一份報價回答的是不是同一個問題。兩份報價如果差了三倍，那麼其中一份一定假設了文件沒有寫的東西，找出是哪一份，比任何評分矩陣都有用。

什麼時候不該走 RFP

如果工作量很小，或者帶有探索性質，或者你還不知道自己需要什麼，那麼 RFP 就是用錯了工具。它會讓雙方各花掉幾個星期，最後只留下一種精確的假象。

這些情況下，通常更好的做法是先做一次付費的需求訪談：用一小段工作產出一份規格書，之後再拿它去找廠商；或者得出結論說這件事根本不值得做。這兩種結果，都好過讓大家圍著一個誰也定義不清的範圍去比價。關於怎麼收斂範圍，我們那篇MVP 軟體開發指南裡的做法可以直接沿用。

Mecanik 既會以廠商身分回應 RFP，也會協助採購方把 RFP 寫出來，這是我們軟體開發工作的一部分。真正能換來好報價的文件，無一例外都是比較短的那一份，而且裡面有真實的數字。

常見問題

一份軟體 RFP 應該包含什麼？ 業務問題與成功的定義，帶真實數字的規模與數量，需要串接的系統逐一點名並說明每個是否有完整文件的 API，待轉移資料的狀態，哪些限制是真正動不了的，哪些內容明確不在範圍內，以及一個預算區間。

要不要在 RFP 裡寫預算？ 要寫。藏著預算並不會讓價格變低，只會換來一批依照誰也不知道的預算裁切過的提案，之後還得重做。給出區間，廠商才能告訴你在這個範圍內實際做得到什麼，各家的回覆也才具備可比性。

同一套軟體，報價為什麼可以差這麼多？ 通常是因為文件留了空白，而每家廠商用了不同的假設去填。像「使用者管理」這樣一行字，沒有說明角色數量、是否依單筆資料設定權限、是否需要串接使用者目錄，報一週和報兩個月都可以是誠實的。這種落差是 RFP 的性質，不是廠商的性質。

哪些問題能看出一家好的軟體廠商？ 他們會先做什麼、為什麼這樣做，他們認為風險最大的是什麼、打算怎麼降低，具體由誰來做、投入多少比例的工時，範圍變更怎麼處理，需要你配合什麼，以及結束之後哪些東西歸你所有。

什麼情況下不該用 RFP？ 工作量小、帶探索性質，或者你還無法定義自己需要什麼的時候。圍著一個沒定義清楚的範圍比價，會讓雙方各花掉幾個星期，只換來精確的假象。更適合的工具是一次付費的需求訪談，它要麼產出一份規格書，要麼直接得出這個專案不值得做的結論。