專案為什麼會延期?時程失控的解剖報告

做了這麼多年專案,先認了:我們也延期過。所以這篇不是廠商在推卸責任,是一份解剖報告——把延期的屍體切開,看看裡面到底是什麼。結論先講:延期很少是「工程師寫太慢」造成的,多數是流程裡的等待和反覆吃掉的。

延期的四大真因

一、需求變更(最大宗)

「順便加一下」「這裡改一下應該很快吧」——每一個小改動單獨看都合理,加總起來就是時程的凌遲。更隱蔽的是「看到成品才知道自己要什麼」:規格階段點頭的東西,做出來之後推翻重來。這無關善惡,是人性;但沒有變更管理機制去接住它,人性就會直接輾過時程。這題值得單獨一篇,我們寫在需求變更怎麼處理。

二、等待:素材、內容、帳號

講一個業內都知道、業主都不信的事實:專案卡最久的環節,常常是等客戶交東西。商品照、公司介紹文案、金流申請文件、網域權限——這些只有業主能給的東西,每晚一週,上線就晚一週。而且它有連鎖效應:我們的人力排程是接力的,你的空檔撞上我們下一個專案的檔期,一週的延遲會滾成三週。

三、決策卡關

設計稿送出去,兩週沒有回音;或者更慘,回了三個互相矛盾的意見,沒有人拍板。專案裡每一個「待確認」都是一顆停止時間的按鈕。我們現在簽約前必問:誰是唯一決策窗口?這題沒有答案的專案,時程表只是裝飾品。

四、第三方的驚喜

金流審核比預期久、平台審核被退件、外部 API 文件跟現實不符。這類風險無法歸零,只能提早:所有依賴第三方的申請,第一週就送出去,不要留到需要的前一刻。

專案時程不是被某一個大災難毀掉的,是被十幾個「小事,等一下就好」慢慢失血而死的。

我們的預防機制

解剖完,講藥方。我們現在的做法:兩週一次交付可操作的版本,讓「做歪」在兩週內就被發現,而不是三個月後(這套節奏的細節在這篇);開案第一天就給業主一張交付清單,素材、帳號、文件,每項標死線,並且誠實告知「晚給的後果是什麼」;回饋設定回覆期限,例如設計稿七天內回覆,逾期視同下一輪處理;估時程時把「等待與反覆」估進去——只估工程時數的時程表,從第一天就是假的。

還有一件事跟預防同樣重要:延期真的發生時怎麼處理。我們的原則是提早講、講實話、給選項——一發現時程有風險就通報,不拖到死線當天;誠實說明原因,不編故事;同時給出取捨方案:是延後上線日,還是先砍掉部分範疇如期上線核心功能。多數業主可以接受延期,不能接受的是被瞞到最後一刻。時程失控不一定毀掉合作,失去誠信才會。

最後給業主一句真心話:選廠商時,把「你們會不會延期」換成「你們延期過嗎?後來怎麼處理?」前者只會得到保證,後者才會得到真相。從不承認延期過的團隊,和保證絕不延期的團隊,是同一種團隊。