可比較的提案始於清楚的專案需求：值得提供的12項資訊

英國現行Sourcing Playbook指出，清晰的需求說明應向潛在投標方提供足夠資訊，使其能夠在充分瞭解情況的基礎上決定是否參與。文件還指出，如果各方對要求沒有共同理解，就很難把所報價格與採購方對成本和預期結果的理解聯繫起來。 [1]

Government Commercial Function的表述更加直接：好的需求說明應包含足夠資訊，讓供應商能夠準確計算商品或服務的成本，從而讓採購方在相近基準上比較不同提案。 [2]

與此同時，英國Digital, Data and Technology Playbook提醒不要把解決提案規定得過細。它建議關注使用者、問題和預期結果，同時給供應商留出提出有效實作方式的空間。 [3]

因此，結論並不是 “把所有事情寫得越細越好”。更好的原則是：

準確寫明所有提案必須共同遵循的內容，而不要替有能力的專業人員預先決定那些本可以合理自行設計的部分。

兩份專業提案不會完全一樣，也不應該追求完全一樣。

可比較意味著專業人員是在 大體相同的假設下回答同一個問題。

因此，他們對以下內容應有大致一致的理解：

• 目標,
• 範圍,
• 起點,
• 預期結果,
• 重要限制,
• 時間安排,
• 客戶責任,
• 價格如何呈現,
• 提案將依據甚麼標準評估.

而以下內容可以不同：

• 建議的思路,
• 工作順序,
• 方法,
• 團隊構成,
• 工具,
• 階段劃分,
• 降低風險的方式.

這些差異往往正是有價值的部分，因此應該保持可見。

從問題開始，而不是從功能清單開始。

與其寫：

“我需要一個帶總覽頁面、通知和報告的應用。”

不如寫：

“目前有五個人通過電子錶格和電子郵件管理流程。很難檢視每個事項的目前狀態、負責人以及下一步任務。我們希望減少人工跟蹤，並在一個地方看到最新狀態。”

第二種描述仍沒有決定應該做甚麼樣的應用。

但它能幫助專業人員理解 這個專案為甚麼存在。

針對成果導向服務，Federal Acquisition Regulation建議主要通過所需結果描述工作，而不是只規定工作方式或投入小時數。目標說明的最低內容包括目的、範圍、背景、所需結果和運行限制等。 [4]

因此，應寫清工作結束後甚麼事情應該能夠實作。

例如：

• 使用者能夠獨立完成指定流程,
• 團隊能夠檢視所有事項的目前狀態,
• 客戶獲得帶優先級的分析,
• 系統移轉到新環境並按商定標準運行,
• 準備好的材料可在指定渠道發佈.

結果應足夠具體，讓雙方都能理解工作的方向。

但這不意味著必須保證由市場、使用者行為或供應商無法控制的其他因素決定的商業結果。

同一個最終目標，根據起點不同，所需工作量可能差別很大。

建議說明：

• 已經有哪些東西,
• 哪些可以正常工作並應保留,
• 哪些不能正常工作,
• 是否有原始檔,
• 是否有現有文檔,
• 是否需要移轉資料,
• 是否必須在現有系統上繼續工作,
• 哪些材料已經準備好.

“新網站” 可能意味著從零開始建設，也可能意味著在保留內容、網址、分析設定、系統集成和資料的情況下重建現有網站。

即使最終外觀可能相似，這也是兩種不同的工作。

專案範圍不應讓專業人員自己猜測問題的哪些部分需要計價。

例如：

範圍內：

• 分析目前提案,
• 設計新頁面,
• 實作,
• 移轉已經明確的一部分資料.

範圍外：

• 創建新內容,
• 購買授權,
• 第一個月之後的維護,
• 重建付款系統.

世界銀行的Terms of Reference示例強調，應清楚說明咨詢服務的要求和期望，並根據具體專案進行調整。 [5]

當兩項工作天然相關，很容易讓人誤以為一項包含另一項時，明確邊界尤其重要。

如果你期待特定材料或結果，就直接寫明。

例如：

• 可運行的解決提案,
• 原始檔,
• 報告,
• 文檔,
• 視覺設計,
• 一組材料,
• 環境配置,
• 訓練,
• 錄制文件,
• 程式碼和存取權限的交接.

