team-health

团队健康

开始之前

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

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

如果对话中某个具体人员是核心人物，且 .agents/reports/[name].md 不存在，请先询问并记录该人员的精简档案，再提供详细建议：职称／级别、任职时间、优势，以及当前挑战或成长领域。

如果后续对话揭示了持久的新背景信息，请自动更新 .agents/em-context.md 或 .agents/reports/[name].md。记录稳定的事实和模式，不要记录猜测、短暂的挫败情绪或尚未厘清的解读。

回复风格

首次回复要简洁实用。除非用户要求深入讲解，否则不要一股脑抛出完整框架。

默认做法：

• 先说明可能的诊断或建议
• 只有在缺失的背景信息会改变建议时，才提出最多 2-3 个有针对性的问题
• 给出下一步具体行动，并在有帮助时提供经理人可直接使用的措辞
• 简要提及相关框架，但不要逐一解释所有部分
• 先直接回答，再提出可提供更深入的版本

---

如何使用此技能

• 不知道从何入手／需要健康状况诊断 → 有效团队的 5 大要素
• 团队进展缓慢、未能兑现承诺或精疲力竭 → 团队健康状态
• 团队正以不可持续的节奏工作 → 管理团队工作强度
• 有人说“团队不够努力” → “团队不够努力”
• 团队似乎缺乏投入或彼此疏离 → 参与度阶梯
• 正在规划团队会议，需要内容创意 → 团队会议
• 正在规划团队外出活动或专注日 → 团队专注日
• 想要一系列活动创意（成长／联结／影响） → 阅读 references/activities.md
• 回顾会上总是反复出现相同问题 → 当回顾变得重复
• 团队成员似乎不信任彼此 → 信任电量
• 出了问题——需要进行复盘 → 无责复盘
• 团队技术实力强，但凝聚力似乎不稳固 → 凝聚团队与团队扼杀行为
• 不确定应该向团队分享多少信息 → 透明度作为团队健康信号
• 想要示范灵活工作方式，同时避免形成监控文化 → 大方休假

---

默认回复结构

提供团队健康方面的帮助时，先诊断，再推荐活动：

1. 健康状况判断： 士气、安全感、可靠性、清晰度、工作强度、信任或参与度。
2. 依据： 用户观察到了什么，以及这可能意味着什么。
3. 立即稳定措施： 本周该做什么。
4. 结构性干预： 会议、惯例、透明度调整、恢复计划、回顾调整或活动。
5. 观察信号： 监测哪些指标，以判断团队是否有所改善。

如果团队正处于倦怠或高强度工作状态，应先处理恢复和优先事项，再建议提升士气的活动。

---

高效团队的 5 个因素

Google 的 Project Aristotle 研究了数百个团队，探究究竟是什么让团队高效。按重要性排序，排名前 5 的因素是：

1. 心理安全感 — 团队成员能否在不感到不安或尴尬的情况下承担风险？
2. 可靠性 — 团队成员能否指望彼此按时完成高质量工作？
3. 结构与清晰度 — 目标、角色和执行计划是否清晰？
4. 意义 — 这项工作对每位团队成员来说是否具有个人意义？
5. 影响力 — 团队是否相信自己的工作很重要？

顺序很重要。五者缺一不可，但心理安全感是基础——没有它，其他因素便无法发挥作用。当人们担心受到评判时，就不会提出顾虑、分享想法或指出问题。

一种实用的方法是：组织一次简短的团队练习，让每个人为每个因素打分（1–5）。看看哪些因素得分最低。平均得分最低的因素就是最重要的关注领域，而不是你觉得最紧迫的那个。

---

你的同级团队也很重要

当问管理者“你的团队有哪些人”时，他们几乎总是列出自己的直接下属，而从不提同级。

但管理者的同级群体也是一个团队，同样适用这五个因素。把同级关系完全视为交易关系（或竞争关系）的工程经理，会营造出孤岛效应：没有知识共享、跨团队协调缓慢，以及出现边界问题时相互指责。

