团队健康检查模型怎么做：用可视化发现团队改进机会

团队健康检查模型是一种帮助团队审视协作状态、发现改进机会、提升组织效能的方法。它通过一组结构化问题和可视化结果，让团队更清楚地看到当前状态、优势、痛点和变化趋势。

想了解这类团队健康检查模型的更多最新实践，也可以参考相关后续文章。

什么是团队健康检查模型？

许多公司都在尝试用不同方法衡量和可视化团队的工作状态。这类方法通常被称为“成熟度模型”，其中往往包含某种发展过程的不同阶段或等级。

这些模型的初衷通常是好的。例如，大型组织中的管理者或敏捷教练，希望了解改进工作应该聚焦在哪里，发现系统性问题，并帮助团队提升自我认知，从而让团队也能把改进精力投入到真正重要的地方。

不过，我们更倾向于使用“健康检查模型”这样的说法。因为“成熟度”听起来多少有些居高临下。此外，我们的大多数模型并不强调团队要从一个等级“晋升”到另一个等级，主要受众也不是管理层，而是团队成员自己。

组织改进在很大程度上是一场猜测游戏：你如何知道哪里需要改进？又如何知道自己是否真的在改进？采用系统化的方法，并配合清晰的可视化呈现，可以减少其中的一部分猜测。

团队健康检查模型真的有效吗？

情况并不绝对。

有时候，这类模型确实很有帮助。但有时候，它的效果也可能很一般：人们只是例行参加工作坊、填写调查问卷或完成其他活动，随后就把数据放在一边，不再真正使用。

更需要警惕的是，在一些公司里，我们看到类似模型演变成了一种怪物：一种系统性的压迫工具。它让团队效率下降，也让恐惧在组织中蔓延。管理者利用“成熟度模型”评判团队、比较团队，甚至挑动团队之间的竞争；而团队为了维护良好形象，不得不掩盖自己的真实问题。

这绝不是我们希望看到的结果。

以下是基于我们在海外某些公司观察到的情况，绘制出的一个非常粗略的“成功概率”示意图：

尽管潜在损害可能大于潜在收益，但它确实存在正向价值，而且也有办法避免它走向灾难。

在某海外大型音频平台公司，我们多年来一直谨慎地进行实验，并逐渐找到了一些相对有效的方法。总体来看，这些方法带来的收益大于弊端。最好的情况下，它非常有帮助；最差的情况下，也只是效果一般。到目前为止，我们还没有遇到灾难性后果。

我们也曾将这种健康检查模型介绍给其他几家公司，并收到了类似反馈。因此，我们觉得是时候把这些经验写下来，分享给更多团队了。

团队健康检查模型适用于哪些人？

当我们检查一个团队的健康状态时，实际上有两个主要利益相关方。

首先是团队本身。

在讨论不同健康指标的过程中，团队成员会逐渐意识到：哪些方面做得好，哪些方面做得不好。宽泛的问题有助于拓展他们的视角。也许他们很清楚代码质量存在问题，却从未真正从客户价值的角度思考过；也许他们没有意识到，团队的学习速度本身也是一个值得关注的问题。

健康检查也能提供一种更平衡的视角：既看到团队优势，也看到团队痛点。

第二类利益相关方，是支持团队的人。

在团队之外，或部分参与团队工作的管理者、敏捷教练和其他支持者，可以通过健康检查获得团队运作状况的概要信息，了解哪些方面有效，哪些方面存在问题。他们也可以观察多个团队之间的共性。

如果你负责支持几十个团队，不可能和每个人深入讨论所有事情，那么这样的可视化概要就能帮助你判断：自己的时间应该投入在哪里，应该和哪些团队讨论哪些问题。

解决问题的第一步，是意识到问题的存在。而可视化能让问题更难被忽视。

团队健康检查怎么做？

我们主要做三件事：

1. 举办工作坊，让团队成员从多个角度讨论和评估当前状态，例如质量、乐趣、价值等。
2. 创建结果的图形化摘要。
3. 利用这些数据帮助团队改进。

健康检查产生的洞察，最好不要停留在讨论现场，而应该进入团队日常协作流程。对于通用项目协作场景，可以借助 Worktile 这类项目协作系统，将改进行动转化为任务、项目、文档、日历和审批等可跟踪事项；如果是研发团队，也可以使用 PingCode 这类智能化研发管理工具，把团队目标、客户反馈、需求评审、开发测试、发布上线和 Wiki 知识沉淀串联起来，让团队健康检查真正转化为持续改进。

