标签归档:技术管理

关于复杂系统的思考:从语雀服务中断想到的

在 10 月 23 日,语雀服务出现了一次重大故障,中断时间超过 7 小时。具体来说,这次故障的起因是在执行系统升级操作期间,新的运维升级工具出现了 bug,导致华东地区生产环境的存储服务器被误下线。由于存储系统使用的机器类别过于陈旧,无法直接将其上线,这导致了恢复过程时间延长。尽管语雀的工程师们立刻进行了恢复工作,但由于数据量大,恢复方案有限,恢复过程耗时 4 小时,数据检验耗时耗时 2 小时。这次故障给用户带来了严重的影响,也让我们重新审视关于本次故障带来的思考。

我将整个复盘报告输入给到 chatGPT,其给我的回复如下:

从语雀的这次事故中,我们可以学到以下几个关键的教训:

  1. 重视运维工具的测试和质量保证:在这次事故中,新的运维升级工具的 bug 是导致故障的主要原因。这说明,即使是运维工具,也需要进行足够的测试和质量保证。在实际使用之前,应该在相似的环境中进行充分的测试,确保其稳定性和安全性。
  2. 灾备和恢复系统的重要性:即使有了数据备份,恢复仍然可能需要花费大量时间,这会导致服务中断时间过长。因此,除了定期备份数据外,还需要建立有效的灾备和恢复系统,以便在灾难发生时,能够快速恢复服务。
  3. 灾难恢复演练的必要性:定期的灾难恢复演练可以帮助我们在真实的灾难发生时,更快地恢复服务。通过演练,我们可以发现并解决恢复过程中可能存在的问题,提高恢复的效率。
  4. 高可用架构的重要性:高可用架构可以保证在部分系统组件发生故障时,整个系统仍能继续运行。在这次事故中,由于存储系统的故障,导致了整个服务的中断。如果有高可用架构,即使某个组件发生故障,也可以通过其他的组件提供服务,从而减少服务中断的可能性。
  5. 灾难通信的重要性:在灾难发生后,应该及时向用户通报情况,说明故障的原因,修复的进度,以及预计的恢复时间。这样可以增加用户的信任度,减少用户的不安。在这次事故中,语雀做了很好的灾难通信,及时向用户报告了故障的详情,以及修复的进度。
  6. 持续改进和学习的重要性:每次故障都是一次学习的机会。通过分析故障的原因,我们可以找出问题,改进系统,避免类似的故障再次发生。在这次事故中,语雀提出了一系列的改进措施,这表明他们有持续改进和学习的意识。

但是从复杂系统的角度来看这个事件:复杂系统的性质使得它们在面临故障时,能够以我们意料之外的方式表现出来。尽管我们可能已经在设计和实施阶段做了很多工作来确保系统的稳定性,但是在实际运行中,仍然会出现我们没有预见到的问题。

高尔在讨论复杂系统时提到:「具备故障防备能力的系统出故障的原因恰恰就是故障防备能力的失灵」。这是因为在设计防备系统时,我们往往会基于我们对系统的理解来设计,但是实际上,系统的行为可能会超出我们的理解范围。当系统的行为超出我们的预期时,我们的防备措施就可能会失效。

这与这次语雀服务故障的情况非常相似。尽管语雀设计了一套备份恢复机制,但是在实际的故障中,由于对系统的理解不足,这套机制并没有发挥出应有的效果,反而延长了恢复时间。

在许多情况下,一些复杂系统的故障并不是单一的、孤立的事件,而是由一系列的因素相互作用、相互影响的结果。这通常包括了系统设计、运维策略、人为错误等多个方面。

具备故障防备能力的系统,其设计和运营目标是提供连续、稳定的服务,即使在面临内部错误或外部攻击等影响时也能持续运行。这种系统通常包含冗余的组件、自动故障切换机制、灾难恢复策略等措施,以保证系统的正常运行。