你在与直接下属建立信任、处理冲突、承担责任和培养承诺上投入多少，也要同样投入到与你同级的 EM 身上。

---

团队健康状态

摘自 An Elegant Puzzle（Will Larson）：团队在任何时候都处于以下四种状态之一，每种状态都需要 EM 采取不同的应对方式。

状态	表现	应对方式
进度落后	每个 sprint 的待办事项都在增加；团队感到不堪重负；承诺的事项一再延误	增加人力。这是唯一一种招聘能直接起效的状态。短期内：缩小承诺事项的范围，并如实向利益相关者说明。
勉强维持	团队持续交付，但只做产品工作——没有处理技术债，也没有进行改进	减少 WIP。让团队专注于更少的事项。先完成现有工作，再开始新工作，以此腾出空间。
偿还技术债	团队正积极处理技术债；感觉交付速度变慢	保护这项工作。在技术债还清之前，挡住新的产品需求。这种状态是暂时且必要的——不要让紧迫事项打断它。
创新	技术债较少，交付稳定，团队有精力开展实验	谨慎维持这种状态。它很脆弱。只加入与团队当前工作方式相容的工作。招错人或选错项目，都可能很快让团队退回到勉强维持的状态。

最常见的错误是把所有状态一视同仁。要求一个“进度落后”的团队同时偿还技术债行不通。勉强维持的同时还尝试创新也行不通。先判断当前状态，再采取恰当的应对方式。

---

团队会议

大多数工程经理对团队会议投入不足——要么完全不开（太忙，或担心浪费时间），要么开会却没有议程。常见的借口是：“等我有值得说的内容时再安排。”结果就是：一年只开 3 次会。

团队会议能营造共同背景、共同记忆和彼此联结，这些是 1:1 沟通无法替代的。

7 个会议内容创意

1. 回顾下一个项目：它如何契合路线图、为什么选择它、你们希望达成什么目标。这不能替代技术启动会——目的是让大家了解背景并达成共识。

2. 近期事件复盘：梳理发生了什么，并以团队为单位集思广益，探讨如何防止类似事件再次发生。

3. 由开发者分享自己参与的项目：提升他们的演讲能力；团队其他成员也能学到新知识。

4. 公司其他部门的有趣项目：与客户开展的新 PoC、其他团队正在进行的技术工作。

5. 业务动态：你了解一些团队通常不了解的情况。分享销售动态、使用指标以及下一轮融资计划。

6. 邀请嘉宾：

   • 销售代表——在启动大型项目之前，请他们介绍客户背景，以及项目是如何拿下的
   • 设计师——他们的工作方式、看重什么、如何做出决策
   • 产品副总裁——他们的议程、如何看待路线图，以及未来 6 个月的规划
   • 你自己的经理——尤其是在不确定时期
   • 其他团队负责人、架构师、支持人员、客户成功人员，或任何跨职能岗位的同事

7. 轻松活动：一起吃午餐、玩个简短的游戏。远程团队可以尝试 Drawize 之类的活动。

频率

没有放之四海而皆准的答案。每周开 30 分钟的会议，很可能难以长期保持质量。一个合理的起点是：每月两次，每次 30 分钟——之后根据实际情况调整。

最重要的是：先开始，然后不要取消。趁你还没打消念头之前，先创建定期会议。

---

团队专注日

优秀团队与普通团队的差异，往往体现在三方面：

1. 团队如何沟通——不只是沟通什么，还包括如何沟通
2. 团队如何处理冲突——是正面解决，还是任由问题发酵
3. 团队成员彼此的联结有多紧密——是把彼此视为一个个的人，而不只是同事

团队专注日是一种有组织的方式，可以围绕这三方面开展工作。其理念是：每年两次，带团队离开办公室一整天，将工作与增进联结的活动结合起来。

活动形式

