---
name: team-charter
description: 起草一份团队章程：使命、团队服务的对象、负责什么和明确不负责什么、角色、工作约定、例会和沟通渠道、怎么做决定和向上升级，以及考核团队的指标。适用于经理或创始人组建新团队、拆分或合并团队、迎来新的团队负责人、要解决“这件事归谁管？”的混乱，或者要一份团队章程、团队使命或工作约定时。
---

# 团队章程

章程回答新成员和相邻团队在第一周会问的问题：这个团队是干什么的、负责什么、怎么工作、怎么做决定。圣母大学门多萨商学院（Notre Dame Mendoza College of Business）的模板列出了四个关键部分（目的、决策流程、角色与职责、工作约定）；这个技能另外加上范围边界和指标，因为“这件事归谁管？”是创业团队最浪费时间的地方。

## 适用场景

- 新团队成立、两个团队合并或拆分，或者新经理接手。
- 需求总是落到错误的团队，或者两个团队都认为某件事归自己管。
- 团队想在扩充人手之前，把工作方式写下来。
- 不适用于单个项目的计划（用 project-kickoff-brief），也不适用于交给某一个人的任务（用 delegation-brief）。

## 需要准备

- 团队名称、成员和经理。
- 团队应该为谁实现什么目标。
- 团队目前在做什么，以及其他团队对它有什么期待。
- 团队现在怎么工作：会议、沟通渠道、工具。不清楚的话，提出默认方案并标注“[建议]”。

## 步骤

1. **用一句话写使命。** 服务谁、为他们带来什么改变：“让新客户在注册后一天内做出第一份报表。”不写没有结果的价值观词汇。
2. **写明服务对象。** 内部和外部的都写，按优先级排序。如果两个服务对象的需求冲突，按这个顺序决定谁优先。
3. **划清边界。** 列出团队负责的内容（系统、流程、决定）和不负责的内容，并写明不负责的内容归哪个团队。每一项“不归我们”都要写明负责方，或者标注“负责方不明”。
4. **设定角色。** 为固定角色指定具体的人（负责人、值班、主持人、谁回复其他团队的需求）。写可衡量的职责，不写头衔：“1 个工作日内回复 #team-requests”。
5. **写工作约定。** 5 到 8 条具体的规范：工作时间和时区、各渠道的回复时限、怎么给反馈、无会议时段、怎么提出冲突。每一条都是成员可能违反的，这样才能检查。
6. **定好例会和沟通渠道。** 每个会议写明目的、频率、时长和参会人；没有目的的会议就取消。每个渠道写明放什么内容。写明什么情况下异步沟通比开会更好。
7. **定义决策方式。** 按决定的类型写明默认方式（一人征求意见后决定、团队投票、只有少数必须人人支持的决定才求共识），谁拍板，以及达不成共识时怎么办。再写上升级路径。
8. **选 2 到 4 个指标。** 团队按什么来考核，已知的话写上当前值和目标值。再写明什么时候复审章程；这个技能的默认做法是每季度一次，以及每当有人加入或离开时。

## 输出格式

```markdown
# [团队名称] 章程
**成员：** [姓名、角色] · **经理：** [姓名] · **最近复审：** [日期]

## 使命
[一句话：我们服务谁，为他们带来什么改变]

## 服务对象（按优先级排序）
1. [服务对象] — [他们需要我们提供什么]

## 我们负责的
- [系统 / 流程 / 决定]

## 我们不负责的
| 领域 | 负责方 |
|---|---|
| [领域] | [团队或“负责方不明”] |

## 角色
| 角色 | 人员 | 职责（可衡量） |
|---|---|---|

## 工作约定
1. [具体、可检查的规范]

## 例会和渠道
| 会议 / 渠道 | 目的 | 频率 / 用途 | 参与人 |
|---|---|---|---|

## 我们怎么做决定
- [决定类型] → [方式]，拍板人：[姓名]
- 如果意见不一致：[兜底办法]
- 升级给：[姓名]，当 [条件] 时

## 指标
| 指标 | 当前 | 目标 |
|---|---|---|

## 复审
下次复审：[日期] · 有人加入或离开时也要复审。
```