然而,这些故障防备能力本身可能成为系统故障的源头,原因可能有以下几点:

  1. 复杂性故障防备能力会增加系统的复杂性,复杂性本身就可能带来故障。例如,冗余的组件需要保持同步,如果同步机制出现问题,可能导致数据不一致,进而产生故障。

  2. 人为错误故障防备能力的维护和操作需要人工参与,人为操作错误可能导致防备能力失灵。如语雀故障案例中,运维工具的 bug 就是人为因素导致的。

  3. 预期和实际的差距:故障防备能力的设计和实施都是基于对可能故障的预期,但实际发生的故障可能超出了预期,导致防备能力无法应对。

面对一个每天都在演化的复杂系统,我们应该做些什么呢?

面对复杂,我们第一个能想到的原则应该就是 KISS 原则了。

「KISS」 原则是 「Keep It Simple, Stupid」 的缩写,这是一种广泛应用于工程、设计和决策过程中的设计原则。其最主要的理念就是保持事物的简单性。

KISS 原则主张:

  • 避免不必要的复杂性
  • 优先选择简单、清晰和直观的解决方案
  • 不要添加不必要的特性或功能
  • 简单的设计更易于维护、理解和修改

这个原则并不是说所有的事物都必须以最简单的方式来完成,而是鼓励我们在设计和决策过程中,优先考虑最简单和最直接的方法,除非有充分的理由去选择更复杂的方案。

简单性是一个非常重要的设计目标,因为它可以降低错误的可能性,提高系统的可靠性,减少维护的难度,提高效率,以及其他许多好处。

我们如果应用了以下的一些建议,应该可以往 KISS 原则靠近一些:

  1. 明确需求:首先明确我们试图解决的问题是什么。这有助于避免在设计和实现过程中添加不必要的功能或复杂性。

  2. 简化设计:在设计过程中,始终问自己是否可以把事情做得更简单。避免过度设计,只实现真正需要的功能。

  3. 模块化:把大问题分解成小问题,每个小问题都可以用简单的方式解决。这样,每个模块都保持简单,而整个系统则由这些简单模块组成。

  4. 避免不必要的优化:过早的优化可能会增加复杂性。除非确定优化会带来显著的好处,否则最好先实现功能,然后再考虑优化。

  5. 使用已有的解决方案:如果有已经存在的工具或库可以满足我们的需求,那就使用它,而不是从头开始创建。这样可以降低复杂性,同时节省时间。

  6. 代码和设计的清晰性:代码应该易于理解,设计应该直观。这不仅提高了可维护性,也让其他团队成员更容易理解你的工作。

  7. 定期回顾和重构:随着时间的推移和需求的变化,我们可能需要调整或简化现有的设计。定期回顾我们的代码和设计可以帮助我们找出可以简化的地方。

作为一个技术管理者应该作些什么呢?我认为最应该做的是拒绝那些让系统变得复杂的不合理需求,守好技术实现的大门。

面对复杂系统,我们需要对系统有深入的理解,尽可能地简化系统,避免不必要的复杂性。通过模块化设计,将复杂系统分解为相对独立的部分,每个部分都可以单独理解和测试。并且设计出健壮的错误处理和恢复机制,同时也需要进行持续的监控和回顾。只有这样,才能提升系统的稳定性,减少服务中断的可能性。

指标的本质

在我们的工作中经常会看到各种类型的指标,如营收指标、技术指标、效能指标等等,细化下来有年营收金额、SLA、千行代码缺陷率等等。

这些指标量化着我们的工作和目标,让我们朝着目标前进,如果指标有问题,也会导致走偏,或者为了指标而玩数字游戏。

当迷惑于指标,或者指标有问题的时候,需要停下来思考一下:

  • 指标是什么,可以分为几类?
  • 指标有什么价值?
  • 指标是如何生成的?制定指标的过程中有什么讲究?
  • 如何评判一个指标的好处?
  • 跟进指标的过程中有什么注意点?
  • 对指标进行复盘时要看哪些点?

指标是什么

指标的本质是一种衡量工具,它提供了一个客观的、定量的方法来评价某个特定的目标或过程的性能或结果。换句话说,指标是把抽象的目标或过程转化为可以衡量和跟踪的具体数值,是一个由虚转实的工具。

