Kick-off meeting（專案啟動會議）是專案正式動工前的第一場正式會議，目的是讓所有關係人對五件事一次對齊：專案目標、工作範圍、誰負責什麼、時程節點，以及後續怎麼溝通。它不是進度會議，也不是腦力激盪，而是一次把「大家以為的共識」攤開來檢查有沒有真的一致。
這場會議開得好不好，通常不會當天顯現。它會在第三週才報到——有人以為某項工作在範圍內，另一個人以為不在；某個決定卡住兩天，因為沒有人確定自己有沒有拍板的權限。這些都是啟動會議沒做完的事，等到後面才補，成本高得多。
先說明立場：我經營 Subanana，一個把會議錄音轉成逐字稿與會議紀錄的服務。所以這篇的順序是先講會議本身怎麼開，最後才講工具——議程和產出的部分，你不用任何工具也套得上。
專案啟動會議到底要解決什麼問題？
專案初期最貴的成本不是執行，是「重做」。而重做幾乎都來自同一個源頭：專案開始的時候，每個人腦中的專案版本並不相同。
業務記得的是提案時答應客戶的範圍；工程記得的是技術評估時說「可以試試看」的那個版本；設計以為某個功能會在第二階段。三個版本都合理，但只要沒有一次攤開來對，它們就會各自往下走兩個星期，然後在整合的時候撞在一起。
啟動會議的價值就在這裡：它用一場會議的時間，換掉後面反覆的來回確認。所以會議的重點不是「介紹專案」，而是製造分歧、當場解決。一場所有人都點頭、沒有任何爭論的啟動會議，通常代表問題還沒被找出來，不代表大家有共識。
開會前要準備的四件事
沒準備的啟動會議會變成一場冗長的簡報。開會前請先備好：
- 一頁專案說明：目標、成功的定義、預計期間。一頁就好，會前寄出，不要在會議上第一次露面。
- 範圍初稿：包含「這次不做什麼」。這份初稿的用途是被挑戰，不是被宣讀。
- 關係人清單：誰要出席、誰只需要知道結果。出席者請控制在真的需要當場做決定的人。
- 已知的未定事項：把還沒答案的問題先列出來。會議上最有價值的時間，就是花在這張清單上。
會前把資料寄出，並明確寫上「請在會議前看完」。這一步能把會議從「說明會」變成「決策會」。
專案啟動會議議程範本（60 分鐘版）
適用於同一個組織內、關係人彼此熟悉的專案。
| 時間 | 議程項目 | 這一段要產出什麼 |
|---|---|---|
| 5 分鐘 | 開場與出席確認 | 確認決策者都在場 |
| 10 分鐘 | 專案背景與目標 | 一句話說得出「成功長什麼樣子」 |
| 15 分鐘 | 工作範圍與非範圍 | 白紙黑字的範圍邊界 |
| 10 分鐘 | 角色與決策權 | 每個工作區塊有一位負責人 |
| 10 分鐘 | 時程與里程碑 | 前兩個里程碑的日期 |
| 5 分鐘 | 風險與未定事項 | 每項風險有負責人與回頭確認的時間 |
| 5 分鐘 | 溝通方式與下一步 | 固定會議頻率、文件放哪裡 |
以上時間只是起點，請依專案規模調整。如果你要的是一般例行會議的議程結構，而不是啟動會議，會議議程範本那篇有三份可以直接複製的版本；跨部門或有外部客戶的專案，建議直接拉長成 90 分鐘版，在範圍與角色兩段各多給 10 分鐘，並增加一段「雙方各自的內部流程」。
啟動會議一定要留下的五項產出
會議結束時，如果這五樣東西沒有變成文字，這場會議就還沒開完。
- 範圍邊界：兩欄——這次做什麼、這次不做什麼。「不做什麼」那一欄的價值遠高於另一欄，因為它是後續擋需求變更時唯一站得住的依據。
- 決策權歸屬：每個工作區塊寫下一位負責人。這裡要問的問題不是「誰參與」，而是「意見不一致的時候，誰說了算」。
- 前兩個里程碑的日期：不用排完整個專案。把最近的兩個節點釘死，比排一份三個月後就失效的甘特圖有用。
- 風險清單：每一項配一位負責人和一個回頭確認的日期。沒有負責人的風險等於沒有記錄。
- 溝通約定：固定會議的頻率、文件放在哪裡、緊急狀況怎麼找人。
這五項應該以會議紀錄的形式在會後寄給所有出席者，包含沒能出席但需要知道結果的人。紀錄的重點是決議與待辦，不是把對話逐句抄下來——完整的格式可以參考會議紀錄範例與格式範本。
三個最常見的失敗模式
第一，把啟動會議開成簡報大會。 主辦方講了 40 分鐘，最後留 5 分鐘問「大家有問題嗎」，沒有人有問題。這種會議的資訊是單向的，沒有對齊任何東西。解法是把說明資料改成會前閱讀，會議時間留給範圍與角色的討論。
第二，找了太多人。 出席者一多，發言成本就變高，真正的疑慮會留到會後私下講。啟動會議請只找當場需要做決定的人，其他關係人用會議紀錄同步。
第三，沒有人記錄。 這是最常見也最貴的一種。會議上明明討論出了範圍邊界和負責人，但沒有落成文字，兩週後每個人記得的版本又不一樣了。指定一個人做紀錄，或者讓工具接手這件事。
怎麼把啟動會議變成一份查得到的紀錄？
啟動會議的資訊密度很高，而且大多是後面會被反覆引用的決定。要求某個與會者一邊參與討論一邊打字，通常會犧牲掉其中一件事。實務上比較合理的做法是讓會議自己留下紀錄：
- 讓錄音自動發生。 在 Google Meet 或 Microsoft Teams 上開會的話，Subanana 可以連接行事曆，依排定的會議自動加入並錄下整場討論。要注意的是，這個機器人是在會議結束之後才建立專案、進行轉檔與摘要，它不是即時字幕功能。用 Zoom 或實體會議的話，做法是把錄影或錄音檔上傳處理，結果一樣。
- 拿到標好發言者的逐字稿。 轉出來的逐字稿會區分不同發言者，並自動補上標點與分段，所以讀起來是段落，不是一整片沒有斷句的文字。啟動會議常常是多人交叉發言，發言者標示在事後追「這句是誰說的」時特別有用。
- 用摘要範本產生會議紀錄。 摘要會整理出重點討論、決策事項與待辦項目。如果你把上一節那五項產出當成固定的紀錄結構，這一步就是直接產出你要的文件，而不是再一份需要重寫的草稿。
- 有疑問直接問這場會議。 編輯器裡可以直接向 AI 追問這場會議的內容，例如「範圍裡最後決定不做哪些項目」「誰認領了第一個里程碑」，答案會回到這份逐字稿本身。
- 匯出成要交出去的格式。 付費方案可以把結果匯出成 DOCX、XLSX、TXT 或 Markdown，再依你們既有的文件流程歸檔。
跨國團隊的啟動會議還有一層語言問題。Subanana 支援 95 種以上語言，逐字稿與摘要可以再翻成團隊需要的另一種語言。缺席的關係人，以及習慣另一種工作語言的成員，因此也讀得懂這份紀錄。想看完整的操作流程，如何用 AI 自動生成會議記錄那篇寫得比較細。
常見問題
Kick-off meeting 中文怎麼說？
一般譯為「專案啟動會議」，有些組織也稱作「開案會議」或「啟動會議」。指的都是同一件事：專案正式進入執行前，讓關係人對目標、範圍、角色與時程取得共識的第一場正式會議。
專案啟動會議應該開多久？
同一組織內的中小型專案，60 分鐘通常夠用。跨部門、有外部客戶，或範圍還有較多未定事項的專案，建議拉到 90 分鐘，多出來的時間放在範圍界定與決策權歸屬這兩段。超過兩小時的啟動會議，多半是把應該會前完成的閱讀搬到了會議上。
啟動會議上該說什麼？
依序講四件事：這個專案要達成什麼、這次做與不做的範圍、每個區塊誰負責與誰拍板、最近兩個里程碑的時間。剩下的時間全部留給未定事項。避免把時間花在逐頁報告簡報內容，那些資料應該在會前就寄出。
誰應該出席專案啟動會議？
當場需要做決定的人一定要在，包括各工作區塊的負責人與能夠拍板範圍的角色。只需要知道結果的關係人不必出席，用會議紀錄同步即可。出席人數愈多，真正的疑慮愈容易被留到會後才講出來。
專案啟動會議要留下什麼文件？
至少五樣：範圍邊界（含不做的項目）、各區塊決策負責人、前兩個里程碑日期、附負責人的風險清單，以及溝通約定。這五項應在會後儘快以會議紀錄的形式寄給所有關係人，趁記憶還清楚的時候確認無誤。
小結
專案啟動會議的價值不在於把專案介紹得多完整，而在於它能不能在專案開始前，把大家理解不一致的地方逼出來解決。議程只是工具，真正的判準是散會時那五項產出有沒有變成文字，以及所有人看到的是不是同一份。
會議怎麼開，你已經有範本了。紀錄那一段如果不想再指派一個人邊聽邊打字，可以看看會議記錄怎麼寫裡的結構，或直接讓 Google Meet 會議記錄與 Teams 會議記錄的自動流程接手。方案與額度可以在方案費用頁面查到。