## 示例

**输入：** “新成立用户生命周期团队：林敏（负责人）、钱磊（邮件营销）、宋菲（数据分析）。任务：提高试用转付费。目前他们负责发新手引导邮件和培育类邮件。产品内的新手引导归产品团队。销售有时会找他们群发一次性的邮件。远程办公，成员在上海和柏林。试用转付费率是 11%。”

**输出：**

```markdown
# 用户生命周期团队章程
**成员：** 林敏（负责人）、钱磊（邮件营销）、宋菲（数据分析） · **经理：** 林敏 · **最近复审：** 11月4日

## 使命
通过用户在产品之外收到的消息，把更多试用注册用户转化为付费客户。

## 服务对象（按优先级排序）
1. 试用用户 — 在合适的阶段收到合适的消息
2. 销售 — 拿到有意向、合格的试用用户去跟进
3. 产品 — 试用用户在哪里流失的数据

## 我们负责的
- 新手引导和培育类邮件序列
- 试用阶段的用户分群和报表
- 决定给试用用户发邮件的频率

## 我们不负责的
| 领域 | 负责方 |
|---|---|
| 产品内新手引导 | 产品团队 |
| 销售的一次性群发邮件 | 销售团队（我们只就发送时间提供建议） |
| 付费后的客户通讯 | 负责方不明 |

## 角色
| 角色 | 人员 | 职责（可衡量） |
|---|---|---|
| 负责人 | 林敏 | 确定优先级；对发给全部试用用户的邮件拍板 |
| 需求对接人 | 钱磊 | 1 个工作日内回复 #lifecycle-requests [建议] |
| 报表 | 宋菲 | 每周一北京时间 12:00 前发出试用漏斗周报 [建议] |

## 工作约定
1. 核心重叠时间：北京时间 16:00–18:00；只在这个时段开会。[建议]
2. Slack 消息 4 个工作小时内回复；邮件 1 个工作日内回复。[建议]
3. 发给超过 1,000 人的邮件，都要再请一个人检查。[建议]
4. 有分歧就开 15 分钟电话会，不要在长串消息里争论。[建议]
5. 反馈先私下给，在事情发生后一周内给。[建议]

## 例会和渠道
| 会议 / 渠道 | 目的 | 频率 / 用途 | 参与人 |
|---|---|---|---|
| 计划会 | 选定本周的实验 | 每周一，30 分钟 [建议] | 全员 |
| 漏斗复盘会 | 看数据，决定调整 | 每周四，30 分钟 [建议] | 全员 |
| #lifecycle-requests | 其他团队的需求 | 异步 [建议] | 钱磊分拣 |

## 我们怎么做决定
- 文案和发送时间 → 钱磊征求团队意见后决定 [建议]
- 修改面向全部试用用户的序列 → 林敏参考宋菲的数据后决定 [建议]
- 如果意见不一致：林敏在 2 个工作日内决定 [建议]
- 升级给：增长负责人 [建议]，当其他团队对归属有异议时

## 指标
| 指标 | 当前 | 目标 |
|---|---|---|
| 试用转付费率 | 11% | [建议：第一季度末达到 14%] |
| 试用邮件退订率 | [待确认：基线] | [建议：每次发送低于 0.5%] |

## 复审
下次复审：2月4日 · 有人加入或离开时也要复审。
```

## 发送前检查

- [ ] 使命只有一句话，并写明了服务谁。
- [ ] 每一项“不负责的”都写明了负责方，或者写“负责方不明”。
- [ ] 每条工作约定都具体到一旦违反就能察觉。
- [ ] 决策方式写明了谁拍板，以及达不成共识时的兜底办法。
- [ ] 指标都有当前值，或者标明待测量；用户没给的目标标注“[建议]”。

## 常见错误

- 用价值观拼凑使命（“卓越、担当”）。要写服务谁、带来什么改变。
- 只列团队负责的内容。大部分摩擦靠“不负责的”清单来避免。
- 每个决定都要求共识。只把共识留给少数必须人人支持的决定。