这本与其说是书，不如说是演讲实录。书的内容来源自张小龙在 2012 年的那次著名的 8 小时演讲，2016 年被整理成书稿，在 2021 年决定出版。好的内容是经得起时间考验的，在 9 年之后出版，在 12 年后的今天来看也不过时，甚至部分观点会刷新我们的一些认知。

以下是我在读这本书的过程感受比较强烈的三个观点或建议。

1 如果解决方案非常复杂，一定是问题错了。

这是从一个开发能力很强很全面的在朋友圈抱怨：「觉得微信的代码越来越复杂了，开始搞不定了」，张小龙在下面评论说：「如果一个问题的解决方案太复杂，一定是问题本身错了。事实上就是这样子的。」

一个好的问题不应该导致解决方案太复杂。

从研发的角度来看，引申出来有 3 点:

1. 如果解决方案非常复杂，一定是问题错了或者是需求有问题

很多时候，我们在面对一个问题时，容易陷入复杂的解决方案中或者限入为了解决问题而解决问题。但其实当一个解决方案变得非常复杂时，我们应该反思问题的提法是否正确，需求是否是真正的需求。一个好的问题应该能够用一个相对简洁优雅的方案去解决。

陷入困境时我们要学会换个角度或者跳出问题来思考问题。当感到解决方案过于复杂时，不妨退一步问问自己，是不是对需求或问题有误解，有没有更本质更简单的诉求。化繁为简，用简单的方法解决问题，是一种智慧。

2. 优秀的工程师其实可以帮助产品经理矫正需求

产品经理提出的需求，研发同学往往会无条件去满足。但优秀的工程师，应该具备产品思维，有能力去审视和质疑需求背后的逻辑，去引导产品经理矫正需求。

一味地满足需求，只会让产品变得复杂和庞大。优秀的工程师应该成为产品经理的思想伙伴，而不仅仅是执行者。在开发过程中提出合理化建议，做有价值的事，把控产品的定位和走向，这是更高境界的工程师素养。

3. 写代码只是其次，思考和讨论产品也是重要的工作

作为研发同学，不能把自己局限在写代码上。思考产品，了解用户，参与需求讨论，才能真正驱动产品的进步。

代码只是工具，而洞察需求，理解人性，思考产品形态，决定产品体验，这些应该是每一个研发同学的内功。要把自己的视野拓展到产品层面，主动去思考为什么做这个功能、用户会喜欢吗、还能怎么改进体验。唯有这样，才能成为真正优秀的工程师。

2 抽象方能化繁为简

这个观点应该是大部分场景下面，研发同学都认同的。

当面对大量繁杂的需求时，与其逐一满足，不如试图提炼出其中的共性和本质，将之抽象为更少量、更高层次的需求。这个过程就是「抽象」。

以订阅内容为例，如果把各类内容提供方(如企业、个人、媒体等)的形形色色的诉求都一一满足，系统必然会变得非常复杂。但若能抽象出一个统一的账号体系和内容载体，就能用一套接口来服务各方，大大简化了系统。

抽象的层次越高，派生出的子需求就越多。比如将 100 个需求抽象、归纳为 10 个，甚至 1 个，则原本的 100 个需求都可以被这 10 个或 1 个「母需求」所覆盖。

要做好抽象，关键是要找准需求的共性、本质之处，即所谓的不变量，而非沉陷于各自差异化的细枝末节。唯有升维思考，才能在更高层次上对繁复的事物进行归纳和简化。

通过「以简御繁」「归一化」的抽象思路，可以大大降低系统复杂度，提升开发和管理效率。同时让产品对用户更加友好，使用更加简单统一。

这种化繁为简的抽象思维，是一种非常重要的思考方式和设计原则，对于管理大型复杂系统、满足多元需求有重要指导意义。不仅开发人员要掌握，其他非技术人员也很有必要学习这种思维方式。

3 改变旧世界的意愿

在书中，改变旧世界的意愿是在气质篇的第一篇，从其定义上更多的是一些日常记录的点。

在「改变旧世界的意愿」这一点上，张小龙提到了自己：「对于对iPhone5的唯一期待是，像iPad（3G）一样，不支持电话功能。这样，我少了电话费，但你可以用kik跟我短信，用 googlevoice跟我通话，用 facetime 跟我视频。」

做一个产品，意愿是很重要的。我们有没有去一个改变旧世界的意愿

作为一个研发团队的管理者，改变旧世界的意愿是一个团队管理中的核心逻辑。上次和小帅聊天，也有聊到我们在团队管理岗上，我们始终应该改变点什么。

「改变旧世界」的意愿，本质上是一种创新驱动和价值追求。它意味着不满足于现状，主动去探索和尝试新的可能性，并以之来重塑既有的产品形态、技术架构乃至商业模式。这种意愿需要从管理者开始，成为团队的共识和愿景，并指引技术决策和项目实践的方向。

技术管理者需要与团队一起，去思考如何用技术的力量去创造更多的附加价值，解决用户和业务的痛点。要审视自己的产品定位和技术路线，看是否还有优化和颠覆的空间。同时要放眼行业前沿和未来趋势，去探索下一个风口和变革点。唯有确立了明确的变革方向和价值诉求，才能凝聚共识，激发动力。

事实上，很多时候阻碍我们「改变旧世界」的，恰恰是技术和架构层面的「旧世界」。长期累积下来的历史债务，割裂的系统，低效的架构，过时的技术栈，都成为了创新的桎梏。团队往往需要耗费大量时间和精力在修修补补和「打补丁」上，而无暇去思考和实现变革。

这就需要技术管理者下定决心，带领团队去正视和解决技术债务。要客观评估既有系统的健康度，识别出最急需重构和升级的部分。同时要重新思考整个技术架构，看如何通过解耦、重构、引入新技术等手段，来提升系统的灵活性、可扩展性和创新友好度。只有在架构层面打好基础，才能为变革扫清障碍。

除了对技术、架构、债务的改变，「改变旧世界」的意愿，还需要适配研发团队的现状和组织形态。如果团队长期处于产品需求的压力之下，缺乏思考和探索的时间；如果组织过于层级化和官僚化，创新的想法很难被听到和采纳；如果绩效考核过于短视和功利，大家不愿承担变革的风险，那么这种意愿就很难真正落地。

技术管理者需要为团队争取一定的自主权和探索空间。在项目排期和任务分配上，要预留出一定比例的「创新时间」或者技术时间，鼓励大家尝试新的 idea。同时要优化组织架构和流程，让信息和想法能够更顺畅地在团队中流动，减少决策链路，提升反应速度。绩效评估也要将创新和长期价值纳入考量，为「改变」提供合理的回报。

从技术管理者自身来说，站在产品和技术实现交汇的点上，对产品的认知和对实现细节的认知让研发管理可以更高效，更合理的决策技术方案和产品规划，从而更好地引领技术团队实现产品价值和商业目标。

作为管理者，要具备产品视角和技术视角的双重思维，一方面深入了解业务需求和用户痛点，另一方面洞悉技术方案的可行性和优劣。要善于在两个视角之间切换和权衡，找到既能满足需求，又能控制成本和风险的平衡点。也要能跳出具体实现，从更宏观的层面去思考技术战略和产品演进路径，看清下一步的发力点和布局方向。

在具体的实践过程中，技术管理者需要深入了解产品需求的来龙去脉。不能仅停留在需求文档上，而要主动与产品经理甚至客户沟通，理解需求背后的业务逻辑、用户痛点和产品价值。唯有对需求有了全面的认知，才能在技术选型、架构设计、任务拆分等环节做出正确的决策。

同时，技术管理者要对技术实现有足够的了解。这并不意味着要事无巨细地参与到每一行代码中，而是要对关键技术难点、潜在风险、优化方向等有把握。要与技术骨干保持频繁的讨论，时刻掌握开发进度和问题。只有将宏观的需求理解和微观的实现细节结合起来，才能站在全局的高度去调配资源、优化流程、控制质量。

管理者要营造产品和研发的良性互动。鼓励研发团队主动了解业务，引导产品经理关注技术价值，提倡双方同理共情、互相成就。打造一种「产品驱动研发，研发反哺产品」的良性循环，激发团队斗志，凝聚团队向心力。

小结

以书中提到的微信 4.0.1 和 4.2 发布时的文案作为本篇文章的结尾：

很喜欢这句话：如你所知，微信不只是一个聊天工具；如你所见，微信，是一个生活方式。

你曾经在微博上虚掷光阴
如今又在微信里蹉跎岁月
你以为通过手机就连接了世界，
其实只是躲在屏幕后面获取了安全感。
是时候放下手机，和朋友面对面了!
如若不能，试试微信视频通话
少发微信，多和朋友见见面！

书中所说的「鸿沟」指的是产品从「早期采纳者」阶段过渡到「早期大众」阶段时面临的市场接受度的断层。在 SaaS 领域，这个概念尤其重要，因为产品往往需要迅速获得大规模用户基础以实现规模经济。

在《跨越鸿沟》中有一个非常重要的技术采用生命周期（Technology Adoption LifeCycle），技术采用生命周期为一钟形曲线（Bell Curve），该曲线将消费者采用新技术的过程分成五个阶段，分别包括创新者、早期采用者、早期大众、晚期大众与落后者。

每个阶段都代表了产品在市场上获得不同群体用户接受的过程，并且对于 SaaS 企业来说，用户行为也略有不同：

1. 创新者 - 冒险家，这些是最早采纳新技术的人。他们愿意承担较高的风险，对新技术充满热情，并且通常拥有技术背景。在这个阶段的 SaaS 企业提供的通常是最新的、创新的服务或功能。这些服务吸引了那些对新技术充满热情的早期用户，他们愿意尝试共建并提供反馈。这些用户通常对新技术的接受度高，愿意承担一定的风险。
2. 早期采纳者 - 意见领袖，他们也对新技术抱有热情，但他们更关注技术能为他们带来的实际价值和优势。对于 SaaS 企业的这个阶段来说，用户开始认识到 SaaS 产品的价值，并开始在他们的业务中实施。他们可能是行业内的意见领袖或早期采纳者，愿意分享他们的成功案例，从而吸引更多的用户。
3. 早期大众 - 深思熟虑者，这个群体更加实用，他们愿意采纳新技术，但需要看到明确的证据表明该技术已经被其他人成功采用。这个阶段的用户需要产品更稳定、支持更好，且集成到现有系统中的风险更低。随着 SaaS 产品的成熟和市场教育的深入，更多的企业开始认识到 SaaS 的优势，如成本效益、灵活性和可扩展性。这些用户开始采用 SaaS 解决方案，但仍然需要看到明确的证据，证明这些服务能够满足他们的需求。
4. 晚期大众 - 传统群众，他们通常在市场上采纳新技术的时间比早期多数要晚。这个群体通常更保守、更价格敏感，并需要大量的用户证明和支持服务。在这个阶段，SaaS 企业的方案已经成为行业内的主流选择。它们已经成为行业标准，并且用户对这些服务的信任度很高。在这个阶段，SaaS 企业需要关注服务质量、客户支持和持续创新，以保持竞争力。
5. 落后者 - 落伍者，这个群体最后采纳新技术，通常是出于必要而非选择。他们对新技术不感兴趣，可能是因为对新技术不信任或是对变化有抵触感。但当他们的客户和合作伙伴已经转向了 SaaS 解决方案时，他们也会使用 SaaS 产品。

从技术采用生命周期的角度来看，SaaS 产品在不同阶段的产品研发、资源配置、商业逻辑等都有所不同。

创新者阶段

在创新者阶段，SaaS 企业提供的通常是最新的、创新的服务或功能。这些服务吸引了那些对新技术充满热情的早期用户，他们愿意尝试共建并提供反馈。这些用户通常对新技术的接受度高，愿意承担一定的风险和成本。

在创新者阶段，SaaS 业务的用户群体相对较小但高度专注，可能包括以下三种：

• 早期采纳者：愿意尝试新技术并提供反馈的个人或组织。
• 细分市场：特定的行业或市场细分，对于定制化的或高度专业化的解决方案有明确需求。
• 技术热心者：对最新技术充满热情，对产品未完全成熟有一定的容忍度。

特别是「早期采纳者」，会是整个业务的起点，从服务好一个客户开始，这个客户可能是刚好遇到的，也可能是刻意寻找的共创者。

在这个阶段，SaaS产品通常是原型或者最初版本，强调创新和独特的功能。可能这个时候还称不上一个 SaaS，甚至只是一个私有化的定制方案。

此时的产品不完善，但提供了新的解决方案或业务模式，解决了现有市场上尚未被满足的需求。主要解决的问题包括探索新的市场机会、验证产品概念和提早获得用户反馈。

从产品层面，大概具备以下的特征：

• 创新性强，可能是市场上首个提供某种服务的产品。
• 用户界面和客户体验可能未完全弄好。
• 功能集中在核心创新点，可能缺乏辅助功能。

从研发的角度，我们需要重点关注

1. 快速迭代和验证：我们要快速开发出 MVP，并与早期用户密切合作，收集他们的反馈，不断迭代和改进产品。这个阶段的重点是验证我们的产品理念，确保我们的解决方案能够满足用户的实际需求。
2. 灵活性和定制化：由于早期用户可能来自不同的细分市场，他们的需求可能各不相同。我们需要保持产品的灵活性，能够根据不同用户的反馈进行定制化开发，满足他们的特定需求，同时积累案例。
3. 技术创新和领先：作为创新者，我们必须在技术上保持领先。我们要敢于尝试新的技术和架构，为用户提供独特的价值。同时，我们也要确保产品的稳定性和可扩展性，为后续的发展打下坚实的基础。
4. 与早期用户建立紧密关系：早期用户是我们最宝贵的资源。我们要与他们建立紧密的合作关系，倾听他们的反馈，了解他们的痛点。我们要让他们感受到自己是产品的一部分，共同塑造产品的未来。

在创新者阶段，SaaS 产品面临的最大问题是市场验证和产品市场契合度（Product-Market Fit）。虽然我们的创新理念可能源于对市场和用户需求的洞察，但在实际推出产品之前，这些假设都没有得到真正的检验。我们可能会犯两种错误：一是对用户需求的判断失误，二是高估了市场对创新产品的接受程度。这就像是在黑暗中航行，我们看到了目标，却不确定航向是否正确。如果产品定位偏离了用户的真实需求，再好的创意也难以吸引和留住早期用户。因此，我们必须通过频繁的用户互动和数据分析，不断校准我们的方向，确保产品的每一次迭代都朝着正确的方向前进。

创新往往意味着探索未知的领域，采用新的技术和架构。这对研发团队提出了更高的要求，既需要快速学习和掌握新技术，又要在有限的时间和资源内交付高质量的产品。同时，由于我们的重点是尽快推出 MVP，产品在功能的完整性、性能的稳定性、用户体验的友好性等方面可能还存在不足。这就像是一个幼儿，虽然充满了潜力和想象力，但在很多方面还不够成熟和完善。我们必须在快速迭代的过程中，时刻关注产品质量和用户反馈，不断打磨和优化我们的产品，让它尽快成长为一个稳定、可靠、易用的 SaaS 服务。

