作者归档：admin

技术管理必备技能之管理好系统性风险

我们在平常工作中经常会听到有人说系统性风险，但系统性风险到底是个啥？

1 系统性风险是什么

1.1 定义

「系统性风险」是一个经济术语，主要指的是一种可能导致整个金融系统或市场瘫痪的风险或概率。它是从系统性风险的整体性出发，而不是单一机构或者单一行业的危机。这通常是由于金融体系中一个重要组成部分的失败，例如一个大银行或一系列银行的破产，这可能引发一种连锁反应，影响整个系统。

当突发性事件导致金融机构或市场失灵时，资金无法在市场中有效输送和配置，从而引起整个市场的崩溃。系统性风险不仅仅是经济价值损失，还会对实体经济造成严重影响，并导致大部分金融体系的信心丧失。

如 2008 年的全球金融危机。在这个危机中，许多大型金融机构由于负债过重和资产质量下降而陷入困境，这引发了对全球金融系统稳定性的广泛担忧。

系统性风险是监管机构、政策制定者和经济学家关注的主要问题，因为如果这种风险实现，可能会导致重大的经济损失和社会动荡。因此，他们会尝试制定和执行各种政策和法规，以减少系统性风险的可能性。

1.2 系统性风险和非系统性风险的差别

系统性风险作为一种具有更大影响面的风险，和非系统性风险有以下几个方面的区别：

1. 影响范围：系统性风险具有广泛的影响范围，不仅仅局限于特定个体或组织，而是可能波及整个系统、市场或行业。非系统性风险则相对较局部化，通常只对特定个体、组织或项目产生影响。

2. 相互关联性：系统性风险与系统中各个组成部分相互关联，其中一个部分的风险可能会传播、扩大或影响其他部分。非系统性风险通常是单个因素或事件的结果，并不涉及系统的相互依赖关系。

3. 复杂性和不确定性：系统性风险往往更加复杂和不确定，因为它们涉及到多个变量、因素和相互作用。非系统性风险可能更加可控和可预测，因为它们通常涉及特定事件或条件。

4. 长期影响：系统性风险可能具有长期影响，并可能导致持续的连锁反应和不良后果。非系统性风险通常具有较短期的影响，并且其影响通常更容易限定和控制。

5. 解决方法：由于系统性风险的复杂性和广泛影响，解决它们通常需要跨部门、跨组织或跨行业的合作和综合性措施。非系统性风险通常可以通过特定个体或组织的行动来解决。

系统性风险与非系统性风险在影响范围、相互关联性、复杂性和不确定性、长期影响以及解决方法等方面存在明显的区别。

2 技术上的系统性风险

类比经济上的系统性风险，对于一家企业的技术负责人来说，技术上的系统性风险也是一个需要重点关注的点。

2.1 定义

在技术上，系统性风险指的是一个技术系统或者一个技术生态系统中，某个关键组件或者某些关键组件出现故障、漏洞、安全问题等，导致整个系统或者生态系统无法正常运行，进而引发连锁反应和影响。

例如，在云计算生态系统中，某个云服务提供商的故障可能会影响到众多企业和用户的业务运营；在物联网领域，某个智能设备的漏洞可能会导致整个物联网网络遭受攻击和瘫痪。因此，在技术领域中，识别和防范系统性风险也是非常重要的。

2.2 系统性风险和非系统性风险的不同

和经济上的系统性风险一样，技术上的系统性风险和非系统性风险也有 5 个不同点：

1. 影响范围和规模：系统性风险通常具有广泛的影响范围和规模，涉及整个技术系统或架构。它可能涉及多个组件、子系统或关键基础设施，甚至可能跨越多个应用程序或服务。非系统性风险更倾向于局部范围，通常仅影响特定的组件、功能或子系统。

2. 相互关联和依赖：系统性风险涉及到技术系统中各个组件和环节之间的相互关联和依赖关系。它们可能因为一个组件或环节的故障或问题而影响其他组件或环节的正常运行。非系统性风险更倾向于独立存在，其影响相对较为局限，不会对其他组件或环节造成波及效应。

3. 复杂性和不确定性：系统性风险通常更加复杂和不确定，因为它们涉及到多个技术组件、系统交互、数据流和相关的外部因素。这使得系统性风险的评估、预测和解决变得更加困难。非系统性风险通常更容易辨识、评估和控制，因为其范围和影响相对较小。

4. 长期影响和连锁反应：系统性风险可能导致长期的影响和连锁反应，其中一个问题可能触发多个级联故障或影响多个关键业务流程。非系统性风险的影响通常更为短期和局限，不会引起大规模的系统级问题。

5. 解决方法和复杂度：由于系统性风险的复杂性和广泛影响，解决它们通常需要跨部门、跨团队的协作，涉及多个技术专长和领域的知识。这可能需要综合性的技术改进、架构调整或系统重构。非系统性风险通常可以通过单个组件或功能的修复或改进来解决，其处理相对较为简单和局部化。

3 系统性风险的传播

在技术系统中，系统性风险通过多种方式传播，包括以下几种：

级联传播：级联传播是指一个组件的故障导致其他相关组件的故障，从而在整个系统中形成一种连锁反应。这种传播方式可能导致整个系统的瘫痪，影响业务的正常运行。例如，在一个分布式计算环境中，如果某个关键任务执行节点发生故障，可能导致其他依赖于该节点的任务无法正常执行，从而引发其他节点的过载或故障。这种风险传播会在整个分布式系统内形成级联效应，可能导致整个系统瘫痪。
传染传播：传染传播是指一个系统的风险通过某种途径传播给其他系统，从而导致多个系统受到相同类型风险的影响。例如，WannaCry 勒索病毒，它通过网络传播，利用 Windows 系统的一个漏洞进行攻击。当某个系统被感染后，病毒会自动搜索其他具有相同漏洞的系统，并尝试感染它们。这种风险传播方式导致了全球范围内大量系统受到勒索病毒的影响。
共同暴露：共同暴露是指多个系统由于共享相同的风险因素，而同时受到该风险因素的影响。例如，多个在线服务都依赖于一个第三方身份验证服务。如果这个第三方身份验证服务出现故障或者安全漏洞，那么所有依赖它的在线服务都将面临安全风险或者无法正常运行，因为它们共同暴露在同一个风险因素下。
放大效应：放大效应是指一个较小的初始风险经过多次传播和叠加，最终导致整个系统面临较大的风险。例如，在社交网络中，一个虚假信息可能经过多次转发和传播，形成恶性舆论，对整个社会产生较大的负面影响。

