官方技能 · 營運與行政

專案啟動簡報

v1.0.0 · 2026 年 11 月 4 日 更新

寫出一頁的專案啟動簡報：目標、一個成功指標、範圍內外、里程碑、簡化版 RACI 表、各有負責人的主要風險，以及溝通方式。

可在 Claude、ChatGPT 和程式設計代理中使用。使用 Team 和 Business 方案時，我們改進官方技能後，你 Pod 裡的這個技能會自動更新。

適用情境

• 專案、上線或客戶合作要開始，需要一頁共用的說明
• 進行中的專案，大家對範圍或由誰決定有不同意見

你要提供的內容

• 目標和為什麼現在重要
• 目標日期
• 參與的人和角色
• 已知的限制和決定（選填）

你會得到的內容

一頁的 Markdown 簡報，包含目標、成功指標、範圍表、里程碑、簡化版 RACI 角色、風險和溝通計畫。

運作方式

1. 用 1 到 2 句寫出目標 說明什麼會不一樣，以及為什麼現在重要。Asana 的啟動指南認為，對「我們要達成什麼、這項工作為什麼重要」取得共識，是啟動會議最重要的部分。
2. 選一個成功指標 一個數字加一個日期（「6月30日前有 40 位客戶轉到新方案」），或任何人都能檢查的是／否測試。Atlassian 的啟動做法把這些測試稱為「對『完成』的共同定義」。這個技能的預設：一個主要指標，最多 2 個護欄指標（不能變差的事）。
3. 把範圍分成範圍內和範圍外 列出 3 到 6 項範圍內，以及至少 3 項範圍外。範圍外的項目，就是做到一半會有人提出來的那些；及早寫明，才能防止範圍蔓延。不清楚的項目放進待釐清的問題，不要放進範圍內。
4. 設定 3 到 6 個里程碑 每一個都是完成、可檢查的東西，附日期和負責人（「定價頁在測試環境上線」），而不是一項活動（「處理定價」）。最後一個里程碑就是成功指標的日期。
5. 填好簡化版 RACI 表 每個工作流一列。R（執行者）做事；A（最終負責人）簽核並對結果負責；C（諮詢者）在進入下一步前審閱；I（知會者）會收到進度通知。Asana 的 RACI 指南：「每項任務只應該有一個 A。」這個技能的預設：整個專案也只有一位 A，寫在最上方。
6. 列出前 3 到 5 大風險 每一項寫出：可能出什麼錯、可能性多高（高／中／低）、現在要做什麼，以及一位負責人。快速找出風險的方法是 Atlassian 的事前驗屍（pre-mortem）：團隊各自安靜寫下可能出錯的事，再投票選出最大的威脅，為每個主要風險指定一項行動和負責人。沒有負責人的風險只是擔心，不是計畫。
7. 寫出團隊的溝通方式 日常討論在哪裡（頻道）、進度怎麼分享（每週的書面更新、哪一天、誰寫）、小組什麼時候開會，以及決定記錄在哪裡。Asana 的啟動指南把這列為啟動會議的標準內容。
8. 列出待釐清的問題和已決定的事 待釐清的問題要有負責人和日期。已經決定的事每項寫一行，避免啟動會議又重新討論。

SKILL.md 檔案

完整檔案，就是你的 AI 讀到的內容。 下載檔案

---
name: project-kickoff-brief
description: 從目標和粗略的筆記寫出一頁的專案啟動簡報：目標和它的重要性、一個成功指標、範圍內和範圍外、附日期的里程碑、只有一位最終負責人的簡化版 RACI 角色表、各自有負責人的主要風險，以及團隊的溝通方式。適用於專案要開始、有人要啟動文件、專案章程或專案簡報，或團隊需要在動工前談定誰做什麼的時候。
---

# 專案啟動簡報

啟動簡報讓所有人在動工前，對專案為什麼存在、「完成」長什麼樣子、誰負責什麼取得共識。它一頁就寫得完。不會改變大家這個月做什麼的內容，放到連結的文件裡。

## 適用情境

- 新的專案、上線、系統搬遷或客戶合作要開始，大家需要一頁共用的說明。
- 有人要「啟動文件」「專案章程」「專案一頁簡報」或「啟動會議的事前閱讀資料」。
- 專案已經在跑，但大家對範圍或由誰決定有不同意見。寫這份簡報來重新對齊。
- 不適用於產品規格或需求文件。產品要做什麼請用 PRD；這份簡報講的是專案怎麼運作。

## 需要準備

- 目標，以及為什麼現在重要。缺的話問一次：「做完之後，對公司或客戶來說有什麼改變？」
- 截止日或目標日期。沒有的話寫「[尚未訂日期]」，並列為第一個待釐清的問題。
- 參與的人和他們的角色。角色不清楚的話，列出名字，並把 RACI 表標成「[草稿，啟動會議時確認]」。
- 選填：預算、已知的限制、相關專案，以及已經決定的事。

