team-composition

团队构成

开始之前

先检查是否有 EM 背景信息。如果 .agents/em-context.md 存在，请先阅读。

如果 .agents/em-context.md 不存在，请先询问并保存一份精简的经理档案，然后再提供详细建议：角色/职称、团队规模、团队使命或负责领域，以及当前挑战或优先事项。

如果对话中某位特定人员是核心人物，且 .agents/reports/[name].md 不存在，请先询问并保存一份该人员的精简档案，然后再提供详细建议：职称/级别、任职时间、优势，以及当前挑战或成长方向。

如果后续对话透露了持久有效的新背景信息，请自动更新 .agents/em-context.md 或 .agents/reports/[name].md。保存稳定的事实和模式，而非猜测、一时的挫败情绪或尚未解决的解读。

回复风格

第一条回复应简洁实用。除非用户要求深入探讨，否则不要一次性讲完整套框架。

默认应：

• 先说明可能的诊断或建议
• 仅在缺失的背景信息会影响建议时，提出最多 2-3 个有针对性的问题
• 给出下一步具体行动；适当时提供经理可以直接使用的确切措辞
• 简要提及相关框架，但不要解释其中的每个部分
• 直接回答之后，再询问是否需要更深入的版本

---

如何使用此技能

• 诊断团队缺少什么／下一步该招谁 → 地下城队伍模型
• 人手足够但团队进展缓慢 → 桶与弹药
• 曾经表现出色的资深工程师如今陷入困境（或反之） → 突击队、步兵与警察
• 团队规模小得危险，或过度依赖某个人 → 最小团队规模

---

默认回复结构

在帮助分析团队构成时，先诊断能力，再建议增加人手：

1. 团队需求： 执行、可靠性、协作纽带、架构、探索或阶段适配。
2. 当前失衡： 哪种原型或能力缺失或负担过重。
3. 证据： 交付、事件、规划、协作或士气方面的症状。
4. 干预： 招聘、培养、重新分配、结对、拆分职责或调整预期。
5. 风险： 如果团队增加了不合适的人，会发生什么。

不要默认建议“招一位资深人员”。要说明团队缺少什么能力。

---

地下城队伍模型

每款角色扮演游戏都需要一支均衡的队伍。全是战士的队伍会死于魔法攻击。全是治疗者的队伍什么也杀不死。工程团队也是同样的道理。

五种原型：

战士

资深问题解决者。负责棘手的 Bug、生产环境故障和复杂迁移。果断，在压力下也能高效工作。真正出问题时，你会找的那个人。

满足的团队需求： 执行困难且风险重大的工作。

坦克

可靠的执行者，通常处于职业生涯早期，与战士密切合作。不要求其领导团队，而是要求其稳定交付定义明确的工作，并分担战士的一部分工作量。

满足的团队需求： 持续完成常规工作，而不消耗资深人员的精力。

治疗者

富有同理心、以业务为导向，是团队的社交纽带。通常是工程与产品/设计之间的桥梁。擅长引导困难对话、化解跨团队摩擦，并在艰难时期维持团队士气。

满足的团队需求： 人际关系、沟通和组织协作。

巫师

负责系统设计、架构文档和系统性思考的资深或 Staff 工程师。能提前数步洞察后果。产出速度较慢，但能避免代价高昂的错误。

满足的团队需求： 架构质量和长期技术方向。

全能型选手

多面手型全栈通才。能在不同领域间切换，推进探索性工作，填补空缺。无论接手什么，都能推动事情进展的人。

**填补的团队需求：**在不可预测的情况下保持灵活性并全面覆盖。

---

使用此模型

**盘点你当前的团队阵容。**确定每位工程师的主要类型。然后找出缺口：哪些类型缺失或人手过剩？

常见缺口：

• 没有坦克型 → 战士型会被日常工作耗尽精力
• 没有治疗者型 → 团队技术实力强，但组织韧性不足；跨职能摩擦不断累积
• 没有巫师型 → 架构决策临时拼凑；技术债不断累积

**留意工程经理（EM）的类型偏见。**工程经理往往会过度招聘与自己同类型的人。前战士型会招聘战士型，却忽视治疗者型。前治疗者型会优先考虑文化契合度，结果执行力不足。该模型通过明确指出缺口来纠正这种倾向。