“設計”、“分析”、“實作” 等詞可能被不同的人理解成不同內容。

統一列出主要交付內容，可以避免某份提案實際上包含遠多於另一份提案，卻因為服務名稱相似而看不出差異。

並不是每個限制都屬於技術細節。

重要限制可能包括：

• 必須使用的系統或環境,
• 必須與指定服務集成,
• 無障礙需求,
• 行業法規,
• 資料存儲限制,
• 必須保留現有基礎設施,
• 指定設備或瀏覽器,
• 必須在特定時間工作,
• 資料存取限制.

FAR在目標說明中明確包括運行限制，而英國Digital, Data and Technology Playbook也說明，如果並不存在真正的限制，就不應提前規定解決提案。 [4] [3]

一個實用原則是：

明確專業人員不能改變的內容，但不要僅僅因為你習慣某一種提案，就人為創造一個限制。

專業人員需要知道，自己的提案可以建立在怎樣的客戶配合基礎上。

請說明你是否會提供：

• 決策者,
• 系統存取權限,
• 現有材料,
• 資料,
• 測試帳號,
• 團隊資訊,
• 與使用者接觸的條件,
• 內容,
• 定期會議,
• 在指定時間內回復.

如果你現在還不知道能夠提供甚麼，也應該直接說明。

缺少對資料、材料或人員的存取，可能改變方法、成本和時間。這不是小的行政細節，而是提案成立所依賴的條件之一。

不是每一個日期都有同樣的含義。

應區分：

• 希望開始的日期,
• 不能移動的截止日期,
• 與外部事件相關的日期,
• 參考日期,
• 必須按特定順序發生的階段.

如果截止日期確實不能移動，請解釋原因。

如果可以調整，也應說明。

這樣專業人員可以提出不同的範圍、順序或分階段交付，而不是把所有日期都當成絕對要求。

沒有一條統一規則要求客戶必須始終公開全部預算。

根據情況，你可以提供：

• 最高預算,
• 預算區間,
• 第一階段預算,
• 先希望收到範圍建議，再討論價格,
• 希望價格按甚麼結構拆分.

為了比較，最重要的是讓專業人員用類似結構呈現成本。

例如：

“請分別列出分析、設計、實作和每月維護的價格，同時注明未包含在報價中的第三方服務費用。”

這種格式比四個總價更容易比較，因為不同總價可能各自包含完全不同的內容。

不確定性不會因為沒有寫下來就消失。

如果你不知道：

• 需要移轉多少資料,
• 外部介面是否支持所需操作,
• 所有內容是否能夠按時準備,
• 目前程式碼是否適合繼續擴展,
• 必需的批准是否會按時獲得,

就直接說明。

GAO關於可靠成本估算的指南強調，明確假設以及分析風險和不確定性非常重要。 [6]

這樣，好的專業人員可以：

• 設置合理預留,
• 建議先做調查階段,
• 分別給不同提案報價,
• 指明甚麼條件會導致價格變化,
• 拒絕假裝給出目前還無法誠實達到的精確程度.

公開的未知事項，比隱藏的假設更好。

如果你已經知道決策時哪些因素重要，應在專業人員準備提案之前說明。

可以評估：

• 所提方法是否合適,
• 是否有類似問題的經驗,
• 過去工作證據的質量,
• 時間計畫是否現實,
• 可投入程度,
• 風險管理方式,
• 實際執行專案人員的能力,
• 價格,
• 維護成本,
• 溝通質量.

世界銀行目前關於Rated Criteria的資料指出，非價格標準可以包括方法和工作計畫質量、風險管理、履約和能力以及關鍵人員。標準根據具體採購進行調整，並按相對重要性設置權重。 [7]

這並不意味著小專案需要正式打分。

在發送需求前，能夠回答這個問題就很有幫助：

“除了價格之外，甚麼會讓一份提案對我而言比另一份更好？”

如果你確實希望比較提案，就讓所有人回答同一組基本問題。

例如：

1. 你如何理解這個問題和預期結果？
2. 你建議甚麼方法？
3. 你的提案具體包括甚麼？
4. 哪些內容不包括？
5. 你基於哪些假設？
6. 時間安排是甚麼？
7. 你需要客戶提供甚麼？
8. 主要風險是甚麼？
9. 價格是多少，具體包含甚麼？
10. 哪些類似經驗或工作證據與本專案有關？