在技术系统中，了解这些传播方式和机制对于有效管理技术风险至关重要。

4 系统性风险的来源

系统性风险的由来可以追溯到技术系统的复杂性和相互依赖性。当一个技术系统由多个组件、流程和环节组成时，它们之间存在着相互依赖和相互作用。这种相互依赖性使得一个组件或环节的故障或问题可能会影响整个系统的运行和稳定性。

以下是一些常见的系统性风险的来源：

复杂性和交互作用：技术系统的复杂性和各组件之间的交互作用可能导致系统性风险的出现。当系统变得越来越复杂，组件之间的相互依赖性增加，可能出现不可预见的问题和故障。例如，一个庞大的分布式系统可能由多个模块和子系统组成，彼此之间的相互作用可能导致系统范围的故障，如性能下降或数据不一致。
外部环境因素：外部环境因素也是技术系统性风险的重要来源。例如，技术系统可能受到恶劣天气、自然灾害（如山洪地震等导致光纤断了）、供应链中断或恶意攻击等外部因素的影响。这些因素可能导致系统中断、数据丢失、安全漏洞暴露等问题。例如，一家电子商务平台可能受到网络攻击，导致用户信息泄露或交易中断。
人为错误和疏忽：技术系统性风险也可能源自人为错误和疏忽。人员的操作失误、编码错误、配置错误或安全意识薄弱等问题都可能导致系统故障或数据泄露。例如，一个开发人员可能在代码中引入漏洞，导致系统容易受到攻击。
技术演进和更新：技术的演进和系统的更新也可能引入系统性风险。当引入新的技术、框架或库时，可能存在兼容性问题或未知的缺陷。例如，将系统从一个版本升级到另一个版本时，可能出现功能不兼容、新增的安全漏洞或数据不一致的问题等。
依赖供应商和第三方：技术系统通常会依赖外部供应商或第三方服务。这种依赖性可能带来风险。例如，如果一个关键供应商无法按时提供所需的硬件设备，可能导致项目延期或无法正常运作。另外，如果一个 CDN 第三方服务提供商的服务出现故障，可能会影响到技术系统的正常运行。

以上是一些常见的技术系统性风险的来源示例。在技术管理中，了解和识别这些来源是非常重要的，以便采取相应的措施来减轻和管理系统性风险的影响。

5 管理好系统性风险的意义

聊了这么多术语类的东西，看一下对于一个技术管理者来说，管理好系统性风险到底有什么用，有什么收益。这里我们从技术管理和技术团队，以及业务的角度来看。

5.1 技术管理上的意义

从技术管理和技术团队的角度来看，管理好技术上的系统性风险具有以下意义：

1. 保障系统的稳定性和可靠性：系统性风险管理可以帮助确保技术系统的稳定性和可靠性，减少系统故障和服务中断的可能性。这有助于降低业务中断的风险，提高技术系统的可用性和持续性，保障业务的正常运行。

2. 提高技术投资的回报率：有效管理系统性风险可以降低技术投资的风险并提高回报率。通过规避潜在的系统性风险，可以减少因系统故障或不稳定性而造成的额外成本和资源浪费，提高技术投资的效益和投资回报。

3. 增强技术管理者决策能力：系统性风险管理使技术管理者能够更全面地了解和评估技术系统的风险情况。这有助于他们做出明智的决策，选择合适的措施来降低风险，并确定优先级，以使资源和精力能够最大程度地应对最重要的风险。

4. 提高团队效率：通过管理系统性风险，技术管理者可以减少系统故障和问题的发生，从而减少紧急修复和事后处理的工作量。这使团队能够更加专注于战略性的工作，提高工作效率和生产力。

5. 增加业务可信度：有效管理系统性风险可以提高技术系统的可靠性和稳定性，增加业务的可信度。这有助于提高内部和外部利益相关者对技术部门的信任，加强与其他部门的合作和协调，为企业的可持续发展和成长奠定基础。

6. 促进技术创新和发展：管理好系统性风险有助于为技术管理者提供稳定的技术基础，支持技术创新和发展。他们可以更好地专注于推动新技术的应用、优化现有技术架构和流程，为业务增长提供技术支持和竞争优势。

5.2 业务价值上的意义

从业务价值的角度来看，管理好技术上的系统性风险具有以下意义：

1. 提高效率和生产力：通过管理系统性风险，技术系统可以更加稳定和可靠地运行，减少系统故障和问题的发生，从而减少因为系统问题导致的客诉、修复、沟通等成本。这有助于提高业务的效率和生产力，节省时间和资源，并降低运营成本。

2. 支持业务增长和扩展：有效的系统性风险管理可以为业务提供可靠的技术基础，支持业务的增长和扩展。通过降低系统故障和数据泄露的风险，技术管理者可以为业务提供稳定的平台，支持业务的创新、市场拓展和新产品的推出。

3. 支持业务创新和竞争优势：系统性风险管理为技术团队提供稳定的技术基础，支持业务的创新和发展。通过降低系统性风险，技术团队能够更好地专注于业务创新、新产品开发和市场敏捷性，从而获得竞争优势。