创新者阶段的 SaaS 企业还面临着资源限制和竞争压力的双重挑战。作为一家初创公司，我们在资金、人才、时间等方面的资源都非常有限。我们必须做出艰难的取舍，将有限的资源集中在最关键的创新点和最紧迫的问题上。同时，我们也必须时刻关注市场动态，警惕来自其他初创企业或成熟企业的竞争威胁。这就像是一场赛跑，我们需要在有限的资源下跑得更快、更稳、更远。这需要我们在产品开发、市场营销、客户支持等方面做到协调高效，需要我们的团队具备极强的学习能力、应变能力和执行力。只有这样，我们才能在激烈的竞争中脱颖而出，赢得用户的认可和市场的青睐。

面对这些问题，我们需要有一些做事的原则，在繁杂的问题中不至于走偏：

1. 用户至上：一切以用户的需求为中心。我们要深入了解用户，与他们建立信任和共鸣，让他们成为我们的坚实后盾。
2. 快速行动：创新者阶段的窗口期可能很短，我们必须抓住每一个机会。我们要快速做出决策，快速开发和迭代，不断推进产品的发展。
3. 拥抱变化：在这个阶段，变化是常态。我们要有灵活的思维，随时准备调整方向。我们要勇于接受用户的反馈，即使这意味着要推倒重来。
4. 追求卓越：即使是 MVP，我们也要力求做到最好。我们要在创新的同时，保证产品的质量和可用性。我们要为早期用户提供优秀的体验，赢得他们的信任和支持。

上面这些表述原则的词语看着挺虚的，但是却是我们在这个阶段做事过程中要秉承的原则。

当然，这些原则也不是仅适用于这个阶段，一些原则在其它阶段也会适用。

只有与早期用户建立起牢固的合作关系，我们才能真正实现产品的突破，为后续的发展奠定基础。

早期采纳者阶段

在早期采纳者阶段，创业者已经开始积累了一些客户，产品基本已经 SaaS 化，用户开始认识到 SaaS 产品的价值，并开始在他们的业务中实施。他们可能是行业内的意见领袖或早期采纳者，愿意分享他们的成功案例，从而吸引更多的用户。

这些用户大多数具有以下的特征：

• 更愿意尝试新技术的个人或企业。
• 在他们的社群或行业中具有影响力，可能是意见领袖。
• 寻找创新解决方案以获得竞争优势。
• 对产品尚不完善的部分有一定的容忍度，并愿意提供反馈。

SaaS 产品在这个阶段开始形成更加稳定的 SaaS 版本，同时保持创新性。产品开始解决用户更实际的业务问题，通过提供更好的用户体验、更多的功能和改进的性能。主要解决的问题是如何提供足够的价值驱动用户付费，并且建立品牌的信任度。

从产品层面，此时大概具备以下的特征：

• 更加用户友好，有明确的价值主张。
• 开始关注市场反馈，进行功能优化和迭代。
• 旨在解决特定行业或市场细分的问题。

从产研的角度，我们需要重点关注以下事项：

1. 提升产品价值：我们要深入了解早期采纳者的业务需求，不断优化和完善产品功能，提供更多的价值。我们要让用户真正感受到我们的产品能够帮助他们提高效率、降低成本、获得竞争优势。只有不断提升产品价值，我们才能驱动用户付费，实现商业上的成功。
2. 优化用户体验：早期采纳者虽然对产品的容忍度较高，但我们仍然要重视用户体验的优化。我们要简化产品的使用流程，提供直观的界面设计，完善产品的帮助文档和用户指南。我们要通过良好的用户体验，减少用户的学习成本，提高他们的满意度和粘性。
3. 重视客户反馈：早期采纳者是我们最宝贵的资源。我们要建立完善的客户反馈机制，通过多种渠道收集他们的意见和建议。我们要认真分析每一条反馈，深入了解用户的痛点和需求。我们要让用户感受到他们的声音被重视，他们的反馈被采纳，从而增强他们的认同感和归属感。

在这个阶段可能会面临比较多的问题，因为会服务于更多的客户，需求也会越来越多……

从技术架构的角度，随着用户数量的增长，我们的产品开始面临扩展性的挑战。我们需要确保我们的技术架构和基础设施能够支撑更大规模的用户访问和数据处理。 如果我们的产品无法平稳地扩展，就可能面临性能下降、服务中断等问题，影响用户体验和满意度。

从服务的角度，进入早期采纳者阶段后，SaaS 产品开始面临巨大的客户支持压力。这些压力主要来自三个方面：首先，随着客户数量的增加，支持工作的量级也成倍增长。其次，早期采纳者对产品和服务的期望值很高，他们希望能够得到最及时、最专业的支持。最后，随着产品功能的不断丰富，客户问题的类型也变得越来越多样化，对支持人员的技能要求越来越高。这就像是一个快速膨胀的气球，我们需要源源不断地输入新鲜空气，才能维持它的形状和张力。

但有一点我们经常会缺失，就是安全与合规性要求。早期采纳者中可能包括一些大型企业客户，他们对数据安全和隐私合规有着更高的要求。我们需要确保我们的产品符合行业标准和法规要求，并具备完善的安全防护机制。如果我们在这方面处理不当，可能面临法律风险和损失。

在做事的原则上，除了创新者阶段的原则以外，我们还可以增加以下的一些原则：

1. 持续创新：虽然我们的产品已经初具规模，但我们仍然要保持创新的精神。我们要紧跟技术发展的步伐，不断尝试新的解决方案。我们要在稳定的基础上，持续优化和创新，为用户提供更多的价值。
2. 数据驱动：我们要建立完善的数据分析体系，通过数据了解用户的行为，洞察用户的需求。我们要用数据说话，用数据做决策。我们要通过数据监控产品的健康状况，及时发现和解决问题。
3. 协作共赢：我们要与早期采纳者建立紧密的合作关系。我们要与他们共同成长，与他们共享成功。我们要通过与早期采纳者的合作，完善我们的产品，扩大我们的影响力。

从早期采纳者阶段到早期大众有着深深的鸿沟，他们在采用新产品时表现出截然不同的心理特征和行为模式。

早期采纳者以变革为驱动力，他们视创新产品为颠覆现状、获取竞争优势的利器，为此甘愿承担风险，并积极参与产品的优化迭代。

相比之下，早期大众追求的是在现有基础上的渐进式进步，他们期望新产品能与已有的技术体系无缝衔接，并稳定高效地运行，从而提升生产力和效率。他们希望在尽可能小的阻力下实现技术变革，不愿意承担过多的不确定性和潜在风险。

这种心理预期和行为特征的差异，反映了创新产品在不同市场渗透阶段所面临的采纳门槛和挑战。

企业要想成功跨越鸿沟，PMF 扮演着关键角色。它象征着产品与市场需求之间的完美契合，是产品成功实现商业化的基石。

PMF 的关键标志包括：

• 用户增长率：自发的口碑传播引发用户数量稳定增长。
• 高用户保留率：用户不仅试用产品还持续使用。
• 有能力为产品支付：用户认为产品提供的价值足以支付其费用。
• 市场反馈：用户反馈积极，有明显的需求和用户满意度。

找到 PMF 意味着企业已经发现了其产品在市场上的位置，并且可以开始专注于增长和扩张战略。这通常是在产品经过初步开发和迭代之后，企业开始理解哪些功能是用户真正需要的，哪些方面的产品体验能够带来用户的满意和付费。

在技术采用生命周期中，PMF 通常出现在创新者和早期采纳者之间，是过渡到早期大众之前的关键一步。一旦企业实现了产品市场契合度，它就处于较好的位置上，可以开始向早期大众和晚期大众推广其产品。

未来的研发、销售、定价、服务、培训等业务流程都应当围绕这些关键的契合点进行设计和调整。产品所满足的关键需求应该是清晰明确的，避免模糊不清的情况发生。这种方法隐含着一个策略选择，即可能需要临时搁置某些客户群体和需求的满足。

此外，确保已经建立了最小可行性闭环是至关重要的。对于面向企业的产品（toB），这意味着整个业务运作流程需要能够顺畅无阻碍地进行。

一个有效的策略是首先构建最小可行性闭环，随后将产品推向市场。产品应在与用户的互动过程中不断进步，与用户共同成长。用户能够在使用过程中目睹产品的持续改善，这不仅是一种高质量的体验，同时也是建立信任的重要途径。人们天生倾向于欣赏成长，有时甚至比个人成长更加欣赏见证他人或事物的成长历程。

早期大众阶段

早期大众阶段的用户需要产品更稳定、支持更好，且集成到现有系统中的风险更低。

随着 SaaS 产品的成熟和市场教育的深入，更多的企业开始认识到 SaaS 的优势，如成本效益、灵活性和可扩展性。这些用户开始采用 SaaS 解决方案，但仍然需要看到明确的证据，证明这些服务能够满足他们的需求。

这些用户大多数具有以下的特征：

• 他们通常比早期采纳者更为审慎，并且在采用新技术之前需要看到清晰的证据和效益。
• 这类用户可能不是技术先驱，但他们愿意采用经验证的新技术以提高效率或获得其他好处。
• 他们更加关注产品的稳定性、用户支持和性价比。
• 早期大众用户需要看到其他公司或行业同行已经成功采用该技术。

在这个阶段，SaaS 产品需要更加稳定和成熟，因为其现在面向的主流市场的需求，用户体量已经很大了。

此时的产品通常具有更完善的功能、更高的可靠性和更佳的用户支持。主要解决的问题是如何扩大市场份额，满足更广泛用户的需求，同时保持产品的易用性和高性价比。

从产品层面，此时大概具备以下的特征：

• 功能更全面，更好地集成到用户的现有工作流程中。
• 稳定性和可靠性提高，减少错误和宕机时间。
• 提供更多的客户支持和培训资源。

在早期大众阶段，产品的用户规模将大幅增长，系统面临更大的压力和挑战。如果产品的稳定性和可靠性无法满足用户需求，频繁出现故障或宕机，将直接影响用户体验和满意度，导致用户流失和负面口碑。这是我们在这个阶段面临的最大问题，需要我们在产品架构、性能优化、容错设计等方面投入大量精力，以确保产品能够稳定、可靠地运行。

同时，早期大众用户来自不同的行业和领域，他们对产品的需求和期望也各不相同。如何在有限的资源内，平衡和满足不同用户群体的需求，是我们面临的又一个重大挑战。我们需要深入了解不同用户群体的痛点和需求，并在产品规划和设计中做出权衡和取舍。同时，我们还需要应对不断变化的市场需求和技术趋势，及时调整产品策略和功能规划，以保持产品的竞争力和吸引力。

前面的产品稳定性和可靠性问题和用户需求多样化问题都会带来一些衍生的问题，如不够稳定或可靠，以及随着用户的大幅增长，我们将面临更大的客户支持和服务压力。早期大众用户对产品的熟悉程度和技术能力参差不齐，他们在使用产品时遇到问题时，往往需要更多的指导和帮助。如果我们的客户支持和服务体系无法及时、有效地响应用户需求，将直接影响用户体验和满意度，甚至导致用户流失。我们需要在客户支持和服务方面投入更多的人力和资源，建立完善的知识库和自助服务体系，并通过多种渠道和方式，为用户提供及时、专业的帮助和支持。

在早期大众阶段，SaaS 企业的成功依赖于能够有效地向更广泛的市场证明其产品的价值，并确保产品稳定、支持到位并能够满足不断增长的客户基础的需求。同时，这一阶段提供了通过增加市场占有率和建立品牌声誉来巩固市场地位的机会。

晚期大众阶段

在晚期大众阶段，SaaS 企业的方案已经成为行业内的主流选择。

它们已经成为行业标准，并且用户对这些服务的信任度很高。在这个阶段，SaaS 企业需要关注服务质量、客户支持和持续创新，以保持竞争力。

这些用户大多数具有以下的特征：

• 对新技术持保守态度，更倾向于在大多数人都接受后才采用。
• 他们可能更关注价格，寻求成本效益高的解决方案。
• 对技术变革的适应速度慢，需要更多地引导和支持。
• 这一阶段的用户往往更注重产品的实用性而非创新性。

在这个阶段，SaaS 产品已经非常成熟，并且通常是市场上的主流选择。产品需要解决的问题是如何维持市场地位，提供更高性价比的服务，并不断改进以对抗竞争对手。

从产品层面，此时大概具备以下的特征：

• 高度标准化，功能丰富，用户体验优化。
• 强调易用性和可访问性，以吸引不太技术熟练的用户。
• 价格可能更有竞争力，以吸引价格敏感的用户。

在晚期大众阶段，市场竞争日趋激烈，各种同类产品和服务不断涌现。如何保持产品的创新性和差异化优势，是我们面临的最大挑战之一。我们需要深入分析市场趋势和用户需求，不断推出新功能和服务，以满足不同用户群体的需求。同时，我们还需要在产品设计和用户体验方面进行创新，提供更加智能、个性化的服务，以区别于竞争对手。如果我们无法保持产品的创新性和差异化，将面临用户流失和市场份额下降的风险。

在这个阶段，我们的用户群体更加多样化，既有技术熟练的专业用户，也有技术能力较弱的普通用户。如何兼顾不同用户群体的需求，提供一致、优质的用户体验，是我们面临的另一个重大挑战。我们需要在产品设计中综合考虑不同用户群体的特点和需求，提供灵活、可配置的功能和界面，以及清晰、直观的操作流程和帮助文档。同时，我们还需要通过用户研究和数据分析，不断优化产品的易用性和可访问性，以提高用户满意度和留存率。

在晚期大众阶段，我们的客户群体更加庞大和多元化，对客户支持和服务的要求也更高。如何提供高质量、高效率的客户支持和服务，是我们面临的又一个重大挑战。我们需要建立完善的客户成功管理体系，为不同层次的客户提供差异化的支持和服务。同时，我们还需要建立多渠道、全天候的客户支持体系，提供及时、专业的技术支持和问题解决服务。如果我们的客户支持和服务质量无法满足用户需求，将直接影响用户体验和满意度，甚至导致用户流失和负面口碑。

从技术的角度，我们需要进一步提高产品的稳定性、可靠性和安全性。在这个阶段，产品已经成为行业标准，用户对产品的依赖程度很高，任何服务中断或数据安全问题都可能导致严重的后果。因此，我们要继续优化产品架构，加强容错设计和故障恢复能力，确保产品能够持续、稳定地运行。同时，我们要建立完善的数据安全和隐私保护机制，严格遵守相关法律法规和行业标准，保护用户数据的机密性和完整性。

在晚期大众阶段，SaaS 企业需要聚焦于巩固现有市场地位，提高运营效率，增强客户忠诚度，并在可能的情况下寻找市场细分领域以实现增长。此时，企业通常需要在保持竞争力的同时优化成本结构，确保长期的盈利能力。

