適用範圍
適用 Odoo 19；各流程須具備相應應用、訂閱、權限及郵件設定。例子均為虛構，介面翻譯可能不同。
研究方法
僅核對 Odoo 19 官方文件；本輪沒有新增 Odoo 產品實測。來源核對僅涵蓋下列 scope。
先選一個交付里程碑，定義客戶需要接受甚麼成果。工作涉及共同負責及可追溯交接時，Odoo Project 才有清楚用途；新增看板不能補救未定義的範圍。本文依據 Odoo 19 官方文件分析工作方式，沒有在測試資料庫實際完成專案。
目錄
選擇最小可用流程
以虛構的辦公室網站專案為例，階段可設為待開始、進行中及客戶審閱。在團隊手冊寫明進入條件：「待開始」代表素材及範圍已齊備；「客戶審閱」代表已提供可閱讀頁面及驗收問題。這些是建議業務規則，不是 Odoo 內建階段定義。
| 任務 | 最終負責人 | 所需證據 | 目標日期 |
|---|---|---|---|
| 確認頁面文案 | 客戶經理 | 客戶已接受的文字 | 2026-11-02 |
| 製作聯絡頁面 | 開發人員 | 可審閱頁面及欄位表 | 2026-11-05 |
| 驗收聯絡流程 | 專案負責人 | 已記錄的驗收決定 | 2026-11-06 |
Odoo 允許多位受指派人。即使多人參與，本例仍建議在描述中指定一位最終負責人，避免共享指派後沒有人決定是否可以交接。
分清階段與完成狀態
開啟 Project，選取專案，以加號建立任務，輸入標題及受指派人，再開啟任務補上期限及成果證據。官方文件將 Customer 與 Sales Order Item 列為可收費工作相關的條件欄位，不是每個專案都會顯示。
看板階段表示工作位置；任務狀態表示該位置內的處理情況。Odoo 19 文件指出 Done 與 Canceled 是獨立於階段的結案狀態。因此，把卡片移到名為「完成」的欄位，不能單獨成為團隊的結案準則。
描述應可以核對，例如：「聯絡表格收集姓名、電郵及查詢；專案負責人記錄是否符合已議定要求。」不要只寫「完成網站」，將多個決定藏在一張卡片。移動階段可能將 Approved 或 Changes Requested 重設為 In Progress，因此交接時要再看狀態，不要將先前批准視為永久有效。
只為真正阻礙設定依賴
只有前項成果未完成便不能進行後項工作時，才有必要建立依賴。本例中，未有確認文案便不能驗收製作成果，但草擬檢查清單可以獨立進行。
如有此需要，在專案 Settings 的 Tasks Management 啟用 Task Dependencies。在後續任務的 Blocked by → Add a line 選取前置任務。官方依賴流程可令後續任務處於 Waiting，直至前項達到文件列明的批准或結束條件。不要為了隱藏延期而移除依賴，應記錄誰可提供欠缺成果。
若系統顯示不能開始，但業務認為可以，先檢查每項前置任務的狀態及連結方向。過長的依賴鏈可能代表任務拆分不足，不一定需要更複雜的排程。
判斷甘特圖工時表與自動化是否值得加入
| 需要 | 起步選擇 | 額外確認條件 |
|---|---|---|
| 查看負責人及下一個交接 | 看板／清單及期限 | 所需專案權限 |
| 比較重疊的預定工作 | 評估現有版本的甘特圖 | 視圖可用性及方案授權 |
| 了解實際投入或按工時收費 | 獨立評估 Timesheets | 應用、專案設定及開票政策 |
| 按階段變更建立動作 | 先寫出規則才啟用 | Studio 自動化可能影響方案 |
分配工時是預算，工時表是實際記錄；兩者都不能證明客戶已驗收或該工作可以收費。四小時預算用了六小時，首先需要釐清範圍或估算原因，再決定開票。
本文不承諾免費方案，也不將甘特圖視為所有版本均有的權利。官方階段文件明確指出 Automations 會啟用 Studio，可能影響價格。採用進階視圖或規則之前，先核對實際訂閱及已安裝應用。
檢討延期時保留真正原因
每次檢討選最近的里程碑，核對負責人、期限、前置任務及驗收證據。若延期源於文案未獲批准，只改期限會掩蓋現象，依賴仍未解除。應記錄欠缺決定及可作決定的人。
讓整個團隊開始使用前，確認一個具名里程碑、一組有最終負責人的任務、完成定義、可見範圍，以及是否另需工時或收費功能。APAA 可協助將已選流程整理為設定範圍；提供里程碑及一項虛構任務例子，比提交功能清單更容易判斷工作內容。
參考來源
- Task creation
任務標題、受指派人、期限及可收費專案欄位
來源查核日期
- Task stages and statuses
自訂階段、結案狀態與 Studio 自動化條件
來源查核日期
- Task dependencies
專案設定、Blocked by 及前置任務行為
來源查核日期