## 步驟

1. **用 1 到 2 句寫出目標。** 說明什麼會不一樣，以及為什麼現在重要。Asana 的啟動指南認為，對「我們要達成什麼、這項工作為什麼重要」取得共識，是啟動會議最重要的部分。
2. **選一個成功指標。** 一個數字加一個日期（「6月30日前有 40 位客戶轉到新方案」），或任何人都能檢查的是／否測試。Atlassian 的啟動做法把這些測試稱為「對『完成』的共同定義」。這個技能的預設：一個主要指標，最多 2 個護欄指標（不能變差的事）。
3. **把範圍分成範圍內和範圍外。** 列出 3 到 6 項範圍內，以及至少 3 項範圍外。範圍外的項目，就是做到一半會有人提出來的那些；及早寫明，才能防止範圍蔓延。不清楚的項目放進待釐清的問題，不要放進範圍內。
4. **設定 3 到 6 個里程碑。** 每一個都是完成、可檢查的東西，附日期和負責人（「定價頁在測試環境上線」），而不是一項活動（「處理定價」）。最後一個里程碑就是成功指標的日期。
5. **填好簡化版 RACI 表。** 每個工作流一列。R（執行者）做事；A（最終負責人）簽核並對結果負責；C（諮詢者）在進入下一步前審閱；I（知會者）會收到進度通知。Asana 的 RACI 指南：「每項任務只應該有一個 A。」這個技能的預設：整個專案也只有一位 A，寫在最上方。
6. **列出前 3 到 5 大風險。** 每一項寫出：可能出什麼錯、可能性多高（高／中／低）、現在要做什麼，以及一位負責人。快速找出風險的方法是 Atlassian 的事前驗屍（pre-mortem）：團隊各自安靜寫下可能出錯的事，再投票選出最大的威脅，為每個主要風險指定一項行動和負責人。沒有負責人的風險只是擔心，不是計畫。
7. **寫出團隊的溝通方式。** 日常討論在哪裡（頻道）、進度怎麼分享（每週的書面更新、哪一天、誰寫）、小組什麼時候開會，以及決定記錄在哪裡。Asana 的啟動指南把這列為啟動會議的標準內容。
8. **列出待釐清的問題和已決定的事。** 待釐清的問題要有負責人和日期。已經決定的事每項寫一行，避免啟動會議又重新討論。

## 輸出格式

```markdown
# [專案名稱]：啟動簡報

**最終負責人：** [一個名字] · **開始：** [日期] · **目標日期：** [日期，或「尚未訂日期」]

## 目標
[1–2 句：什麼會改變、對誰、為什麼是現在。]

## 成功指標
- **主要：** [數字 + 日期，或是／否測試]
- **護欄：** [不能變差的事，沒有就刪除]

## 範圍
| 範圍內 | 範圍外 |
|---|---|
| [項目] | [項目] |

## 里程碑
| 里程碑（完成的東西） | 負責人 | 日期 |
|---|---|---|
| [里程碑] | [姓名] | [日期] |

## 角色（簡化版 RACI）
| 工作流 | R 執行 | A 最終負責 | C 諮詢 | I 知會 |
|---|---|---|---|---|
| [工作流] | [姓名] | [一個名字] | [姓名] | [姓名或群組] |

## 風險
| 風險 | 可能性 | 現在要做什麼 | 負責人 |
|---|---|---|---|
| [風險] | [高／中／低] | [行動] | [姓名] |

## 溝通方式
- **日常：** [頻道]
- **進度：** [書面更新、哪一天、誰寫]
- **會議：** [哪些會議、多久一次]
- **決定記錄在：** [地方]

## 已決定的事
- [決定，一行]

## 待釐清的問題
- [問題]：[負責人]，[日期] 前
```

## 範例

**輸入：** 「我們要把 120 位活躍客戶從舊的帳單工具（帳易通）搬到 Stripe。4月7日啟動；帳易通在 6月30日解約。黃美玲主導，劉家豪做串接，蔡宜蓁負責客戶通知信，財務（鄭雅文）要在 5月2日前簽核新的發票範本。執行長許志明希望在 7月1日調價前完成。家豪的計畫：4月25日前讓 5 個內部測試帳號在 Stripe 測試模式中正確扣款，6月13日前所有客戶上線。宜蓁在 5月16日前寄出通知，之後在每位客戶搬遷前 1 週寄提醒，並打電話給前 20 大客戶。不做：已解約客戶的歷史資料、自助帳單入口、會計系統的修改。擔心的事：已儲存的信用卡可能轉不過去；切換當月有人被重複扣款。付款失敗不能增加。我們在 #billing-migration 討論，美玲每週五寫更新，週二開 20 分鐘的會，決定寫在專案文件裡。已經決定搬遷期間不調價。雅文想知道解約後是否保留帳易通唯讀一個月。」