4. 提升用户体验和满意度：系统性风险管理有助于提供稳定、安全和高性能的技术系统，提升用户体验和满意度。用户倾向于选择那些能够提供稳定服务、快速响应和数据安全的产品或服务，有效的系统性风险管理可以增强用户对技术产品或服务的信任和满意度。

5. 降低损失和风险：有效的系统性风险管理有助于降低业务面临的潜在损失和风险。通过识别和管理系统中的风险，可以减少数据泄露、安全漏洞和技术故障所带来的损失，并降低法律诉讼和声誉损害的风险。

6. 提升客户信任和忠诚度：通过管理系统性风险，技术管理者可以建立客户信任和忠诚度。稳定、安全和可靠的技术系统能够增强客户对企业的信心，提高客户满意度和保持客户的长期合作关系。

可以看到如果能管理好系统性的风险，对于技术组织，对于技术管理者，对于业务和业务价值来说，都是一件非常好的事情。从生产效率的提升，到业务稳定性，到对成本的减少以及客户成功都是极好的。

那么如何管理系统性风险呢？

6 如何管理系统性风险

6.1 风险模型

风险模型是风险管理的第一步：理解系统中已有的风险，识别、标记并对已知的风险排列优先级，最终形成一张包含了系统所有已知风险的当前状态的表格。这就是我们所说的风险模型。

建立风险模型的过程是识别风险的过程，在这个过程中我们需要识别出系统中已有的风险，并对其进行分析，标记出优先级、梳理当前状态和历史情况。

风险模型构建过程中需要考虑模型的作用范围，是公司级的，团队级的，项目组的，还是服务级的。

对于一个小公司，可以是公司级的，对于大型一些的公司，可以考虑团队或项目级的。

风险模型至少包括以下一些方面：

严重性/可能性：高中低，先评估严重性，再评估可能性
风险缓和计划：可以使用的或者正在使用的用来降低该风险严重性或者可能性的风险缓和措施。
监控：对该风险的发生是否进行了监控，如果监控了说明监控的指标，如果没有监控，说明原因，以及达成监控目标的原因，最终所有的风险应该是要监控起来的。
状态：活跃 / 已缓和 / 正在修复 / 已解决
历史风险情况：该风险在历史上有没有发生过，什么时候，发生频率等
风险缓和计划：当我们制定风险缓和计划的时候，需要从严重性最高的项开始，缓和风险不是为了消除，而是为了降低风险的严重性和可能性。并不是每一个风险都要制订风险缓和计划。
风险预案：当风险发生的时候，我们可以采取的措施

除此之外，还包括一些常规的添加时间，ID，负责人之类的

6.2 识别和评估系统性风险

识别系统性风险是一个关键的步骤，它需要深入分析和理解组织或项目所面临的技术环境和相关因素。以下是一些常见的技术上的系统性风险示例：

依赖单点故障：系统中存在关键组件、设备或服务的单点故障，一旦出现故障，将导致整个系统或业务的中断。例如，网络设备的故障、云服务提供商的服务中断等。
服务间的强弱依赖：如果系统中的服务之间存在强依赖关系，一旦其中一个服务发生故障或不可用，可能会导致整个系统的故障或性能下降。
内部和外部/离线和在线业务的相互影响：系统中的离线和在线业务之间存在相互依赖关系，如果其中一个业务出现问题，可能会影响其他业务的正常运行。
安全漏洞和数据泄露：系统存在安全漏洞或不当的安全措施，可能导致黑客攻击、数据泄露或信息安全问题。这可能对组织的声誉、客户信任和合规性产生严重影响。
技术过时和不可维护：系统采用的技术或架构已过时，不再受支持或难以维护。这可能导致系统难以升级、演进和修复漏洞，增加系统故障和风险的概率。
第三方供应商问题：系统依赖于第三方供应商提供的技术、服务或组件，但供应商出现问题，无法提供所需的支持、维护或升级。这可能导致系统中断、服务质量下降或业务受阻。
文档或流程的问题，如没有文档，没有沉淀，只在某些人的脑袋里面：如果系统或流程存在缺乏文档、知识沉淀或依赖于个别人员的情况，可能会造成知识孤立和团队合作的问题，影响系统的可维护性和可扩展性。
数据完整性和一致性问题：数据在系统内部或与其他系统之间的传输和处理过程中，可能遭受损坏、丢失或篡改，导致数据完整性和一致性问题。这可能对决策和业务流程产生负面影响。
大规模系统故障：系统由多个组件、服务或子系统组成，如果其中一个组件出现故障，可能导致整个系统的大规模故障。例如，云服务提供商的故障、硬件故障等。
法规和合规风险：系统必须符合特定的法规要求和合规标准，如果系统无法满足这些要求，将面临法律风险、罚款或业务停摆的风险。
服务容量的不足：系统中的某些服务容量可能不足以应对高负载或峰值流量，这可能导致性能下降、响应时间延迟或系统崩溃。
基建发布或扩容等发布操作会影响业务的情况：系统基础设施的发布操作，如服务器扩容、网络配置变更等，可能会对业务产生影响，例如服务中断或性能下降。
线上配置/环境/网络等的变更：对线上系统的配置、环境或网络进行变更时，可能会引入风险，如配置错误、网络中断等，导致系统故障或不稳定。
安全问题：系统面临的安全漏洞、攻击风险或数据泄露等问题可能对业务运行和用户数据安全产生重大影响。

要识别系统性风险，可以采取以下方法：

审查历史数据和经验教训，了解以前的系统故障和问题。
进行风险评估和风险工作坊，与团队一起识别潜在的系统性风险。
与各个部门和团队合作，收集反馈和洞察，了解系统的弱点和关键风险点。
借鉴行业标准和最佳实践，了解常见的系统性风险和应对方法。
定期进行系统评估和安全审查，以发现潜在的系统性风险。
通过识别系统性风险，组织可以有针对性地采取措施来降低风险，并确保系统的稳定性、安全性和可靠性。