指标的设计和选择必须反映出我们所关注的核心问题和目标。比如,如果我们的目标是提高产品质量,那么我们需要的指标可能包括产品缺陷率,客户满意度等。

同时,指标也是一种沟通工具。它们可以帮助团队成员理解目标,以及衡量他们的工作是否有助于实现这些目标。当所有人都清楚地知道他们的工作如何对公司的总体目标产生影响时,他们可能会更积极地参与和投入。

总的来说,指标的本质是将目标和过程量化,以便于衡量和沟通,从而推动团队或组织向预定的目标前进。

从价值的角度来看,指标在企业管理和决策中发挥着重要的作用:

  1. 提供信息和见解:指标能够提供实时的、可量化的信息,帮助企业了解其运营状况和业绩表现。

  2. 支持决策制定:通过分析指标,企业可以更好地理解其优势和短板,从而制定更有效的策略和决策。

  3. 跟踪进度和绩效:企业可以使用指标来监控项目进度、员工绩效等,以确保目标的实现。

  4. 促进连续改进:指标可以揭示存在的问题和改进的空间,从而推动企业持续改进。

  5. 提高透明度和问责制:清晰、明确的指标可以提高企业的透明度,并有助于问责制的实施。

从分类的角度来看,指标可以根据不同的分类方法进行分类:

  1. 输入、过程、输出和结果指标

    • 输入指标:衡量投入的资源,如资金、人力和时间。
    • 过程指标:衡量活动或操作的效率和效果,如生产速度、错误率等。
    • 输出指标:衡量产出的数量或质量,如生产量、销售额等。
    • 结果指标:衡量最终的结果或影响,如客户满意度、市场份额等。
  2. 财务和非财务指标

    • 财务指标:关于财务表现的指标,如利润、收入、现金流等。
    • 非财务指标:关于非财务表现的指标,如客户满意度、员工满意度、环境影响等。
  3. 主观和客观指标

    • 主观指标:基于个人观点和感觉的指标,如员工满意度、客户满意度等。
    • 客观指标:基于可观察和可度量的事实的指标,如销售额、生产量等。
  4. 滞后和领先指标

    • 滞后指标:反映过去表现的指标,如上个季度的销售额、去年的利润等。这些指标通常用来评价过去的表现。
    • 领先指标:预示未来表现的指标,如新订单量、客户满意度等。这些指标可以帮助预测和改善未来的表现。

分类方法可以根据需要混合使用,以创建最适合特定情境的指标,比如一个指标可能是客观指标,同时也可能是财务指标和结果指标。

制定指标

制定有效的指标是一个结构化的过程,涉及对组织的目标、战略和关键活动的深入理解。

对研发团队来说,不同团队在不同时期制定的指标可能会有所不同,这主要取决于团队的特定目标、战略方向、业务需求、以及所处的市场和行业环境的变化。换句话说,指标的制定需要根据团队当前的业务重点和未来的发展目标,同时考虑到外部环境的影响,以确保指标的相关性、实效性和灵活性。

一般来说,研发团队的指标制定大概可以包括以下的逻辑:

  1. 明确目标:目标是什么,这是制定任何指标的首要步骤。研发团队的目标可以包括开发新产品,提高现有产品的性能,提高生产效率,减少产品缺陷等。

  2. 确定关键活动:关键活动应与团队的目标紧密相关。例如,如果目标是开发新产品,关键活动可能包括市场调研,产品设计,原型开发,测试,生产等。

  3. 确定度量标准:对于每个关键业务活动,确定可以衡量其性能的度量标准。例如,项目管理的度量标准可能包括项目的按时完成率和预算执行率;产品设计的度量标准可能包括设计的创新程度和用户满意度;编码的度量标准可能包括代码的质量和效率;测试的度量标准可能包括测试的覆盖率和缺陷发现率;质量控制的度量标准可能包括产品的缺陷率和客户满意度。

  4. 制定具体指标:基于度量标准,制定具体的指标。每个指标都应有明确的目标值和时间框架。例如,项目按时完成率的目标值可能是90%,时间框架可能是每个季度;代码质量的目标值可能是每1000行代码中缺陷数少于5个,时间框架可能是每个项目。

  5. 收集和分析数据:这是衡量和跟踪指标的关键步骤。数据可以来自内部(如项目管理系统,质量管理系统等)或外部(如市场研究,客户反馈等)。

  6. 定期审查和调整指标:随着业务目标和环境的变化,可能需要调整或更新指标。这要求团队周期性地评估指标的有效性,并根据需要进行调整。