• 在办公室以外进行。 换个环境会改变互动氛围。租用其他地方的会议室、去共享办公空间，或找个外出活动场地都可以。重点是：不要待在平时的环境里。
• 每 6 个月一次。 频率足够高，能发挥实际作用；间隔也足够长，能让活动保持特别感。
• 包括项目经理（PM）。 这不是工程团队专属的一天。如果你有合作的 PM，也应该邀请他们参加。面对面交流最有利于共享背景信息并达成共识。
• 兼顾工作与联结。 既不要一整天都待在会议室，也不要一整天都在参加活动。两者都很重要。

10 个专注日内容创意

1. 回顾路线图： 梳理团队的目标方向和原因。未来 6 个月有什么计划，做出了哪些取舍。
2. 技术债务审查： 什么在拖慢团队进度？让工程师畅所欲言。
3. 复盘： 过去 6 个月里，哪些事情进展顺利？哪些不顺利？
4. “我希望我们能多做一些 X”： 每个人说一件事。不作评判，然后确定优先级。
5. 跨团队协作情况： 与其他团队之间是否存在摩擦？面对面交流更容易发现这些问题。
6. 流程审查： 站会、代码审查、部署——哪些流程有效，哪些只是增加了额外负担？
7. 两人一组进行职业发展交流： 安排专门时间，让工程师分享自己的职业发展方向。
8. 黑客马拉松或原型开发时间： 构建一些实验性项目。不必担心是否能发布。
9. 互相教学： 每个人用 10 分钟分享自己了解、但其他人不了解的内容。
10. 一起用餐或参加活动： 以社交活动收尾。不是强制娱乐，而是大家共同选择的活动。

---

透明度作为团队健康信号

你与团队分享（或不分享）的内容，会影响他们对你和公司的信任。

别当“遮风伞”。 经理们以为，替团队挡住所有困难的现实是在保护大家。实际上，他们只会让团队总是被坏消息打个措手不及，也无从准备或应对。有些信息确实需要保密，但大多数“坏消息”都应该分享。

失望临界点。 分享团队迟早会了解到的信息——例如路线图变更、组织调整、财务压力和战略转向。如果他们从别人那里听说，或事后才知道，你的信誉就会受损。最好尽早分享，即使消息尚不确定。

分享财务状况。 了解业务状况的开发者能做出更好的决策——他们也能理解紧迫性、范围和权衡。你不必展示电子表格。但“我们本季度表现强劲，有资金余量可以投入”与“过去几个月比较艰难，我们需要提高效率”，会改变大家对工作的看法。

不妨把团队想象成一艘船上的船员：船上的每个人都知道船是否正在下沉。船员不需要开董事会才能了解情况。为团队提供足够的背景信息，让他们成为船员，而不是乘客。

分享路线图草案。 在优先事项最终确定之前，分享正在考虑的内容及其原因。大家能接受草案，无法接受的是面对一份已经定稿、却对其形成过程一无所知的计划。

---

管理团队强度

不是每周都应该感觉一样。长期全速冲刺的团队会精疲力竭。一直悠着来的团队则会失去锐气。关键在于了解自己处于哪个强度区间，并有意识地做出选择。

一个借鉴耐力训练的简单 5 区模型：

区间	感受	适用时机
1 — 非常轻松	平静、可持续、压力低	高强度时期后的恢复；新成员入职
2 — 轻松	稳定产出，没有赶工	一年中大多数时候的默认健康节奏
3 — 适中	专注，有一定紧迫感	常规冲刺时期、定期交付周期
4 — 高强度	精力充沛、截止日期紧迫	产品发布、关键里程碑
5 — 极限	全力以赴、不可持续	仅限真正的危机——生产环境故障、决定成败的关键时刻

大多数 EM 常犯的错误： 把区间 4 设为常态。区间 4 让人感觉效率很高，看起来也很投入。但它有极限——团队无法长期维持，而且恢复成本很高。

如何运用：

• 明确说出当前区间。“这次冲刺我们处于区间 4，因为要发布产品。”有了明确的名称和结束日期，团队会更容易承受高强度。
• 区间 4 或 5 时期结束后，安排区间 2 的恢复期。不要立刻安排下一轮高强度冲刺。
• 如果团队一直处于区间 3–4，得不到恢复，那是工作量问题，而不是动力问题。

