專案時程（Project Schedule）是專案管理中用來規劃、追蹤與控制所有任務時間安排的核心文件，涵蓋任務起迄日期、依賴關係、里程碑與關鍵路徑。
專案時程是什麼？定義與核心術語（Project Schedule vs. Timeline）
在台灣職場中，「專案時程」和「專案時間軸」常被混用，但它們在專案管理中其實指向不同的東西。搞清楚這些術語的差異，能讓你在跟主管報告或跟團隊溝通時更精準。
Project Schedule 與 Project Timeline 的中文差異
專案時程（Project Schedule）是一份正式的排程文件，詳細記錄每項任務的開始日期、結束日期、負責人、依賴關係與關鍵路徑。 它是 PM 日常管理的核心工具，通常以甘特圖或任務清單呈現，需要定期更新。
專案時間軸（Project Timeline）則偏向視覺化的時間軸呈現，通常用來向高層或利害關係人展示專案的整體時間範圍與主要里程碑，不會深入到每個任務的細節。
簡單來說：Project Timeline 是「給老闆看的」，Project Schedule 是「給團隊執行的」。在台灣，「project timeline 中文」最常翻譯為「專案時間軸」或「時間軸」，而「專案時程」則對應 Project Schedule。
專案時程 vs. 進度表 vs. 專案計畫書
這三份文件在專案管理流程中各司其職。「時程」的意思就是「事先規劃好的時間安排」，它是一份計畫；而「進度表」則是對照計畫的實際執行狀況。
| 比較項目 | 專案計畫書 | 專案時程 | 專案進度表 |
|---|---|---|---|
| 定義 | 定義專案目標、範疇、資源與整體策略的高層文件 | 細化每項任務的時間安排、依賴關係與關鍵路徑 | 記錄實際執行進度，對照時程檢視落後或超前 |
| 製作時間點 | 專案啟動階段 | 專案規劃階段 | 專案執行階段起，持續更新 |
| 主要使用者 | 專案發起人、高層主管 | PM、團隊成員、利害關係人 | PM、團隊成員 |
| 更新頻率 | 重大變更時才更新 | 每週或每次變更時更新 | 每日或每週更新 |
白話來說：專案計畫書是「我們要做什麼、為什麼做」，專案時程是「什麼時候做、誰來做」，進度表是「做到哪了、有沒有落後」。
專案時程的 5 大功能與重要性
以下是專案時程在實務中發揮的五個核心功能。
1. 掌控進度，及早發現偏差
時程讓你能在任務延遲的第一天就發現問題，而不是等到週會才知道。舉例來說，一個軟體開發專案的「API 串接」任務原定 5 天完成，如果第 3 天進度只有 20%，PM 就能立即介入——可能是技術卡關，也可能是需求不清楚。沒有時程，這個問題可能要到 Sprint Review 才浮出水面。
2. 明確分工，減少重工與遺漏
時程不只是時間表，它同時標示了每項任務的負責人。當行銷團隊知道「設計稿必須在 3/15 前完成，因為印刷需要 5 個工作天」，設計師就不會把這個任務排到 3/20。
3. 促進跨部門溝通協作
在建築工程專案中，結構工程師、水電承包商、室內設計師各自有不同的施工時程。一份共享的專案時程讓所有人看到同一張圖——當水電管線必須在灌漿前完成，時程上的依賴關係會自動提醒相關人員。
4. 預警風險，識別瓶頸
透過關鍵路徑分析，時程能告訴你「哪些任務一旦延遲，整個專案就會延期」。這比「感覺好像快來不及了」精準得多。
5. 優化資源分配
當你把所有任務攤開在時間軸上，就能看到哪些時段資源過載、哪些時段有閒置。一個 10 人的行銷團隊如果在同一週要同時處理 3 個活動的素材製作，時程會清楚顯示這個衝突，讓 PM 提前調度。
實務上，你可以用 monday.com 的甘特圖視圖一次看到所有任務的時間分布與依賴關係。我們團隊的做法是每週一早上花 10 分鐘檢視看板上的時程狀態，紅色標示的延遲任務會自動跳到最上方，不需要逐一詢問每個人的進度。
專案時程的 4 種類型：如何選擇適合你的工具
不同的專案規模和複雜度，適合不同的時程呈現方式。選錯工具不只浪費時間，還可能讓團隊更混亂。以下逐一說明四種常見類型，以及各自的最佳使用情境。
甘特圖（Gantt Chart）
甘特圖是最廣泛使用的專案時程工具，以橫條圖顯示每項任務的起迄時間、持續天數與重疊關係。它的優勢在於「一眼就能看出整個專案的時間分布」。
適用情境：
- 5 人以上的團隊，需要跨部門協作
- 任務之間有明確的先後依賴關係
- 需要向利害關係人展示整體進度
實務範例 1（行銷活動）： 一個行銷活動專案包含「市場調研 → 創意發想 → 設計製作 → 媒體投放 → 成效分析」五個階段，甘特圖能清楚顯示設計製作必須等創意發想完成才能開始，但媒體投放的前置準備可以與設計製作同步進行。
實務範例 2（軟體開發）： 軟體開發專案會將「需求分析 → 設計 → 開發 → 測試 → 上線」等階段，依照邏輯順序與預估工期繪製成甘特圖。例如「開發」必須等「設計」完成才能開始，但「測試案例撰寫」可以與「開發」同步進行，甘特圖上就能清楚呈現這些重疊與依賴。
如果你想快速建立甘特圖，可以參考我們的甘特圖產生器軟體評測。
里程碑圖（Milestone Chart）
里程碑圖只標示專案中的關鍵節點——例如「需求確認完成」、「Beta 版上線」、「正式交付」。它不顯示每個任務的細節，而是聚焦在「什麼時候要完成什麼重要的事」。
適用情境：
- 向高層主管或客戶報告進度
- 階段性交付的專案（如軟體開發的版本發布）
- 需要快速溝通專案整體狀態
里程碑設定原則： 每個里程碑必須有明確的交付物。「設計階段完成」不是好的里程碑，「設計稿經客戶簽核」才是——因為後者有明確的完成標準。建議每 2-4 週設定一個里程碑，太密集會失去聚焦效果，太稀疏則無法及時預警。
關鍵路徑法（CPM）
關鍵路徑法（Critical Path Method）是一種分析技術，用來找出專案中「影響總工期的最長任務鏈」。這條鏈上的任何任務延遲，都會直接導致整個專案延期。
如何識別關鍵路徑：
- 列出所有任務及其依賴關係
- 計算每條路徑的總工期
- 找出最長的那條路徑——這就是關鍵路徑
- 關鍵路徑上的任務，浮時（Float/Slack）為 0
浮時（Float）的概念： 浮時是指一個任務可以延遲多久而不影響專案總工期。計算方式是「最晚開始時間 – 最早開始時間」。浮時為 0 的任務就在關鍵路徑上，沒有任何延遲的餘地。
適用情境：
- 工程專案（建築、基礎設施）
- IT 系統導入專案
- 任務依賴關係複雜、超過 50 個任務的專案
想深入了解相關的網路圖分析技術，可以參考 PERT 圖表教學。
任務清單與 Excel 時程表
對於小型專案或個人任務管理，一份結構清楚的 Excel 時程表就夠用了。它的優勢是零成本、不需要學習新工具，適合預算有限或剛開始接觸專案管理的團隊。
適用情境：
- 5 人以下的小型專案
- 個人任務管理或自由工作者
- 預算有限，無法購買專業工具
Excel 專案時程表基本製作步驟：
- 建立任務欄：在 A 欄列出所有任務名稱，B 欄填入負責人，C 欄填入預估工期（天數）
- 設定日期欄：D 欄填入開始日期，E 欄填入結束日期，用公式
=D2+C2自動計算 - 加入條件格式色塊：選取日期範圍，使用 Excel 的條件格式功能，將進行中的任務標為藍色、已完成標為綠色、延遲標為紅色——這就是簡易版的 Excel 甘特圖時間軸
這個方法能做出基本的 Excel 專案時程管理表，但當任務超過 30 個或需要自動計算依賴關係時，建議升級到專業的專案管理工具。
選擇判斷框架：哪種類型適合你？
| 判斷條件 | 甘特圖 | 里程碑圖 | 關鍵路徑法 | Excel 任務清單 |
|---|---|---|---|---|
| 團隊規模 | 5-50 人 | 不限 | 10 人以上 | 1-5 人 |
| 任務複雜度 | 中高 | 低 | 高 | 低 |
| 預算 | 中（需工具） | 低 | 高（需專業工具） | 免費 |
| 學習成本 | 中 | 低 | 高 | 低 |
| 最適場景 | 跨部門協作專案 | 高層報告 | 工程/IT 複雜專案 | 小型專案/個人 |
制定專案時程的 5 個步驟
掌握了時程類型之後，接下來是實際動手制定。以下五個步驟是專案規劃階段的核心流程，每一步都有具體的操作方法。
步驟 1｜明確專案目標與範疇
時程安排的第一步不是打開工具，而是確認「我們到底要做什麼」。範疇不清楚，排出來的時程一定會被推翻。
範疇蔓延（Scope Creep）的風險： 專案進行中不斷加入新需求，是時程延誤的頭號殺手。一個原本預計 3 個月完成的網站改版專案，如果在開發中途加入「順便做一個會員系統」，時程可能直接多出 6 週。
具體做法：
- 用專案章程（Project Charter）明確定義目標、範疇與排除項目
- 與利害關係人確認「什麼不做」比「什麼要做」更重要
- 將確認後的範疇文件化，作為後續變更的基準線
步驟 2｜任務分解（WBS）
WBS 工作分解結構是把大目標拆成可執行的小任務。分解的原則是：最小任務單位建議控制在 8-80 小時之間。
- 小於 8 小時的任務太瑣碎，管理成本大於執行成本
- 大於 80 小時的任務太模糊，難以準確預估工期和追蹤進度
軟體開發範例：
- 第一層：網站改版專案
- 第二層：需求分析、設計、開發、測試、上線
- 第三層（開發）：前端開發、後端開發
- 第四層（前端開發）：首頁切版（16hr）、產品頁切版（24hr）、RWD 適配（16hr）、瀏覽器相容性測試（8hr）
這個結構從「需求分析 → 設計 → 開發 → 測試 → 上線」的五個階段逐層往下拆解，每一層都比上一層更具體、更可執行。
在 monday.com 中，你可以用「子項目」功能直接建立 WBS 的層級結構，每個子項目都能獨立設定負責人、工期和依賴關係，不需要另外畫 WBS 圖。
步驟 3｜確認任務依賴關係
任務之間的先後順序決定了時程的邏輯是否正確。依賴關係有四種類型，用白話來說：
| 依賴類型 | 英文縮寫 | 白話解釋 | 範例 |
|---|---|---|---|
| 完成-開始 | FS | A 做完才能開始 B | 設計稿完成 → 才能開始前端切版 |
| 開始-開始 | SS | A 開始後 B 才能開始 | 地基開挖開始 → 安全圍籬架設同步開始 |
| 完成-完成 | FF | A 完成時 B 也必須完成 | 所有模組測試完成 → 整合測試報告也必須完成 |
| 開始-完成 | SF | A 開始後 B 才能結束 | 新系統上線 → 舊系統才能關閉（最少見） |
實務中 90% 以上的依賴關係都是 FS（完成-開始），但 SS 在工程專案中也很常見。正確設定依賴關係後，工具會自動計算關鍵路徑。
步驟 4｜預估工期與設定緩衝
工期預估是時程安排中最容易出錯的環節。人類天生傾向低估任務所需時間（這叫「規劃謬誤」）。以下是三種實用的估算方法：
三點估算法（PERT 估算）：
公式：預估工期 = (O + 4M + P) ÷ 6
- O（Optimistic）= 最樂觀估計
- M（Most Likely）= 最可能估計
- P（Pessimistic）= 最悲觀估計
實際計算範例： 「API 串接」任務
- 最樂觀：3 天（一切順利，文件齊全）
- 最可能：5 天（正常開發速度）
- 最悲觀：12 天（遇到第三方 API 文件不全、需要反覆溝通）
- 預估工期 = (3 + 4×5 + 12) ÷ 6 = 5.8 天 ≈ 6 天
緩衝期設定建議：
- 一般任務：加 10% 緩衝（6 天任務 → 排 6.5-7 天）
- 高風險任務（新技術、外部依賴）：加 20-30% 緩衝
- 整體專案：在最後加一個「專案緩衝」，通常是關鍵路徑總工期的 10-15%
更多排程管理的進階技巧，可以參考我們的專題文章。
步驟 5｜繪製時程表與標示關鍵路徑
把前四個步驟的成果整合到一張時程表上。這一步的重點不只是「畫出來」，而是讓時程表成為團隊每天都會看的工具。
在甘特圖上標示關鍵路徑：
- 關鍵路徑上的任務通常以紅色或深色標示，與一般任務區分
- 在 monday.com 的甘特圖中，設定好依賴關係後，系統會自動計算並高亮關鍵路徑
- 非關鍵路徑的任務可以用較淺的顏色，讓團隊一眼就知道哪些任務「絕對不能延遲」
里程碑的設定位置：
- 每個主要階段的結束點設一個里程碑（如「需求確認完成」、「開發完成」、「UAT 通過」）
- 里程碑不是任務，它的工期為 0 天，代表的是「某個狀態的達成」
- 建議在時間軸上用菱形符號標示里程碑，與一般任務的橫條區分
4 個常見時程挑戰與解法（含時程壓縮技術）
時程延誤：趕工法 vs. 快速跟進法
當專案時程已經落後，你有兩種壓縮技術可以選擇：
趕工法（Crashing）：增加資源來縮短工期
做法是在關鍵路徑上的任務投入更多資源。例如原本 1 個工程師做 10 天的任務，改成 2 個工程師做 6 天。
- 優點： 不改變任務順序，風險較低
- 代價： 成本一定會增加（加班費、外包費、額外人力）
- 限制： 不是所有任務都能靠加人縮短（「9 個孕婦不能在 1 個月內生出小孩」）
快速跟進法（Fast Tracking）：將循序任務改為並行
做法是讓原本「A 做完才做 B」的任務變成「A 做到一半就開始 B」。例如設計稿還沒全部完成，前端就先開始切已完成的頁面。
- 優點： 不增加成本
- 代價： 返工機率上升（如果 A 的結果改變，B 可能要重做）
- 限制： 只適用於可以部分重疊的任務
判斷框架：
- 預算充足、不能接受品質風險 → 趕工法
- 時間極度緊迫、可接受一定返工風險 → 快速跟進法
- 兩者都不行 → 與利害關係人協商縮減範疇或延後交期
資源衝突：資源平衡與視覺化排查
當同一個設計師在同一週被排了 3 個專案的任務，就會出現資源衝突。
資源平衡（Resource Leveling） 的概念是：在不增加資源的前提下，調整非關鍵路徑上的任務時間，讓資源分配更均勻。代價是專案總工期可能會延長。
實務做法：
- 在工具的資源視圖（Resource View）中查看每個人的工作量分布
- 找出超載的時段，將非關鍵路徑上的任務往後移動
- 利用浮時（Float）來調整——浮時越大的任務，調整彈性越高
（推薦試試 monday.com 的工作負載視圖，它會用顏色標示每個成員的工作量是否超載，紅色代表過載、綠色代表有餘裕，不需要手動計算。）
需求頻繁變動：建立變更管理流程
需求變動不可怕，可怕的是「沒有流程地變動」。每次口頭說一句「順便加個功能」，時程就默默延後一天。
變更請求單的 5 個必要欄位：
- 提出人：誰提出這個變更？
- 變更描述：具體要改什麼？
- 影響評估：對時程、成本、資源的影響（由 PM 填寫）
- 決策結果：核准 / 拒絕 / 延後（由決策者簽核）
- 更新日期：時程基準線何時更新？
敏捷式時程如何降低衝擊： 如果你的專案需求本來就會頻繁變動（如產品開發），考慮用 Sprint 規劃取代傳統的瀑布式時程。每 2 週一個 Sprint，只規劃這 2 週要做的事，需求變動在下一個 Sprint 才納入。這樣時程的「被推翻範圍」最多就是 2 週，而不是整個專案。
團隊配合度不足：時程透明化與參與感設計
時程是 PM 自己關在會議室裡排出來的，還是團隊一起討論出來的？這個差異直接影響執行力。
讓團隊參與時程制定的具體做法：
- 規劃會議流程建議： PM 先準備 WBS 草稿 → 團隊成員各自預估自己負責任務的工期 → 共同討論依賴關係與風險 → PM 整合成正式時程
- 讓負責人自己估工期，比 PM 代估更準確，也更有承諾感
進度透明化的工具設定：
- 設定自動提醒：任務到期前 2 天通知負責人，延遲當天通知 PM
- 儀表板共享：讓所有人都能看到專案整體進度，不只是自己的任務
- 每日站會（15 分鐘）：每人回答三個問題——昨天做了什麼、今天要做什麼、有什麼阻礙
善用時間管理技巧搭配時程工具，能讓團隊的執行效率進一步提升。
專案時程管理工具推薦（含 NT$ 價格與功能比較）
選工具不是選最貴的或功能最多的，而是選最適合你團隊現況的。以下是五款常見工具的實際比較。
| 比較項目 | monday.com | ClickUp | Notion | Microsoft Project | Excel |
|---|---|---|---|---|---|
| 甘特圖支援 | ✅ 內建，拖拉操作 | ✅ 內建，支援依賴 | ⚠️ 需搭配第三方或時間軸視圖 | ✅ 完整 CPM 支援 | ⚠️ 需手動建置 |
| 資源視圖 | ✅ 工作負載視圖 | ✅ 工作量視圖 | ❌ 無內建 | ✅ 資源圖表 | ❌ 無 |
| 自動化提醒 | ✅ 自訂規則 | ✅ 自動化功能 | ⚠️ 基本提醒 | ⚠️ 有限 | ❌ 無 |
| 免費版限制 | 限 2 人 | 有限功能 | 免費版功能完整 | 無免費版 | 免費（M365 用戶） |
| 付費方案起價 | 約 NT$390/月/人 | 約 NT$230/月/人 | 約 NT$270/月/人 | 約 NT$900/月起 | 免費 |
| 最適團隊規模 | 5-200 人 | 3-50 人 | 1-10 人 | 10 人以上 | 1-5 人 |
| 學習曲線 | 低 | 中 | 低 | 高 | 低 |
4 種情境的選擇建議
情境 1：5 人以下小團隊，剛開始接觸專案管理
先用 Excel 時程表範本建立基本的任務追蹤，熟悉時程管理的邏輯。當任務量超過 30 個或需要多人協作時，升級到 ClickUp 免費版。
情境 2：小型團隊或個人，偏好簡潔介面
Notion 適合 1-10 人的小型團隊或個人使用者，介面簡潔、上手快，免費版功能就很完整。它的資料庫功能可以建立任務清單並搭配時間軸視圖，但甘特圖與依賴關係的支援不如專業 PM 工具完整，適合任務依賴較簡單的專案。
情境 3：10-50 人跨部門專案，需要視覺化與自動化
這是 monday.com 最擅長的場景。我們團隊實際使用的經驗是：PM 設定了一條自動化規則——任務延遲超過 2 天自動通知負責人和主管。這個設定在半年內觸發了超過 20 次，每次都讓問題在擴大前被處理。以前要到週會才發現的延遲，現在當天就能介入。免費方案不需要信用卡，可以先試用看看是否符合團隊需求。
情境 4：工程/IT 複雜專案，需要完整 CPM 分析
Microsoft Project 仍然是關鍵路徑法的標準工具，支援完整的資源平衡、浮時計算與多專案管理。但學習曲線較高，建議搭配培訓課程。
結論
回顧本文重點：
- 專案時程（Project Schedule） 是細化到每項任務的排程文件，與專案時間軸（Timeline）和進度表各有不同用途
- 4 種時程類型（甘特圖、里程碑圖、CPM、Excel 任務清單）各有適用場景，依團隊規模、任務複雜度與預算選擇
- 5 步驟制定流程：明確範疇 → WBS 分解 → 確認依賴 → 三點估算法預估工期 → 繪製時程表並標示關鍵路徑
- 時程壓縮有兩種技術：趕工法（加資源）和快速跟進法（任務並行），根據預算與風險承受度選擇
- 工具選對比功能多更重要：小團隊用 Excel 就夠，個人或小型團隊可選 Notion，跨部門協作選 monday.com，複雜工程用 Microsoft Project
善用專業工具與流程，將讓你的專案管理更有效率、更具彈性。
下一步行動： 想把這篇文章的方法論付諸實踐？第一步：在 monday.com 建立一個新看板，用甘特圖視圖把你手上的專案任務排進去，設定依賴關係和里程碑。10 分鐘就能建好你的第一份專案時程，比在 Excel 裡手動畫格子快得多。
專案時程 FAQ
專案時程和進度表有什麼不同？
專案時程（Project Schedule）是事先規劃的任務時間安排，包含開始日期、結束日期、依賴關係與關鍵路徑，屬於「計畫」。專案進度表則記錄實際執行狀況，對照時程檢視哪些任務落後或超前，屬於「追蹤」。兩者搭配使用才能有效管控專案。
Project timeline 中文怎麼說？
Project Timeline 中文最常翻譯為「專案時間軸」，偏向視覺化的時間範圍呈現，適合向高層報告。而 Project Schedule 翻譯為「專案時程」，是包含任務細節、依賴關係與資源分配的正式排程文件。在台灣職場中，兩者常被混用，但嚴格來說 Timeline 是 Schedule 的簡化版。
如何因應時程變更？
建立正式的變更管理流程：每次變更都必須填寫變更請求單（含提出人、變更描述、影響評估、決策結果、更新日期），經決策者核准後才能調整時程基準線。避免口頭承諾變更，否則時程會在不知不覺中失控。
有哪些常見的時程規劃錯誤？
五個最常見的錯誤：（1）低估工期，未使用三點估算法導致過度樂觀；（2）忽略任務依賴關係，排出邏輯矛盾的時程；（3）未預留緩衝期，任何意外都會導致延誤；（4）沒有識別關鍵路徑，不知道哪些任務絕對不能延遲；（5）時程制定後不更新，與實際執行脫節。
小團隊不用專業軟體，可以只用 Excel 管理時程嗎？
可以，5 人以下的小型專案用 Excel 專案時程表完全夠用。建立任務欄、日期欄，搭配條件格式做出簡易甘特圖即可。但當任務超過 30 個、需要自動計算依賴關係或多人即時協作時，建議升級到 monday.com 或 ClickUp 等專業工具，避免手動維護的錯誤與效率損耗。
如何提升團隊配合時程的意願？
讓團隊成員參與工期預估、共享進度儀表板、設定自動到期提醒，當時程是「大家一起訂的」而非「PM 單方面指派的」，執行承諾感會明顯提升。
