工程团队如何营造心理安全感：提升协作、创新与研发效能的关键

衡量一个团队是否成功，最重要的指标并不是成员资历、领导经验或薪资水平，而是团队是否具备心理安全感。对于工程组织来说，心理安全感不仅影响团队协作，也直接影响创新能力、故障复盘质量、人才留存和长期研发效能。

我曾在一家大型科技公司担任站点可靠性工程师，也有机会跟随一个负责团队发展的团队走访不同地区。我们的任务，是为希望提升协作能力的团队设计并交付团队建设课程。

后来的研究得出了一个非常关键的结论：衡量团队成功与否的首要指标，并不是团队成员的资历、团队领导的管理经验、成员背景或薪资水平，而是团队的心理安全感。

所谓心理安全感，指的是团队成员能够放心表达观点、承认错误、提出不同意见、寻求帮助，而不必担心因此被羞辱、惩罚或贴上负面标签。

用 5 个问题评估团队心理安全感

想想你正在密切合作的一个团队。你对下面五个说法的认同程度如何？

1. 如果我冒险尝试，结果搞砸了，这会对我很不利。
2. 我们团队有很强的既有文化，新人很难真正融入。
3. 当有人遇到困难时，我们团队通常行动迟缓。
4. 发挥我的独特技能和才能固然重要，但团队目标总是更重要。
5. 围绕团队中的敏感问题进行坦诚对话，会让人感到不舒服。

如果一个团队在类似问题上的得分较高，往往意味着它处在一种“不安全”的状态中。

不安全的团队不敢创新，不敢处理冲突，也不敢承认自己需要帮助。只要大家仍能专注于短期目标，并暂时忽略人际关系和协作问题，这样的团队或许还能在短期内取得不错成绩。但最终，由于成员无法真正改变和成长，不安全的团队要么会崩溃，要么会出现明显的绩效下滑。

换句话说，不安全的团队之所以会崩溃，往往不是因为成员能力不够，而是因为人们不敢改变。

心理安全感不足，会如何影响新人工程师？

为了理解不安全的团队会如何影响个人，我们可以从一位刚毕业、充满热情、能力出色的新人工程师视角来看这个问题。

这位虚构的新人工程师，我们暂且称她为凯伦。她以优异成绩毕业，专业背景包括算法、数据结构和分布式计算。

某天，凯伦读到一篇关于如何减少分布式数据库底层锁竞争的优化文章。她意识到，这项优化似乎可以应用到团队正在开发的服务中。于是，她决定先在测试集群上验证，结果发现 CPU 资源消耗降低了 15%。

她非常兴奋，决定把这项配置变更部署到生产环境。由于这只是对数据库配置文件的修改，不涉及代码变更，因此没有经过通常的代码审查流程。

不幸的是，这次变更导致数据库彻底崩溃，网站出现了短暂但完整的服务中断。幸运的是，一位更有经验的同事很快发现问题，并在 10 分钟内回滚了变更。

作为专业团队，他们在每周事故复盘会议中讨论了这次事件。

1. “如果我冒险尝试，结果搞砸了，这会对我很不利。”

在复盘会议上，工程负责人明确表示，为了一个小幅优化而导致系统停机，是不可接受的。

凯伦当着整个团队的面被指责为“不负责任”。团队成员也纷纷提出建议，试图防止类似事件再次发生。

对工程负责人来说，这可能只是一次普通复盘，很快就被忘记了。但对凯伦来说，这次谈话会被长期记住。她由此得出一个结论：以后绝不能在没有明确许可的情况下主动尝试任何创新。

一次本可以转化为团队学习机会的事故，就这样变成了一次对个人的羞辱。

2. “我们团队有很强的既有文化，新人很难真正融入。”

凯伦受到的伤害之所以更大，是因为没有人站出来支持她。

没有人指出，数据库配置缺少审查机制本身就是导致事故发生的重要原因。也没有人提醒大家，“指出一次行为存在问题”和“给一个人贴上不负责任的标签”之间，有很大区别。

