軟體外包 Kickoff Meeting 完整 SOP：8 個必對齊事項、4 份必交付文件、5 個老闆首次開會該問的問題、3 個決定後 90 天命運的議題——把專案開頭那 4 小時開好

我們開過超過 30 場客製化系統開發的 Kickoff Meeting。其中開得不好的、有 70% 在後續 60 天內爆出進度問題或範圍爭議；開得好的、有 80% 在預算內準時上線。同一群工程師、同一張合約、就因為 kickoff 那 4 小時沒對齊，後面 90 天差別可以到 3 個月與 200 萬。

中小企業老闆對 kickoff 普遍存在三個誤解：以為它就是「彼此認識的破冰會」、以為合約簽完就算「對齊好了」、以為「先做了再說、邊做邊改」效率比較高。實際上這場會的本質是「把合約裡所有模糊地帶都壓回具體可驗證的字眼」——這 4 小時做好，後面 90 天少 20 次爭議；這 4 小時偷懶、後面 90 天每週都在開「澄清會」。本篇把我們開過的 30+ 場 kickoff 經驗整理成可直接抄走的 SOP。

為什麼 Kickoff Meeting 是中小企業外包案最被低估的 30% 成敗因素

PMI（Project Management Institute）2024 Pulse of the Profession 報告指出，high-performing organizations 的專案準時上線率達 73%，underperforming 只有 48%——兩者最大差距不在工程師能力，而在「專案啟動階段的對齊深度」。延伸資料見 PMI Pulse of the Profession 報告概覽

我們自己的觀察符合這份數據：kickoff 開得仔細的案子、change request 數量平均 4-6 次；kickoff 草草帶過的案子、change request 平均 18-24 次。後者每次 change request 不只是「多做一個功能」、是「以為已經談好的事其實沒談好」、要回頭吵範圍 + 預算 + 時程，每次平均吃掉 1-2 週。

更糟的是 kickoff 階段的對齊失誤、會在後面以「廠商不專業」「客戶很 trolling」這種人身攻擊形式爆出來。明明是議程沒對齊、最後變成情緒對立、信任崩盤——這時候即使換廠商也救不回，因為下一家廠商接手時你連自己要什麼都說不清楚。Kickoff 開好不是「對廠商客氣」，是保護自己後續 90 天的決策能力。

8 個必對齊事項：kickoff 議程逐項拆解

我們把開過的 30+ 場 kickoff 議程歸納成 8 個必對齊事項。每一項都對應後面 90 天會爆出來的某個典型爭議——少對齊一項，那個爭議幾乎一定會發生。建議照這個順序對齊，前面對齊不好、後面議題會回頭吵。

這 8 項都做完約 3.5 小時，加上 30 分鐘討論餘裕，剛好 4 小時。短於這個時間幾乎一定有 1-2 項沒對齊；長於這個時間表示「在 kickoff 上又談需求」、要拉回「對齊」而不是「設計」。

5 個老闆首次開會該問的問題：把廠商的話術翻譯回實際承諾

Kickoff 上有些話術是廠商的常用詞、聽起來很合理、實際上是「我這時候還不想答」的委婉拒絕。下面 5 個問題是我們建議老闆主動問的——把廠商還沒想清楚的部分逼出來，比後面爆出來代價低。

Q1：「你們上一個同規模案子實際上線時程跟原訂時程差多少？延遲的原因主要是什麼？」

這題的目的是評估廠商歷史延遲率。會直接答的廠商通常有 case study + 反思；會回「我們不太會延遲」的廠商在說謊（已上線 8 年的公司不可能完全不延遲）、會說「每個案子都不同沒辦法比」的廠商不願面對自己的歷史。我們建議「延遲率超過 50%」的廠商直接列高風險、合約裡的罰則條款要更嚴。

Q2：「如果我們今天突然加一個新功能、你們怎麼算錢、最快幾天回報價？」

這題在問 change request SLA。好的廠商會說「24-48 小時內回 t-shirt size（S/M/L/XL 對應預估工時）、3-5 天回正式報價、需要客戶簽 change order 才開工」。模糊回答「看狀況」「我們會盡快」的廠商，第 3 週你提一個小變更他會做 2 個月、吵錢時你拿不出依據。

Q3：「Production 環境上線後第一個月、你們的 on-call 機制怎麼運作？回應時間多久？」

這題打的是「廠商有沒有想過上線後」——很多廠商只規劃到「交付」、上線後就是「按 case 收費」、出問題回應慢到客戶崩潰。專業廠商會有清楚的 SLA：P0（系統不能用）4 小時內回、P1（核心功能異常）24 小時、P2（小 bug）3 個工作日。沒這個 SLA 的、要在合約裡把「上線後 30 天免費 hot fix + 隔月轉維運合約 SLA 」寫進去。

Q4：「你們團隊在這個案子上同時還有幾個別的案子？我們的優先級排第幾？」