6.3 风险治理

风险治理不是一个一蹴而就的事情，需要持续的来做，需要从组织，流程机制，系统工具和文化层面进行治理。

组织层面：一个事情或方案想要比较好的落地，一定是有一个完整的组织来承接，至少需要有 PACE 的逻辑来支撑，明确分工。
流程层面：流程层面至少要建立明确的沟通机制，如周报、例会等，同时还需要建议风险控制流程，明确制定风险识别、评估、控制和监测的标准流程，确保风险管理工作的有序进行。
系统工具：理想中是希望有建立统一的风险管理信息系统，用于收集、整理和分析风险相关信息。甚至可以利用数据分析和人工智能，对潜在风险进行预测和预警，提高风险应对的时效性。简化版可以通过群、Jira 系统等项目管理工具来达到前期的系统工具落地的程度。
文化层面：通过宣导、洞察、关注、固化、奖励等方式引导大家对于风险的关注，将风险意识融入日常工作中，提高大家对风险的认知，强化风险意识。

以上的组织、流程、系统工具和文化层面的治理都是为了更好的管理风险而存在。在这个过程中，风险模型是抓手，通过不停的识别风险，消除风险，缓和风险，不断提高系统变好的可能，以最终达到治理系统性风险的目标。

风险评估和应对规划是一个反复重复的过程，不停的迭代风险模型，识别出新的风险。

当风险模型构建完成后，我们需要定期逐个风险拉出来 review 一次，我们可以问我们自己如下的一些问题：

与上次回顾相比，风险有更严重吗？可能性有更高吗？
接下来会排专人来解决某些风险吗？是否应该安排？
上次回顾安排的事项落实了，对应的风险情况如何，是否有更新到风险模型中？

问完问题，我们可能需要有一些实际的行动：

评估是否有新的风险；
删除旧的风险：如果风险已经解决了，可以归档；
评估原有风险模型中的每一项风险，评估其严重性和可能性，如果有变动，对其进行更新；
对于不同的优先级的风险区别对待。

以上的回顾操作我们在上面建设的某个管理系统来承载，并且这个管理系统是带有通知等功能，以更好的将风险相关的信息周知出去，如 Jira 系统。

7 小结

系统性风险是一个动态的概念，持续反复的监测和评估至关重要。定期审查系统的运行情况、漏洞和潜在风险，确保及时发现和解决问题，以减少系统性风险。

如何不依着惯性做事

发表回复

文章从一个小和尚的故事开始。

在一个古老的寺庙里，住着一位小和尚，每天的任务就是从山下的小溪里挑水到山上的寺庙。小和尚每天日出而作，日落而息，用他的小木桶，一次又一次地从山下挑水到山上，生活在这种重复中过去了好多年。

有一天，小和尚遇到了一个问题，随着寺庙里的弟子越来越多，他一个人挑水已经无法满足大家的需求了。他感到非常焦虑，但加快了挑水的速度，每天几乎都精疲力尽。然而，无论他多么努力，总是无法满足大家的需求。

这一天老和尚问小和尚：「你为什么不想想看，有没有更好的方法来解决这个问题呢？」小和尚一愣，他才意识到，他一直都是在埋头做事，从未想过有其他的方法。

于是，小和尚开始思考，他观察发现，从山上到山下有一条小溪，而这条小溪的水源就是他每天去挑水的地方。他萌生了一个念头，为何不直接将山下的水引到山上来呢？

于是，小和尚开始行动，他用竹子和石头制作了一套简单的引水系统，经过数天的努力，他成功地将水从山下引到了山上的寺庙。从此，他不再需要每天辛苦地挑水，寺庙里的水源也变得更加充足。

这个 AI 写的小故事虽然有点浅，但也告诉我们，在生活和工作中，往往会习惯性地使用过去的方法和思维模式，而忽视了其他可能的解决方案。只有当我们打破惯性，从新的角度去思考问题，才能找到更好的解决方法，实现真正的创新和突破。

这也是我们今天要聊的「如何不依着惯性做事」。

1 定义

咱们先从定义开始。

惯性：惯性原本是物理学中的一个概念，指的是物体在没有受到外力作用时，静止的物体保持静止，运动的物体保持匀速直线运动的状态。在这里，我们将惯性的概念引申到思维和行为上，表示一种习惯性的思考和行动方式，倾向于维持现状，抵制改变。
思维惯性：思维惯性是指个体在思考问题和决策过程中，容易受到过去经验和认知的影响，导致思维和判断受限，难以接受新观念和变革。这种现象使得人们在面对新旧问题和挑战时，容易陷入固定思维模式，缺乏创新和灵活性。
依着惯性做事：依着惯性做事是指在工作和生活中，人们习惯于沿用过去的方式和方法，对新的观念和变革持保守态度，不愿意主动寻求改进和创新。这种行为方式往往会导致效率低下、缺乏竞争力，甚至无法适应不断变化的环境。

2 惯性的好与坏

辩证的看，依着惯性做事有好有坏。在某些情况下，惯性思维和行为可能有利于保持稳定和效率。然而，在其他情况下，过于依赖惯性可能会限制创新和发展。我们需要客观地评价惯性思维对于特定情境的影响，以便在恰当的时机采取适当的行动。

优点如下：

保持稳定：惯性思维和行为有助于维持现状，确保日常工作的稳定进行。在某些情况下，这可能有助于降低风险和不确定性。
提高效率：对于一些已经经过优化的任务和流程，遵循惯例可能会提高工作效率。在这些情况下，尝试新的方法可能会浪费时间和资源。
简化决策：依赖惯性可以简化决策过程，减少思考和计划的时间。这在面临紧迫的截止日期或资源有限的情况下可能有一定优势。