这个团队一直为系统可靠性而自豪。维护团队声誉，似乎比帮助一名新人融入团队更重要。

于是，凯伦意识到：当她犯错时，团队和管理者都不会真正支持她。

3. “当有人遇到困难时，我们团队通常行动迟缓。”

凯伦是生产环境的新手。她并没有接受过正式的事件管理、生产环境维护或分布式系统故障排查培训。

团队里的许多成员都有多年经验，他们从未觉得自己需要培训，也没有意识到新员工需要系统化的入职文档。团队文化中也没有任何明确信号表明，一个应届毕业生花时间学习这些技能是合理且必要的。

于是，凯伦开始产生冒名顶替感。她不明白自己为什么能通过招聘流程，也经常怀疑自己为什么还没有被解雇。

这就是不安全团队的典型问题：当新人遇到困难时，团队并不会主动补足支持系统，而是默认新人应该自己学会一切。

4. “发挥我的独特技能和才能固然重要，但团队目标总是更重要。”

凯伦的专业背景让她很快意识到，现有系统整体设计并不理想，根本无法很好地应对负载高峰。

团队却总是把问题归因于客户超出预期的使用量。这就像在雨天烧烤时，把下雨归咎于天气预报员一样。

凯伦提出了一个新设计方案，灵感来自她实习期间使用过的一项技术。但由于同事们对这项技术并不熟悉，他们认为风险太大。

没有充分讨论，也没有深入评估，凯伦很快放弃了这个方案。她只是想写代码、构建系统，而不想陷入看似毫无意义的争论。

在心理不安全的团队中，成员会逐渐学会沉默。即使他们掌握了有价值的专业知识，也会因为担心被否定、被误解或被孤立，而选择不再表达。

5. “围绕团队中的敏感问题进行坦诚对话，会让人感到不舒服。”

后来，大量客户访问导致产品数小时无法使用。公司高层要求与运营团队开会。

会议上讨论了很多细节。凯伦解释说，现有设计根本无法应对这种访问高峰，并再次提到了自己的设计方案。她的主管提醒她，这个方案已经在工程评审中被否决了，并向高层承诺，团队可以继续改进现有设计。

会后，凯伦和一位团队成员讨论这次会议。她感到非常失望，因为主管似乎看不到现有设计才是问题根源。

那位同事耸耸肩，说团队过去几年一直提供着不错的服务，而且大家并不想和主管讨论其他设计方案。

凯伦决定提前离开公司，寻找新的机会。

她离开后，公司并没有感到可惜。毕竟，在他们看来，她“鲁莽、爱抱怨，而且不服从权威”。他们从未意识到，她提出的方案本可能挽救产品，避免因反复宕机导致客户流失。

如何为工程团队营造心理安全感？

那么，工程组织中究竟有什么特殊之处，会让我们赶走这么多有潜力的工程师，也让更多人无法充分发挥自己的能力？

答案往往不在技术本身，而在团队文化。

我们都知道，强大的文化认同、共同理解和共同价值观对团队成功非常重要。但与此同时，我们也需要在尊重现有文化的基础上，保持开放心态，并在必要时调整它。

一个最初非常适合远程办公的团队，如果开始接收实习生，就可能需要改变协作方式。一个以“所有工程师都随时待命”为荣的团队，随着系统故障对业务影响越来越大，也可能需要建立更专业的运维机制，而不是继续依赖所有人随时救火。

真正健康的文化，不是永远不变的文化，而是能够在新的人员结构、业务阶段和系统复杂度面前持续进化的文化。

平衡个人擅长的工作与组织必须完成的工作

团队还需要认真思考一个问题：如何平衡员工热爱的工作和公司必须完成的工作。

优秀的管理者会识别出某些工程师不适合当前团队的工作内容，并帮助他们找到更合适的位置。卓越的管理者则会进一步拓展团队职责范围，更好地利用现有工程师的技能，让他们感受到自己的能力和才华被看见、被认可、被使用。