在制定研发团队的指标时,需要考虑到团队的特性,如团队的规模,成员的技能,资源的可用性等。此外,也需要考虑到业务的特性,如市场环境,竞争态势,客户需求等等。

评判指标好坏

当我们制定了指标后,如何评判一个指标的好坏,什么样的指标是好的指标,什么样的指标是不好的指标?

评价指标的好坏,通常要参考以下几个关键标准:

  1. 相关性:好的指标应与团队或组织的目标和策略密切相关。如果一个指标与组织的目标没有直接的关系,那么它可能就不是一个好的指标。比如落地 XXX 个方案和在 XXX 个客户中落地 XXX 个方案是两个完全不同的相关性的指标。

  2. 可度量性:好的指标应该是可以量化的,这样才能进行准确的跟踪和测量。如果一个指标无法量化,那么很难判断是否达到了目标。

  3. 可行性:好的指标应该是可以实际操作和实施的。如果收集一个指标的数据需要花费大量的时间和资源,那么这个指标就可能不是一个好的指标。

  4. 敏感性:好的指标应该能够反映出关键业务活动的变化。如果一个指标对业务活动的变化反应迟钝,那么它可能就不是一个好的指标。

  5. 有预测价值:好的指标应该能提供有关未来性能的信息。如果一个指标只能提供历史数据,而不能用来预测未来,那么它就可能不是一个好的指标。

  6. 易于理解和解释:好的指标应该是明确的,易于理解和解释的,这样所有的团队成员都可以理解这个指标的含义和重要性。

评价指标的好坏需要考虑多个因素,包括指标的相关性、可度量性、可行性、敏感性、预测价值、以及是否易于理解和解释。在制定和选择指标时,需要根据具体的业务需求和环境,权衡这些因素,选择最合适的指标。

当我们看到一个指标时,感觉像是看一个模糊的地图,它与我们真正要达到的目的地关系不大,无法具体量化我们的进步,难以实施和操作,对我们的行动反应慢,不能预测我们未来可能遇到的情况,而且还难以理解和解释。这样的指标无法帮助我们清晰地了解自己的表现,也无法有效地指导我们改进工作,甚至可能让我们误入歧途,此时就需要更新指标。

说到指标这种量化场景,就不得不提一下 SMART 原则,在这种带量化性质的场景,SMART 原则是一个非常好用的原则。

在指标制定的过程中也有一些坑,大概梳理了一下,看看你有没有遇到过:

  1. 指标不够具体:如果指标模糊不清,团队成员可能会对应该集中精力在哪里感到困惑,这会导致效率低下并可能阻碍目标的实现。

  2. 过度依赖「虚荣指标」:虚荣指标是指那些看起来很好,但实际上对业务的核心目标贡献不大的指标。例如,网站的页面浏览量可能是一个虚荣指标,如果它不能转化为实际的用户参与或销售。

  3. 指标过多:过多的指标可能会导致注意力分散,使人们难以确定应该关注哪些最重要的事情。而且,过多的指标也可能导致数据收集和分析的工作变得过于复杂和繁重。

  4. 指标设置过于理想化:如果指标过于理想化,可能会导致团队成员感到挫败,并可能抑制他们的积极性。要确保指标既有挑战性,又具有可达成性。

  5. 未能定期审查和更新指标:随着业务环境的变化和组织目标的演化,原先设定的指标可能不再适用。因此,必须定期审查并更新指标,以确保它们持续对组织有价值。

  6. 未考虑指标可能带来的副作用:有时,指标可能会导致意想不到的负面结果,因为人们可能会过于专注于达成指标,而忽视了其他重要的事情。例如,过度关注销售指标可能会导致客户服务的质量下降。