**将其用于招聘决策。**出现新的编制名额时，先梳理当前团队。下一位招聘对象应填补最关键的缺口，而不是复制团队中最常见的类型。

---

注意事项

这是一种诊断模型，不是把人框定在固定类型中的标签。大多数资深工程师都兼具多种类型。重点不是给人贴标签，而是找出团队当前缺少什么，以及下一步应优先补足什么。

---

火炮与弹药

Keith Rabois 的洞见：增加人手并不会线性提升速度，因为大多数新员工都是弹药——需要指引的专业人才。限制团队产出的，是火炮的数量。

火炮是指能够将一个想法从构思一路推进到发布，并在过程中带动他人的人。他们不需要指引——他们会创造方向。增加一门火炮，就能让有效产出翻倍。没有火炮却只增加弹药，只会带来更多协调成本。

**火炮稀少，而且因企业文化而异。**一个人在某家公司是火炮，在另一家公司未必如此——这项能力有一部分取决于能否驾驭特定组织。找到这样的人，就应给予相应待遇：股权、曝光度和广泛的职责范围。几乎不可能找到火炮的替代者。

**实际应用：**团队人手不少却进展缓慢时，问题往往是“火炮不够”。申请增加工程师之前，先问问：现有成员中有多少人能端到端地主导一项工作？如果答案只有一两人，增加弹药也解决不了问题。

---

突击队、步兵与警察

Robert X. Cringely 提出的模型认为，企业在不同发展阶段需要不同类型的人：

突击队——第一波人马。以初创公司的速度行动。努力、迅速且低成本地工作。他们的任务是建立滩头阵地：构建原型、验证想法，在别人察觉之前迅速行动。他们不执着于质量——他们执着于速度。

步兵——第二波人马。将突击队开创的事业规模化。他们有条不紊地工作、规范地构建，并发布第一个真正的产品。突击队每天做出 20 个决定，而步兵则让这些决定落地。

警察——第三波人马。成功的企业最终需要合规、流程和稳定性。警察确保质量可重复，但不擅长创新或提速。

**管理陷阱：**大多数人都强烈偏好这三种模式中的一种，因此不适合其他模式。在警察阶段的突击队成员会成为麻烦制造者。在突击队阶段的警察会成为瓶颈。这种错配能解释大量“为什么这个人表现不佳？”的情况。

两种实际用途：

1. 招聘时，先判断团队或产品处于哪个阶段。构建新事物时招聘突击队；扩大规模时招聘步兵。在工程领域，警察型技能很少会供不应求。
2. 一位曾在初创阶段表现出色的资深工程师，在规模化后的组织中遇到困难（反之亦然）时，阶段错配往往就是原因，而不是技能突然退步。

---

团队最小规模

摘自 An Elegant Puzzle（Will Larson）：团队规模永远不要低于约 4 人，也不要围绕单个人组建团队。

1 到 2 人的团队在结构上很脆弱：一个人休假、生病或离职，就可能让一切停摆。这也意味着没有真正的代码审查、没有知识冗余，也无法在处理事故的同时开展日常工作。

需要避免的失败模式：把小型“团队”当作组织上的虚构——一名工程师“负责”某个产品领域，名义上就是一个团队。这名工程师承担所有风险，却得不到真正团队所能提供的任何支持。出了问题或他们离职时，没有团队可以接手。

**最低可行团队（Larson 的建议）：**约 4 名工程师。这样可以充分覆盖值班、代码审查、技术设计和休假安排，同时避免形成单点故障。

**团队人数低于这一标准时：**要么把团队扩充到最低可行规模，要么将其并入规模更大的相邻团队，要么明确说明这只是有过渡计划的临时单人／搭档安排，而非永久架构。

---

深入了解

如果用户询问某个框架的来源、想阅读原始文章，或想深入了解本技能中的任何主题，请阅读 references/sources.md。

---

相关技能

• hiring — 在撰写职位描述之前，使用该模型明确你要寻找的人才
• delegation — Kingdom 分工通常遵循原型：将系统所有权交给 Warriors 和 Wizards，将跨团队协调交给 Healers
• managing-high-performers — 尤其是 Wizards，需要能让他们保持投入的、高可见度且复杂度高的工作
• engineer-motivation — 阶段错配（Commando 处于 Police 阶段）往往看起来像是动力问题