---
name: team-charter
description: 起草團隊章程：使命、團隊服務的對象、負責和明確不負責的範圍、角色、工作約定、例行會議和溝通管道、如何做決定和往上反映，以及評估團隊的指標。適用於主管或創辦人要成立新團隊、拆分或合併團隊、迎接新的負責人、解決「這到底歸誰？」的混亂，或要團隊章程、團隊使命、工作約定的時候。
---

# 團隊章程

章程回答新成員和相鄰團隊在第一週會問的問題：這個團隊是做什麼的、負責什麼、怎麼運作、怎麼做決定。聖母大學（Notre Dame）Mendoza 商學院的範本列出四個關鍵要素（目的、決策流程、角色和職責、工作約定）；這個技能再加上範圍邊界和指標，因為新創團隊最浪費時間的地方，就是「這歸誰？」。

## 適用情境

- 新團隊成立、兩個團隊合併或拆分，或新主管接手。
- 需求一直送錯團隊，或兩個團隊都認為某件事歸自己。
- 團隊想在增加人手前，先把運作方式寫下來。
- 不適用於單一專案的計畫（請用 project-kickoff-brief），也不適用於交辦給一個人的任務（請用 delegation-brief）。

## 需要準備

- 團隊名稱、成員和主管。
- 團隊被期待達成什麼，以及為了誰。
- 團隊目前在做什麼，以及其他團隊對它有什麼期待。
- 目前的運作方式：會議、溝通管道、工具。不清楚的話就提出預設做法，並標上「[提案]」。

## 步驟

1. **用一句話寫出使命。** 服務誰，以及對他們來說什麼會改變：「讓新客戶在註冊後一天內做出第一份報表。」不寫沒有成果的價值觀字眼。
2. **寫出服務對象。** 內部和外部都要寫，依優先順序排列。兩個對象有衝突時，順序決定誰優先。
3. **畫出邊界。** 列出團隊負責的東西（系統、流程、決定），以及不負責的東西和實際負責的團隊。每一項「不歸我們」都要寫出負責人，或標為「負責人不明」。
4. **設定角色。** 為例行角色指定具體的人（負責人、值班、會議主持人、回覆其他團隊需求的人）。寫可量測的職責，不是職稱：「1 個工作天內回覆 #team-requests」。
5. **寫出工作約定。** 5 到 8 條具體的規範：工作時間和時區、各管道的回覆時間、怎麼給回饋、不開會的時段、怎麼提出衝突。每一條都是成員可能違反的事，這樣才能檢查。
6. **設定例行會議和溝通管道。** 每個會議寫出目的、頻率、長度和參加者；沒有目的的會議就取消。每個管道寫出放什麼內容。寫明什麼時候用非同步溝通比開會好。
7. **定義怎麼做決定。** 依決定的類型訂預設方式（一個人徵詢意見後決定、團隊投票、少數每個人都必須支持的決定才用共識），誰有最終決定權，以及無法達成共識時的備案。加上往上反映的路徑。
8. **選 2 到 4 個指標。** 評估團隊的依據，已知的話寫出目前數值和目標。加上章程的檢討時間；這個技能的預設是每季一次，以及每當有人加入或離開時。

## 輸出格式

```markdown
# [團隊名稱] 章程
**成員：** [姓名、角色] · **主管：** [姓名] · **最近檢討：** [日期]

## 使命
[一句話：我們服務誰，以及對他們來說什麼會改變]

## 服務對象（依優先順序）
1. [對象]：[他們需要我們提供什麼]

## 我們負責的
- [系統／流程／決定]

## 我們不負責的
| 領域 | 負責人 |
|---|---|
| [領域] | [團隊，或「負責人不明」] |

## 角色
| 角色 | 人員 | 職責（可量測） |
|---|---|---|

## 工作約定
1. [具體、可檢查的規範]

## 例行會議和溝通管道
| 會議／管道 | 目的 | 頻率／用途 | 參與者 |
|---|---|---|---|

## 我們怎麼做決定
- [決定類型] → [方式]，最終決定權：[人員]
- 無法達成共識時：[備案]
- 往上反映給：[人員]，當 [條件]

## 指標
| 指標 | 目前 | 目標 |
|---|---|---|

## 檢討
下次檢討：[日期] · 有人加入或離開時也要檢討。
```

