半年救回一個「雙方已經吵到停擺」的億級公家機關專案

客戶背景

某外商系統整合大廠（年營收億級）承接政府機關核心業務系統，前端開發交由外部設計公司承包。專案採政府標案規格：驗收規則繁複、時程有法定壓力、延遲即違約。

災難現場

我進場時，專案已被正式判定延遲：

• 委託方的 API 規格完成度不到 50%，卻已要求承包方開始串接。
• 承包方是設計公司，誤判工作範圍，承諾了自己做不到的「切版＋串接全包」，而合約金額不到百萬——遠低於實際工作量。
• 雙方沒有共同的溝通規範：一句「API 好了」與一句「打不通」，就能各自延宕一到兩週。小至欄位修改都以「日」為單位在來回。
• 現場氣氛：進度看不見，互相指責看得見。

進場條件

我向專案經理提出一個條件式承諾：

以技術規格為範圍，兩週內給你可驗證的結果；給不了，我走人。

要求的對價是現場指揮權。救援案沒有權力，就只是多一個淌渾水的人。

兩週內完成的四件事

一、止血。 釐清設計公司的合約與能力落差，協調折價驗收、轉為維護支援角色——先讓戰場少一個混亂源。

二、重建架構。 親手建立前端專案架構，將 API 層、驗證層、共用元件全部分層封裝。此後一般開發者的工作被簡化成一件事：看懂規格書、照填、測試。

三、建立紀律。 下班必推送、上班先同步的版本規則；我每日最後留守，逐一檢視合併、隔日一對一回饋。

四、複製自己。 挑出配合度高的成員建立組長制，把檢視與回饋的工作逐步交出去——讓體制在我離開後仍能運轉。

關鍵的一個事實

實際投入開發的人力，多數是從未寫過前端的後端工程師。

架構把難度封裝掉之後，人力就不再是瓶頸。這不是因為那些工程師突然變厲害了，是因為「需要多厲害才能參與」這件事，本身是可以設計的。

成果

• 已判定延遲的專案，六個月後成功進入 UAT 驗收階段，脫離違約風險。
• 停擺的雙方溝通，重建為以日為單位穩定推進的開發節奏。
• 交付的不只是程式碼，還有一套後續團隊能自行運轉的開發體制。

救援案的第一步不是寫程式，是讓所有人重新相信「這件事做得完」。