**輸出：**

```markdown
# 帳單系統搬遷到 Stripe：啟動簡報

**最終負責人：** 黃美玲 · **開始：** 4月7日 · **目標日期：** 6月30日

## 目標
在 7月1日調價前，把所有客戶從帳易通搬到 Stripe，讓新價格在單一系統上生效，並能解約帳易通。

## 成功指標
- **主要：** 6月30日前，120 位活躍客戶中的 120 位都透過 Stripe 扣款。
- **護欄：** 任何月份都沒有客戶被重複扣款或漏扣；付款失敗維持在目前的每月水準或更低。

## 範圍
| 範圍內 | 範圍外 |
|---|---|
| 搬移活躍中的訂閱和已儲存的信用卡 | 調價（已決定：搬遷期間不調價） |
| 經財務核准的新發票範本 | 搬移已解約客戶的歷史資料 |
| 搬遷前後寄給客戶的通知信 | 新的自助帳單入口 |
| 解約帳易通 | 會計系統的修改 |

## 里程碑
| 里程碑（完成的東西） | 負責人 | 日期 |
|---|---|---|
| Stripe 測試模式正確扣款 5 個內部帳號 | 劉家豪 | 4月25日 |
| 發票範本簽核完成 | 鄭雅文 | 5月2日 |
| 寄出客戶通知信 | 蔡宜蓁 | 5月16日 |
| 120 位客戶全部在 Stripe 上線 | 劉家豪 | 6月13日 |
| 帳易通解約 | 黃美玲 | 6月30日 |

## 角色（簡化版 RACI）
| 工作流 | R 執行 | A 最終負責 | C 諮詢 | I 知會 |
|---|---|---|---|---|
| 串接和資料搬移 | 劉家豪 | 黃美玲 | 鄭雅文 | 許志明 |
| 發票 | 劉家豪 | 鄭雅文 | 黃美玲 | 蔡宜蓁 |
| 客戶通知信 | 蔡宜蓁 | 黃美玲 | 鄭雅文 | 許志明 |

## 風險
| 風險 | 可能性 | 現在要做什麼 | 負責人 |
|---|---|---|---|
| 已儲存的信用卡轉不過去，客戶必須重新輸入 | 中 | 這週詢問帳易通客服是否支援把卡片資料匯出到 Stripe | 劉家豪 |
| 切換當月有客戶在兩個系統都被扣款 | 中 | 每位客戶在 Stripe 開始扣款的當天，就關閉他在帳易通的訂閱；每天核對清單 | 劉家豪 |
| 客戶忽略通知，沒注意到變更 | 高 | 5月16日前寄出通知，每次搬遷前 1 週寄提醒；宜蓁打電話給前 20 大客戶 | 蔡宜蓁 |

## 溝通方式
- **日常：** #billing-migration
- **進度：** 每週五由黃美玲寫書面更新
- **會議：** 每週二 20 分鐘的進度確認
- **決定記錄在：** 專案文件的「決定事項」段落

## 已決定的事
- 搬遷期間不調價。

## 待釐清的問題
- 解約後是否保留帳易通唯讀一個月？鄭雅文，[啟動會議時訂日期] 前
```

## 寄出前檢查

- [ ] 目標寫了為什麼是現在，成功指標是附日期的數字或是／否測試。
- [ ] 範圍外至少有 3 項有人可能會提出來的項目。
- [ ] 每個里程碑都是完成的東西，有一位負責人和日期。
- [ ] 每一列 RACI 剛好一位 A，而且專案最上方寫了一位負責人。
- [ ] 每個風險都有現在就採取的行動和一位負責人。
- [ ] 沒有出現輸入中沒有的名字、日期或數字；缺的部分標「[尚未訂日期]」或列為待釐清的問題。
- [ ] 一頁寫得完。

## 常見錯誤

- 寫一個沒人能檢查的成功指標（「改善帳單」）。問清楚什麼數字或測試能證明它。
- 範圍外留白。第 4 週的爭論就從那裡開始。
- 同一列有兩位 A。如果兩個人都必須同意，讓一位當 A，另一位當 C。

分享給你的團隊

把它加入 AI Skill Pod，團隊每個人（外包人員也包括在內）都能從自己的 AI 使用同一個版本。 看看和團隊分享 AI 技能的最佳做法

加入我團隊的 Pod

更新紀錄

• v1.0.0 · 2026 年 11 月 4 日 · First release.