## 範例

**輸入：** 「新的生命週期行銷團隊：吳敏華（負責人）、張立凱（email 行銷）、林思穎（數據分析師）。任務：讓試用轉成付費。目前他們負責寄新手引導信和培育活動信。產品團隊負責產品內的新手引導。業務有時會請他們臨時發一次性的群發信。遠端工作，成員在台灣和歐洲。試用轉付費率是 11%。」

**輸出：**

```markdown
# 生命週期行銷團隊章程
**成員：** 吳敏華（負責人）、張立凱（email 行銷）、林思穎（數據分析師） · **主管：** 吳敏華 · **最近檢討：** 11月4日

## 使命
透過使用者在產品以外收到的訊息，讓更多試用註冊者成為付費客戶。

## 服務對象（依優先順序）
1. 試用使用者：在對的步驟收到對的訊息
2. 業務：值得跟進、已篩選過的試用名單
3. 產品：試用使用者在哪裡流失的資料

## 我們負責的
- 新手引導和培育的 email 序列
- 試用階段的分群和報告
- 對試用使用者寄信頻率的決定

## 我們不負責的
| 領域 | 負責人 |
|---|---|
| 產品內的新手引導 | 產品 |
| 業務臨時的一次性群發信 | 業務（我們只提供寄送時間的建議） |
| 購買後的客戶電子報 | 負責人不明 |

## 角色
| 角色 | 人員 | 職責（可量測） |
|---|---|---|
| 負責人 | 吳敏華 | 訂優先順序；寄給所有試用使用者的信由她最終決定 |
| 需求窗口 | 張立凱 | 1 個工作天內回覆 #lifecycle-requests [提案] |
| 報告 | 林思穎 | 每週一 12:00（台灣時間）前交出試用漏斗週報 [提案] |

## 工作約定
1. 核心重疊時段：台灣時間 16:00–18:00（歐洲中部時間 9:00–11:00）；只在這個時段開會。[提案]
2. Slack 在 4 個工作小時內回覆；email 在 1 個工作天內回覆。[提案]
3. 寄給超過 1,000 人的信，都要再請一個人檢查。[提案]
4. 意見不合就開 15 分鐘的通話，不要在討論串裡吵很久。[提案]
5. 回饋先私下給，在事情發生後一週內給。[提案]

## 例行會議和溝通管道
| 會議／管道 | 目的 | 頻率／用途 | 參與者 |
|---|---|---|---|
| 規劃會議 | 選出這週要做的實驗 | 週一，30 分鐘 [提案] | 全員 |
| 漏斗檢討 | 看數字、決定要改什麼 | 週四，30 分鐘 [提案] | 全員 |
| #lifecycle-requests | 其他團隊的需求 | 非同步 [提案] | 張立凱分派 |

## 我們怎麼做決定
- 文案和寄送時間 → 張立凱徵詢團隊意見後決定 [提案]
- 修改寄給所有試用使用者的序列 → 吳敏華參考林思穎的資料後決定 [提案]
- 無法達成共識時：吳敏華在 2 個工作天內決定 [提案]
- 往上反映給：成長部門主管 [提案]，當其他團隊對歸屬有爭議時

## 指標
| 指標 | 目前 | 目標 |
|---|---|---|
| 試用轉付費率 | 11% | [提案：第一季結束前達到 14%] |
| 試用期 email 的取消訂閱率 | [待確認：基準] | [提案：每次寄送低於 0.5%] |

## 檢討
下次檢討：2月4日 · 有人加入或離開時也要檢討。
```

## 寄出前檢查

- [ ] 使命只有一句，而且寫出了服務的對象。
- [ ] 每一項「不負責」都寫出負責人，或寫「負責人不明」。
- [ ] 每一條工作約定都具體到違反時看得出來。
- [ ] 決策方式寫出了誰有最終決定權，以及沒有共識時的備案。
- [ ] 指標都有目前數值，或標明待量測；沒有提供的目標都標「[提案]」。

## 常見錯誤

- 用價值觀組成使命（「卓越、當責」）。要寫出服務誰、什麼會改變。
- 只列團隊負責的東西。「不負責」的清單才能避免大部分的摩擦。
- 每個決定都用共識。共識留給少數每個人都必須支持的決定。