我们有几种不同版本的健康检查方式。其中一种就叫“团队健康检查模型”，其他版本包括敏捷能力游戏和季度反思。这些也许以后可以单独写文章介绍。

健康检查模型，是对某海外公司早期“自主团队”季度调查的改进版本。

下面是某个团队群组健康检查输出的真实示例：

这张图展示了该团队群组中 7 个不同团队如何看待自己的当前状态。颜色代表现状：绿色表示状态良好，黄色表示存在一些问题，红色表示情况非常糟糕。箭头代表趋势：整体是在变好，还是在变差。

盯着这张图看一分钟，你就会开始发现一些有趣的信息。

如果纵向看每一列，你会发现不同团队之间存在明显差异。第四团队几乎对所有事情都很满意。第二团队遇到了很多麻烦，但大多数情况正在好转。

如果横向看每一行，你会发现一些系统性规律。每个团队都觉得工作很有趣，而且这种感受还在持续改善。显然，团队积极性并不是问题。但发布流程明显存在问题，整体代码库状态也很糟糕。长期来看，这些问题很可能会影响团队的工作乐趣。

如果从整体来看，你会发现几乎所有箭头都是向上的，整张图中只有两个向下箭头。这说明改进过程，也就是所有过程中最重要的一个过程，似乎正在发挥作用。

当然，这只是对现实的一种近似描述。所有模型都不可能完全准确，但有些模型是有用的。因此，在采取行动之前，值得进一步核实。

例如，第四团队真的状态那么好吗？还是他们只是过于乐观，没有看到自己的问题？大多数团队都认为自己为客户提供了良好价值，但他们怎么知道？这种判断是基于一厢情愿，还是真实客户反馈？

在这个具体案例中，第四团队其实是在健康检查前一周才刚刚组建的。他们显然还处在形成阶段，或者说“蜜月期”。因此，第二团队和第四团队都需要大量支持，只是支持方式可能不同。

“易于发布”显然是一个主要问题。因此，我们把更多注意力放在持续交付等相关事项上，并已经在这方面取得了一些不错进展。

请注意，这是一个自我评估模型，完全基于团队成员的诚实度和主观判断。因此，它只适用于高度信任的环境：团队成员相信他们的管理者和同事会以帮助他们为出发点。

数据很容易被操纵。因此，关键是确保没有人有动机去操纵数据。

幸运的是，在这家公司内部，团队之间的信任水平相当高。管理者和教练们也非常谨慎地强调：这是一个支持工具，而不是评判工具。

如何收集团队健康检查数据？

我们发现，在线调查在这类事情上的效果并不好。最主要的原因是：它扼杀了对话，而对话才是最有价值的部分。

团队成员会在讨论中获得启发，教练也能从讨论中获得洞察，知道如何更有效地支持团队。单独的数据只能呈现冰山一角，而且很可能产生误导。

因此，我们通常由敏捷教练组织团队工作坊，促进团队围绕不同健康指标进行面对面交流。一般来说，一到两个小时就足够了。

为了方便讨论，我们准备了一套实体卡片。每张卡片代表一个健康指标，并分别给出“理想状态”和“糟糕状态”的示例。

一套卡片通常包含大约 10 张。下面是一个完整卡组示例。

领域	理想状态	糟糕状态
易于发布	发布过程简单、安全、无痛，而且大部分已经自动化。	发布风险高、过程痛苦、需要大量人工操作，而且耗时很长。
合适的流程	我们的工作方式非常适合我们。	我们的工作方式糟透了。
技术质量，也就是代码库健康状况	我们为代码质量感到自豪。代码简洁易读，测试覆盖充分。	代码一团糟，技术债已经失控。
价值	我们交付的产品和服务很棒。我们为此感到自豪，利益相关方也非常满意。	我们交付的东西很糟糕。我们为此感到羞愧，利益相关方也非常不满意。
速度	我们推进事情很高效，不需要长时间等待，也不会反复拖延。	我们似乎永远无法真正完成事情，总是遇到瓶颈、被打断，项目经常因为依赖关系停滞不前。
使命	我们非常清楚自己为什么在这里，并且对此感到兴奋。	我们完全不知道自己为什么在这里，没有清晰愿景，也没有明确目标。所谓使命既模糊，也毫无鼓舞性。
乐趣	我们热爱自己的工作，也很享受一起工作。	工作无聊透了。
学习	我们一直在学习许多有趣的新东西。	我们从来没有时间学习任何东西。
支持	每当我们寻求帮助和支持时，总能获得很好的回应。	我们经常陷入困境，因为得不到所需的支持和帮助。
玩家还是棋子	我们掌握着自己的命运。我们决定做什么，也决定如何做。	我们就像棋盘上的棋子，对做什么和怎么做几乎没有影响力。