缺点如下：

限制创新：过度依赖惯性会阻碍创新和改进，导致陈旧的观念和方法得以延续。这可能会让我们错过新的机遇和发展潜力。
降低适应能力：在不断变化的市场和技术环境中，过于依赖惯性可能导致我们在应对新挑战时缺乏灵活性和适应能力。
忽视潜在问题：依赖惯性做事可能让我们忽视潜在的问题和风险。在这些情况下，持续改进和调整可能更加重要。

我们需要在不同的情境下权衡惯性思维和行为的利弊。在某些情况下，遵循惯例可能是合理的选择；而在其他情况下，我们需要挑战惯性，寻求创新和改进。关键在于识别何时应该保持现状，何时应该追求变革。

保持惯性大多数人可以做到，今天我们要聊的是如何打破惯性，不依着惯性做事，因为能够用打破惯性，突破常规的人毕竟是少数。

3 如何不依着惯性做事

在个人的认知中，有一个原理和一个架构能在一定程度上打破惯性。他们是「第一性原理」和「四项行动架构」。

3.1 第一性原理

3.1.1 第一性原理简介

第一性原理是指将问题拆解到最基本的事实或原则，然后从这些基本事实出发来重新构建问题的解决方案。在解决问题和制定决策时，从第一性原理出发，有助于深入挖掘问题的本质，避免受到惯性思维的限制。

3.1.2 如何运用第一性原理

运用第一性原理规避惯性思维可以采用以下的 4 个步骤：

拆解问题：将问题拆解到最基本的事实或原则，剥离掉惯性思维带来的先入为主的观念和偏见。
重新构建解决方案：基于拆解后的基本事实，从零开始思考问题的解决方案，避免受到过往经验和传统观念的束缚。
鼓励创新：以第一性原理为指导，积极探索新的解决方案，提高创新能力和应对变革的能力。
实事求是：第一性原理要求我们在思考问题时，始终以事实为依据，避免陷入惯性思维的主观判断。

3.1.3 应用实例

以输出质量报告为例，如何应用第一性原理呢?

当我们谈论编写质量报告时，通常会按照固定的模板或流程进行，这是惯性思维的体现。然而，当我们想要打破惯性，提升报告的质量和有效性时，我们可以尝试以下策略：

反思报告的目标：通常，我们按照惯性写报告，可能因为这是例行公事，或者是因为上级要求。但是，如果我们从第一性原理思考，报告的真正目标是什么？是传达信息，是指导行动，还是促进决策？明确目标后，我们可能需要对报告的结构、内容甚至呈现方式进行改变，以更好地达成目标。
重新审视数据和信息：在收集和呈现数据时，我们往往依赖于固定的方式和工具，如表格、图表等。但是，这样真的能有效地传达信息吗？如果我们打破惯性，尝试新的数据分析和可视化工具，可能会发现更深入、更直观的洞察，从而更好地支持报告的目标。
采用迭代的方式编写报告：依照惯性，我们可能会一次性完成报告的编写，然后提交。但是，如果我们采取迭代的方式，先编写一个初稿，然后进行反馈、修订，再反馈、修订，这样可能会花费更多的时间，但最终的报告可能会更准确、更有洞见。
引入跨领域的视角：我们通常会从自己的专业角度编写报告，但是如果我们引入其他领域的视角，比如用户体验、商业模式等，可能会发现一些意想不到的洞见，这也是打破惯性的一种方式。

3.2 四项行动架构

金教授和莫博涅教授提出的「四项行动架构」是一个用于挑战现有商业模式和行业战略逻辑的工具。其最开始出处是蓝海战略，来自《蓝海战略》一书，它通过改变现有的商业模式来区分与竞争对手的模式，从而创造出新的行业。

3.2.1 四项行动架构简介

四项行动架构主要包含以下四个关键问题，通过这四个问题挑战一个行业的战略逻辑和现行的商业模式：

删除：在我们的产品、服务或流程中，哪些被视为理所当然的元素其实可以删除？
减少：哪些元素我们可以大幅度削减，使其低于行业标准？
提升：哪些元素我们可以大幅度提升，使其高于行业标准？
创新：哪些从未在我们的产品、服务或流程中出现过的元素值得创新引入？

3.2.2 四项行动架构应用实例

在带技术团队过程中，我们也可以应用「四项行动架构」来打破惯性，以挑战技术团队的做事逻辑和现行的工作模式：

删除：技术团队中哪些看起来理所当然的要素应该被删除？
- 可以考虑减少过多的会议和报告，将精力集中在实际的技术开发和创新上。
- 去除过时的技术和方法，避免拖慢团队的发展速度。
- 削减在某些环节的过度管理，让团队成员有更多自主权和创新空间。

如取消每周的固定例会，改为根据项目进度和团队需求灵活安排讨论和分享会。

消减：哪些要素应该被大幅削减到行业标准之下？
- 减少冗余的代码审查和质量控制流程，以提高团队的工作效率。
- 精简项目管理流程，减少不必要的文档和审批环节。

如将代码审查流程简化为一次轮流审查，而不是多次审查。

提升：哪些要素应该大幅提升到行业标准之上？
- 加大对新技术和方法的投入，以求在行业中领先地位。
- 提高团队成员的技能培训和成长机会，以便团队更好地适应市场变化。

如为团队成员提供更多的技术培训和参加行业大会的机会，以便他们能跟上技术的最新发展。

创造：哪些行业中从未提供的要素是应该被创造出来的？
- 开发独特的技术解决方案，为客户创造更大的价值。
- 创造新的合作模式，跨部门和跨行业合作，以实现技术的广泛应用。

如开发一款能够实时分析用户行为的工具，以便为客户提供更精准的个性化推荐服务。