在公共採購中，統一回復、評估標準和價格呈現格式，就是為了能夠在共同基礎上評估提案。Government Commercial Function強調，應提供足夠資訊，以支持準確成本計算和相同基準上的比較。 [2]

統一格式不應抹去不同專業人員之間的差異，而應讓這些差異出現在相同的位置，便於看清。

這取決於需求的目的。

公開預算可能有幫助，例如：

• 可以根據可用資金調整範圍,
• 希望在明確上限內獲得最佳提案建議,
• 希望迅速排除不符合專案財務現實的提案.

不公開完整預算也可能合理，例如：

• 希望先獲得對合理範圍的獨立意見,
• 還不知道現實成本,
• 正在比較不同解決模式,
• 流程要求用其他方式收集價格.

最糟糕的情況不一定是沒有預算，而是沒有說明 你希望對方以甚麼形式回答價格問題。

專業人員應知道，是給一個總價、一個區間、幾個提案、分階段價格，還是給出獲得更精確估算所需的前提條件。

好的專案需求說明不需要回答所有問題。

可以坦率地寫：

• “我們還不知道目前系統能否安全擴展。”
• “我們不知道需要移轉的準確紀錄數量。”
• “我們還沒有決定第二種語言是否進入第一階段。”
• “我們需要幫助選擇最合適的提案。”

這些都是有價值的資訊。

不確定性應該影響提案如何準備，而不是從文檔里消失。

在某些情況下，第一項最合適的服務並不是全面實作，而是一個短期調查階段，最終得到決策、更準確的範圍或更可靠的估算。

1. 給每位專業人員不同的資訊。

2. 只列功能，不解釋問題和目標。

3. 不說明已經有哪些東西。

4. 隱藏會在後面改變實作方式的限制。

5. 要求一個最終總價，卻不說明這個價格應包含甚麼。

6. 用自己事前都沒有明確的標準評估提案。

7. 把詳細描述問題和詳細規定解決提案混為一談。

1. 我是否清楚描述了問題，而不僅僅是自己想象的解決提案？
2. 我希望達到的結果是否清楚？
3. 專業人員是否能理解目前狀態？
4. 必須保留的內容是否清楚？
5. 第一階段範圍邊界是否清楚？
6. 我是否列出最重要的交付內容？
7. 我是否說明真實限制？
8. 我這一方會提供甚麼是否清楚？
9. 時間安排是否連同靈活程度一起說明？
10. 價格呈現格式是否方便比較提案？
11. 我是否公開說明最重要的未知事項？
12. 我是否知道除了價格還要評估甚麼？
13. 所有專業人員是否會回答類似的一組問題？
14. 我是否為比自己設想更好的解決提案留下空間？

好的專案需求說明有兩個看似相反的目標。

它應當 足夠具體，讓幾位專業人員針對同一個問題報價。

同時也應當 足夠開放，讓每個人提出自己的、可能更好的解決思路。

一個實用順序是：

問題 -> 結果 -> 目前狀態 -> 範圍 -> 交付內容 -> 限制 -> 客戶責任 -> 時間安排 -> 價格格式 -> 未知事項與風險 -> 選擇標準 -> 統一回復格式。

如果收到提案後才發現，一個人報價整個專案，一個人只報價分析，第三個人又假設存在額外集成，那麼問題不一定出在價格本身。

即使所有人收到的是同一段文字，他們實際理解到的也可能是不同的專案。

[1] UK Government - The Sourcing Playbook
打開來源

[2] Government Commercial Function - How to write a procurement specification
打開來源

[3] UK Government - The Digital, Data and Technology Playbook
打開來源

[4] U.S. Federal Acquisition Regulation - Subpart 37.6, Performance-Based Acquisition
打開來源

[5] World Bank - Sample Consultants Terms of Reference
打開來源

[6] U.S. Government Accountability Office - Cost Estimating and Assessment Guide, GAO-20-195G
打開來源

[7] World Bank - Rated Criteria
打開來源

方法說明： 這些來源主要來自公共採購和成本管理環境，並不作為私人專業人員市場的直接規則。本文只採用它們實際支持的原則：要求清晰、聚焦結果、明確假設和風險、可比較的價格資訊，以及使用價格之外的質量標準進行評估。