落后者阶段

在落后者阶段，面对的用户通常是出于必要而非选择。他们对新技术不感兴趣，可能是因为对新技术不信任或是对变化有抵触感。但当他们的客户和合作伙伴已经转向了 SaaS 解决方案时，他们也会使用 SaaS 产品。

这些用户大多数具有以下的特征：

• 极为保守，可能由于成本、技术恐惧或是对变化的抗拒而迟迟不愿采用新技术。
• 他们通常在等待产品成为市场标准或者完全无法避免采用时才会改变。
• 这类用户可能对技术不太熟悉，需要额外的教育和支持才能使用新系统。
• 他们可能更信任长期存在的解决方案和传统的做事方式，而不是新兴的技术。

这个阶段的 SaaS 产品通常是行业标准，具有很高的稳定性和可靠性。产品需要解决的问题是如何持续吸引那些对新技术抗拒感强的用户，通常需要通过更好的客户服务、产品的简化和成本优化来实现。

从产品层面，此时大概具备以下的特征：

• 极致地简化和优化，以降低使用复杂性。
• 提供额外的个性化服务，以满足特定客户群体的需求。
• 可能需要提供更多的本地化服务和支持。

在落后者阶段，我们面对的用户大多对新技术不感兴趣，甚至存在排斥和抗拒心理。他们可能由于成本考虑、技术恐惧或是对变化的抗拒而迟迟不愿采用新技术。如何提高这部分用户对 SaaS 产品的接受度和认知，是我们面临的最大挑战之一。我们需要通过各种渠道和方式，向用户普及 SaaS 的优势和价值，消除他们对新技术的疑虑和抗拒感，同时提供简单易用、稳定可靠的产品，降低用户的使用门槛和学习成本。

在这个阶段，我们面对的用户群体可能非常多样化，他们来自不同的行业、地区，有着不同的业务场景和使用习惯。如何为这些用户提供个性化的服务和支持，满足他们的特定需求，是我们面临的另一个重大挑战。我们需要深入了解不同客户群体的特点和需求，提供差异化的服务和支持，例如为重要客户或特殊行业提供专属的客户成功经理和技术支持团队，为不同地区的用户提供本地化的服务和支持等。这需要我们在客户服务和支持方面投入更多的资源和精力。

在落后者阶段，我们面对的用户对成本非常敏感，他们可能更信任长期存在的解决方案和传统的做事方式。如何在保证产品质量和服务水平的同时，不断优化成本，提供有竞争力的价格，是我们面临的又一个重要挑战。我们需要从产品架构、运营模式等方面入手，通过技术创新和流程优化，提高资源利用率和自动化水平，降低运营成本。同时，我们还需要提供灵活、多样的定价模式和服务方案，让用户能够根据自己的需求和预算选择合适的服务。

在落后者阶段，SaaS 企业需要特别关注市场教育、客户支持和产品的易用性。尽管这一阶段的增长空间有限，通过精细化管理和优化产品，企业仍然可以在市场中找到利润和维持稳定的客户基础。此时，关注客户的长期价值和满意度可能比追求快速增长更为重要。

小结

SaaS 产品的生命周期与技术生命周期密切相关，不同阶段的用户需求和产品特点都有所不同。在早期市场阶段，SaaS 产品需要专注于创新和差异化，吸引技术爱好者和早期采用者。随着产品进入主流市场，重点应转向提高产品的易用性、可靠性和性价比，以吸引务实主义者。在晚期大众阶段，SaaS 产品已成为行业标准，需要持续创新和优化用户体验，维持竞争优势。而面对落后者时，产品需要极致简化，并提供个性化服务和支持，以降低使用门槛。

SaaS 业务的核心在于长期积累复利效应，这是其区别于其他追求指数级增长模型的关键特征。随着时间推移，续费收入将成为 SaaS 企业收益的重要组成部分，而成长性收入（即客户业务增长带来的收入）也将贡献更高的毛利率。这种模式意味着 SaaS 企业需要在产品研发和客户服务上持续投入，深入了解并满足客户需求，不断优化产品和服务，以实现长期价值的积累和复利效应。

因此，SaaS 产品的产研逻辑需要兼顾技术生命周期的特点和长期积累复利效应的本质。在产品研发过程中，要根据不同阶段用户的需求和期望，制定相应的产品策略和优先级，同时要建立完善的客户反馈机制和数据分析体系，持续跟踪和优化产品性能。在客户服务方面，要提供全生命周期的支持和服务，帮助客户充分实现产品价值，提高续费率和满意度。只有在产品研发和客户服务两个维度上持续发力，SaaS 企业才能真正实现长期可持续的增长和盈利。

我将整个复盘报告输入给到 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. 定期回顾和重构：随着时间的推移和需求的变化，我们可能需要调整或简化现有的设计。定期回顾我们的代码和设计可以帮助我们找出可以简化的地方。

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

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

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

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

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

指标是什么

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

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

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

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

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

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. 增强信息保护意识：作为一个好传声筒，个人在处理信息时会更加注重信息的安全和隐私，增强了信息保护意识。

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

小结

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

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

如何有效的管理团队已经成为企业成功的关键因素之一。特别是在技术团队，在管理过程中都面临一些共性问题，如沟通不畅、目标不明确、流程混乱、人才流失等等。这些问题在很大程度上影响了团队的效率和产出。

针对这些问题，我们将在本文中探讨什么是团队，团队的发展过程，以及如何有效的管理团队。

1 什么是团队

1.1 定义团队

从定义上来看，团队是为了达成某一承诺的共同目标而相互协作的一群人。

团队可以被定义为一组由个体组成的实体，这些个体共享共同的目标，对其达成负有责任，并通过相互协作以实现这些目标。这个定义包含了团队的两个关键特性：目标的共享性和协作的必要性。

1. 共享的目标：团队的成员都应该对共同的目标有清晰的理解，并对达成这些目标有共享的承诺。这可能是完成一个项目，解决一个问题，或者达到一个业绩目标。这种对目标的共享理解和承诺为团队提供了方向，并保证了所有成员都在努力的推动团队向着同一方向发展。
2. 相互协作：团队的成员需要通过相互协作来达成这些目标。这可能涉及到分工协作，相互学习，以及共享资源和信息等行为。相互协作不仅可以提高团队的效率，也能促进团队成员之间的关系，增强团队的凝聚力，从而提高团队的整体效能。

除此之外，还有相互依赖、尊重、信任和有效的沟通。

1.2 团队是一个开放系统

从整体上来看，团队是个动态复杂的开放系统

团队是由多个相互依赖、相互影响的部分组成的，这些部分包括团队的成员、团队的结构、团队的目标，以及团队的工作流程等。团队的各个部分都是动态的，都会随着时间和环境的变化而变化。其拆解来看可以分为三部分：

1. 动态： 团队的状态和行为会随着时间改变。这可能是由于团队成员的交互、团队成员的更换、新的任务或目标的设定，或者团队成员的个人成长和发展。

2. 复杂： 团队的行为和效能不仅取决于个体成员的行为，还取决于这些成员之间的交互和关系。因此，理解和管理团队需要考虑到这种复杂性。

3. 开放系统： 团队不是孤立存在的，而是和周围的环境相互作用的。这可能包括其他团队、组织的其他部分、组织的领导、客户、供应商、法规和社会文化等。这些外部因素都可以影响团队的行为和效能。

1.3 团队组成框架

从组成框架来看，团队包括 PCP、SCP 和 ICP 三个层面

任务程序（PCP）、社会程序（SCP）和个体程序（ICP），这三个层面共同构成了团队的基本框架，它们互相交织、互相影响，共同推动了团队的运行和发展。

1. 任务程序（PCP）：任务程序是团队为了实现共同目标而进行的工作流程和规范。这可能包括任务分配、决策制定、问题解决等一系列的工作程序。一个有效的任务程序可以提高团队的效率，确保团队的工作有序进行，帮助团队成功地完成其目标。
2. 社会程序（SCP）: 社会程序是团队中的人际交往和沟通方式，它决定了团队内部的氛围和文化。有效的社会程序可以增强团队的凝聚力，提高团队成员的工作满意度，促进团队成员之间的良好关系。一些如决策程序、冲突解决机制和团队建设活动等，都是社会程序的重要组成部分。
3. 个体程序（ICP）:个体程序是指团队成员各自的行为模式和工作方式，它受到各个成员的个性、技能、经验等因素的影响。团队成员的个体程序会影响到团队的整体效能，因此，管理者需要关注团队成员的个体程序，尽可能地提供适合各个成员的工作环境和条件，以发挥他们的潜力。

总的来说，团队可以被视为一个由任务程序、社会程序和个体程序共同构成的复杂系统。这个系统中的各个部分都是相互关联、相互影响的，只有当这三个部分都有效地运作时，团队才能够高效地运行，成功地实现其目标。

2 团队管理的发展过程

我们常用的团队模型包括 Bruce Tuckman 的团队发展模型，Hersey-Blanchard 情境领导理论，Drexler/Sibbet 团队绩效模型。这三个模型各有偏重：

• Tuckman 的模型主要是为了解决团队成长过程中的冲突和团队动态问题。它帮助团队理解团队发展的自然进程，并通过理解各个阶段的特点，来更好地应对团队中出现的冲突，提高团队合作的效率。
• Hersey-Blanchard 模型的重点是领导风格如何应对团队成员的成熟度变化。它主要解决的是领导者如何根据团队成员的成熟度和能力级别，灵活地改变自己的领导风格，以激励团队成员，提高团队效能。
• Drexler/Sibbet 模型着重于团队的任务完成和效能提升。它解决的主要问题是如何通过明确的目标设定、建立信任、承诺和高效协作，帮助团队在完成任务的过程中提高效率和效果。同时，它也强调了团队在项目结束后的反思和更新。

这里我们主要是根据 Bruce Tuckman 的团队发展模型来看团队的发展过程。

2.1 团队发展模型

Bruce Tuckman 的团队发展模型是一种描述团队从最初形成到最终达到高效运作的理论模型。这个模型最初在 1965 年被 Tuckman 提出，原本包含四个阶段：形成、激荡、规范和执行。然后，在 1977 年，Tuckman 和 Mary Ann Jensen 添加了第五个阶段：解散/休整。

以下是这五个阶段的详细描述：

2.1.1 形成阶段

在形成阶段，团队成员刚刚被组织在一起，他们可能对团队的目标、结构和领导者感到不确定或不安。成员们可能会表现得比较矛盾，既希望被接纳，又害怕过度投入。通常，成员们会对领导者寻求指导和明确的指示。

在此阶段，主要解决的问题是团队成员的熟悉和初步建立关系。团队成员可能会对彼此、团队的目标和期望、以及他们在团队中的角色感到不确定。这个阶段要解决的问题包括：

• 什么是我们的团队目标？
• 我们每个人的角色和职责是什么？
• 如何分配和管理任务？
• 我们的工作流程和通信方式是什么？
• 我们如何决定和解决问题？

针对这些问题，我们有一些常用的应对策略：

• 生命地图：这是一种让团队成员分享他们的个人历史和经验的方法，让大家更好地了解彼此，建立信任和熟悉度。
• MBTI：MBTI（Myers-Briggs Type Indicator）是一种性格类型指标，由凯瑟琳·库克·布里格斯和她的女儿伊莎贝尔·布里格斯·迈尔斯在二十世纪中叶创立。这种指标基于荣格的心理类型理论，用于评估个体的性格特质和倾向。通过使用 MBTI，我们可以理解团队成员的个性类型，这有助于增进团队内的理解和接纳。
• 团建活动：通过组织团队建设活动，我们可以通过共享的经验和挑战来增强团队的凝聚力。俗一点，喝点小酒不错，不俗一些，可以一起搞点事情，比如一起解决某个问题。
• 新成员欢迎仪式：通过举行欢迎新成员的仪式，可以让新成员感到被接纳和重视。
• 团队画像：提供一个框架，帮助团队成员理解和识别团队整体特征、动态和关系的工具。它可以是一幅图像，一张图表，或者一个模型，描绘出团队的结构，成员的角色，团队的目标，以及团队中的关系和互动等。

2.1.2 激荡阶段

在激荡阶段，随着团队成员开始表达个人观点，冲突可能会开始出现。团队成员可能会对团队的目标、任务分配、工作方法或团队的领导产生分歧。这个阶段可能会有所挫折，但也是团队发展的重要阶段，因为它可以帮助清晰地定义团队的方向和结构。

在此阶段，主要解决的问题是团队内部的冲突和分歧。团队成员可能会对团队的目标、工作方式或他们在团队中的角色产生分歧。这个阶段要解决的问题包括：

1. 职责和角色的定义：团队成员对自己的角色和职责是否有清晰的认识？是否存在角色冲突或不清晰的地方？

2. 决策制度：团队有明确的决策流程吗？谁有权做重要决定？团队成员是否对这一流程感到满意？

3. 沟通效率：团队的沟通是否畅通？是否存在信息传递不准确或不完全的情况？

4. 冲突解决机制：团队内部出现冲突时，有明确的解决机制吗？成员们是否知道如何提出和解决问题？

5. 团队文化和价值观：团队的价值观是否明确？成员们是否接受并认同这些价值观？

6. 信任和尊重：团队成员之间是否存在足够的信任和尊重？是否有开放的、支持性的环境，让成员们能够表达自己的观点和感受？

7. 团队合作：团队成员是否能有效地合作？是否有明确的工作流程和配合机制？

针对这些问题，我们有一些常用的应对策略：

• 团队委任状：通过明确团队的目标、角色和工作方式，可以帮助团队达到一致。
• 团队原则：团队成员共同确定的行为准则和期望，这有助于他们更有效地协作。
• 1 对 1会议：通过私人会议，可以促进直接的沟通和反馈，增强信任和理解。
• 情感银行：通过积极的行为和互动，可以建立和保持信任，这是团队协作的重要基础。
• 处理冲突：使用各种冲突解决策略来处理团队内部的分歧和冲突。
• 建设性反馈：团队成员需要学习如何提供和接受反馈，这对改进工作效率和团队关系至关重要。
• 双赢思维：鼓励团队成员寻找既能满足所有人需要又能满足个人需求的解决方案。

2.1.3 规范阶段

在规范阶段，团队成员开始解决在激荡阶段出现的冲突，并开始建立更深的相互理解和协作。团队成员开始对团队的目标、角色和工作方式达成一致。团队凝聚力增强，团队成员开始更加尊重彼此，建立更强的关系。

在此阶段，主要解决的问题是团队的凝聚力和工作方式。团队成员开始形成一种共享的工作方式和行为准则。这个阶段要解决的问题包括：

1. 如何建立并维护有效的团队规则和行为规范？
2. 如何设计和实施有效的沟通机制以保证信息的准确及时传递？
3. 如何提供具体且有效的反馈，促使团队和个人的持续发展？
4. 如何监控和调整团队的工作效果以及内部的关系和氛围？
5. 当团队或个人取得成就时，应如何进行有效的庆祝和认可以提高团队的凝聚力和动力？