要解决这些问题,关键是对你的业务目标有深入的理解,明智地选择和使用指标,并定期审查和调整你的指标体系。

跟进指标

跟进指标是一个持续的过程,需要定期检查和评估以确保指标的达成,从而达成目标。以下为我们常用的一些跟进指标的方法:

  1. 定期检查:可以是每周、每月或每季度的检查,具体取决于我们的目标和业务需求。在这些检查中,可以查看每个指标的最新数据,了解是否在达成目标的道路上取得了进展,以及和目标的差,风险、信心值等。

  2. 可视化:使用类似于数字仪表板的组件,自动收集和显示关键指标的数据,使能够一目了然地看到所有重要指标的最新状态。复杂一些,可以搞一个专门的数据可视化工具;简单一点,一个简单的电子表格也行。

  3. 定期报告:定期报告和定期检查不同,定期检查是自己的行动,定期报告是在定期检查的基础上,形成自己的总结,并周知给相关方,其作用更多是沟通逻辑。定期向团队和其他相关人员(如管理层)汇报关键指标的进展。这可以帮助保持透明度,也可以让所有人都对目标的进展保持了解。

  4. 分析和解释数据:仅仅收集数据是不够的,还需要对数据进行分析并解释其含义。例如,如果一个指标的表现比预期差,需要找出可能的原因,并提出改进的策略。

  5. 调整和优化:如果某个指标的表现持续低于预期,或者发现了一个更好的衡量方法,我们可能就需要调整或优化指标。记住,指标应该是灵活的,并能随着业务需求和目标的改变而变化。

通过这些方法,我们可以确保我们的指标始终保持相关和有效,同时也可以确保我们的团队在达成目标的道路上始终保持正确的方向。

在跟进的过程中,有一些常见的问题也是需要注意一下的:

  1. 过度关注指标,忽视目标:有时,团队可能过于关注达到指标,而忘记了这些指标背后的真正目标。例如,一个团队可能过于关注提高销售额的指标,而忽视了客户满意度或产品质量。

  2. 数据收集和分析的问题:如果没有足够的资源或正确的工具进行数据收集和分析,可能会导致指标结果不准确或被误解。

  3. 指标操纵:当人们的绩效考核与指标紧密相关时,可能会出现操纵指标数据以达到个人目的的情况。例如,销售员可能会推迟一些销售,以便在下一个评估周期中看起来表现更好。

  4. 指标失衡:有时,过于重视某一指标可能导致其他重要指标被忽视,从而造成业务的失衡。例如,过度关注成本削减可能会牺牲产品质量。

  5. 指标过时:随着业务环境的变化,一些原本有效的指标可能变得不再相关或有效。固执地坚持使用这些过时的指标可能会导致做出错误的决策。

  6. 对指标的误解:如果团队对指标的理解不准确,可能会导致他们采取错误的行动。因此,确保团队对指标的正确理解非常重要。

复盘指标

当到一个里程碑,或者到一个 OKR 周期结束,需要阶段性的停下来做一下复盘总结。

而在复盘总结的过程中,指标的复盘是相当重要的一环。通过复盘指标这一种反思过程,能够帮助你理解哪些指标有效,哪些需要改进或淘汰。我们可以从如下的几个方面来复盘指标,这和上面评判指标的好坏也是相关的:

  1. 评估指标的有效性:看看每个指标是否帮助我们接近目标。如果一个指标的改进并没有带来预期的效果,那么这个指标可能需要重新考虑。

  2. 检查指标的相关性:评估每个指标是否与我们的主要目标和战略保持相关。如果一个指标不再相关,那么可能需要将其替换为一个更相关的指标。

  3. 考虑指标的易度量性:如果一个指标难以度量或数据难以收集,那么可能需要寻找一个替代的、更易于度量的指标。

  4. 反思指标的预测价值:看看每个指标是否能有效预测未来的表现。如果一个指标的表现与未来的结果没有强烈的关联,那么可能需要将其替换为一个有更强预测性的指标。

  5. 获取反馈:向团队成员和其他利益相关者获取反馈,了解他们对当前指标的看法。他们可能会提供有价值的观点和建议,帮助改进指标。