对于每一个问题，我们会请团队成员讨论：他们更接近“理想状态”，还是更接近“糟糕状态”。我们会使用一些基本的工作坊技巧，例如点投票，帮助团队就该指标应该选择哪种颜色，以及趋势是稳定、改善还是恶化达成共识。

为了保持简洁，我们喜欢把颜色等级控制在三个级别：绿、黄、红。颜色的具体定义可以根据情况略有调整，但大致如下：

绿色并不意味着一切完美。它只是表示团队对现状感到满意，并认为目前不需要进行重大改进。

黄色表示存在一些需要处理的重要问题，但情况还没有糟到失控。

红色表示情况真的很糟，需要尽快改进。

是的，这些数据带有主观性。理论上，团队可以选择使用客观数据，例如周期时间、缺陷数量、发布频率等，但实际很少有团队这样做。

原因是，即使有了客观数据，团队也仍然需要解释这些数据，并判断它们是否代表问题。因此归根结底，一切仍然包含主观判断。如果某件事让团队感觉像是问题，那么这种感受本身就是一个问题。

有时候，我们会把健康检查和回顾会结合起来。例如，团队会围绕某张卡片进行投票，并决定采取哪些行动来改进这个领域。

团队健康检查应该问哪些问题？

如果你查看上面的各种示例，会发现实际问题略有不同。我们的指导原则如下。

这些问题应该覆盖多种不同视角。

这些问题只是起点，是默认选项。各个团队可以根据自己的需要，自由删除、添加或修改问题。

尽量将问题数量控制在 10 个左右。如果问题太多，很可能其中有些问题重复性太强，可以删掉。

我们会确保问题都围绕团队的工作环境展开，而不是围绕具体产出，例如速度。这样可以降低调查带来的威胁感，并强化它的目的：提供支持和帮助改进，而不是评判团队。

我们的基本假设是：团队本质上都希望成功，并且会在既定条件下尽力做到最好。这个假设未必永远正确，但它是一个更有建设性的起点。

团队健康检查多久做一次？

如前所述，我们目前使用多种不同模型，因此实际频率也有所不同。我们还没有找到一个所谓“完美间隔”，而且很可能永远也找不到。

不过，每季度一次似乎是一个不错的起点。

每月一次通常太频繁。人们容易感到厌烦，而且数据变化也不一定快到值得如此频繁更新。

每半年一次又似乎太少。因为这段时间里可能已经发生了太多事情。

当然，具体频率仍然取决于团队和组织实际情况。

总结：如何用团队健康检查推动组织改进？

这样的模型确实可以帮助组织提升改进工作的聚焦度。但如果使用不当，它也可能严重破坏企业文化。因此，一定要谨慎使用。

以下是一些可以提高成功概率的指导原则。

第一，明确引入模型的动机。它应该是为了改进，而不是为了评判。

第二，主要通过面对面交流收集数据，而不是依赖在线调查。数据收集过程本身应该是有趣、轻松且有价值的。

第三，让团队参与模型的使用方式设计，并允许他们根据实际情况调整模型。

第四，团队接受度比数据一致性更重要。如果 A 团队选择的问题和 B 团队略有不同，也没关系。即使最终汇总结果看起来有些混乱，也比强迫所有团队使用一模一样的问题更好。

第五，确保没有人有动机钻空子。任何团队都不应该有理由想要“看起来不错”。

第六，找到一种简单的数据可视化方法。可视化越直观、越清晰，就越容易被真正使用。

第七，不要轻易比较两个团队。如果 A 团队大部分指标是绿色，而 B 团队大部分指标是红色，并不意味着 A 团队“更好”。这很可能只是说明 A 团队面临的情况更简单，或者他们更乐观；也可能说明 B 团队更坦诚地面对自己的困难。

无论如何，B 团队很可能需要帮助。管理者的态度应该是：“我能帮上什么忙？”而不是：“你们为什么比其他团队差？”

第八，持续跟进。你可以询问用户：“这个模型对你有帮助吗？”“如果我们停止健康检查，你会感到遗憾吗？”“我们怎样才能让这个模型更有用？”

模型本身，以及你使用模型的方式，也需要不断改进。

团队健康检查模型的价值，不在于给团队打分，而在于帮助团队看见问题、讨论问题，并持续改进团队协作方式。只要使用方式得当，它就可以成为团队管理和组织改进中非常实用的工具。

好了，就是这些。希望这篇文章对你有帮助。你是否也尝试过类似方法？欢迎分享你的经验，无论是好的，还是不那么好的。