针对这些问题，我们有一些常用的应对策略：

1. 创建并传播团队原则和规则：建立清晰、明确的团队原则和规则是创建健康团队文化的关键。这些原则和规则应该包括团队的使命、价值观、行为标准以及决策流程等内容。所有团队成员都应参与到创建过程中来，这样可以确保这些原则和规则得到大家的认同。一旦原则和规则确定，就需要通过各种方式（比如团队会议、内部通讯等）在团队中进行传播，并在日常工作中持续实施和维护。

2. 提供及时的反馈并处理冲突：反馈是提升团队效率和效果的重要工具。建设性反馈应该是具体的、积极的，旨在帮助团队成员改善工作效果和个人发展。1 对 1的沟通机制可以提供一个私密的环境，让团队成员能够分享他们的观察、想法和感受。如果出现冲突，应立即进行处理。处理冲突的过程应以理解和解决问题为目标，避免指责和争吵，寻求双赢的解决方案。

3. 庆祝成功和成就：庆祝仪式是提高团队士气和增强团队凝聚力的有效方式。当团队或团队成员达到一定的目标或取得了显著的成就时，应进行适当的庆祝和认可。庆祝的方式可以多种多样，比如组织团队聚餐、颁发证书或奖杯、公开表扬等。重要的是，庆祝应该是真诚的，要让团队成员感到他们的努力和贡献得到了认可。

2.1.4 执行阶段

这是团队发展的最后一个阶段，团队已经达到了高效运作的状态。在这个阶段，团队成员能够自我管理，解决冲突，并且能够有效地完成任务。团队的目标已经很清晰，所有的团队成员都对此有深入的理解，他们都为达成这个目标而努力工作。

在此阶段，主要解决的问题是团队的效能。团队已经形成了一种有效的工作方式，并且能够高效地完成任务。这个阶段要解决的问题包括：

• 如何保持和提高团队的效能？
• 如何适应和应对新的挑战和变化？
• 如何确保每个人都能持续地学习和发展？

针对这些问题，我们有一些常用的应对策略：

• 教练技术：通过使用教练技术，可以帮助团队成员提高他们的技能和效率，从而提高团队的效能。
• 更新团队规则：团队的发展和变化可能需要我们更新团队的工作方式和期望。
• 授权：团队领导人可以让团队成员有权做出决策，这样他们能更好地完成任务和承担责任。

2.1.5 休整阶段

这是 Tuckman 和 Jensen 后来添加的阶段。在这个阶段，项目或任务完成后，团队开始解散。团队成员可能会对团队的解散感到不安，尤其是当他们在团队工作中建立了强烈的归属感和相互依赖时。这个阶段的关键是确保团队的努力和成果得到认可，同时支持团队成员进行过渡。

在此阶段，主要解决的问题是团队的结束和转变。当团队的任务或项目结束时，团队可能需要解散或进行重组。这个阶段要解决的问题包括：

• 如何处理团队成员的情绪和反应？
• 如何确保团队的知识和经验能够被保留和传递？

需要注意的是，这个模型并不是严格线性的，团队可能会在不同的阶段之间来回移动，甚至可能会跳过某些阶段，或者同时具备两个或多个阶段的特点。

2.2 领导者的成长阶段

以上是团队的发展过程，对一个团队的管理者来说，也有一个类似的发展过程，用《礼记·大学》中我们特别熟悉的一句话来概括就是：「修身齐家治国平天下」。这是一句讲自我修炼，一生成就的四个阶段，将其映射到团队领导者的成长上看，也是适用的。

1. 修身（个人）： 在这个阶段，重点是发展个人能力。这包括技术知识、专业技能、时间管理、沟通、解决问题的能力等。个人也需要建立自我驱动和自我学习的习惯，这样他们可以不断地学习新的技能和知识。

2. 齐家（团队）： 当从个人转向团队的角色时，需要发展一种新的技能集。这包括领导力、决策能力、团队建设、冲突解决、激励和教育团队成员等。领导者需要从个体视角转向集体视角，思考如何提高团队的整体效能，而不仅仅是提高个人的产出。

3. 治国（组织）： 当领导者从团队管理转向组织管理时，他们需要开始考虑更为复杂的问题。这包括组织战略、组织结构、文化建设、财务管理、风险管理等。领导者需要考虑如何建立和维护一个高效、稳定、健康的组织。

4. 平天下（行业/社会）： 在这个阶段，领导者需要考虑他们的组织如何影响更大的社会和行业环境。这涉及到公共政策、行业标准、社会责任等问题。领导者需要考虑如何利用他们的影响力来推动行业的发展，以及如何通过他们的决策和行动来产生积极的社会影响。

每一个阶段都需要领导者具备不同的技能和认知，领导者需要根据不同的角色和责任来适应和发展。

3 有效的团队管理

有效的团队管理是指通过一种系统化的方式，领导一个团队，运营之，以实现既定的目标。这包括以下几个关键要素：

1. 明确的目标：团队需要有一个明确和共享的目标或愿景，以指导其工作和决策。

2. 卓越的领导：团队需要有一个或多个能够激励和指导团队的领导者。这包括设定明确的期望，提供反馈，处理冲突，以及帮助团队应对挑战。

3. 明确的角色和责任：每个团队成员需要明确他们的角色和职责，以确保所有的任务都能得到有效的处理。

4. 良好的沟通：团队需要有良好的沟通机制，以促进信息和想法的分享，解决问题，以及提高团队的协调性和效率。

5. 有效的系统和流程：团队需要有一套有效的系统和流程来支持其日常运作。这可能包括决策制定的流程，任务管理的工具，以及反馈和评估的机制等。

6. 良好的团队关系：团队成员之间需要有良好的工作关系，以提高团队的凝聚力和满意度。

将其概括一下，就是包括方向，领导力、角色分工、系统、沟通和关系六个方面。这六点是基础，在此基础上，有效的团队管理也需要有适应性和灵活性，以应对不断变化的环境和挑战。这可能包括调整团队的目标，改变工作方法，以及提供持续的学习和发展机会等等。接下来我们从这六个方面来阐述如何有效的管理团队。

3.1 方向

带团队如大海行舟，方向是第一要务。为什么要有方向，因为当所有人都对方向有共同的理解，并且同意并承诺支持这个方向时，他们有更大概率的有效地合作，并积极地向目标前进。

方向主要关注三个问题：团队的目标和战略是否明确？每个团队成员是否理解并认同这些目标和战略？团队的目标是否需要随着环境的变化进行调整？

方向在团队管理中非常重要，原因有以下几点：

1. 共享目标：一个明确的方向为团队提供了一个共享的目标或愿景。这可以帮助团队成员理解他们的工作为何重要，以及他们的努力如何帮助团队实现其目标。

2. 决策指导：方向也提供了一个框架，用于指导团队的决策和优先事项。团队成员可以根据团队的目标来决定他们应该如何分配资源，选择哪些任务，以及如何执行这些任务。

3. 提高凝聚力：当团队成员对团队的方向有共同的理解和认同时，他们可能会感到更加投入和满足。这可以提高团队的凝聚力和满意度。

4. 提供动力：明确的方向也可以为团队提供动力。团队成员知道他们正在追求的目标，了解他们的工作如何贡献于这个目标，这可以激发他们的积极性和热情，将从被动执行任务变为主动推动目标的实现。

5. 测量进度：最后，方向可以帮助团队测量其进度和成效。通过比较当前的状态和目标，团队可以了解他们在实现目标方面的进度如何，以及他们是否需要改变策略或方法。

在我们做战略沟通，或者在探讨方向时，需要考虑以下三个方向：

• Why：为什么我们要这样做？这通常涉及到组织的使命、愿景或核心价值观。
• What：我们要做什么？这是具体的目标或战略。
• How：我们如何做到这一点？这包括实施战略的具体步骤或方法。

要想达成方向的一致，有许多方法，我们常用的方法如下：

1. 一对一讨论： 领导者可以与每个团队成员单独会面，讨论并达成共识。

2. 集体共创： 可以组织工作坊或大会，让所有人都有机会参与讨论和决策。

3. 单方宣导： 在某些情况下，领导者可能需要明确阐述他们的观点，并期望团队成员接受和支持。

无论选择哪种方式，最重要的是确保每个人都有机会表达他们的观点，并且他们的观点被认真考虑。这样才能保证达成真正的共识，而不仅仅是表面的一致。

3.2 领导力

经常有人说「领导者决定了团队的基因」，这说明领导者的行为、决策、态度、价值观和领导风格对团队的特质和行为有着重大影响。就像基因决定了生物的特性一样，领导者的特质和行为也可以决定团队的「特性」。其主要体现在以下 4 个方面：

1. 设定价值观和期望：领导者通常会设定团队的价值观和期望，这些价值观和期望形成了团队文化的基础。例如，如果领导者重视创新和风险承受能力强，那么团队可能也会发展出一种鼓励尝试新事物和接受失败的文化。

2. 塑造行为和决策：领导者的行为和决策模式对团队成员有示范作用。例如，如果领导者以开放和透明的方式进行决策，那么团队成员也可能会采取同样的方式。

3. 激励和驱动：领导者通过他们的激励策略影响团队的动力和表现。如果领导者激励团队成员追求卓越和持续改进，那么这可能会成为团队的一个核心驱动力。

4. 选择和发展人才：领导者在招聘和发展人才方面的决策也会影响团队的特性。例如，如果领导者倾向于招聘具有强烈团队精神和合作能力的人，那么整个团队可能也会具有这些特性。

在领导者改变团队的过程中，领导的领导力是一个非常重要的因素，在团队管理和组织成功中扮演着重要的角色。

当你在管理岗位上时，看看以下的一些陷阱你有没有遇到过：

1. 过度放权或忽视领导职责：领导者有时可能会过度放权，以至于放弃了领导权力，并忽略了团队管理的各种要素，如ICP/SCP/PCP（Input/Control/Process）。可能过于乐观地认为，只要给团队足够的自由，一切都会按计划进行。然而，这是一种误解。领导者不仅要放权，还要根据团队的成熟度正确使用权力，以及情景管理。我们应该与团队一起工作，帮助解决难题，而不是完全放手。

2. 以自我为中心，忽视团队需求：领导者可能过于关注自己的想法和目标，而忽视了团队的需求和感受。可能把人性假设得太理想化，缺乏对团队的爱和耐心。领导者应该以团队的理解和需求为出发点来进行沟通和赋权。他们也应该愿意为提高团队的能力付出努力，包括必要时进行人员调整。

3. 过度依赖自我思考，忽视团队输入：领导者可能会认为自己已经清楚了解了所有问题，结果导致团队成员只是执行者，没有参与决策的机会。这种做法可能会阻碍团队成员的发展和创新。领导者应该把团队成员视为平等的伙伴，愿意花时间进行沟通和同步，并相信他们具有巨大的潜力。

4. 过度参与执行，忽视领导职责：有些领导者可能过于关注执行任务，以至于忘记了他们的领导职责。他们可能会在周会上跟进每项任务，但忽视了作为领导者的责任，包括设定战略，提供支持，和激励团队。领导者应该意识到他们是团队的扩大器，他们的主要职责是领导和赋能，而不仅仅是执行任务。

5. 避免冲突：领导者可能会避免处理团队之间的冲突，以希望保持和谐。然而，未解决的冲突可能会升级，影响团队的士气和效率。领导者应该勇于面对和解决冲突，而不是避开它。

6. 过度承诺：有些领导者可能会对团队成员或者与他们合作的人过度承诺，这可能会导致资源过于紧张，或者在无法达到承诺的时候失去信任。领导者应该明白他们的能力范围，并理性地做出承诺。

7. 忽视个人发展：领导者可能过于专注于团队的目标，而忽视了他们自己的个人成长和发展。这可能导致他们的技能和知识变得过时，无法有效地领导团队。领导者应该意识到，他们自己的发展同样重要，他们需要不断地学习和提高。

8. 忽视人才培养：领导者可能过于关注短期的目标，而忽视了人才的培养。这可能导致团队的长期发展受到限制。领导者应该投资于人才的培养，为团队的未来做好准备。

9. 抵制变革：领导者可能对变革持防御态度，尤其是当这些变革可能影响他们的权力和舒适区时。然而，变革是必要的，领导者应该积极接受并驱动变革，以变化应对不断变化的环境。

每个领导者都可能面临这些陷阱，关键在于认识到它们，然后采取行动来避免或者克服它们。避免这些陷阱需要领导者具有深度的自我认识，对团队的尊重和理解，以及对长期目标和策略的清晰理解。

那么，领导力是什么？

领导力是一种复杂的能力，包含多个层面。领导作为团队绩效的放大器，他们的作用和影响占团队成功要素的 70%，他们的角色既不是独自承担所有工作，也不是放任不管，而是负全责。领导力有一个基本框架，可以分为以下 6 个层面：

1. 战略层面：这涉及到制定和实施长期目标和策略，以及识别和适应外部环境的变化。领导者在这个层面需要展示出前瞻性和战略性思考。

2. 人际层面：这涉及到与团队成员、客户、合作伙伴等各方进行有效的沟通和协作。领导者在这个层面需要展示出强大的沟通、协调和冲突解决能力。

3. 任务层面：这涉及到设置和实现具体的目标，以及管理和分配资源。领导者在这个层面需要展示出强大的组织、规划和执行能力。

4. 发展层面：这涉及到培养和发展团队成员，以及自我学习和成长。领导者在这个层面需要展示出教育、指导和激励他人的能力，以及开放性和学习意愿。

5. 情绪层面：这涉及到理解和管理自己和他人的情绪。领导者在这个层面需要展示出较高的情商，包括自我意识、自我管理、社会意识和关系管理。

6. 变革层面：这涉及到驱动和管理变革，以适应不断变化的环境。领导者在这个层面需要展示出创新思维、灵活性和适应性。

换成宝洁的 5E 领导力模型来描述，即：高瞻远瞩(Envision)，凝聚他人(Empower)，发展他人(Encourage)，激励人心(Educate)，和高效执行(Evaluate)。

1. 高瞻远瞩（Envision）： 领导者需要有构建愿景的能力，能够给整个组织指明方向，激发团队内心的激情。好的愿景应该符合外部市场、用户和业务现阶段的需求，有足够的力量解决业务目前面临的根本问题，并且不只是口号，而要有实际的行动路线。要设计一个好的愿景，可以参照行业标杆，找出关键路径，建立 KPI。领导者需要清晰、有说服力地表述这个愿景，并展示出他们如何带领团队实现这个愿景。

2. 凝聚他人（Engage）： 领导者需要将员工、同事、客户甚至老板纳入自己的愿景达成梯队，让每个项目的所有参与者都把这个项目当成重要的项目。在这个过程中，需要保持开放的沟通，同步进展和规划，让每个人都有机会了解项目的全局情况并参与其中。这包括倾听他人的观点，尊重和理解他们的需求，以及鼓励他们在实现共同目标的过程中扮演积极的角色。