通过运用这个四项行动架构，技术团队可以挑战现有的做事逻辑和工作模式，实现价值创新。这将有助于提高团队的竞争力，为公司创造更大的价值。

4 应用在技术团队管理

4.1 应用方法：「解脱」

打破惯性的常用方法我称之为「解脱」，从一个惯性中解脱出来。解脱看到背后的真实，透过真实，把全部的惯性打破，也就自然而然地走出来了。

一般我们会基于意识到问题、解决问题和透过真实来不依着惯性做事，我们可以遵循以下步骤：

意识到问题：在日常工作中，关注自己的行为和思维模式。观察是否存在惯性思维，例如对新观念的排斥、抵制变革或过于依赖过去的经验。当我们意识到这些问题时，就迈出了第一步。
深入了解问题：分析惯性思维的来源，可能来自个人经验、团队文化或行业惯例。了解问题背后的原因有助于我们制定更有效的解决方案。
寻求解决方案：针对发现的问题，积极寻求创新性和实用性的解决方案。这可能包括改变思维模式、学习新技能、尝试新方法或调整工作流程。
解脱：在实践新方案的过程中，逐步摆脱惯性思维的束缚。这可能需要时间和努力，但随着不断的尝试和改进，我们会越来越不依赖惯性。
看到背后的真实：透过表面现象，关注背后的实质和深层次需求。这有助于我们更好地理解问题，找到更有效的解决方案。
持续改进：在摆脱惯性思维的过程中，保持对问题的关注和反思。不断学习和成长，培养开放、创新和挑战的心态。

通过以上六个步骤，我们可以逐渐摆脱惯性思维，实现真正的自我解脱。在这个过程中，我们需要保持耐心和毅力，不断努力提升自己的认知水平和能力，以达到更好的工作成果。

4.2 应用实践

我们以常见的问题解决方式和团队沟通为例看一下如何应用「解脱」

4.2.1 问题解决方式

意识到问题：观察团队成员在解决问题时是否习惯于采用已知的方法和经验，而忽视了其他可能的解决方案。
深入了解问题：可能是因为团队文化倾向于避免冒险，或者团队成员没有足够的技能或知识去尝试新的方法。
寻求解决方案：可以通过培训和学习，提升团队成员的技能和知识，鼓励他们在解决问题时尝试多种可能的解决方案。
解脱：在实践中，尝试新的方法和技术，逐步摆脱对过去经验的依赖。
看到背后的真实：意识到问题解决的本质是创新和改进，而不仅仅是应用已知的方法。
持续改进：在实践中，不断反思和改进，培养开放和创新的心态。

4.2.2 团队沟通

意识到问题：注意到团队成员是否在沟通中经常遇到障碍，比如信息传递不畅、沟通效率低下等。
深入了解问题：可能是因为沟通方式过于传统，比如过度依赖会议，而忽视了其他可能的沟通方式。
寻求解决方案：可以尝试新的沟通方式，比如异步沟通、立即反馈、跨部门沟通等。
解脱：在实践中，尝试新的沟通方式，逐步摆脱传统的沟通模式。
看到背后的真实：理解到沟通的本质是传递和理解信息，而不是遵循某种固定的方式。
持续改进：在实践中，不断反思和改进沟通方式，提高沟通的效率和效果。

这样的思考和实践，可以应用到技术团队管理的所有方面，包括任务分配、技术选型、项目管理等。关键是要有意识地发现和打破惯性，以创新和改进的心态去面对问题和挑战。

5 小结

小结一下，在上面的文章中我们探讨了惯性思维的利弊，尤其强调了依赖惯性思维可能对创新和发展产生限制。提出两种打破惯性思维的方法：「第一性原理」和「四项行动架构」。第一性原理鼓励我们将问题拆解到最基本的事实或原则，然后从这些基本事实出发重新构建解决方案；而四项行动架构则挑战现有商业模式和行业战略逻辑，包括”删除”、”减少”、”提升”和”创新”四个关键问题。最后详细阐述了如何在技术团队管理中应用这些方法，通过一个被称为「解脱」的过程来摆脱惯性思维的束缚。

技术管理者必备技能之解决问题的 3 个层次

发表回复

作为一名技术管理者，面对日常工作中的各种问题和挑战，我们需要具备出色的问题解决能力。技术团队管理本身就是一项充满挑战的任务，而解决问题的能力更是推动团队向前的关键。当一个技术管理者拥有极强的解决问题的能力后，他大概能应对挑战、降低风险、提高团队绩效、增强领导力并提升个人职业发展。

在解决问题的过程中，我们可以将问题分为三个层次。了解这三个层次将帮助我们更好地应对不同场景下的问题，成为更优秀的技术管理者。

1 应急响应类

应急响应类问题的处理是通过快速反应和短期改进措施来修复问题的反应性流程。其主要作用是停止损害，防止蔓延。

应急响应通常是一种反应式行为，并不研究根本性的问题以及背后的原因。应急响应不会导致理想状态的实现，但是仍然可以满足即时需求、保护客户，为更加深入地挖掘和调查重要细节赢得宝贵时间。有效的应急响应有助于企业产品获得更好的稳定性。

应急响应类问题涉及到系统或产品出现紧急故障时，需要立即采取行动以避免进一步影响。这种解决方式专注于快速应对问题，暂时稳定状况，但可能不会深入探讨问题的根本原因。例如，服务器宕机导致网站无法访问，技术管理者需要立即组织团队快速评估问题的严重性，制定并实施紧急应对措施，进行故障排查，找出问题根源并进行修复，以保障系统正常运行。

针对此类问题，常规处理流程如下：

确认问题：在故障发生时，第一步是确认问题的具体表现和影响范围。
快速定位：尽快找到故障发生的关键环节或设备。
制定应急措施：为了防止问题扩大，制定临时应对措施，如切换备用设备或临时修复。
实施解决方案：采取相应的技术手段和方法解决故障。
验证修复：确认故障已被解决，系统恢复正常运行。
总结复盘：分析故障原因，制定预防措施，避免类似问题再次发生。