這題逼廠商承認資源實際分配。回「只接你們這個案」的廠商在說謊（公司不可能養工程師只接一單）、回「您的案子是我們本季 top priority」沒指標的空話、回「我們 PM 同時跑 3 個案子、Tech Lead 你們專屬」這種具體答案才可信。資源分配是延遲第一大原因、kickoff 不問清楚後面只能怪自己。

Q5：「如果中途我們對某個技術選型有疑慮、想找第三方顧問來 audit，你們配合的方式是？」

這題篩「廠商願不願意被第三方檢視」。願意配合 audit 的廠商通常做事乾淨、不怕被看；推三阻四「我們的 code 是商業機密」「audit 會影響進度」的廠商已經在預告「我們不想被檢視」。Audit 是客戶最後的止血手段、kickoff 就把規則談清楚、後面真的需要時不會吵翻。

4 份必交付文件：kickoff 後 48 小時內客戶必須拿到的東西

kickoff 會議跑完後、廠商該交付 4 份文件、客戶要在 5 個工作日內 review 並簽回。這 4 份文件是後面 90 天的「法律 + 工程」基礎——少一份、後面有 30% 機率回頭吵。

這 4 份文件最常見的瑕疵是「文件有但內容模糊」——範圍清單寫「會員系統」（OK）但沒拆「會員系統包含登入 / 註冊 / 忘記密碼 / OAuth / 個資頁面 / 訂閱管理」（NG）。客戶 review 時的責任就是「逐條問廠商這個範圍實際邊界在哪」——這個對話會痛、但比後面爆出來痛少 10 倍。

3 個決定後 90 天命運的議題：kickoff 上沒談清楚就會反覆爆

有 3 個議題特別容易在 kickoff 被「先放著、之後再說」、但這 3 個只要沒談、後面 90 天保證會以各種爭議形式爆出來。建議在 kickoff 上強迫談完、寧可吵 1 小時也比後面吵 4 週好。

議題 1：「快速 vs 完整」的取捨偏好

專案中後期會出現大量「這個功能要做齊還是先求能用」的抉擇。如果客戶心裡是「上線時要完整」、廠商以為是「先求能用」、雙方期待錯位、做出來的東西誰都不滿意。kickoff 上就要明確：產品定位偏 MVP（minimum viable）還是 GA（general availability）？哪些功能是「上線必要」、哪些是「上線可後補」？這個傾向白紙黑字寫進範圍清單——廠商技術決策會基於這個傾向，吵不到後面。

議題 2：「客戶提供 vs 廠商代購」的第三方服務劃分

金流（綠界 / 藍新）、簡訊（Twilio / 三竹）、寄信（SendGrid / Postmark）、OAuth（Google / Line）、AI API（OpenAI / Anthropic）——這些第三方服務每個都涉及「誰申請帳號」「誰付月費」「誰擔資安責任」。沒談清楚的後果是：帳號綁在廠商個人名下、廠商收到月費帳單想轉嫁、出資安事件責任不清。kickoff 上明確：所有第三方服務「客戶名義開戶、客戶付費、廠商以 contributor 身分操作」——這條從 kickoff 就定、後面不用再吵。

議題 3：「客戶自己的人需要學多少」

系統做完之後客戶內部需要有人 maintain、要不要客戶側培訓？培訓誰？需要多少時間？培訓費包在合約裡還是另計？這題大部分 kickoff 都跳過、結果上線後客戶以為廠商會教、廠商以為 GA 後不再負擔教學、雙方吵翻。Kickoff 上明確：是否包培訓 / 培訓對象 / 培訓時數 / 培訓教材歸誰 / 培訓費怎麼算——這 5 點談清楚，上線後客戶的學習曲線會順很多。

Kickoff Meeting 議程範本：4 小時逐分鐘流程

這份議程是我們自己 kickoff 的實際範本、過去 18 個月跑了 18 場、效率與滿意度最高的版本。直接抄走就能用、或根據自己案子大小調整時間。

最容易被偷時間的是「範圍邊界對齊」這 40 分鐘——很多廠商會想 20 分鐘帶過、客戶累了也想早點結束。但這 40 分鐘是 ROI 最高的——少談 20 分鐘、後面 90 天多吵 10 次。寧可午餐推遲 30 分鐘、也不要在這條偷時間。

延伸閱讀

發包前的準備：｜軟體 RFP 怎麼寫？老闆版需求書範本與 30 條必備欄位 checklist｜老闆找外包前必備的客製化系統需求書（BRD）完整寫法｜客製化系統發包『3 家報價差 5 倍』完整解碼框架

發包後可能遇到的：｜客製化系統開發專案延遲完整指南｜軟體外包驗收後的維運合約怎麼簽？｜客製化系統『源碼託管』(Source Code Escrow) 完整指南

採購決策框架：｜SaaS vs 客製化系統：中小企業到底該選哪一個？