3. 发展他人（Enable）： 领导者需要确保团队有信心、有能力、有精力来做好自己的那部分工作。这包括提前告知工作需求和意义，提供全面的信息，及时提醒需要的方向调整，以及在可控的范围内给予团队犯错和改进的机会。

4. 激励人心（Energize）： 无论困境逆境，领导者需要保持团队的斗志。这可以通过保持积极的态度，使用幽默来化解压力，及时庆祝小胜利，反馈表扬，以及了解并回应每个人的想法来实现。

5. 高效执行（Execute）： 领导者需要保证任务的完美执行。这包括梳理工作，做好分配和排期，让每个人都有机会参与，不遗余力地寻求帮助，以终为始，及时检查里程碑，以最终体验为目标。

作为一名领导者，需要持续的自我反思和对团队的深深关爱，时刻反思 ，时刻反思自己的行为和决定，以确保它们都是以团队的最佳利益为导向的。这意味着你需要放下自我，优先考虑团队的需求和利益。在决策时，你需要考虑的是决策对团队的影响，而不仅仅是对自己的影响。此外，你需要建立一个开放和透明的环境，鼓励团队成员提供反馈，以帮助你更好地理解他们的需求和期望。

同时许以 严格的爱。严格的爱是建立在对标准、规则和期望的坚持上的。这意味着你需要设定明确的期望，使团队知道他们需要达到什么样的标准。你也需要坚持规则和程序，确保所有的工作都按照既定的方式进行。同时，你需要提供及时和具有建设性的反馈，帮助团队成员理解他们需要如何改进。在这一过程中，你也需要给予团队成员必要的支持和关心，以帮助他们达到这些标准。

如 Python 中的「鸭子模型」：如果一个对象能够完成你需要的操作（也就是它“走起来像鸭子，叫起来像鸭子”），你就可以把它当作鸭子来对待（即不在乎它的真实类型或类别）。

如果你像领导者一样思考，像领导者一样讲话，像领导者一样行动，那你就是一个合格的领导者。

3.3 角色和分工

在有效的团队管理中，角色和分工十分关键。明确的角色和分工可以确保团队的高效运作，减少重复工作和冲突，同时也能让每个团队成员明确自己的责任和期望。

首先，我们需要根据团队的战略和核心任务来规划组织结构，即「先岗再人」的原则。这一步包括：

1. 基于战略和核心任务的组织规划：在招募团队成员之前，我们需要首先明确团队的目标和任务，以确定所需的角色和这些角色在组织中的位置。

2. 任务性质和管理范围的团队分工和分层：根据任务的性质和管理范围来决定团队的结构和角色分配。这样可以帮助每个人清楚地理解他们的职责和与其他团队成员的关系。理解团队分工和分层就像是在打造一支足球队。首先，你需要了解比赛的规则和每个位置的特点（任务性质）。例如，守门员的任务是防守，而前锋的任务是进球。然后，你需要决定哪个球员去打什么位置（团队分工）。这取决于他们的技能和才能，以及他们与其他球员的协作方式。你还需要了解每个位置在球场上的位置（管理范围）。例如，队长可能需要管理全队的战术，而边锋可能只需关注自己的区域。最后，你需要明确哪些位置是领导位置，哪些位置是执行位置（团队分层）。例如，队长和教练需要做战略决策，而前锋和中场球员需要执行这些决策。

3. 明确关键岗位：我们需要确定哪些是关键岗位，这些岗位在实现团队目标和任务上起着决定性的作用。

接着，我们要遵循「强将精兵高产出」的效率原则，以提高团队的效率：

1. 强将是核心：强将被视为团队或组织的核心，因为他们拥有推动力、领导力、专业知识和技能，同时他们的行为和态度常常被其他团队成员视为模范。他们不仅能推动团队前进，提供专业的解决方案，还能通过他们的领导力引导和协调团队的工作。另外，他们的存在为团队提供了稳定性和信任，特别是在面对挑战的时候，他们的冷静和果断能帮助团队保持稳定并继续前进。

2. 精兵至关重要：精兵是团队或组织的重要组成部分，他们的专业技能、执行力、稳定性和团队协作能力对于团队的成功起到了关键的作用。他们不仅能以高效和质量的方式完成任务，提升整个团队的效率，也通过他们的纪律性和可靠性为团队提供了稳定性。同时，他们的协作精神让他们能够与团队中的其他成员携手合作，共同推动团队的进步。并且，他们的专业性和忠诚度也使他们成为未来领导角色的有力候选人。

最后，当团队规模越大，结构越复杂时，我们更需要重视核心团队的建设和分层管理，以形成像涟漪一样向外扩散的效应，拆解下来分为三个关键点：：

1. 核心团队的建设：随着团队规模的扩大和结构的复杂化，建设一个强大的核心团队变得越来越重要。核心团队的成员应具有关键的角色或岗位，并且能够对组织的目标和决策产生直接影响。

2. 分层管理：应使用分层管理的方式来应对团队规模的增长和结构的复杂化。每一层都有自己的职责和管理者，以保持信息流和决策过程的效率。

3. 涟漪效应：一个强大的核心团队和有效的分层管理系统可以在整个组织中产生积极的影响，就像在水面上投下一颗石子会产生涟漪一样。可以提高整个团队的效率和生产力。

随着团队规模的增长和结构的复杂化，我们应更加重视核心团队的建设和分层管理，以实现有效的组织管理和协同工作，从而产生涟漪效应，提高整个团队的效率和生产力。

3.4 系统

这里的所说的系统是一种整体观念，强调整体大于部分之和，部分之间的互动关系对整体的性质和功能有决定性的影响。以系统观来解决问题。

系统可以理解为一套组织的流程、规则和机制，这些流程、规则和机制协同工作，以实现组织的特定目标。系统观强调整体性和协同性，而不仅仅是单个流程或机制。

有效的团队管理中的系统，包括了流程（如工作流程、决策流程）、规则（如政策、规章制度）和机制（如奖励机制、反馈机制）。这些元素相互关联，共同构成了一个整体，以实现团队的目标。系统的设计和实施主要是为了解决团队管理中的各种问题，如效率低下、信息流通不畅、决策错误、员工满意度低、团队目标达成困难等问题。

系统中的各部分都建议遵循目的、痛点、方案、行动的逻辑来走，这其实也就是我们之前聊过的解决问题方案中的第二类方法，深度分析类问题。

系统的建设和实施需要以下几个步骤：

1. 明确目的：首先，需要明确系统的目的，即希望通过系统解决什么问题，实现什么目标。

2. 识别痛点：然后，需要识别和分析现有的问题和痛点，这将为系统的设计提供依据。

3. 制定方案：根据目的和痛点，制定相应的流程、规则和机制。这可能包括重新设计工作流程，制定新的政策，或设置新的奖励机制等。

4. 实施行动：将方案落实到实际行动中，这可能需要培训员工，改变工作方式，或调整资源分配等。

5. 持续优化：在实施过程中，需要收集反馈，评估效果，然后根据结果进行调整和优化，使系统能够更好地服务于团队的目标。

这里的系统是指一系列的流程、规则和机制。今天我们主要简单聊一下流程和运营机制。

3.4.1 流程

对于流程建设，它的核心并不仅仅是管理者制定内部规章的过程，而更是一个机会，一个可以总结和提炼团队内部的最佳实践，同时也是管理者对于自身权力的一种约束。流程建设是将团队实践中的隐性知识沉淀为明文规定的最佳工具。

流程本质上是人与任务的有效组合。 它是为了完成特定目标或任务，人们进行的一系列逻辑相关的，跨时间和空间的活动集合。流程是将投入转化为产出的方法，通常包含三个组成部分：投入、转换活动和产出。具有系统观点的人会将组织视为一个流程，而不是各自独立的部门。

流程中的专责化的含义并不是专门的机构或者人员来负责团队所有的标准流程建设，而是谁负责工作，谁就应该负责流程的建设工作。流程建设是一种实践性的工作，源于实际工作，服务于实际工作。如果由专职人员负责流程，可能会导致一线管理者在责任上有所缺失。

流程是一个过程性的制度，需要在过程中发现问题，解决问题，并随着业务的发展和变化进行持续迭代。当某些流程不再适用时，我们需要主动发起优化，按照更优的方向优化流程，精简冗余的流程，追求极简。

一个组织实际上是由各种流程串联起来的。这些流程可能并不都是书面的，但一定隐藏在团队的常规操作和员工的习惯中。组织的工作效率在很大程度上受到流程的影响，组织的运行本质上就是业务流程的运行。

每个管理者都应该学会建立和优化流程。建立流程的目的是高效管理业务，让大家可以按照流程解决问题，尤其是跨团队的问题，而不是寻找人来解决；每件事情都可以按照流程来解决，而不是频繁的开会沟通。那么如何来构建有效的流程呢?

1. 从实际出发：流程建设应该是为了解决实际问题或提高某个事情的效率，而不是为了流程本身。比如，如果在人力调度问题上需要频繁地找各级领导开会讨论，明显存在效率问题。为此，我们可以制定一个人力调度的流程，明确需要提供的信息，哪些人需要讨论，哪些人需要审批等。在此之后，大家可以按流程执行，无需频繁地找各级领导开会。

2. 灰度执行：流程建设完成后，不应立即全面实施，而应该先在某个部门或业务部门进行试点，发现可能存在的问题，如流程的顺序、时限等，然后有针对性地对流程进行优化和完善，再逐步扩大试点范围，最后全面实施。这个逻辑和我们服务灰度的逻辑是一致的，尽量减少新变化的影响范围，使变化更好地落地。

3. 持续迭代：流程全面实施一段时间后，需要对流程进行复盘和回顾，而不是一旦流程建立就不再关注。例如，如果公司是从事 toC 业务，现行的研发流程是双周迭代，运行了一段时间。但现在，公司要转向 toB 业务，这时候就需要重新审视双周迭代的流程，看是否需要优化，以满足新的业务需求。

在流程的构建过程中需要注意不是所有的事情都需要建立流程，关键的流程能够大大提升团队的效率，在出现以下的情况时，我们就需要注意是否要创建新的流程或者优化流程了：

1. 刻意跟进的重要不紧急（突破创新）的事情
2. 多方共同参与，提升协同效率（流程/角色/决策等需要配置）
3. 日常的重复性工作

流程建设是一个动态的过程，需要管理者从实际工作出发，灰度执行并持续迭代，以达到提升工作效率，解决问题的目标。

3.4.2 运营机制

运营机制是一套规范团队运作的方法和流程，它解决的是如何有效管理和协调团队资源，以实现团队的目标。它的本质是制度和流程，它旨在提高团队的效率，减少混乱，提升团队的协作能力，以及适应环境的变化。

在有效的团队管理中，以下是关键的运营机制：

1. OKR 跟进：OKR（Objectives and Key Results）是一种目标设定框架，它明确了团队的目标（Objectives）和衡量目标实现程度的关键结果（Key Results）。团队需要定期跟进 OKR，以确保目标的实现。这个过程包括定期检查关键结果的进展，以及调整策略以更好地实现目标。

2. 常规基础工作：这是团队日常运营的重要组成部分，包括任务分配、项目管理、报告编制，以及其他常规的管理工作等。这些工作是确保团队正常运行的基础，也是团队能够有效执行其职能和达成目标的基础。

3. 处理突发问题/bug：在日常运营中，团队可能会遇到突发的问题或者 bug。团队需要有处理这些问题的能力，这包括快速定位问题，制定解决方案，并执行修复。这种能力不仅可以避免问题对业务造成影响，也是提升团队解决问题能力的重要方式。

除此之外，还有关于团队、领导和反馈的一些机制，详细内容在前面讲过，这里带一下：

1. 明确的角色和职责：一个高效的团队需要有一个核心团队，其中每个成员的角色和职责都应该明确。这可以确保每个人都明白自己的工作是什么，以及如何与其他团队成员协作。明确的角色和职责，可以提高团队的协作效率，也可以有效地避免工作的重复和遗漏。

2. 团队领导的责任：团队的领导者（Owner）是决定团队成功的关键因素。他们需要对团队的成功负责，这包括确定和维持团队的战略方向，做出关键的判断和决策，以及协调资源以支持团队的工作。适当的领导可以激发团队成员的潜力，驱动团队的创新和进步。

3. 定期的跟进和反馈：团队需要进行定期的跟进和反馈，这包括周度跟进和月度跟进，以及在关键节点的洞察。这些跟进和反馈可以帮助团队了解他们的进展，发现问题，并在需要的时候做出调整。定期的跟进和反馈，也是团队持续改进和学习的重要机制。

通过以上这些运营机制，团队可以确保目标的实现，日常工作的正常推进，以及在遇到问题时能够有效地解决。这也可以帮助团队建立一个明确的定位和团队精神，使成功成为一群人共同的事情。

从流程观到系统观，是一个从关注单个流程或机制，到关注整个系统如何协同工作以实现目标的转变。这需要明确目的，识别痛点，制定并实施方案，最后通过收集反馈和持续优化，以实现系统的最大价值。

有系统观的团队管理，能使团队运行更高效、更有序，有助于提高工作效率，减少错误，提升员工满意度，最终实现团队的目标。同时，通过系统的反馈机制，可以不断学习、优化和改进，从而实现组织的持续改进和发展。

3.5 沟通

在团队管理中，沟通是一个至关重要的组成部分。沟通是团队成员之间交换信息、观点、想法和感受的过程。沟通不仅仅是说出自己的想法，更重要的是倾听和理解他人的观点。在沟通过程中，我们应首先接纳对方的观点，然后再去理解。这样的沟通方式可能更容易促成有效的合作。

沟通从种类上来分，可以分为语言沟通或非语言沟通、口头沟通和书面沟通、正式沟通和非正式沟通，向上沟通、向下沟通和平级沟通等。

• 语言沟通或非语言沟通是从沟通的载体来区分，语言沟通包括书面沟通和口头沟通，非语言沟通包括面部表情，身体语言等；
• 口头沟通和书面沟通是从语言的载体来区分，口头沟通有会议、面谈、演讲、电话等，书面沟通有电子邮件、信函、刊物（电子和非电子）、报表、通讯录等传递书面文字的手段。口头沟通的特点是快速传递和反馈，但是可能传递过程中会失真，书面沟通更偏向于单向沟通、一般会缺少反馈且耗时较多。
• 正式沟通和非正式沟通更多的是在组织层面，通过是否具有系统性和结构性来区分。正式沟通是从组织所规定的路线和程序进行信息的传递和交流，如组织间的信函、内部的文件、汇报、会议等等；非正式沟通一般是线下的一些闲聊、喝酒时的吹牛以及一些小道消息等。
• 向上沟通、向下沟通和平级沟通，这里主要是以组织层级间沟通的对象为区分，以方向表述对象群体。向上沟通一般是指向你的老板沟通，即所谓的下情上达；向下沟通是指向你的下属沟通，即所谓的上情下达；平级沟通是指横向的沟通，如一些平级的部门负责人之间的沟通，以交接意见，互助互赢为主。