以某个互联网产品的后台服务出现异常，导致用户无法正常登录。为解决该问题，我们可以采取以下步骤：

确认问题：收集用户反馈，查看日志和监控数据，确定问题的具体表现和影响范围。
快速定位：分析日志和监控数据，找出异常发生的关键服务或代码模块。
制定应急措施：为防止问题扩大，可以临时限制新用户注册，或者启用备用服务器等。
实施解决方案：针对定位到的问题，进行相应的代码修复或配置调整，然后重新部署服务。
验证修复：测试修复后的服务，确认用户可以正常登录，系统恢复正常运行。
总结复盘：分析故障原因，制定预防措施，优化代码质量和监控预警机制，避免类似问题再次发生。

在职场中，经常会出遇到此类的问题，一个技术管理者也经常需要作为发言人去回复此类问题，可能是对业务方或者上级等等。一般我们回复此类问题可以按以下逻辑来讲：

问题描述：首先，简洁明了地描述问题的现象，包括故障发生的时间、影响范围以及涉及的系统或模块。
原因分析：接下来，阐述经过团队排查后发现的问题根源，以及问题产生的原因。
解决措施：说明已经采取的解决措施以及恢复情况，包括故障处理时间以及目前系统恢复的程度。
防范措施：提出针对此次故障，团队将采取哪些预防措施，以避免类似问题再次发生。
跟进计划：最后，描述团队将如何跟进并持续关注问题的后续处理，以确保问题得到妥善解决。

示例：

★ 问题描述：今日上午 10:00，我们的网站出现了访问故障，影响了所有用户对网站内容的访问。
原因分析：经过团队紧急排查，我们发现问题出在流量爆涨，导致服务器负载过高，从而让部分服务无法正常响应用户请求。
解决措施：我们迅速扩展了服务器资源，同时优化了负载均衡策略。截止目前，网站访问已恢复正常，全部用户可以正常访问。
防范措施：为防止类似问题再次发生，我们将加强服务器负载监控，提前预警潜在风险。同时，我们将对现有负载均衡策略进行评估和优化，确保系统稳定性。
跟进计划：我们将在未来一周内密切关注网站运行状况，并定期向您汇报服务器性能数据。如有任何问题，请随时联系我们。

”

2 深度分析类

深度分析类问题和应急响应类问题相比有一个不同点，在于速度。应急响应类的方式以一种快速而急切的方式处理紧急问题，深度分析的方式则遵循更加严谨的结构，通常包括数据收集、多方分析和深度研究，可能需要以一种更科学的方式花费几小时、几天、几周，甚至更长时间来完成。

深度分析类不会每次出现问题就触发，仅在以下场景下发生：

重复发生的问题。
对安全、质量、交付、成本、士气、生产率或者其他关键绩效指标产生负面影响，且不知道根本原因与解决方案的任何问题。

深度分析类问题的解决是通过确定一个明确的目标，以及与之对应的衡量和管理流程来实现的。深度分析类的问题解决是重复的，直到人们清楚地了解问题，解决问题，并且防止问题再次出现为止。

针对此类问题，常规处理步骤如下：

界定问题：在这个阶段，技术管理者需要充分了解问题的背景，并使用事实和数据来描述现状与期望标准之间的差距。这包括明确问题的目的、范围、影响和紧迫性。问题描述应遵循 SMART 原则（具体、可衡量、可实现、相关、时限）。
分解问题：分解问题是第一步的延续，但是更加细化，为了更好地理解问题，技术管理者需要将问题分解成更小的部分。可以采用逻辑树、鱼骨图等工具来实现问题的分解。在分解过程中，应确保各部分之间的关系符合 MECE 原则（互斥且完全穷尽）。然后，针对每个子问题进行深入的分析、量化和细化。
建立目标和成功判断：在明确了问题的具体表现和原因后，技术管理者需要设定一个清晰的目标，以便于团队集中精力解决主要问题。目标应具有明确的完成标准和时间节点，并遵循 SMART 原则。此外，管理者还需要确保目标与公司战略目标保持一致。同时，为了衡量解决方案的成功程度，需要确定一些关键成功指标。
根因分析：根因分析是指根本原因分析，技术管理者需要深入挖掘问题的根本原因，以便于制定针对性的解决方案。可以采用 5W、因果图等工具来进行根本原因分析。找到根本原因后，管理者需要验证这些原因，确保它们是问题产生的关键因素。
制定解决方案：根据根因分析的结果，技术管理者需要制定相应的解决方案。解决方案是能够防止问题再次发生的应对措施，并不是指实施你感觉正确或者你希望奏效的行动。对于任何实施措施而言，能否防止问题再次发生和达成前几个步骤所确定的目标，是验证解决方案是否有效的主要检查点。解决方案应具有可行性和可持续性，以确保长期效果。同时，解决方案应具有创新性，以提高团队的问题解决能力。
里程碑：为了确保解决方案的实施过程井然有序，技术管理者需要设定一系列里程碑。每个里程碑都应与特定的任务或目标相关联，有助于监控项目进度和实现预期结果。里程碑除了监控项目进度，还有一个作用是对外或对上的汇报，以大的时间节点同步项目的进展。
工作计划：在这个阶段，技术管理者需要为团队制定详细的工作计划，包括任务分配、时间表和预期结果。工作计划应确保各个团队成员清楚自己的职责和期望，以提高执行效率。同时，管理者需要与团队成员保持密切沟通，确保计划的实施过程中能够及时调整和改进。在工作计划中预期结果一定要体现必须的交付物，让预期结果是有能落地的点。
风险判断：在实施解决方案的过程中，技术管理者需要关注可能出现的风险和问题。这包括对潜在风险进行识别、评估和分类，以便于采取适当的预防和应对措施。管理者应与团队成员共同讨论可能的风险，制定风险应对策略，确保项目的顺利进行。
未来改进：问题解决并非一次性事件，而是一个持续的过程。在解决方案实施后，技术管理者需要关注其效果，并根据实际情况进行调整和改进。同时，管理者还应从这个过程中总结经验教训，为未来解决类似问题提供借鉴。