---

“团队不够努力”

如果有人告诉你团队不够努力，既不要置之不理，也不要不加批判地接受。背后有三种截然不同的根本原因，每种都需要不同的应对方式：

1. 缺少“拼劲”——外部人士看不到明显的努力迹象。大家似乎很放松、不紧不慢，也看不出有多忙。这往往是认知落差，而非绩效差距，尤其是在远程办公环境中。

2. 缺少可见产出——沟通不佳、期望不合理，或优先级安排不当。团队确实在工作，但利益相关者看不到进展。这是沟通与透明度问题。

3. 缺少热情——团队看起来缺乏动力或心不在焉。这是士气和参与度问题。

这三种情况都不要忽视反馈。想办法弥合你看到的情况与反馈者看到的情况之间的差距。很多时候，让工作更可见就够了（更频繁地更新进展、更清晰地沟通进展）。

---

坦然离开，不必征求许可

当开发者告诉你他们接下来会在家办公时，不要只说“好”——这会让人觉得他们需要解释原因或征求批准。

不妨这样说：“我相信你能安排好自己的时间——接下来在家办公时，不用特意告诉我。”

然后以身作则。提前离开时，不要补上一句“等孩子睡着后我会继续工作”。直接离开即可。告知一声，不必解释理由。这表明你信任大家能够自行安排时间，而不需要受到监视——这才是灵活工作中真正的心理安全感。

---

当回顾会议变得重复乏味时

如果回顾会议总是反复提出相同的问题，却没有得到解决，可以试试：

• 换些问题。 4Ls 格式（喜欢的、学到的、缺少的、期待的）能让大家提出不同的内容。
• 换些工具。 在线回顾工具（EasyRetro、Parabol 等）可以重新调动那些已经多次走过场的人。
• 进行一次元回顾。 总结过去 6 个月的回顾会议。反复出现的主题有哪些？为什么一直没有解决？
• 采用“最后揭晓”形式。 每个人写下自己的事项，但看不到其他人的内容。最后一次性全部揭晓。这样可以减少锚定效应。

回顾会议总让人似曾相识，背后的深层问题通常是会议产出没有转化为行动。更改形式之前，先检查一下，之前回顾会议提出的问题是否真的得到过处理。

---

敬业度层级

个人敬业度需要四个层面协调一致——每一层都依赖其下的一层：

1. 个人——这个人从根本上来说是否在工作中充满干劲？
2. 角色——工作是否能发挥其优势，并帮助他们成长？
3. 团队——他们是否觉得与同事关系紧密，并受到尊重？
4. 公司——他们是否认同公司的发展方向，并为自己的工作单位感到自豪？

当有人缺乏敬业度时，找出最先出问题的是哪个层面。改善公司沟通，对身处不合适岗位的人没有帮助；调整岗位，对身处糟糕团队氛围中的人也没有帮助。

---

工程师的情绪状态是绩效信号

站会前紧张。每个冲刺结束后都筋疲力尽。对自己无权参与的决策感到沮丧。这些都不是个人问题，而是团队健康状况的信号。

当身体处于压力状态时，没有人能发挥出最佳水平。在 1:1 沟通中问一句 “你这周感觉怎么样？”——这不是为了进行心理治疗，而是为了诊断情况。留出空间，让对方给出真实的回答。

如果某人的神经系统在工作中持续处于威胁模式，那既是环境问题，也是绩效问题。

---

凝聚的团队与团队扼杀

摘自 Peopleware（DeMarco 和 Lister）：凝聚的团队是指成员已经融合为一个紧密的整体——彼此信任、行动协调一致，团队整体表现远超根据成员个人能力所能预期的水平。这样的团队确实十分罕见，价值也远超寻常。

团队凝聚所需条件：

• 有足够的共事时间，以建立共同背景和信任
• 有值得投入的挑战——不只是分配来的工作，而是团队拥有目标归属感的目标
• 不受官僚主义阻碍，避免打断心流并传递出管理层不信任团队的信号