沟通的主要目的有几个方面。首先，沟通可以帮助团队的成员对团队的目标、任务、策略和进度有清晰的理解，这需要我们寻找合适的沟通「切入点」。其次，沟通也可以帮助解决可能出现的误解或冲突，这需要我们正确对待和处理抱怨。最后，沟通可以增强团队的凝聚力和合作精神，这需要我们建立完善的内部沟通机制，消除沟通障碍，确保信息共享，引导团队成员之间进行充分的沟通。

沟通在团队管理中的重要性不可忽视。首先，良好的沟通可以加强团队的协作效率，帮助团队成员更好地理解和接受团队的目标和策略。其次，通过沟通，我们可以及时发现和解决问题，避免小问题演变成大问题。此外，通过有效的沟通，我们可以建立一个开放、透明的工作环境，增强团队的凝聚力和合作精神。

有效的沟通方法包括以下几个方面：

1. 定期的团队沟通：可以通过团队会议，一对一的交谈等方式进行定期的沟通，以确保团队成员对团队的目标和策略有清晰的理解。

2. 寻找沟通的「切入点」：寻找合适的沟通「切入点」可以使沟通更为有效。这可能是一个共享的目标，一个共同关注的问题，或者一个相关的话题。

3. 消除沟通障碍：消除沟通障碍，确保信息的准确、及时和有效的传递。这可能包括明确的表达，有效的倾听，以及建立开放和透明的沟通环境。

4. 处理抱怨：对于抱怨，我们应该先理解抱怨的原因，然后提供有效的反馈，最后寻找和实施解决方案。

对于团队管理来说，需要建立有效的沟通机制。以下是一些常见的步骤和建议：

1. 明确沟通的目标：首先，我们需要明确沟通的目标，这可以帮助我们确定沟通的内容和方式。比如，我们的目标是提高团队的协作效率，还是解决具体的问题，或者增强团队的凝聚力。

2. 设定沟通规则：我们需要设定明确的沟通规则，这包括沟通的时间，方式，频率，以及参与的人员。规则需要根据团队的具体情况进行设定，比如，团队成员的地理位置，时间区域，工作方式等。

3. 选择合适的沟通工具：我们需要选择合适的沟通工具，以支持我们的沟通活动。这可能包括面对面的会议，电话，电子邮件，即时消息，视频会议，项目管理工具等。我们需要根据团队成员的需求和习惯，以及沟通的内容和目标，选择最合适的工具。

4. 提供沟通培训：我们可以提供一些沟通培训，以帮助团队成员提高他们的沟通技巧。这可能包括如何清晰的表达自己的观点，如何有效的倾听他人的观点，如何解决沟通中的冲突和误解等。

5. 鼓励开放和透明的沟通：我们需要鼓励开放和透明的沟通，让团队成员感到他们的观点和感受被尊重和接纳。我们可以通过设定安全和尊重的沟通环境，以及提供反馈和建议的机会，来实现这一点。

6. 定期评估和改进沟通机制：我们需要定期评估我们的沟通机制的效果，以便进行必要的改进。我们可以通过收集和分析沟通的数据，以及听取团队成员的反馈和建议，来进行评估和改进。

通过这些步骤，我们可以建立一个支持团队目标和策略，增强团队凝聚力和协作精神，以及应对变化和冲突的沟通机制。

3.6 关系

这里的关系不是指拉帮结派，而是涉及到团队成员之间的相互作用、感情、理解和信任。这些关系能够影响团队的凝聚力、合作效率和整体的工作环境。这包括团队成员如何沟通、如何协作、如何处理冲突，以及他们对彼此的信任和尊重程度。有效的团队关系不仅涉及到个体与个体之间的关系，也涉及到个体与团队，以及团队与其他团队之间的关系。

团队关系对于有效的团队管理来说非常重要，其意义主要表现在以下几个方面：

• 提高效率：当团队成员之间的关系良好时，他们更可能愿意共享信息，协作解决问题，这可以大大提高团队的工作效率。

• 增强凝聚力：良好的团队关系可以增强团队的凝聚力，使成员感到他们是团队的一部分，愿意为团队的目标努力。

• 提高满意度：当团队成员在工作中感到被尊重和被理解时，他们的工作满意度也会提高，这对于保持团队的稳定性和吸引优秀的人才非常重要。

• 创新和解决问题：良好的关系可以促进不同观点的碰撞，从而激发创新和解决问题。

建立良好的团队关系需要投入时间和努力，以下是一些有效的策略：

• 建立信任：信任是关系的基础，需要通过遵守承诺、公平对待所有成员、开放和诚实的沟通以及接受反馈来建立。
• 提供支持：团队领导应提供必要的资源和支持，帮助团队成员成功完成任务，同时也要关注他们的职业发展。
• 鼓励开放沟通：团队领导应鼓励开放、诚实和尊重的沟通，以确保所有成员都能够表达他们的观点和感受。
• 解决冲突：团队领导需要具备解决冲突的能力，以及确保冲突的有效解决。

一旦建立了良好的关系，就需要进行维护。以下是一些有效的策略：

• 定期沟通：团队领导需要定期与团队成员进行沟通，了解他们的需求和期望，解决可能出现的问题。
• 公正和一致：团队领导需要公正地对待所有成员，确保所有的决策和行动都是公平和一致的。
• 承认和奖励：团队领导应该承认和奖励团队成员的努力和贡献，以增强他们的满意度和投入度。

建立和维护良好的团队关系需要团队领导和成员的持续努力。在遇到破坏团队信任感的人，不能留，但用人不疑，疑人不用。团队关系在团队管理中起着关键的作用。通过建立信任、提供支持、鼓励开放沟通和有效解决冲突，我们可以建立和维护良好的团队关系，从而提高团队的效率，增强凝聚力，以及提高满意度。

4 团队有效性的评估和度量

当我们做了一些手段来优化团队管理的有效性，就需要有一个评估和度量的过程。以下是一个基于各种机制的团队系统有效性评估表。其分为五个主要类别：决策与目标设定、沟通与任务分配、报酬与激励、绩效评估、人才管理和日常运营。

1. 决策与目标设定

2. 沟通与任务分配

3. 报酬与激励

4. 绩效评估

5. 人才管理和日常运营

使用此评估表时，可以为每个项目打分，比如在 1-5 的范围内，其中 1 表示不满意，5 表示非常满意。然后对所有分数进行总结，得出总体评估结果。也可以将这些分数与其他团队或行业标准进行比较，以获得更深入的洞察。

后记

花老师说：你是爱自己还是爱团队？

一言以蔽之：搭班子、定战略、带队伍。

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 小结

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

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

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

1 应急响应类

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

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

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

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

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

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

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

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

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

示例：

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

”

2 深度分析类

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

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

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

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

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

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

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

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

3 追求卓越类

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

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

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

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

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

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

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

4 小结

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

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

1 为什么会有异地团队

当一个企业成长到一定程度后，往往会在多地建立研发中心或者业务中心，这里企业的考量可能会有如下的一些点：

1. 人才资源：不同的城市和地区可能具有独特的人才资源，通过在多个城市建立研发中心，公司可以吸引和招聘到更多具有不同技能和背景的优秀人才。这有助于公司在保持竞争力，并确保能够获取到足够的人才来支持研发和业务需求。
   比如深圳是中国的高新技术产业中心，其在硬件制造、消费电子、通信技术等方面具有很强的竞争力，对硬件制造、物联网、人工智能等领域拥有丰富经验的工程师较多，并且由于深圳地理位置优越，靠近香港，拥有国际化的人才环境，因此在跨境项目和多元文化沟通方面具备优势；
   又如北京是中国的政治、文化和教育中心，拥有众多顶级高校和研究机构，拥有大量理论研究和技术创新方面的顶尖人才，北京的互联网行业较为成熟，尤其是在互联网+政务、在线教育、大数据等方面有较多经验的人才。

2. 市场覆盖：在多个城市设立研发中心有助于公司更好地了解和适应不同地区的市场需求。这可以让公司更迅速地响应市场变化，提供更符合客户需求的产品和服务。

3. 成本优化：不同地区的劳动力成本、房地产成本和生活成本可能存在差异。在多个城市建立研发中心可以让公司充分利用各地的成本优势，降低整体运营成本。如一些深圳/北京的公司，会把一些研发中心放到西安、成都、武汉、长沙等城市。

4. 政策支持：一些城市为了吸引优秀企业入驻，可能会提供各种政策支持，如税收优惠、低息贷款、用地优惠等。在多个城市建立研发中心可以让公司充分利用这些政策优势，降低研发成本。

除此之外，还有风险分散的考虑，技术合作与创新等等，最终都是帮助公司获得更多的资源和优势，提高整体竞争力。

2 异地团队会有什么问题

以技术团队为例，当有多个技术团队在不同的城市后，与所有技术团队在同一个地方相比，会有一些问题出现，主要分为以下的 4 个方面：

2.1 团队建设和凝聚力打造困难

由于缺乏面对面交流和互动，异地团队成员之间可能难以建立信任和凝聚力。而团队建设和凝聚力是影响团队绩效的重要因素。当技术团队分布在不同城市时，团队建设和凝聚力可能受到以下方面的影响：

1. 面对面交流机会少： 当团队成员分布在不同城市时，他们的面对面交流机会将大大减少。面对面交流有助于加深团队成员之间的了解、建立信任和加强团队凝聚力。例如，共同参加团队活动、庆祝生日等场合，能增强团队成员之间的情感联系。而分布在不同城市的团队成员可能很难享受到这些互动的机会。

2. 困难的团队文化塑造： 一个健康的团队文化对于团队建设和凝聚力至关重要。在异地团队的情况下，公司需要付出更多的努力来塑造统一的团队文化。例如，各地团队可能在工作习惯、价值观、沟通方式等方面存在差异，这些差异可能导致团队凝聚力降低。

3. 时空的隔阂： 异地团队面临地理距离的挑战，以及各地工作安排导致的时间不一致的问题。这种情况下，团队成员可能较难以达到理想的实时沟通，而在中国实时沟通是大部分公司的必备品，大家更习惯于实时的沟通，而不是异步的非实时沟通。

4. 缺乏有效的团队认同感： 异地团队成员可能会感到自己与其他团队成员的联系较弱，这会导致他们缺乏对整个团队的认同感。例如，一个异地团队成员可能对其他城市团队的工作情况和成果了解较少，难以形成归属感和共同的目标。

2.2 项目管理及实时协同难度大

异地团队成员可能难以实时协作，尤其是涉及紧急问题或需要即时反馈的情况。项目管理及协同难度增大主要表现在以下的 3 个方面：

1. 沟通成本上升：当团队成员分布在不同城市时，团队之间的沟通成本会显著增加。团队成员需要通过电话、电子邮件、即时通讯等工具进行沟通，这可能导致信息传递的延迟和误解。例如，一个团队成员在深圳提出一个需求变更，另一个团队成员在上海可能需要数小时甚至一天后才能了解到这一变更，从而影响项目进度。

2. 快速应对变化的能力变弱：异地团队可能在应对突发事件和变更需求时存在局限。假设一个重要客户要求对产品进行紧急修改，跨城市的团队成员可能需要在短时间内协调资源和安排工作，而地理隔离使得这一过程变得更加困难。

3. 时间管理和跨团队协调困难：不同城市的团队可能存在不同的工作时间和节假日安排（比如某个城市因为办公场地原因而全员居家），这可能导致某些任务在协作过程中出现延迟。例如，在一个紧急 bug 修复的情况下，由于一个城市的团队正在度假，另一个城市的团队需要独自解决问题，可能导致修复速度变慢。

2.3 监督和管理困难

在异地团队中，监控和评估团队成员的绩效可能较为困难。管理者需要找到合适的方法和指标，以便对团队成员的工作成果进行公平、准确的评估。监督和管理困难主要包括以下的一些情况：

1. 工作状态难以掌握：由于地理隔离，管理者可能无法直接了解团队成员的工作状态和情况。例如，一个城市的团队可能遇到了技术难题，导致项目进度受阻，但管理者由于无法亲自与团队成员交流，可能难以及时发现问题并采取相应措施。

2. 绩效评估困难：在异地团队中，评估团队成员的工作绩效可能变得更加困难。由于缺乏面对面交流，管理者可能无法准确评估团队成员的工作质量和效率。例如，一个城市的团队成员可能在某个任务上花费了较长时间，但管理者无法确定这是否是由于技术难题还是工作效率低下。

3. 难以建立信任和团队凝聚力：地理隔离可能导致管理者难以建立与团队成员的信任关系，从而影响团队凝聚力。例如，一个城市的团队成员可能对管理者的决策表示质疑，由于无法进行面对面沟通，管理者可能无法充分解释决策背后的原因，从而导致信任度降低。

4. 协调和调动资源困难：异地团队的管理者可能在协调和调动资源方面面临挑战。当项目需求发生变化或出现紧急问题时，管理者需要快速协调各地团队的资源，但地理隔离可能使这一过程变得更加复杂。例如，在一个紧急项目中，管理者需要从多个城市的团队中调集人力资源，但由于异地情况，这可能导致资源调配的速度和效果受限。

整体来说，主要是由于沟通与协作问题导致的各种延展性问题。缺失的面对面沟通、缺少肢体语言、表情语言等，可能导致信息传递不畅、误解和沟通成本的增加。我们无法彻底解决这些问题，但是能通过一些手段来缓解。

3 三大模式

为解决上面这些问题，我们在工作中发现了一些在不同的环境和场景中具有普遍适用性的解决或缓解问题方法，以模式的形式表述出来。

3.1 代理模式（Proxy Pattern）

代理模式在团队管理中可以被用于创建一个协调人或代表角色，负责处理某个团队或多个团队之间的沟通与协作。代理角色在此情景下充当一个中介，处理跨团队的需求、问题解决和资源协调。代理模式有助于简化沟通流程，提高团队协作效率。

具体实施方案：

• 为每个团队或职能领域设立代理角色，如前端代理、后端代理、QA 代理和移动端代理。
• 代理角色负责处理跨团队的需求和问题，同时将反馈和解决方案传递给相应团队。
• 组织定期的代理角色会议，让代理们相互沟通和协作，以确保团队目标的达成。
• 建立代理角色的沟通汇报机制，如定期晨会、周报和项目维度的回顾会。

3.2 门面模式（Facade Pattern）

门面模式提供了一个统一的接口来访问子系统中的一组接口。在团队管理中，可以创建一个统一的协调角色（如项目经理或技术负责人），该角色负责协调团队成员的工作，并充当各个团队之间的沟通桥梁。这有助于确保团队之间的沟通更加高效，降低沟通成本。

具体实施方案：

• 设立项目经理、技术负责人或者某个业务模块的 DRI 角色，负责跨团队协调和沟通。
• 为每个团队成员分配具体的职责和任务，以便在项目经理或技术负责人的协调下高效协作。
• 定期召开跨团队会议，确保团队之间的沟通畅通，及时解决问题。