如果工程师的技能长期得不到发挥，他们会感到沮丧。如果给工程师分配他们不具备能力或缺乏支持的工作，他们又会觉得自己注定要失败。

心理安全并不意味着降低要求，而是让人们在明确期望和充分支持下，更好地发挥自己的能力。

将尊重融入团队文化，提升团队协作质量

如果一个人把大量精力都耗费在伪装成别人、避免出错、避免被评价上，就很难真正全身心投入工作。

团队需要确保每个人都能以真实状态参与工作。因此，当我们看到不尊重行为时，必须及时站出来。

一位海外组织领导者曾说过：“你选择视而不见的标准，就是你选择接受的标准。”这句话同样适用于工程团队。

不顾及他人的感受和经历，会让他们逐渐关闭自己。下面是一些常见例子：

有人欢迎一位新加入的女性项目经理，却想当然地认为她不懂技术，于是用过度简化的方式解释服务架构。事实上，这位项目经理拥有计算机科学博士学位。即使发言者没有恶意，这种假设也会让人感到被低估。

一次关于同事过往工作的谈话中，有人提到自己曾在一家已经倒闭的公司工作，另一位同事却嘲笑他“胆子真大”，竟然敢承认这一点。这样的嘲笑并不专业，也会让团队成员在分享经历时变得更加谨慎。

一位性格内向但非常有才华的工程师，在会议上总是被更外向的人打断。如果团队不主动确保每个人都有表达机会，就可能错过重要观点。

当不尊重行为发生时，应该在听到这件事的人面前，立即、礼貌地指出它不合适。这不是为了羞辱某个人，而是为了明确团队标准。

如果在凯伦的事故复盘中，有人能够及时提醒大家：这次故障并不严重，真正需要改进的是配置变更的测试覆盖率和审查机制，那么结果可能会完全不同。

要让这些尊重和协作机制持续落地，团队也需要把讨论、任务、文档、目标和审批等工作放在可追踪的协作空间中。Worktile 这类通用项目协作系统，可以帮助团队把日常沟通、任务推进和文档沉淀连接起来，让心理安全不只停留在口号上，而是融入具体协作流程。

给工程师创造安全冒险和创新的机会

有些公司会设置“自由探索时间”，让员工拿出一部分工作时间尝试自己感兴趣的问题。也有一些软件公司会在固定迭代周期之间安排灵活时间，让员工处理那些困扰自己、但又不会影响团队外部承诺的事项。

这种做法传递出一个强有力的信息：团队鼓励每个人跳出惯性思维，也允许大家在不影响关键交付的前提下探索新的可能性。

当然，“创新时间”并不是唯一可以冒险的时候。真正重要的是，团队是否愿意改善一个人的新想法，而不是急于否定它。

想象一下，如果工程评审中的一位资深工程师愿意和凯伦一起改进她的方案，让它更容易被团队理解和接受，凯伦会多么感激。

一个心理安全的团队，不会把新想法当成威胁，而会把它当成可以被打磨的素材。

当团队表现出色时，要明确表扬

很多团队会在每日站会或每周目标会议上，把目标写在便利贴上。当这些可见的目标被移到“已完成”区域时，团队成员会获得一种具体而直接的成就感。

但我们不仅可以庆祝成功，也可以庆祝有价值的失败。

多年前，我负责某大型科技公司一个存储 SRE 团队时，我们正在推进一个为期三年的项目，目标是替换旧的分布式文件系统。当时项目刚进行到一半。

由于电池故障、固件问题、工具不足、软件未经充分测试、部署计划过于激进，以及两次断电等一系列因素，我们让一个完整存储单元失去了可用性，持续数小时。尽管所有服务在其他可用区都有备用存储，团队仍然花了整整三天三夜才完成恢复。

