团队健康检查是什么
团队健康检查用一组固定维度定期自评，例如交付节奏、代码质量、协作、学习与士气，用红黄绿标注状态，并聚焦一到两项改进行动。它是轻量的团队诊断机制，重点是让团队自己看见问题并决定先改什么。
基本要素
| 常见维度 | 交付、质量、协作、学习、士气、工具与支持 |
|---|---|
| 节奏 | 每月或每季度一次，30-60 分钟即可完成 |
| 产出 | 红黄绿结果 + 一到两项下阶段改进行动与负责人 |
| 使用原则 | 结果对团队公开、对上级透明，但不作为考核工具 |
典型使用场景
- 新组建团队并行一段时间后，检查协作与节奏是否成型
- 交付指标下滑但原因不明，用多维度自评定位问题面
- 重组或人员变动后评估团队状态
- 季度复盘前收集一线感受，避免只讨论数字
- 长期高压项目中途检查士气与可持续性
自评维度示例
自评维度示例
交付：需求到上线是否顺畅，等待主要发生在哪？
质量：线上故障是否可控，复盘结论是否落地？
协作：跨团队依赖是否顺畅，冲突如何解决？
学习：是否有时间沉淀与改进，新人上手是否顺利？
士气：大家是否愿意继续留队，压力是否可持续？
# 每项只标注红黄绿，并写下支撑判断的一个具体事例结果处理对照
| 结果 | 含义 | 行动 |
|---|---|---|
| 绿 | 状态健康 | 保持观察，记录可复制的做法 |
| 黄 | 存在问题但可控 | 列入改进项，指定负责人与时间 |
| 红 | 明显影响交付或人员 | 本次检查重点，需上级支持 |
| 连续红色 | 改进未发生 | 检查是否超出团队可控范围，升级处理 |
健康检查的可信度依赖用途：一旦结果影响绩效评级，团队会挑好看的项目打分，数据随之失真。
会议组织要点
- 先由成员各自标注，再公开讨论分歧项
- 颜色有分歧时补充具体事例，再定结论
- 每次只挑一到两项改进，指定负责人与复查时间