团队扼杀——破坏凝聚力的模式：

因素	表现形式
防御式管理	微观管理、质疑决策、不断检查进度——传递出你不信任团队的信号
分散的工作空间	让深度工作无法进行的开放式办公室；缺乏共享异步规范的远程办公安排
工作碎片化	团队成员不断在互不相关的项目之间切换；没有人能完成任何事情
为赶进度降低质量	强行采用工程师明知有问题的捷径——扼杀工艺自豪感
虚假截止期限	人为制造紧迫感；每个迭代都说“这件事至关重要”——工程师会发现，紧迫性毫无意义
小圈子掌控	管理者把团队中的一部分人当作核心圈子，其他人则只是执行者

即使很多事情都做对了，只要出现其中一种情况，仍可能毁掉一个凝聚的团队。最常见的情况是，防御式管理被伪装成积极参与。

---

信任电池

摘自 It Doesn't Have to Be Crazy at Work（Basecamp/Fried）：两个人之间的每段关系都有一块隐含的信任电池，初始电量约为 50%。

当一个人说到做到时，电池就会充电——按承诺的时间回复、交付承诺的成果、按承诺的方式处理情况。反之，电池就会放电。

建立信任主要靠的不是热情、友善或积极，而是履行承诺。每个迭代都默默交付承诺成果的工程师，与同事之间的信任电池，比那个让所有人感觉很好却总是错过承诺的人更满。

实用建议：

• 如果团队中有人在社交方面遇到困难——同事显得冷淡或不积极——在认定这是性格问题之前，先看看他们的交付记录。信任电池电量不足，往往看起来像是人际关系出了问题。
• 如果新员工似乎被孤立，他们还没有足够的时间为信任电池充电。尽早让他们取得一些小而显眼的成果，比任何入职培训活动都能更快地为电池充电。
• 作为管理者，你与团队之间的信任电池是一切的基础。团队会观察你是否履行承诺，是否为你承诺过要争取的事情据理力争。

---

无责复盘

当出现问题时——生产事故、部署失败、重大 Bug——传统的应对方式是找出责任人并纠正他们。Etsy 的做法（后来成为行业标准）则不同：假设人们当时是根据自己掌握的信息和工具，尽力采取了行动。目标不是找出谁导致了问题，而是了解系统如何让问题得以发生。

先问责的复盘为何适得其反：

• 人们会自我审查。他们会隐瞒发生的事情，或淡化自己在其中的责任。
• 你会失去对实际情况的详细了解。
• 你纠正的是个人，而不是系统——于是下一个人会犯同样的错误。

无责复盘的做法：

1. 按时间顺序梳理事件，不归咎于任何人。记录发生了什么，而不是“谁做错了什么”。
2. 询问：每次做决定时，人们掌握了哪些信息？他们几乎可以肯定是根据当时掌握的信息，做出了最好的决定。
3. 询问：需要有哪些不同，才能避免这件事发生？答案通常涉及工具、流程、缺失的告警或背景信息不足，而不是个人失职。
4. 记录能够改变系统的行动项，而不只是改变人们行为的行动项。

**EM 的角色：**树立基调。如果你主持复盘时是在寻找罪魁祸首，团队就会保护自己。如果你真心想了解系统如何让问题得以发生，他们就会告诉你实情。

无责不代表没有后果。个人一再失职或故意违规是另一回事。但这类情况是例外，不应成为默认的解释。

---

深入了解

如果用户询问某个框架的来源、想阅读原文，或想进一步了解此技能中的任何主题，请阅读 references/sources.md。如需按驱动因素（Growth / Connection / Impact）整理的团队活动创意库，请阅读 references/activities.md。

---

相关技能

• 1on1s — 发现并解决个人状态问题的主要途径
• feedback — 解决团队中特定行为问题
• engineer-motivation — 针对个人层面的动机与投入度进行干预
• roadmap-planning — 将工作量和产能作为团队健康状况的考量因素
• retaining-developers — 5 种状态的留任框架与团队健康信号直接对应