重建完成后，整个团队，包括我在内，都感到沮丧、疲惫，甚至有一种彻底失败的感觉。

一位优秀的管理者来办公室时察觉到了这种低落情绪。他提醒我：团队在这三天里对新存储架构的理解，可能比之前三个月加起来还要多。他认为，我们应该庆祝这次学习。

于是，我们买来一些便宜的起泡酒，占用了一间大会议室。每当有人在白板上写下自己从这次事故中学到的东西，我们就举杯庆祝。

走出会议室的团队，和进入会议室时判若两人。

所谓“庆祝失败”，并不是庆祝损失本身，而是承认团队在艰难经历中获得了重要学习，并把这种学习转化为组织资产。

如果凯伦知道，团队会认可她发现了非代码变更缺少测试覆盖率的问题，并且会一起改进这个流程，她一定会更愿意留下来继续贡献。

通过清晰沟通和明确期望提升故障复盘质量

与其在工程团队出故障时大吼大叫，不如帮助团队构建工具，用来衡量故障严重程度；制定服务级别目标，用来展示团队工作进展；并建立一种文化，让团队利用目标与现实之间的差距，选择最有影响力的工作。

在讨论成员可能犯错的问题时，人们需要感到安全。他们应该能够分享所有相关信息，并且明白，团队评价他们的标准不应是他们是否犯错，而应是他们如何处理失败，以及这次失败如何帮助团队学习、改进产品、推动组织进步。

承担运营职责的团队，需要定期聚在一起讨论系统故障和流程缺陷。关键是，这些讨论必须被视为有价值的学习机会，而不是一场寻找替罪羊的行动。

我曾见过一个团队陷入僵局：他们在争论是否推出一项能够提升效率、但会让终端用户延迟增加 20% 的功能。

后来，他们与产品团队进行了简短沟通，并更新了服务级别目标，明确不同延迟水平可能造成的客户流失，以及这会对公司利润产生怎样的影响。于是，团队中的任何人都能很快意识到：低延迟远比节省硬件成本重要得多。过去在硬件配置上的“超支”，其实是合理的业务投入。

如果你希望别人为你完成某件事，就要请求对方做出具体承诺，例如：“这件事什么时候能完成？”而不是想当然地认为所有人都认同它的紧迫性。

模糊的期望会制造误解，而未兑现的承诺会破坏信任。

如果凯伦的经理事先告诉她，团队非常重视可靠性，并明确希望她优先投入可靠性改进，而不是单纯追求性能优化，她一定会更清楚自己该如何做出判断。

对于工程团队来说，清晰沟通和故障复盘还需要和研发流程本身结合起来。比如 PingCode 这类智能化研发管理工具，可以覆盖目标、需求、开发、测试、发布和 Wiki 知识沉淀等研发全生命周期，并打通研发工具链，让事故复盘、改进项和过程数据能够持续流转，帮助团队更系统地提升研发效能。

让你的团队真正感到安全

如果你希望团队拥有更强的心理安全感，可以从今天开始做几件事：

首先，给团队发放一份简短的心理安全调查问卷，并把结果分享给团队。

其次，和团队讨论“安全”对你们意味着什么，看看大家是否愿意分享自己曾经感到“不安全”的时刻。

再次，从管理者和资深成员的具体行动开始，建立一种尊重他人、清晰沟通、鼓励表达的文化。

最后，把心理安全视为一项关键业务指标。它的重要性并不低于收入、销售成本、系统可用性或正常运行时间。

心理安全不是温情口号，而是提升团队效率、生产力、员工留任率和业务结果的重要基础。

工程团队真正需要的，不只是更强的技术能力，也不是更严格的流程控制，而是一种让人们敢于表达、敢于承认错误、敢于提出不同意见、敢于一起学习的环境。

当团队成员能够安全地说出真相，组织才有机会真正变得更好。对工程管理者来说，持续建设心理安全文化，是提升团队协作质量、故障复盘效果、创新能力和长期研发效能的重要路径。