门面模式和代理模式看起来有一点相似，其本质上是有区别的，区别在于授权的范围，门面模式不用太关注其内部实现，而代理模式在管理上要更深入细节一些。

在实际应用中，我们通常在各职能和各业务模块中使用代理模式，而针对不同的区域使用门面模式，由当前地区的负责人提供统一的输出。

3.3 观察者模式（Observer Pattern）

观察者模式在团队管理中可以应用于实时通知和信息共享。当一个团队成员对项目状态或任务完成情况进行更新时，其他相关成员可以作为观察者实时收到通知。这种模式有助于保持团队成员之间的信息同步，提高沟通效率。

具体实施方案：

• 为团队成员创建一个共享平台，如任务管理工具、项目管理系统等。
• 当某个团队成员更新任务状态或项目信息时，系统自动通知其他相关成员。
• 通过观察者模式，确保团队成员之间的信息同步，减少冗余沟通。

4 六项注意

4.1 相互信任

信任是团队协作的命脉。要想促进并保持长久的关系，你就必须信任他人，他们也必须信任你。与此同时，他们还必须相互信任。

信任来自相互理解对方的价值观、个人经历和立场。为了实现这一目标，我们必须承认自己的弱点，我们必须开放。这样我们才能够建立起共同的价值观和彼此信任。

信任在异地团队中有如下的好处：

1. 提高团队凝聚力：信任关系有助于增强团队成员间的默契，从而提高团队凝聚力。当团队成员信任彼此时，他们更愿意携手合作，共同解决问题。
2. 提高工作效率：信任关系可以促使团队成员更加开放地分享信息、资源和建议，从而提高整体工作效率。当团队成员相互信任时，他们更可能分享自己的想法和专业知识，共同解决问题。
3. 降低沟通障碍：信任有助于消除团队成员间的沟通障碍，提高沟通效果。当团队成员彼此信任时，他们更愿意倾听对方的意见，以开放的态度接受建议和批评。
4. 降低管理成本：信任关系有助于减轻管理压力，降低管理成本。当团队成员相互信任时，他们更可能自我管理，减少管理者的介入。
5. 增加创新和风险承担：信任关系有助于创造一个安全的环境，使团队成员更愿意尝试新的想法和承担风险。当团队成员彼此信任时，他们更可能勇于创新和承担失败的风险。

建立相互信任关系的方法，以下是一些常见的方法：

1. 增加沟通：

   • 定期开展团队会议，让团队成员分享项目进展、遇到的困难和解决方案。
   • 鼓励一对一交流，让团队成员有机会深入了解彼此的工作、兴趣和需求。
   • 举办团队活动，如团队建设、庆祝活动和知识分享，促进团队成员间的互动和信任。

2. 增加透明度：

   • 使用项目管理工具，让团队成员能够实时查看项目进度和任务分配。
   • 定期分享业务战略、目标和团队绩效，让团队成员了解公司的发展方向。

3. 赋予责任和权力：

   • 根据团队成员的专长和兴趣分配任务，让他们在完成任务时有更大的自主权。
   • 鼓励团队成员在解决问题时提出建议和改进方案，展现对他们的信任。

4. 鼓励支持和合作：

   • 创建一个支持性的氛围，让团队成员在遇到问题时不惧于寻求帮助。
   • 鼓励团队成员互相学习、分享经验，以解决共同面临的问题。

5. 表扬和认可：

   • 在团队会议上表扬团队成员的优秀表现和努力。
   • 为表现突出的团队成员提供奖励，如奖金、晋升和表彰。

6. 建立公平的环境：

   • 确保团队中的决策过程透明，鼓励团队成员参与讨论和决策。
   • 设定明确的激励和奖惩

4.2 仪式感

在异地管理中，仪式感是一种有意识地营造正式或非正式场景，以传递重要信息、强化文化价值观、增强团队凝聚力和提升员工信任感的方式。

在异地团队中，恰当的仪式感具有以下好处：

1. 增强团队凝聚力：仪式感有助于让团队成员感受到归属感和团队精神，从而增强团队凝聚力。
2. 传递公司文化和价值观：通过仪式感，可以传递公司的文化和价值观，帮助团队成员更好地理解和认同这些价值观。
3. 提升员工士气和信任感：仪式感可以激发团队成员的积极性和参与感，从而提高员工士气和信任感。
4. 建立清晰的期望和目标：仪式感有助于确立团队成员的期望和目标，提高工作效率和执行力。

那如何建立恰当的仪式感呢？

1. 定期召开团队会议：固定时间、地点召开团队会议，让团队成员汇报进展、分享经验、讨论问题。如每周一召开全体成员参加的在线例会，或者对于管理团队，定期如开包含问题同步和处理，学习分享的管理例会。
2. 庆祝重要节点和成就：为团队的重要成就和里程碑设立庆祝活动，以增强团队成员的归属感和自豪感。如在项目完成时，举办在线庆祝活动，表彰优秀团队成员。
3. 组织团队建设活动：定期组织线上或线下的团队建设活动，增进团队成员间的联系和互动。如每季度举办一次线上游戏比赛，增强团队成员之间的合作和交流。
4. 激励和认可：对团队成员的努力和成果给予表扬和认可，提高他们的信任感。如每月颁发「最佳团队贡献者」奖项，表扬表现优秀的团队成员。
5. 传递公司文化：通过仪式感传递公司文化，帮助团队成员理解和认同公司的价值观。如每年举办一次公司文化分享活动，邀请公司领导和团队成员分享公司文化和价值观。

4.3 严格目标管理，注重结果

在异地技术团队管理中，严格的目标管理和注重结果至关重要，因为这有助于确保项目按时完成、质量达标，并提高团队成员的工作效率和执行力。

以下是实行严格目标管理和注重结果导向的好处：

1. 明确工作目标：设定清晰的目标和期望，帮助团队成员明确工作重点，避免资源浪费和目标模糊。
2. 提高工作效率：明确的目标和期望有助于团队成员更高效地完成任务，降低拖延和低效的可能性。
3. 便于评估和改进：结果导向的管理使团队可以通过衡量实际成果来评估工作效果，从而找出不足并进行改进。
4. 激发团队成员积极性：目标明确、注重结果的管理方式有助于激发团队成员的积极性和责任心，鼓励他们为实现目标而努力。
5. 有利于项目按期完成：严格的目标管理和注重结果有助于确保项目按计划进行，按时完成，避免延期。

那么如何实施严格的目标管理和注重结果导向？有如下 7 个方法

1. 设定明确的目标：为项目和团队设定明确、可衡量、可达成的目标。如在项目开始时，为团队设定一个明确的项目交付日期，并明确交付内容的具体要求（也就是大家常说的 deadline 是第一生产力）。
2. 制定详细的计划：为实现目标制定详细的计划和进度表，包括任务分配、时间安排等。如使用项目管理工具（如Trello、Jira等）制定详细的任务列表和时间表，如果没有这些工具，搞个在线表格也是极好的。
3. 定期检查进度：定期与团队成员沟通，了解项目进度和遇到的问题，确保项目按计划进行。如定期的项目晨会（可以按周，或按天，也可以一周两次，根据实际情况调整），让团队成员报告各自的任务进展和遇到的问题。
4. 强调结果导向：鼓励团队成员关注实际成果，以实现预定目标。在管理过程中对团队成员的绩效评估更注重实际完成的任务和贡献，而非工作时长或其他表面指标（不要卷加班）。
5. 及时反馈和调整：根据实际进度和成果，及时给予团队成员反馈，调整目标或计划。如当发现某个任务进度落后时，及时与相关成员沟通，分析原因，并调整计划或提供支持。如当发现某个任务进度落后时，及时与相关成员沟通，分析原因，并调整计划或提供所需资源，以确保项目仍能按时完成。
6. 定期总结和复盘：项目结束后，与团队成员一起总结经验教训，分析成功与失败的原因，以便在未来项目中持续改进。如项目结束后，组织团队进行复盘会议，总结项目的优点和不足，制定改进措施。或者迭代结束后做一些回顾。

我们在团队管理中，目标管理是一个非常重要的点，一定要自己主导，不能授权，作为一个技术团队的负责人，方向是你来定的，未来在你的手里

4.4 扁平、弹性的组织架构

在异地技术团队管理中，组织架构至关重要，因为组织架构会影响团队的沟通效率、决策速度、责任分配和协作。适合异地技术团队的组织架构应具备以下特点：扁平化、模块化、弹性和高度协作。

1. 扁平化：扁平化的组织结构有助于提高沟通效率，减少信息传递过程中的失真和延迟。扁平化组织中，每个成员能够直接向上级汇报，决策速度更快，执行力更强。

2. 模块化：将工作划分为具体的、相对独立的模块，有助于提高团队的协作效率。每个模块可以由一个或多个团队负责，这样可以减少跨团队协作的复杂度，降低沟通成本。

3. 弹性：适应不断变化的项目需求和团队规模，组织架构需要具备一定的弹性。弹性的组织架构可以快速调整资源分配和团队规模，以满足项目发展的需要。

4. 高度协作：鼓励团队成员之间的协作和互助，以提高工作效率和质量。高度协作的团队可以更好地应对复杂问题，减少重复劳动和资源浪费。

以下是如何实现适合异地技术团队的组织架构：

1. 利用技术手段优化沟通：使用沟通和协作工具（如钉钉、企业微信、飞书、Microsoft Teams等）提高沟通效率，方便团队成员跨地域、跨部门协作。
2. 决策下放：授权团队成员在其负责领域做出决策，提高决策速度。如将需求评审的决策权下放至小组 leader 或 DRI，甚至一线开发，让他们根据自己的专业知识对需求进行评估和调整。
3. 设立技术负责人或项目经理：在每个地区或团队设立技术负责人或项目经理，负责协调团队成员的工作，确保项目顺利进行。如在各城市的团队中各设立一名项目经理，负责当地团队的项目进度和资源协调。
4. 定期进行跨团队沟通：组织定期的跨团队会议，让各个团队分享进展、问题和解决方案。这有助于提高团队间的了解和协作。如每两周组织一次跨团队分享会议，让各个团队汇报自己的进展和挑战，共同寻找解决方案。
5. 提供培训和支持：为团队成员提供技能培训和支持，以便他们更好地适应组织架构变化。如提供关于敏捷开发、跨部门协作等方面的培训课程，帮助团队成员提高工作效率和协作能力。
6. 鼓励创新和变革：建立一种鼓励创新和变革的文化，让团队成员敢于尝试新方法，优化工作流程。如设立创新奖励计划，对于提出改进方案并成功实施的团队成员给予奖励。或者团队负责人亲自来参与或推进一些创新的事项，如最近的比较热的 AI。

4.5 统一的技术栈

在异地技术团队管理中，统一技术栈非常重要，因为它能为团队带来以下好处：

1. 提高协作效率：统一技术栈能确保团队成员之间更容易进行技术交流和协作，避免因技术差异导致的沟通障碍和额外工作量。
2. 降低维护成本：使用相同的技术栈，使得维护、调试和优化工作更加简单，减少因为技术差异导致的额外成本。
3. 增强团队能力：统一技术栈有助于团队成员互相学习，提高整体技术能力，使得团队在面对复杂项目时更具备应对能力。
4. 简化招聘和培训：统一技术栈使得招聘和培训过程更加简单，因为公司可以针对特定技术栈进行招聘和培训，提高招聘效率和培训质量。

为实现统一技术栈，我们可以采取以下方法：

1. 制定技术规范和标准：制定统一的技术规范和标准，确保各地团队遵循相同的技术实践。如制定统一的编码规范、代码审查标准和自动化测试要求。
2. 组织上增加架构设计的职能或者技术通道的职能组织: 通过组织的方式构建技术栈统一的土壤。
3. 搭建技术共享平台：创建内部技术分享平台，让团队成员分享技术心得、问题解决方案和最佳实践，有助于统一技术理念和实践。如搭建一个内部的技术博客平台，鼓励成员撰写和分享技术文章。
4. 统一基建和开发流程中的系统: 通过使用工具的统一达到技术栈的统一。
5. 选型时充分调查和论证：在技术选型阶段，充分调查并论证各种技术方案的优缺点，确保选择的技术栈适合公司的业务需求和发展战略。
6. 定期评估和调整：定期评估技术栈的合理性和有效性，根据项目需求和团队能力进行调整，以保持技术栈的统一性和先进性。如每年定期组织技术栈评审和审查，了解目前所使用的技术栈是否仍然满足业务需求，或者是否有新技术可以更好地支持业务发展。

通过以上方法，异地技术团队可以实现技术栈的统一，从而提高协作效率、降低维护成本、增强团队能力，并简化招聘和培训过程。这将有助于提高团队整体的研发效能，使得公司在面对市场竞争和业务挑战时更具备优势。

4.6 高效的沟通机制

异地团队最突出的问题是沟通问题，在我们平常的沟通过程中需要选择合适的沟通渠道和做有准备的沟通。良好的沟通有如下的好处：

1. 能提高沟通效率：采用合适的沟通方式可以确保信息准确、及时地传递给相关人员，避免因沟通不畅导致的误解和冲突。
2. 增强团队凝聚力：良好的沟通方式有助于增进团队成员之间的理解和信任，提高团队凝聚力。
3. 减少资源浪费：有效的沟通方式能够减少不必要的会议和重复工作，降低资源浪费。
4. 支持项目管理：清晰的沟通方式有助于确保项目进度、需求和问题得到及时解决，保障项目顺利进行。

我们可以通过如下的一些方式达到比较高效的沟通机制：

1. 明确沟通目标和内容：在沟通开始前，明确沟通的目的、内容和预期结果。如：在项目会议开始前，列出讨论议题、相关人员和预期决策。
2. 选择合适的沟通渠道：根据沟通内容和参与人员，选择合适的沟通渠道。如：对于紧急问题，可以使用电话或即时通讯工具（如微信、钉钉等）进行沟通；对于团队日常工作，可以使用邮件或者项目管理工具（如Jira、Trello等）进行沟通。
3. 建立沟通规范：制定团队沟通规范，确保沟通有效进行。如：要求团队高效会议，或者要求团队成员在邮件中使用清晰的主题行、合理的收件人列表以及简洁明了的正文。
4. 鼓励开放和诚实的沟通：营造一个鼓励团队成员开放、诚实地表达观点和需求的氛围。如：在团队会议上，鼓励成员提出问题、建议和想法，避免惩罚性的反馈。
5. 定期进行沟通培训：为团队成员提供沟通技巧培训，以便他们更好地进行沟通。如：提供关于有效沟通、团队协作等方面的培训课程。

值得注意的是，异地的沟通中尽量少用邮件，邮件适用于传达信息和事实，撰写时还需要注意措辞，以防误会的发生。

单纯的文字无法传递情绪，如果要传达你的想法时，最好拿起电话进行视频，通过视频也能制造多次「见面」的机会更有利于建立信任。

