文章目錄
網站原本預計六週上線。第三週還在等文案，第五週主管才看到首頁，接著又有人提出要加會員登入。最後大家只記得「網站延期了」，卻說不清楚究竟是哪一段延了。
這類專案常被歸因為設計或工程速度，但真正卡住的，往往是需要有人做決定的事情，一直被當成待辦事項放著。
如果你還在整理需求，可以先看網站改版前的需求檢查表。這篇接著談專案開始後，怎麼找出真正阻塞時程的決策。
先分清楚：現在是在製作，還是在等待？
專案看板上寫「首頁製作中」，不代表這一週真的都在製作。它可能同時包含：
- 等客戶確認服務名稱。
- 等攝影素材與案例授權。
- 等主管決定要不要公開價格。
- 等第三方提供串接帳號。
- 等上一輪意見整合完成。
如果這些等待沒有被單獨記錄，最後就會全部算在設計或開發天數裡。
最簡單的改善，是把每個項目標成「製作中」「待確認」「受阻」或「完成」。待確認還要寫清楚等誰、等什麼、最晚何時需要答案。如此才能判斷是資源不足，還是決策尚未發生。
決策一：誰能做最後決定？
窗口負責傳話，不一定有權定案。當設計稿要經過業務、行銷、主管與老闆，每個人分開回覆，製作端就會收到互相衝突的版本。
專案開始時應先確認：
- 日常聯絡由誰整理。
- 內容、視覺與功能分別由誰核准。
- 意見衝突時，誰做最後決定。
- 最晚幾個工作天內要回覆。
- 決策者不在時，由誰代理。
這不是要求所有事只由一個人決定，而是每一類問題都要有一個結案方式。若沒有最後決策者，再完整的意見收集也只會變成更多待辦。
決策二：內容由誰提供，哪一版才算正式？
網站不是先畫好空格，再把任何文字塞進去就好。標題長度、服務數量、案例照片與 FAQ 結構，都會影響畫面與資料設計。
內容工作至少要有三個欄位：負責人、交付日期、正式版本位置。不要讓正式文案散在聊天訊息、簡報、電子郵件與多份文件裡，再請製作端猜哪一份最新。
若內容來不及，可以選擇：
- 先縮小首波上線範圍。
- 用已核准的舊內容上線，之後排第二階段更新。
- 延後該頁，但不讓它拖住無關頁面。
- 另外委託文案、攝影或資料整理。
真正危險的是沒有做選擇，只說「快好了」，卻讓所有後續工作一起等待。
決策三：哪些是原範圍，新增需求怎麼換？
專案進行中看見成品，想到新功能很正常。問題不是需求會變，而是變更是否被當成沒有成本的小修正。
收到新增需求時，先回答四件事：
| 要確認的事 | 具體問題 |
|---|---|
| 內容 | 新增的是頁面、欄位、流程，還是第三方串接？ |
| 原因 | 它是補足原需求，還是新的商業想法？ |
| 影響 | 會動到哪些設計、資料、測試與既有功能？ |
| 選擇 | 增加預算、延後日期、替換原項目，還是排第二階段？ |
每個變更都應留下選擇結果。這樣不是為了斤斤計較，而是避免團隊一邊維持原上線日，一邊默默把工作量加大。
報價時還沒對齊範圍，可以搭配網站報價應比較的七個項目檢查。很多所謂追加，其實是最初沒有寫清楚交付內容。
決策四：外部依賴何時要到位？
有些工作不在網站團隊手上，卻會直接擋住上線：
- 網域、DNS 與主機帳號。
- 寄信服務與正式收件信箱。
- 金流、物流、會員或 CRM 的測試資料。
- 隱私權條款、法務文字與素材授權。
- 第三方廠商的 API、白名單或審核。
不要只寫「需要金流帳號」，要倒推最晚取得日期，並確認誰申請、誰保管、測試環境能否先用。外部審核時間通常不是網站廠商能壓縮的工時，越晚發現，越容易在最後一週卡住。
如果正式帳號暫時無法取得，也要先決定：使用測試環境、隱藏該功能，或調整上線範圍。等待本身不可怕，沒有替代方案才會讓整個專案停下來。
決策五：回饋怎麼收，哪一輪算完成？
「大家有空看一下」通常不會得到可執行的回饋。有人只看手機，有人只改文字，也有人在兩週後重新討論已確認的架構。
每一輪審查應先說明：
- 這次要看哪幾頁、哪個裝置。
- 要確認的是方向、內容，還是細節。
- 哪些地方仍是暫稿，不用評論。
- 回饋截止時間與統一提交位置。
- 誰負責整合重複或矛盾的意見。
方向稿通過後，就不要在視覺細修階段重新問「網站是不是該換一種定位」。若真的要重開前一階段，可以做，但要同步更新範圍與日期。
決策六：什麼條件下可以驗收與上線？
若上線標準只有「大家覺得差不多」，最後一週一定會出現無限延伸的修改。
請在專案前段就定義：
- 哪些頁面與流程是首波必須完成。
- 哪些文字與素材一定要正式核准。
- 哪些裝置與瀏覽器需要檢查。
- 表單、通知、追蹤與搜尋設定怎麼驗證。
- 哪些小問題可以列入上線後修正。
- 最終上線由誰確認。
網站驗收的八個使用情境可以當成執行清單。驗收標準越早講清楚，團隊越能把時間留給真正重要的測試，而不是在最後三天重新定義完成。
不要再問「完成幾％」，改看這張決策表
百分比很容易製造進度感，卻不一定能預測日期。首頁做到 90%，若剩下的是主管尚未核准的定位，它仍可能阻塞整站。
可以改用這種格式追蹤：
| 項目 | 狀態 | 下一個決定 | 負責人 | 最晚日期 | 逾期影響 |
|---|---|---|---|---|---|
| 服務頁文案 | 待確認 | 核准三項服務名稱 | 業務主管 | 10/07 | 延後版面定稿 |
| 表單通知 | 受阻 | 提供正式收件信箱 | 內部 IT | 10/09 | 無法完成寄送測試 |
| 案例頁 | 製作中 | 確認首波放兩案或四案 | 專案窗口 | 10/10 | 影響內容輸入量 |
表中的內容是示意，不是某個實際專案。重點是把「等待」轉成一個可回答的問題，而不是寫成模糊的「客戶處理中」。
每週會議先處理已受阻與即將到期的決策，再談完成多少畫面。只要阻塞有人接、變更有選擇、驗收有條件，時程才有機會被管理。
常見問題
網站延期時，應該先要求廠商加快速度嗎？
先確認目前卡住的是製作工作，還是等待內容、回覆、帳號與決策。如果待確認事項沒有完成，只要求加速通常只會壓縮後面的測試時間。請把每個阻塞項目、負責人、最晚確認日與影響範圍列出，再決定要加人、減少範圍或調整日期。
網站內容還沒準備好，可以先開始設計和開發嗎？
可以先做架構、元件與已確認的頁面，但不能假設所有內容之後都能無痛塞入。至少要先確認頁面目的、內容類型、預估長度與負責人；若正式內容未到，應標示哪些畫面只是暫稿，以及內容變動到什麼程度需要重新估時。
網站專案要如何處理臨時新增的需求？
不必一律拒絕，但要先記錄新增內容、原因、估計工時，以及會替換或延後哪一項工作，再由有決策權的人確認。若每個新想法都直接插入原排程，交付日就只是願望，不是可管理的承諾。
結論
網站延期不一定代表誰做得慢。內容沒有版本、意見沒有結論、外部帳號沒有到位，或上線條件從未定義，都會讓製作時間被等待吞掉。
先把六個決策的負責人、期限與影響寫出來。你會更早知道問題在哪，也更容易在加預算、減範圍與調日期之間做出清楚選擇。
如果你的網站專案已經卡住，可以帶著目前排程與待確認清單一起討論，先找出真正的阻塞，再決定下一步怎麼救回來。