通过定期复盘指标,我们可以确保指标始终与目标和战略保持一致,从而更有效地驱动团队向目标前进。

小结

指标的本质是一个衡量工具,一个由虚转实的工具,它提供了一个量化的方式来评估和追踪一个组织、团队或个人在达成特定目标或目标集合上的表现和进度。它们将目标和表现转化为可以度量和比较的数据,从而支持决策、驱动行为,并帮助了解是否按照预期的方向发展。

然而,尽管指标是一种强大的工具,但它们只是工具,不能替代全面的判断和考虑。选择和使用指标时,应始终考虑其背后的目标和上下文,并注意避免只关注指标而忽视实际效果的陷阱。

成为问题解决者和好传声筒

在我们的工作中会遇到很多问题,也会有人来问我们问题,对于问题,我们可能会选择直接解决,或者 @ 某个人来解决,或者 @ 好几个人来解决。

如果一个问题是交到我们这里来解决,尽量成为问题解决者。

成为问题解决者

成为问题的解决者意味着什么?

对于技术管理者来说,意味着我们要负责任地处理问题,去解决问题,而不是转发,一定是要对问题本身有认知,有判断后再去处理,再去解决,而不是简单地将问题转发给其他人。这就要求我们深入全面的了解问题的背景和现状,分析问题的根源和可能的解决方案;这就要求我们具备批判性思维、解决问题的能力,以及对我们负责的业务领域和技术领域有深入的理解。

意味着技术管理者要对他的决策和行动负责。我们不仅要解决当前的问题,还要预防未来可能出现的问题,有前瞻性的思维,能够预见可能出现的问题,并提前做好准备。

对于一线开发同学来说,意味着我们要负责任地处理问题,去解决问题,而不是转发,不是简单地把问题推给其他人,需要负责任并主动的去寻找解决方案。这需要我们深化对问题的理解,探索可能的解决方案,然后付诸行动。这不仅要求我们具备强大的技术能力,也要求我们有独立思考和解决问题的能力。

在面对问题时,我们不应该急于求成,而应该耐心分析,找出问题的根源。这可能需要我们查阅相关文档和资料,或者利用调试工具进行深入地分析。我们必须理解问题的本质,以便找出最有效的解决方案,可能最终只是改一个配置或一行代码。

同时,我们需要主动地与团队其他成员,甚至是来自其他团队的同事沟通交流,分享我们的发现和思考,听取他们的意见和建议。这将帮助我们从不同的角度看待问题,可能会发现一些我们之前未曾注意到的解决方案。也可以问问 AI ,它懂得比我们多。

此外,我们还需要积极地跟踪问题的解决进度,确保我们的解决方案能够有效地实施,并能够在实际环境中正常工作。如果我们的解决方案存在问题,我们需要有勇气承认错误,重新回到问题的起点,找出新的解决方案。

如何成为一个好的问题解决者,问题的解决有没有方法论或套路?

从问题的分类来看,问题可以分为以下三类。:

  • 应急响应类:这类问题通常需要立即解决,以防止问题进一步恶化。解决这类问题通常需要快速反应和短期改进措施。例如,系统突然宕机,需要立即修复。

  • 深度分析类:这类问题通常涉及到系统性的、复杂的、长期存在的问题,需要深入分析问题的根源并找出解决方案。例如,产品的用户留存率持续下降,需要通过数据分析、用户访谈等方式深入理解原因,并制定相应的解决策略。

  • 追求卓越类:这类问题更多地关注如何优化和改进现有的流程和系统,预防问题的发生,并提升整体的效率和效果。例如,团队的开发流程效率低下,需要通过对工作流程的持续改进和优化,提高团队的工作效率。