现在用 IM 类工具也比较多了，在清晰的文字表达的基础上，多用表情包。

5 后记

上面说了这么多，有点啰嗦，简单点来说就是：多见见，多一起喝点酒，多一起搞定一些事情，保证基本的机制、流程、标准、工具和系统，也就差不多了。

异地的问题表象是见不着，核心要解决的是效率的问题。

技术团队的管理更多的还是人的问题，还是需要有情感的交流和因为长时间的一起工作而产生的向心力。 我们所做的这些仅能缓解这些问题。

当然，可能有同学会更喜欢异地/远程的工作协同模式，此处因人而异，从个人的角度来看：从团队的角度，从效能的角度，本地化团队会是更高效的选择。

当然以上的模式和注意事项在非异地团队的情况下也是可以使用的，而且效果会更好，因为这些的本质是授权管理和过程管理的逻辑。

在技术团队的日常管理工作中，一个管理者做得最多的事情是决策、开会，最不想看到的是线上事故，线上事故给技术团队带来非常大的冲击，而给线上系统带来风险最大的研发环节是线上环境的变更，甚至有人说：「没有变更就没有问题」，对此我们不置可否，但这些变更之所以会导致事故，从根源上来讲大部分是技术同学犯了错。

这里的决策、会议，变更，错误合起来是我们日常工作中的大部分。而对于这些的基本认知是一个技术管理者在带团队过程中逐步提升的，今天我们就来聊聊这 4 个基本认知。

1 决策

在带团队的过程中我们会做非常多的决策，如去决策是否投入足够大量的人力满足某个业务，或者升级架构，或者构建某个流程机制等等。

这些决策中从服务于时间维分为两种：

• 当下的决策，如评估需求优先级，先做什么，后做什么，关注的是当下和已有的；
• 未来的决策，如评估技术架构演进、团队演化和发展等等，关注的是未来。

当下的决策在我们的工作中最常用于评估产品需求、评估技术方案或实现方案。

对于产品需求，技术管理者的作用是把价值不高，或者没有价值的需求干掉，不让其进入研发，不让公司的人力成本白白浪费掉。一般我们会对于提需求的同学问如下的问题：

1. 为什么会有这个需求？ 一般是想看这个需求是怎么来的，用户故事是怎样的；
2. 这个需求的价值是什么？ 一般是想看这个需求做了之后对产品或业务的好处，看产出；
3. 如何度量这些价值？ 一般是想通过数据看到需求的价值，把价值反馈在指标上，如营收指标、效率指标等。

对于技术需求或技术方案，技术管理者的作用是来评估当下的选择是否正确。一般我们会评估如下的点：

1. 有没有做过方案评估，即有没有评估过业内的方案、公司内的方案以及对于当下的现况的分析；
2. 是否合理的方案，有没有明显的缺陷或漏洞；
3. 有没有显得特别高大上，特别先进，防止过度设计，浪费资源。

未来的决策更多是管理者站在当下思考团队的发展，人员的发展和技术架构的发展等，是一种未雨绸缪的远见。

是基于公司战略，在组织的先进性、技术的先进性的前瞻性布局。如现有的人才梯队和人才密度是否能满足公司三到五年的发展，现在的技术架构是否能满足公司三到五年后的战略，对于行业内新的技术是否我们需要扩大资源投入，去预研并应用在业务中。

这些前瞻性的决策都是管理者基于对公司业务和业务未来发展有足够的认知和理解后做的。

我们所做的这些决策都是以有限的资源达成我们的目的，其本质是资源的分配。当我们分配资源的时候，最最重要是看投入产出比以及和公司战略的方向是否一致。

2 变更

这里的变更是指生产环境的变更。首先我们看一下定义，什么叫生产环境？生产环境是指服务于客户的应用及其运行环境，以及和这些环境相关联的环境和系统。

如果一个应用或环境和生产环境有接触，那它也是生产环境。

什么叫变更管理，变更管理包括什么？

变更管理是指以可控的方式对线上的服务、配置或基础设施进行变更，从而减少变更对业务和服务质量的影响，快速处理变更可能带来的问题，提升系统的稳定性。

在日常工作中我们见到变更有如下 4 种：

1. 应用变更，也称为代码变更，是我们最最常见的变更类型，主要是通过修改代码改变应用程序并通过发布系统发布到线上。这也是我们变更管理中风险最大的地方，因为变更的人，变更的位置和逻辑等都是不确定的。除了正常的发布变更，应用的回滚也是应用变更的一种，因为其改动了线上的应用；
2. 配置变更，是指应用系统的配置变更，一般是通过配置系统来变更，触发线上应用的热更新或滚动，配置如果是写死在代码中，会变为代码变更；
3. 基础设施变更，此变更一般是运维同学来操作，可能涉及网络设施变更，服务解析变更等等，如 DNS 的解析，网络安全配置等等，这些都算到基础设施变更里面，而不是配置变更，又如宿主机挂了，需要替换宿主机，此时也会导致基础设施的变更；
4. 容量变更，此处单独列出是因为相对于基础设施，容量变动的影响逻辑不一样，其主要是通过垂直或水平的方式提升系统的容量，特别是当出现容量告警的时候，此变更经常由运维同学手动，或者系统自动触发。

那么如何控制变更？这里我们先提一下变更管理的标准流程。

变更管理的标准流程：

1. 变更申请：在我们的流程中可能是创建发布记录，或者申请紧急发布
2. 变更评审：变更评审主要是检查变更过程是否完备，以降低变更的风险，其包括如下内容：

   1. 就绪分析：材料是否完备，人员、设备、软件、网络是否就绪，测试是否达到上线要求等。
   2. 风险分析：架构、性能、业务、合规等方面的风险评估，变更内容是否属于需求范围，变更是否可控。
   3. 重要程度：变更属于一般、重要、紧急、标准哪一种。
   4. 变更审查：内容是否满足业务需求，内容是否通过测试，测试是否全面、有效。
   5. 应急管理：变更步骤、应急方案、回滚方案、应急预案是否完备。
   6. 变更实施：变更计划时间如何安排，发布及回退操作步骤是否完备，自动化步骤情况。
   7. 变更验证：变更涉及的业务、技术验证方法与时间安排。
3. 变更审批：相关负责人对于变更评审的结果进行确认，并审批通过。
4. 变更执行

   1. 根据发布计划执行发布操作，一般应该有一个灰度的过程；
   2. 验证线上功能并回归主流程；
   3. 持续灰度，观察用户直到灰度完成。
5. 变更验收

   1. 对发布的功能进行验收，对于影响范围内的功能进行验收，对业务主流程进行回归验收；
   2. 留守，并观察日志、监控服务负载等，这个操作是为了及时发现验收检查漏掉的问题，或者及时处理隐藏的问题，以减少变更后产生的问题对线上业务的影响。

我们做这个流程是形式上的安慰，还是僵化的惯性，还是能真正地解决问题，是我们在做这个流程以及执行这个流程中需要着重思考的问题。

在变更前，即我们变更线上环境前需要自己做 Code Review，以及交叉的检查，以尽量减少问题流转到后面的操作中，节省问题的处理成本。

变更管理没有银弹，我们能做的是控制节奏，敬畏线上，以更机制化的方式提前发现问题并解决问题。

3 会议

会议是一个相互沟通、交互信息、形成一致看法，从而解决问题的管理工具。

从会议的定义来看，会议是一些人有组织、有领导地为了某种目的而进行讨论和商议的集会。

当我们思考一个会议要不要开时，可能需要先思考这个会议的目的是什么。

如果一个会议没有需要讨论的地方，没有明确的目的，可能大概率是一个不需要开的会的，又或者仅仅是一个简单的信息同步，直接文档或者在群里同步就可以了。除非文档没法完全解决问题，比如一些战略的宣讲，一些大的事项的发布，需要有一个仪式感的会，现场答疑的会。

如果发现两个会的参会人差不多，那么是否取消其中的一个会呢？不一定，看目的是否一致，如果解决的问题不一样，可以同时存在。

回顾我们常开的几种会议。

• 项目例会：项目信息同步，问题卡点讨论，待办相关同步，这里的项目例会又包括常规项目例会和专项的项目例会，是项目管理中的信息渠道；
• 管理例会：团队仪式感必不可少的部分，除了事项的讨论，还有一个作用是发散的聊天，不用那么严肃，闲谈之中迸发一些火花，并达成一些共识和认知上的一致；
• 单独定期沟通会议：更私密一些的沟通会议，除了常规事项同步，更多的是一个散而不散的个人想法、规划、思路等的探讨；
• 复盘会议：对特定事项和问题的总结，讨论，属于常规会议机制的一种，起总结，沉淀的作用；
• OKR 会议：目标对齐，起方向对齐的作用；
• 需求规划会：有计划的对于需求进行规划，评审，然后进入迭代，开发测试并交付；
• 技术方案评审会：严格准入技术方案，集众人之力评估方案的可行性，看是否有什么缺漏。

着点讲一下周会，周会我们一般是指周例会，属于例行会议的一种，按周或双周召开。

周会的目的是根据会议的属性，定期回顾讨论总结指定的项，可能是专项，也可能是过程中的事项或突发的事情等。开会的目的主要是交流和讨论，那么在周会上我们讨论什么，在确定讨论内容之前，我们先看看哪些不要在周会上讨论：

1. 紧急的事情不适合在周会讨论，出现的时候直接搞定；
2. 非跨团队的问题不适合周会讨论；
3. 纯执行细节问题不适合周会讨论；
4. 大方向决策问题不适合周会讨论。

总结下来，就是涉及与会各团队的，对整体性计划或者需要协同配合的问题，或者里程碑式的改进型问题适合在周会上讨论。

当然，也不绝对，这还是一个人治的过程。

如果是你一个会议组织者，在组织一个会议的时候，需要考虑以下三件事：

1. 这个会议最重要的事情是什么，是想解决什么问题？想讨论什么？
2. 能否达到目标？ 大家对于目标是否有所了解？
3. 如何达到目标？ 达到目标的关键路径是怎样的？干系人都在吗？

4 错误

工作中我们会出一些错误，生活中我们也会出一些错误，这些错误可能会影响同事朋友，或者影响线上产品，公司业务，甚至可能会造成个人或公司的经济损失，错误有其类型，在了解了这些类型后，我们可以适当的减少出错或规避这些错误。

从个人的角度来看，错误可分为成长之错，无心之错和性恶之错。

1. 成长之错，我们都是从懵懂孩童，成长为有知识的学生，到长大成人，出来工作，工作中也是从不会到会，到熟练和精通，在这个过程中，正是因为一个个的错误，才成就了我们的成长，成长之错为正常之错，可允之；
2. 无心之错，非有意为之的错误，一时失察导致工作出现错误，从而给别人带来不好的影响，或者粗心导致过错，其出发点都非有意，出错了就认，改过即可，不可连续；
3. 性恶之错，以人性之恶为出发点或者动机，此种错不可原谅。

从工作的角度，错误可以分为超出型错误，信息型错误，粗心错误，态度型错误和风险型错误。

1. 超出型错误，当你尝试去做能力之外挑战的时候，或者你不熟悉的领域或知识盲区，或者超出当前因为自身能力或其他条件的束缚，做得不够好而犯的错。比如一些新的想法的落地，一些新技术的试点等等，这些都没有人前人尝试过，至少在当前范围内没有，此时可能会遇到想象不到的坑，或者无法解决的问题，从而出现错误，甚至失误。这种创新或者超前的错误是可以接受的；
2. 信息型错误，属于信息不对等，或者信息不全，知识不全面导致的错误，特别是对于工作中面对某个项目一些信息没有，或者没有去全面了解背景信息从而做出错误的决策，这种错误不会反复出现，但尽可能避免在不同类型的事情上犯同类型的错误；
3. 粗心错误，这种比较常见，与无知错误不同，这种情况是你明明知道怎么回事，但是因为不小心或者忘记了而导致的错误，如果是粗心之人，可能会一错再错，此时需要反思自己，以某种方式规避；
4. 态度型错误，指做事的态度有问题，比如眼看自己负责的一件事情要出问题或者已经出问题了，但是没有想办法去解决，没有付出努力，而是躺平，让事情自己变坏，甚至影响面不可控，这种错误是不允许的；
5. 风险型错误，主动去做事情，但风险很高，是否会犯错不受自己的控制。比如你面临一个重要的选择，但在结果出来之前，你之前掌握的所有信息都无法告诉你哪个选择是绝对正确的，你只能去做自己认为是大概率的选择。而这种错误在工作中是极有可能遇到的。

对于工作中的错误我们应该如何减少或者规避呢？

1. 超出型错误，从公司层面或者团队层面提供一些培训，或者在新人安排导师，提升大家的能力，或者通过流程机制让更有经验或者能力更强的人对于新的内容做一些把关；
2. 信息型错误，信息型错误可以在公司层面搞定完善的文档和快捷的查询机制，任何技术或产品讨论以及达成的共识，要尽可能用某种沟通渠道发送到所有相关的人。让大尽可能的掌控更全面的信息；
3. 粗心错误，设定一些机制来规避，如复盘机制，通过复盘，深挖过程中的问题，总结经验，为后续减少此类问题做准备，同时可以在流程上做一些 check 机制，通过多人的 check 减少错误的出现；
4. 态度型错误，本着治病救人的态度先看看，如果实在不行，考虑换个人吧；
5. 风险型错误，针对高风险的事情，尽可能的准备一个 PlanB，当事情没有按我们预想的方向发展时，启用 PlanB，减少损失，这也是我们下棋时通常会用到的策略，走一步，想三步。

从团队来看，一个人犯错，可能是人的问题，一群人犯错，一定是机制或系统出了问题。

当然，工作中我们允许试错，但是不能一错再错，避免一些不应该犯的错误，最大可能从错误中成长，这才是我们应有的态度。

除了以上，《清单革命》中说人类的错误可以分为两大类型。第一类是「无知之错」，我们犯错是因为没有掌握相关知识。第二类是「无能之错」，我们犯错并非因为没有掌握相关知识，而是因为没有正确使用这些知识。

现在，我们面临的错误更多的是「无能之错」，也就是如何持续、正确地运用我们所掌握的知识。「无知之错」可以原谅，「无能之错」不被原谅。

5 后记

管理是门实践的科学，大多数的书籍和文章都是个人或组织的经验之谈，没有公理，只能在俗世不断修行和精进，以求能「知行合一，止于至善」。

★ 你好，我是潘锦，超过 10 年的研发管理和技术架构经历，出过书，创过业，带过百人团队，也在腾讯，A 股上市公司呆过一些年头，现在在一家 C 轮的公司负责一些技术方面的管理工作。早年做过 NOI 和 ACM，对前端架构、跨端、后端架构、云原生、DevOps 等技术始终保持着浓厚的兴趣，平时喜欢读书、思考，终身学习实践者，欢迎一起交流学习。微信公众号：架构和远方，博客： www.phppan.com

”