通过以上九个步骤，技术管理者可以结构化地解决复杂问题，提高团队的问题解决能力。这种方法论强调了问题的分析和解决过程的重要性，有助于确保解决方案的有效性和可持续性。

这九个步骤可以作为深度分析类问题的规划方案文档的一级标题。

3 追求卓越类

追求卓越类问题和深度分析类问题相比，通常都以检查关键指标开始，但是有一些差别。深度分析类是要对趋势显示出来的与已设定目标的差距进行反应，而追求卓越类的这种机制则是通过建立新的、更具挑战性的未来状态而主动发起。

深度分析类问题解决方式聚焦在澄清问题及其直接原因上，要尽可能明确和具体。其思维和流程在本质上是调查性的，通过发现与标准之间的偏差，并将关键项目恢复到正常工作状况，围绕着恢复到已知标准或者之前的绩效水平而展开。深度分析类的思维接受现有标准。

相比之下，追求卓越类思维会从根本上对现状提出质疑：「理想状态是怎样的，有没有更好的状态，或者应该是怎样的？」。刚开始的时候你可能没有明确的答案，你必须构想一种改进后的目标状态或未来状态。在聚焦到具体明确的个体问题之前，追求卓越类的问题解决者要拓宽思维宽度，去思考多个备选状态和路径以实现构想。

针对此类问题，常规处理步骤如下：

背景：列出受众和参与者可能需要知道的信息。提供项目的背景信息，例如组织环境、历史、市场情况等。确保所有相关人员对项目有充分了解，为后续步骤打下坚实基础。
现状定义：以图表等可视化的方法描述现状，让受众能更好地接收信息。例如，绘制价值流图，展示当前流程的关键环节、瓶颈和效率。通过直观地呈现现状，帮助团队成员更好地理解问题所在。
现状分析：全面地检验不同要素的改善潜力，比如前置时间、服务、绩效、成本和特性等。运用数据分析、用户反馈和内部评估等手段，找出现有流程中可以改进的地方。
设定目标：明确要在什么时候完成什么，并确定改善的具体水平。设定有挑战性且可实现的目标，为后续改进提供方向。
目标状态的定义：可视化地展示改进后的新状态，通过想象图、流程图或数据等方式，形象地呈现预期的目标状态。这有助于团队成员清晰地了解改进的方向和目的。
制定执行计划：列出具体的细节，比如姓名、责任、日期和预期产出结果等。明确具体的细节，确保团队成员清楚自己的职责和期望。如果需要，可以将执行计划与其他项目计划相结合进行管理。
检查结果：检查改进后的绩效水平是否达到预期。通过定期评估和数据分析，了解实施情况及效果，确保改进措施取得实际成果。
跟进与标准化：制定行动清单，确保改进结果在长期运行中是可维持的。对改进措施进行持续跟踪，评估其有效性，确保新的标准在组织内得到广泛应用和推广。

以一个互联网 SaaS 产品在高峰时段用户体验下降，页面加载速度变慢为例来描述整个过程：

背景：我们的 SaaS 产品面向企业客户，提供在线办公协作功能。近期我们发现，用户在高峰时段访问产品时，页面加载速度减慢，影响了用户体验。
现状定义：通过监控系统收集数据，绘制访问速度和用户活跃度随时间变化的图表。在图表中标注高峰时段，突出问题所在。
现状分析：分析服务器资源、带宽、前端优化等多个方面的因素，找出可能导致页面加载速度变慢的原因。例如，检查服务器响应时间、CDN 服务情况、代码优化等。
设定目标：在高峰时段将页面加载速度提高到行业标准水平。为实现这一目标，我们将设定一个合理的实施时间，例如 3 个月。
目标状态的定义：绘制改进后的访问速度和用户活跃度随时间变化的图表，展示目标状态。同时，列出在服务器资源、带宽和前端优化等方面需要达到的具体指标。
制定执行计划:为实现目标状态，我们需要分配任务给团队成员。例如：张三负责服务器资源优化，如升级硬件、调整负载均衡策略等。李四负责带宽和 CDN 服务调整，以确保高峰时段能应对流量需求。王五负责前端优化，如代码压缩、图片资源优化等。
检查结果:在实施改进措施后，持续监控页面加载速度和用户活跃度。通过数据分析，检查改进后的绩效水平是否达到预期。
跟进与标准化:为确保改进效果的持久性，我们需要：对实施过程进行总结，提炼经验教训。将改进措施纳入团队的日常工作流程，确保新的标准得到长期执行。定期回顾和评估改进效果，以便在未来进一步优化。

4 小结

本文主要探讨了技术管理者在应对日常工作中不同类型问题时，如何运用有效的问题解决能力来提升团队绩效。文章将问题分为三个层次：应急响应类、深度分析类和追求卓越类。对于应急响应类问题，例如服务器宕机等紧急故障，技术管理者需迅速评估并实施紧急应对措施。深度分析类问题则需要更加严谨和系统的方法，如面对重复发生或对关键绩效指标产生负面影响的问题，技术管理者要深入挖掘根本原因并防止问题再次出现。而在追求卓越类问题解决过程中，技术管理者需要勇于挑战现状，设定更具挑战性的未来目标，从而实现技术团队的持续进步。

通过了解这三个层次的问题解决方式，技术管理者能更加从容应对各种问题和挑战，为团队创造一个更高效、卓越的技术环境，推动团队不断向前发展。