从问题解决的过程来看,成为问题解决者,无论是面对应急响应类问题、深度分析类问题还是追求卓越类问题,都可以遵循以下的方法论:

  1. 理解问题:全面、深入地理解问题的背景、现状和影响,探究问题出现的原因以及它对工作、团队或公司的影响。
  2. 分析问题:进行深入的分析,找出问题的根本原因。可能需要查阅相关文档、与相关人员进行交谈或使用数据分析工具。
  3. 设定解决目标:明确问题解决的目标或期望结果,设定一个明确且可衡量的目标,以便知道何时问题已经被解决。
  4. 寻找解决方案:根据问题的原因,寻找可能的解决方案。可能包括改变现有的过程、引入新的工具或技术、提供培训和教育等。
  5. 实施解决方案:找到解决方案后,付诸行动,实施解决方案。可能需要与其他人协作,或者独立完成。
  6. 评估结果:实施解决方案后,评估结果,看看是否达到了预期目标。若未达到预期,可能需要重新考虑解决方案,或者寻找新的解决方案。
  7. 反馈和改进:问题解决是一个持续的过程,需要不断地反馈和改进。从失败和成功中学习,以便在将来更好地解决问题。

当然,从另一个方面来说,成为问题的解决者并不是成为所有的问题的解决者,成为问题的解决者也并不意味着我们要独自一人去解决所有的问题。在需要的时候,我们应该寻求他人的帮助,与他人合作,共同解决问题。我们要记住,我们不是工作中的孤岛,我们是一个团队,我们需要彼此的帮助和支持,才能更好地解决问题。

做一个好传声筒

对于一个技术管理者来说,特别是团队大一些的技术管理者来说,根本做不到事事亲自来做或跟进,此时就需要在对事情有一个基本的判断后,将事情指派给某一个同学来处理,做一个好传声筒。

对于一个一线开发同学来说,当一个事情虽然到你这边了,而你没有精力去解决的时候,可以寻求他人或上级的帮助,当有其它人介入后,将当前问题说清楚,交接清楚,做一个好传声筒。

那什么是好传声筒?

好传声筒是「把饭喂到嘴里」。当你需要拉一个人来解决问题,或者要把相关信息传递给他,需要把事情的前因后果都讲清楚,把要传达的内容传达到位,而非仅仅是将问题原封不动的转发给他。这就意味着你需要用尽可能清晰和明确的方式,阐述问题的背景,问题的现状,以及预期的解决结果。你需要告诉他如何才能有效地解决这个问题,以及为什么我们需要他来解决这个问题。

一个好传声筒更是需要具备一定的判断力和思考能力,能够在传递信息的过程中进行筛选和整合,把对方需要的信息准确、完整地传达出去,同时避免不必要的信息干扰。这就需要我们有良好的理解力和表达力,能精准地把握信息的关键点,清晰地表述出来。

此外,作为一个好传声筒,我们还要学会尊重和理解接收信息的人。我们需要理解他们的需求,他们的困惑,以及他们的期望。我们需要用他们能理解和接受的方式,来传递我们的信息。这就需要我们有良好的沟通技巧,有同理心,有耐心。

同时,我们也要注意保护信息的安全和隐私,避免不必要的信息泄露,这是我们作为传声筒的基本职责和底线。

一个好传声筒不仅仅是传递信息的工具,更是沟通和解决问题的桥梁。作为一个好传声筒,我们需要有良好的理解力和表达力,有独立思考和判断的能力,有良好的沟通技巧和同理心,以及对信息安全和隐私的尊重。

特别要注意的一点,在 IM 沟通的时候不要把聊天记录直接转发,这里可能会带来一些问题,如:

  1. 隐私问题:聊天记录可能包含敏感信息或个人信息。在没有得到原始对话者的同意的情况下转发这些信息,可能会侵犯他们的隐私权。

  2. 信息过载:聊天记录可能包含大量的信息,其中只有一部分是相关的或有用的。直接转发整个聊天记录可能导致接收者感到信息过载,难以找到重要的信息。

  3. 上下文丢失:聊天记录中的信息可能需要上下文才能理解。如果接收者没有这个上下文,他们可能会误解信息的含义。这点特别重要,也特别常见。

在传递信息的过程中我们可以有一些结构的表述来帮助确保信息清晰、准确且易于理解。以下是一些可能的方法:

  1. 使用列表和子列表:较常用的一种方式,这可以帮助组织信息,使其更加清晰。例如,你可以列出问题的主要部分,然后为每一个部分提供详细的子列表。

  2. 使用图表和图像:视觉元素可以帮助接收者更好地理解和记住信息。例如,可以使用流程图来解释问题解决的步骤,或者使用图表来展示数据。虽然这有点费劲,但是效果会好很多,不常用,主要应用于相对重要的场合。

  3. 使用模板和框架:例如,你可以使用 STAR 框架(Situation、Task、Action、Result)来描述问题和解决方案。首先,描述 Situation(情境),即问题出现的上下文或背景。然后,描述 Task(任务),即你或接收者需要完成的任务。接着,描述 Action(行动),即你或接收者需要采取的行动。最后,描述 Result(结果),即预期的结果或解决方案。

  4. 使用明确的语言:避免使用术语或行话,除非你确定接收者理解它们。使用简单、明确的语言可以帮助确保信息的准确性。

  5. 提供足够的背景信息:如果使用了 STAR 原则,这个基本都会讲清楚,如果没有,也需要在描述问题或解决方案时,提供足够的背景信息可以帮助接收者理解其重要性和紧迫性。

  6. 重复关键信息:重要的事情说三遍。人们通常需要听到或看到信息几次才能记住它。通过重复关键信息,你可以帮助接收者记住和理解它。

要成为一个好传声筒,不仅要能够准确、清晰地传递信息,还要能够使用合适的方法来组织和呈现信息,使其易于理解和记住。

如果我们做到了成为问题解决者和好传声筒,那会带来什么?

从团队协作的角度来看:

  1. 提升团队效率:团队成员能够独立解决问题和有效地传递信息,这大大提高了团队的工作效率和生产力。
  2. 增强团队凝聚力:通过共同解决问题,团队成员之间的关系会得到加强,增强了团队的凝聚力。
  3. 建立信任和尊重:当团队成员能够负责任地解决问题和准确地传递信息时,这能够在团队内部建立信任和尊重。
  4. 提高团队的问题解决能力:团队成员遇到困难时,他们会学会如何解决问题,这提高了整个团队的问题解决能力。
  5. 保护团队的信息安全:作为一个好传声筒,团队成员会更注重保护信息的安全和隐私,从而减少团队面临的风险。

从个人发展的角度来看:

  1. 提升个人能力:通过解决问题和有效地传递信息,个人的专业能力、沟通技巧和批判性思维能力都得到了提升。
  2. 培养责任心和勇气:负责解决问题和传递信息的过程,会培养个人的责任感和勇气。
  3. 提高问题解决能力:在不断地解决问题中,个人的问题解决能力将得到锻炼和提高。
  4. 增强信息保护意识:作为一个好传声筒,个人在处理信息时会更加注重信息的安全和隐私,增强了信息保护意识。

总的来说,成为问题解决者和好传声筒,不仅可以提高团队的效率和凝聚力,提升团队的问题解决能力,还可以帮助个人提升专业能力,培养责任感和勇气,提高问题解决能力,增强信息保护意识。

小结

在前面我们探讨了在工作中如何成为问题的解决者和优秀的传声筒。对于问题解决者,所需的素质包括对问题的深入理解、批判性思维、对业务和技术领域的深入理解,以及对自身决策和行动的责任意识。对于传声筒,关键在于准确、清晰地传递问题的背景、现状和预期解决结果,同时需要有判断力和思考能力、尊重和理解接收信息的人、以及对信息安全和隐私的保护。

在日常工作中,我们既可能是问题的解决者,也可能是问题的传声筒。但无论我们处于哪种角色,都需要不断提升自身的能力和素质。在实践中,我们应该寻找一个平衡点,既要有解决问题的决心和主动性,也要有智慧知道何时寻求他人的帮助。只有这样,我们才能真正成为一个高效的技术团队,每个成员都是问题的终结者,同时也是团队协作的重要组成部分。