标签归档：研发效能

架构劣化，系统复杂度飙升，如何应对？

在构建和演进复杂企业级系统时，架构师常常面临一个令人头痛的现象：架构劣化。

当系统初始设计时一切都井然有序，但随着业务需求的不断增多、新功能的迭代、技术栈的多样化引入，系统开始逐渐变得复杂，模块间的耦合度不断上升，开发者在维护和扩展时难免感到力不从心。系统的可预测性降低，Bug 频发，技术债务迅速累积，甚至每一次小的改动都可能引发意想不到的问题。

为什么曾经清晰的架构会走向失控？如何在长期的系统演化中，保证架构的灵活性与可维护性，而不让其逐渐腐化？

这一切都指向了一个关键问题：架构设计中的一致性。

正如 Fred Brooks 在《设计原本（The Design of Design）》中所言：「一致性应该是所有质量原则的根基。」

今天我们将从风格一致性、解决方案一致性、以及形式一致性三个方面，聊下架构设计中如何实现一致性。

1 风格一致性：统一的架构模式

何谓风格？

架构风格是构建系统时遵循的一套原则和模式，它为系统的设计提供了抽象框架。风格可以看作是架构中一系列可重复的微观决策，这些决策在不同上下文中应用，旨在最小化开发者的脑力负担。

风格具有其属性：

妥适性：根据奥卡姆剃刀原理，风格应避免引入不必要的复杂性，满足基本功能即可。这意味着架构设计中应当聚焦于最核心的需求，避免过度设计。
普遍性：风格应该具备广泛适用性，能够通过有限的功能支持多种结果。这种普遍性有助于减少架构中的冗余，提升系统的灵活性。

架构风格的一个经典例子是「管道-过滤器」模式。在数据处理系统中，通过一系列过滤器对数据流进行处理，开发者只需理解这种模式的核心思想，即可快速理解系统的其他部分。这种风格的一致性使得系统更加可预测，减少了开发和维护中的复杂性。

风格的一致性的落地会从架构到系统设计。

风格一致性要求在设计系统时，所有模块都遵循相同的架构模式。例如，在一个复杂的企业应用中，如果我们选择了领域模型来处理业务逻辑，那么整个系统的其他部分也应遵循这一模式，而不应在某些模块中使用事务脚本。这种不一致会导致开发者陷入不同模式的转换中，增加理解和维护的成本。

风格一致性的核心在于正交性原则，即各个模块应独立处理自己的职责，减少彼此间的耦合。通过保持架构风格的一致性，系统可以更好地实现模块化和松耦合，这不仅有助于当前的开发，还为未来的扩展打下了基础。

需要注意的是，架构风格并非一成不变。随着技术的发展和业务需求的变化，架构风格也会不断演化。因此，架构师应当通过文档化的方式，确保风格的一致性能够在团队内传播和延续。文档不仅是风格的记录，更是团队成员在开发过程中保持一致的指南。

2 解决方案一致性：统一的实现方式

2.1 为什么解决方案需要一致？

风格一致性更多体现在宏观的架构层面，而解决方案一致性则体现在系统具体实现的细节中。解决方案的一致性要求在同一系统中，开发者应使用相同的技术栈、设计模式和实现方式，以避免由于不同方案混用而导致的系统复杂性。

举例来说，假设在一个大型系统中，某些模块使用了Node.js和Express作为后端技术栈，而其他模块则使用了Java和Spring Boot。这种不一致的解决方案会导致以下问题：

开发效率低下：Node.js 和 Java 的编程范式截然不同，前者是 JavaScript 的异步、事件驱动模型，后者则是 Java 的多线程模型。开发者在不同模块之间切换时，需要调整思维方式和适应不同的编程风格。这种上下文切换会降低开发效率，尤其是在跨模块协作时。
技术债务增加：两种技术栈在依赖管理、错误处理、性能调优等方面有着不同的最佳实践。团队需要为每个技术栈制定不同的管理策略，这可能导致技术债务的积累。例如，Node.js 的异步编程需要处理回调或 Promise 链，而 Java 则更多依赖传统的 try-catch 机制。如果开发团队未能统一错误处理方式，后续的维护工作将变得更加复杂。
测试和部署复杂化：不同技术栈会导致不同的测试和部署工具链。例如，Node.js 项目可能使用 Jest 或 Mocha 进行测试，而 Java 项目则依赖 JUnit 或 TestNG。在部署阶段，Node.js 通常使用 npm 来管理依赖并构建项目，而 Java 则依赖 Maven 或 Gradle。这意味着，CI/CD 流水线需要针对不同的模块配置不同的工具链，增加了自动化部署的复杂性。
团队协作障碍：团队中的开发者可能对某一种技术栈更加熟悉。如果团队成员分工不明确，或者需要在不同技术栈的模块间协作时，可能会遇到技能鸿沟。例如，擅长 Java 的开发者在接手 Node.js 代码时可能不熟悉 JavaScript 的异步处理方式，导致 Bug 频发或进度延迟。反之亦然。

相反，通过保持解决方案的一致性——例如，统一选择使用Java + Spring Boot或Node.js + Express作为后端技术栈——可以确保团队在开发、测试和部署的各个阶段都能使用一致的工具和框架。这样不仅降低了学习成本和上下文切换的负担，还使得团队在协作时更具一致性。测试和部署流程也可以标准化，开发者能够更加专注于核心业务逻辑的实现，从而提高整体开发效率和系统的可维护性。

2.2 如何实现解决方案一致性？

为了实现解决方案一致性，我们需要采取一系列技术和管理上的措施，确保团队在开发过程中能够遵循统一的标准和原则。以下是我们在实际工作中常用的一些的策略和实践：

2.2.1 建立统一的架构原则和技术规范

在项目启动或架构设计的早期，架构师或技术负责人需要制定明确的架构原则和技术规范，并确保团队中的所有成员都理解并遵守这些规范。具体措施包括：

制定技术选型指南：明确系统中使用的核心技术栈（如数据库访问技术、缓存管理、消息传递机制等）。例如，团队可以决定在整个项目中统一使用Spring Data JPA作为ORM解决方案，而不允许直接使用原生SQL或其他ORM框架。这种技术选型需要根据系统的需求和团队的技能水平做出合理的决策。
定义设计模式的应用场景：对于常见的问题，架构师应当指定适当的设计模式。例如，规定在服务层使用策略模式（Strategy Pattern）来处理不同的业务逻辑，而不是让开发者随意选择不同的模式或技术实现。
确定编程规范与代码风格：统一的代码风格不仅能提高代码的可读性，还能增强代码的一致性。通过制定编码规范（如命名规则、注释风格、格式化规则等），并在代码中使用一致的编程风格，可以避免因风格差异导致的困惑和误解。
文档化架构决策：对于每一个重要的架构和技术决策，都要形成文档。这份文档不仅是为了当前的团队成员，也是为了以后加入的开发者能够快速了解并遵循既定的架构规范。

2.2.2 使用代码模板和生成工具

代码模板和生成工具可以帮助团队在技术实现上保持一致性。通过提供预先定义好的代码模板，开发者可以快速生成符合架构规范的代码，避免了手动编写过程中出现的风格不一致问题。具体措施包括：

使用框架提供的代码生成工具：如 beego 框架的 bee generate 。
创建内部代码模板：团队可以根据项目的实际需求，创建一系列内部的代码模板。这些模板可能包括控制器、服务层、数据访问层的标准实现，确保每个模块的代码结构一致。
自动化配置管理：对于基础设施的配置（如数据库连接、日志管理、安全配置等），可以使用框架中的自动化工具或约定优于配置原则，减少开发者手动调整配置的需求，从而保证一致性。

2.2.3 落实 Code Review

Code Review 是确保解决方案一致性的有效手段之一。通过固定的代码审查机制，以及定期的代码评审，团队可以及时发现并纠正不一致的实现方式，确保整个系统遵循统一的设计和技术规范。具体措施包括：

建立严格的代码审查流程：每个开发者在提交代码前，必须经过团队的代码审查。审查的重点除了代码质量之外，还应包括检查代码是否符合项目的架构规范、是否使用了统一的技术栈和设计模式。
引入静态代码分析工具：使用静态代码分析工具（如SonarQube、Checkstyle等）可以自动检测代码中的不一致问题，包括代码风格、架构违规、潜在的错误等。这种工具能够根据预先定义的规则对代码进行检查，并在问题出现时发出警告，帮助开发者在早期修复问题。
定期的架构评审：架构评审是对整个系统架构设计及实现进行统一检查的活动。在架构评审中，团队可以讨论当前的架构是否依然适用，是否有新的技术或模式需要引入，以及现有的解决方案是否一致。通过架构评审，还可以确保整个系统的技术决策继续符合既定的架构原则。

2.2.4 保持团队的沟通与协作

解决方案一致性不仅仅依赖于技术选型和工具，它也需要团队成员之间的高效沟通和协作。团队中的每个人都应该理解和认同一致性原则，并遵循这些原则进行开发。具体措施包括：

定期技术分享与培训：为了确保所有开发人员对系统的架构和技术栈有深入理解，团队可以定期组织技术分享会或培训，帮助开发者熟悉统一的解决方案和设计模式。例如，可以安排关于如何正确使用Spring Data JPA的培训，确保每个开发者都能使用该技术栈的一致实现方式。
建立架构讨论机制：在遇到复杂的技术问题或不确定的实现方式时，开发者应及时与架构师或其他团队成员进行讨论，而不应各自为战。这种持续的沟通有助于避免不一致的解决方案和技术决策。
跨团队协作：在大型项目中，可能会有多个团队同时开发不同模块。在这种情况下，跨团队的技术交流和协作至关重要。团队间的定期同步会议、共享架构文档和技术决策，都有助于确保各个团队在技术实现上的一致性。

2.2.5 标准化的工具链与 CI/CD 流程

工具链和自动化流程的标准化是实现解决方案一致性的另一个关键因素。通过使用相同的开发工具、CI/CD 流程和部署工具，团队可以在从开发到发布的各个环节保持一致性。具体措施包括：

统一的开发环境：为所有开发者提供标准化的开发环境。例如，通过 Docker 容器提供统一的开发环境，确保每个开发者在本地的开发环境与生产环境一致，从而避免由于不同环境配置导致的实现差异。
标准化的CI/CD流程：在 CI 和 CD 中，使用统一的流水线和自动化测试，确保每次代码提交都经过相同的测试和质量检查流程。例如，可以在 CI 管道中集成代码质量检查、单元测试和集成测试工具，确保每个模块都通过相同的验证过程，避免出现质量参差不齐的代码。
统一的发布和部署策略：通过标准化的部署工具（如Kubernetes、Docker Compose等）和配置管理工具（如Ansible、Terraform等），确保系统在不同环境中的部署过程一致，这样可以避免因不同的部署方式导致的运行时错误和不兼容问题。

2.2.6 逐步消除遗留系统中的不一致

在大型项目中，遗留系统中往往会存在解决方案不一致的情况。为了实现解决方案一致性，团队需要有计划地逐步消除这些不一致的问题。具体措施包括：

逐步替换不一致的技术栈：对于遗留的模块，如果存在与当前技术栈不一致的实现方式，可以通过重构或替换的方式，将不一致的部分替换掉。例如，将原先使用的手写 SQL 查询逐步替换为统一的ORM框架。
分阶段的技术债务清理：技术债务的积累往往是导致解决方案不一致的主要原因之一。团队应定期对系统中的技术债务进行评估，并分阶段清理那些导致解决方案不一致的部分。通过持续的技术债务清理，确保系统在长期演进中保持一致性和可维护性。

解决方案一致性是软件系统成功的关键之一，它不仅可以降低系统的复杂性，还能提升团队的协作效率和系统的可维护性。通过制定明确的架构原则、使用统一的技术栈、引入代码审查机制、保持团队的沟通协作，以及标准化工具链和 CI/CD 流程，团队可以有效地实现解决方案的一致性。

在一个长期演进的系统中，解决方案的一致性有助于减少技术债务，避免「架构腐化」，让系统在面对不断变化的需求时依然保持灵活性和可扩展性。通过这些实践，团队能够构建出更加可靠、易于维护的系统，并为未来的扩展提供坚实的基础。

3 形式一致性

形式一致性是指系统设计中各个部分的结构、风格、和实现方式在形式上保持统一和协调。它不仅仅体现在代码的外观和风格上，还包括系统在设计原则、接口定义、组件交互方式等方面的统一性。形式一致性确保了系统的各个模块之间能够无缝协作，减少了理解和维护的困难，并使得系统更加易于扩展和演进。

形式一致性要求设计者在系统的各个层次上都遵循同样的简约和清晰原则，确保每个模块的设计具有相同的模式和风格。例如，系统中所有 API 的命名规则、参数传递方式和返回结构都应保持一致，这样开发者只需学习一次，便能理解和使用所有接口。在前端设计时，所有的用户界面组件应遵循统一的界面规范和交互逻辑，以确保用户在不同模块之间切换时能够获得相同的用户体验。

3.1 简约

在形式一致性中，简约意味着设计需要尽可能地去除冗余，确保每个组件都是必要的、功能明确的。

简约不仅意味着少量的代码或元素，还意味着减少不必要的复杂性。通过使用更少的元素来完成更多的功能，简约的设计不仅减少了开发和维护的成本，还提升了系统的可预测性和稳定性。

在简约的系统中，开发者能够快速理解每个模块的设计意图，并能够在不增加复杂性的前提下对系统进行扩展。

3.2 结构清晰

结构清晰是形式一致性的重要组成部分。它要求系统的设计逻辑应该是直截了当的，模块的职责和功能应该易于理解。每个模块都应具备独立的功能，且模块间的依赖关系应当保持最小化。

结构清晰的系统不仅让开发者能够快速掌握系统的整体架构，还能轻松推测出其他模块的设计方式。在一个结构清晰的系统中，开发者不必反复查阅文档或进行复杂的调试，因为模块的设计和交互逻辑都是一致且直观的。

如在一个微服务架构中，假设我们有一个用户管理服务和订单服务。为了保持结构清晰，这两个服务应该各自负责单一的职责：用户管理服务处理用户注册、登录、个人信息管理等，订单服务则负责订单的创建、支付以及状态管理。这两个服务之间通过 API 进行通信，并且彼此独立，避免了不必要的耦合。如果将用户信息直接嵌入到订单服务中，会导致结构复杂化，增加了理解和维护的难度。通过保持清晰的模块划分，开发者可以很容易地理解每个服务的职责，并在系统发生变化时轻松进行调整。

3.3 隐喻

隐喻是系统设计中提升可理解性的重要工具。通过使用简单易懂、与现实世界或常见概念相类比的隐喻，开发者能够更快速地理解系统的设计意图。隐喻的使用不仅让系统的架构更具亲和力，还减少了开发者的认知负担。

在形式一致性中，隐喻的应用应当贯穿整个系统——无论是从命名到设计模式，还是从接口定义到用户交互，都应当遵循同样的隐喻理念。

如在构建文件系统时，使用「文件和文件夹」的隐喻可以帮助开发者和用户更好地理解系统的组织结构。现实生活中，人们处理物理文件和文件夹的经验非常直观——文件夹用于存放文件，文件可以被打开、编辑、删除或移动。将这种现实生活中的概念引入到计算机系统中，使用户和开发者能够迅速理解系统的操作模型。

通过这种隐喻，用户不需要理解系统背后的复杂实现逻辑，就能够基于现实世界中的经验快速掌握系统的使用方式。同时，开发者在设计时也能够遵循这一隐喻，确保系统结构和操作符合人们的认知习惯，提升了系统的可用性和可维护性。

4 小结

系统架构设计的本质在于持续演进，而一致性则是这种演进过程中不可或缺的基石。

风格、解决方案、形式上的一致性不仅能够减少开发者的认知负担，还能为系统的扩展和维护提供有力的支持。一个具有一致性的系统，往往更具可预测性、更易于理解，并且能够在面对复杂的业务需求和技术变革时保持灵活性与稳健性。

正如 Fred Brooks 所言，一致性不仅是质量的根基，也是系统能够在复杂环境中持续演进的保证。通过在架构设计中贯彻一致性原则，我们不仅在解决当前的问题，更是在为未来的变革与创新铺平道路。

以上。

研发团队没有战斗力，怎么解？

在现代企业中，研发团队的战斗力是企业竞争力的重要组成部分，尤其是在技术驱动型的公司。

一个高效、有战斗力的研发团队不仅能快速适应市场变化，还能通过技术创新为企业创造更多的价值。那么，如何才能打造一个有战斗力的研发团队？

我们先界定问题，拆解问题，然后再看怎么系统化的去解。

1 界定问题

我们需要明确什么是「有战斗力的研发团队」，并清楚当前团队与理想状态之间的差距。

用我和我们家闺女常说的，当有人和你说一些事情的时候，需要看一下他说的「是一个观点还是一个事实」。「研发团队没有战斗力」，这明显是一个观点。基于这个观点，接下来我们要做的，就是去拆解这个观点背后的事实，并找到支撑这个观点的具体原因。

那事实有哪些呢？

1.1 任务完成效率低

团队的任务完成效率可以通过数据来衡量。如果团队频繁出现项目延期、任务积压，或者在完成某些任务时总是比预期时间拖延很多，这通常会被认为是研发团队没有足够战斗力的重要表现之一。这里的事实包括：

项目计划与实际进度的差距有多大？
每个任务的平均完成时间是否过长？
团队在解决问题时是否常常遇到瓶颈？

这些数据可以通过项目管理工具（如 Jira、Trello 等）来进行追踪和量化。一旦明确了当前的情况，我们就能更好地了解团队效率低下的具体原因。

1.2 沟通不畅

沟通问题是研发团队中非常常见的困扰之一。它可以通过以下事实来体现：

团队成员之间是否常常因为沟通不足而产生误解？
在跨部门协作中，是否有任务交接不清、信息传递不准确的情况？
是否存在因为沟通问题导致的工作重复或返工？

通过团队内部的回顾会议、跨部门的反馈等方式，可以明确沟通问题的具体表现和影响。沟通不畅往往会拖慢整体效率，降低团队的战斗力。

1.3 团队士气低落

士气低落是另一个常见的观点化描述，但它背后有很多具体的事实可以支撑：

团队成员是否主动承担任务，还是常常出现推诿现象？
团队的离职率是否高于行业平均水平？
团队成员是否经常表现出疲惫、倦怠，缺乏对工作的积极性？

如果团队中缺乏成就感、归属感，激励机制不到位，这些都会导致士气低落，进而影响团队的整体战斗力。通过员工满意度调查、绩效考核结果等数据，我们可以准确捕捉到士气低落的事实。

1.4 技术债务积累

「技术债务」经常会被忽视，但它实际上是研发团队战斗力不足的重要原因之一。以下事实可以帮助我们判断团队是否面临技术债务问题：

系统是否频繁出现 BUG，导致大量时间用于修复问题而非开发新功能？
是否有大量遗留的代码或架构问题，导致团队在进行新功能开发时效率低下？
系统的可维护性和可扩展性是否在不断下降？

技术债务的积累不仅会拖慢整个团队的开发进度，还可能让团队陷入“救火”而非创新的状态，这无疑是战斗力下降的一个重要体现。

1.5 质量问题严重

质量问题也是影响研发团队战斗力的一个重要因素，并且算是一种非常关键的事实表现。质量问题不仅影响产品的稳定性和用户体验，还会对团队的效率、士气和创新能力造成负面影响。在「研发团队没有战斗力」这一观点下，质量问题可以归结为以下几个具体事实：

有频繁的产品缺陷和返工，可以使用缺陷率、线上故障数、SLA 等指标来衡量
项目交付质量不达标，如功能不完整，性能问题，用户反馈差等
缺乏严格的代码审查和质量控制流程

1.6 工程化和系统化问题

「工程化和系统化问题」是影响研发团队战斗力的重要因素之一，尤其是在团队规模扩大、项目复杂性增加的情况下。工程化和系统化不足通常会导致团队的开发流程混乱、效率低下、交付质量不稳定、可扩展性差，甚至会影响团队的整体协作能力和长期发展。其主要体现在如下几个方面：

缺乏标准化流程
自动化程度不足，缺乏自动化测试，手动操作的事项较多，重复劳动多
系统化不足，缺乏整体架构设计，模块耦合度高或者扩展性差

1.7 人才梯队问题

人才梯队是指团队中不同层级的人才储备和发展体系。如果团队中缺乏明确的人才梯队，意味着团队内部没有清晰的发展路径，成员的技能水平参差不齐，导致团队的整体战斗力不足。以下是一些具体的事实表现：

缺乏明确的晋升机制：团队中没有明确的晋升机制和路径，导致优秀的员工看不到职业发展前景，逐渐失去动力。
关键人员依赖严重：团队中的某些核心人员承担了过多的技术关键任务，一旦这些人离职或出问题，整个项目或团队都会陷入停滞。
缺乏接班人：当团队中的高层或资深技术人员调岗或离职时，缺乏能够快速接替其工作的接班人，导致项目推进或技术维护出现断档。

这些现象说明团队在人才梯队建设上存在严重不足，导致团队的持续作战能力和抗风险能力较差。

1.8 人才密度问题

人才密度指的是团队中高水平技术人才的比例。如果团队的人才密度不足，即高水平人才较少，团队整体的战斗力自然会大打折扣。以下是一些具体的事实表现：

技术水平不均衡：团队中技术能力强的人数较少，大多数成员的技术能力不足以支撑复杂的项目开发，导致高水平的成员承担了大部分工作，而低水平的成员拉低了整体效率。
问题解决能力差：团队整体在面对复杂问题时，解决问题的能力不足，往往需要依赖外部资源或高层决策，无法自主高效地解决技术难题。
技术创新动力不足：由于缺乏高水平人才的引领，团队内部的技术创新能力较弱，难以提出具有前瞻性的技术方案。

人才密度直接影响到团队的技术创新和问题解决能力，因此提升人才密度是打造高战斗力团队的关键。

2 分解问题

在明确了研发团队战斗力不足的主要表现后，我们需要进一步分解问题，以便逐步分析并找到解决方案。根据 MECE 的原则，可以将战斗力不足的问题分解为下列几个方面：

2.1 效率问题

效率是衡量研发团队战斗力的最直接指标之一。如果团队的任务完成效率低下，项目延期频繁，势必会影响整体战斗力。这一问题可以分为以下几个子问题：

流程不清晰：团队的开发流程、测试流程、发布流程是否标准化？是否有明确的职责划分和操作步骤？
工具使用不当：项目管理工具、代码管理工具、自动化工具是否充分使用？是否存在大量的手动操作和重复劳动？
不合理的资源分配：团队成员的任务分配是否合理？是否存在某些成员工作过载，而其他成员任务量不足的情况？
瓶颈无法突破：团队在某些技术领域或开发阶段是否经常遇到瓶颈，导致任务卡住？

2.2 沟通协作问题

沟通不畅往往是导致研发团队效率低下和战斗力不足的主要原因之一。沟通问题可以进一步分解为：

跨部门沟通障碍：研发团队和其他部门（如产品、运营、市场等）之间的沟通是否频繁出现误解或信息不对称？
内部沟通不畅：团队内部成员之间是否缺乏有效的沟通渠道？是否存在信息流动不畅或不透明的情况？
技术与业务脱节：研发团队是否充分理解业务需求？技术方案是否能够及时响应业务的变化？

2.3 士气和激励问题

研发团队的士气低落通常是由激励机制不合理、工作压力过大或缺乏成就感引起的。这个问题可以进一步分解为：

激励机制不健全：绩效考核、薪资、奖金等激励机制是否能够有效激励员工？团队中是否存在“吃大锅饭”的问题，导致优秀员工失去动力？
成就感缺失：团队成员是否能感受到工作的意义？是否有足够的成就感和归属感？
工作倦怠：团队成员是否长期处于高压、加班的状态，导致出现工作倦怠？

2.4 技术债务与质量问题

技术债务和质量问题会严重影响团队的战斗力，因为它们导致团队需要花费大量时间在修复错误和维护上，而不是开发新功能或创新。技术债务和质量问题的细分包括：

代码质量差：团队是否有严格的代码评审流程？代码是否有良好的可读性、可维护性？
技术债务积累：系统中是否存在大量的历史遗留问题（如未重构的老旧代码、架构问题等），导致维护成本高、开发效率低？
缺乏自动化测试：团队是否有足够的自动化测试覆盖？是否依赖大量的手工测试，增加了测试和发布的成本？

2.5 人才梯队建设不足

人才梯队建设不足意味着团队缺乏不同层次的人才储备，导致团队的整体战斗力和可持续发展能力受限。具体问题包括：

晋升机制不明确：是否有清晰的晋升机制和职业发展通道？员工是否知道如何通过努力获得晋升或更多的成长机会？
接班人缺失：是否有计划培养接班人，确保每个关键岗位都有后备力量？
关键依赖严重：团队是否过度依赖某些核心人员，一旦这些人离职或请假，项目进展是否会受到严重影响？

2.6 人才密度不够

人才密度不够会导致团队在面对复杂技术问题时缺乏足够的解决能力，团队的技术创新能力也会因此受到影响。这个问题可以进一步分解为：

招不到合适的人：招聘过程是否存在瓶颈，导致无法及时引入高水平的技术人才？
人才培养不足：是否有系统的内部培训机制，帮助团队成员提升技术水平？
技术水平参差不齐：团队成员的技术能力是否存在较大的差异，导致整体效率不高？

2.7 工程化和系统化不足

工程化和系统化不足会导致团队效率低下、交付质量不稳定，无法应对复杂的项目需求。具体问题包括：

开发流程不标准：是否有统一的开发、测试、发布流程？是否存在大量的手动操作？
自动化程度不够：系统的开发、测试、部署等环节是否充分利用了自动化工具？是否存在大量重复的手工劳动？
架构设计不合理：系统的架构设计是否能够支持业务的扩展和未来的发展需求？是否存在模块耦合度过高、扩展性差等问题？

3 体系化的解决问题

解决研发团队没有战斗力的问题，是一个多维度、跨职能的系统性工程。它涉及到组织文化、组织结构、技术架构、流程设计、工程系统和度量考核等多个方面。每个维度的优化和提升都能够为研发团队带来战斗力的增强，但这些维度并非孤立存在，而是相互关联、彼此支撑的。

我们需要明确的是，研发团队战斗力的提升不仅仅是为了提高「速度」，更是为了提高「质量」和「价值」，即更高效地交付更优质的产品，满足业务需求，并为公司创造长期的价值。

3.1 组织文化和沟通机制构建

组织文化是企业的灵魂，它直接影响员工的行为和思维方式。一个以创新和协作为核心的组织文化能激发员工的创造力，鼓励他们尝试新方法和新技术，并在失败中学习和改进。文化的塑造对研发效能提升而言，是打下「地基」的工作。

如何构建？

建立跨部门沟通机制：通过定期的跨部门会议或项目复盘，确保技术、产品、业务等不同职能部门之间的沟通顺畅。可以采用 OKR 或双向沟通机制，让各部门了解彼此的目标和进展，减少信息孤岛。
鼓励知识共享：定期组织 技术分享会、内部培训，以及设立 技术博客 或 Wiki，这样可以促进技术积累和知识在团队内的流动。还可以通过内部的 导师制，帮助新员工快速融入团队。
认可和激励创新：设立相应的奖项或 肯定机制，对提出创新方案或成功实施新技术的员工进行公开表扬和奖励。比如可以设立 季度创新奖，以鼓励员工在日常工作中不断试验和改进。
领导层的共识：研发负责人应确保与高层管理者达成一致，使研发效能提升工作得到高层支持。领导层的共识会帮助在资源分配、目标设定、团队管理等层面为研发效能的提升提供保障。

我们可以进行如下的一些具体的操作：

定期组织 跨部门的需求讨论会 或 研发复盘会，确保各个部门的需求和反馈能够及时传递。
设立 激励计划，对优秀的创新项目和技术方案进行奖励。
通过 员工满意度调查 或 一对一访谈，了解员工对现有文化的看法，并持续改进。

3.2 调整组织结构

组织结构决定了信息的流动、资源的分配以及决策的效率。一个灵活的、扁平化的组织结构能够促进创新，加速决策过程，同时减少层级间的沟通障碍。通过合理的组织结构设计，可以让团队在面对复杂问题时具备更强的反应能力。

组织结构的调整需要根据实际的团队情况以及业务情况来做优化，是职能型，还是项目型，还是矩阵型等等，可以有如下的一些参考思路：

小型化、自治化的团队：采用 跨职能团队 的形式，促进团队成员之间的紧密合作。每个团队都拥有相对独立的决策权，能够快速响应业务需求。采用 Spotify 模式 或 Scrum 团队 的形式，打破职能部门壁垒，形成更快速决策和执行的团队。
灵活的项目管理机制：引入 动态人员管理 和 内部创业机制，让团队能够根据项目的需求灵活调整人员和资源配置。通过设立 内部孵化器，让员工能够在公司内部尝试新的项目和解决方案。
减少管理层级：通过扁平化管理，减少中间层级的沟通障碍，形成更直接的反馈机制。管理者应该更多地起到 协调者 和 支持者 的作用，而不是微观管理。

在实际操作过程中，我们可以：

设立多个 跨职能团队，每个团队独立负责某个产品或项目的端到端交付。
引入 OKR 管理机制，确保各个团队的目标与公司整体战略保持一致，并且团队间可以灵活协作。
定期进行 组织结构评估，根据业务需求和人员成长情况灵活调整团队架构。

3.3 评估并调整技术架构

技术架构的合理性直接影响团队的研发效率。如果架构设计不合理，团队的开发成本会持续增加，迭代速度会变慢，系统的稳定性和可扩展性也会下降。通过合理的架构设计，可以让团队更高效地应对变化和扩展需求。

以下为一些评估和调整的思路或原则：

模块化、低耦合的架构设计：在架构设计中，遵循 高内聚、低耦合 的原则，确保系统模块之间的依赖性降到最低，便于独立开发和部署。采用 微服务架构 或 服务化架构，将系统拆分为相对独立的服务，确保每个模块可以独立扩展和维护。这虽然是老生常谈，但是很少有组织做得很好。且这里需要根据实际的业务需要和当前架构形态来决策。
云原生架构：通过云原生架构，使用 Docker、Kubernetes 等容器化和编排技术，实现系统的一致性和可移植性，支持快速部署和环境隔离。
灵活的技术栈：根据业务需求选择合适的技术栈，而不是盲目追求技术潮流。技术选择要与团队的技术能力和业务发展阶段相匹配。
DevOps 和 CI/CD 实践：通过持续集成和持续交付（CI/CD）来加速产品发布，减少人工操作的错误，提升发布频率和质量。

具体操作过程中，我们可以：

进行 架构评审，定期对系统的技术架构进行审查，确保架构能够支持当前和未来的业务发展。
引入 DevOps 实践，通过自动化工具（如 Jenkins、GitLab CI 等）实现持续集成和交付。
采用 微服务架构 进行系统划分，确保各个服务可以独立开发、测试和部署。

3.4 优化研发流程

研发流程设计是确保研发活动高效进行的关键。良好的流程设计可以减少非必要的工作，清晰定义各个阶段的输入、输出和质量标准。同时，优秀的流程设计能帮助团队在每个环节上减少浪费，提升整体效率。

以下为常用的一些优化思路：

引入敏捷开发方法：采用 Scrum 或 Kanban 等敏捷开发方法，确保团队能够快速响应需求变化，并通过短周期迭代逐步交付产品。不能为了敏捷而敏捷，根据当前团队情况来实施。
精益开发思想：通过 精益思想（Lean），消除流程中的浪费，减少不增值的工作。例如，减少不必要的会议、文档、审批流程，提升团队专注于高价值任务的时间。
自动化流程：通过引入自动化工具，简化开发、测试和发布流程，减少手工操作和人为错误。比如自动化代码检查、自动化测试、自动化部署等。
数据驱动的流程优化：通过 数据分析工具（如 Jira、SonarQube 等）监控流程中的瓶颈点和低效环节，并持续优化流程。

实际操作过程中可以通过以下的方式来做一些落地的操作：

定期进行 流程审查会议，分析当前流程中的低效环节和瓶颈，提出改进方案。
采用 需求交付周期 和 需求吞吐量 等指标，衡量每个迭代的效率，并根据数据优化流程。
使用 自动化工具 完成代码检查、测试和部署，减少人工干预。

3.5 优化工程系统

工程系统是研发效能提升的基础设施。包括代码管理、构建、测试、部署等一系列工程实践。通过系统化的工具和方法，可以减少重复性工作，提升研发的效率和稳定性。

工程系统如何优化？

统一的开发环境：建立统一的开发环境和工具链，确保团队成员在同一套标准下工作，降低环境差异带来的问题。采用 Docker 等容器化技术，确保本地开发环境与生产环境的一致性。
自动化测试平台：通过自动化测试平台（如 Selenium、JUnit、TestNG 等），实现单元测试、集成测试、回归测试的自动化，提高产品质量，减少人工测试的负担。
版本控制系统：采用 Git 等版本控制系统，建立合理的分支管理策略（如 GitFlow），确保代码的安全性和可追溯性。
监控和日志分析系统：引入 监控工具（如 Prometheus、Grafana）和 日志分析工具（如 ELK Stack），确保系统的运行状况可视化，尽早发现问题并采取措施。

在实际操作过程中我们可以：

建立统一的 Docker 镜像仓库，确保开发和生产使用相同的基础环境。
使用 持续集成工具（如 Jenkins）进行代码的自动化构建和测试。
设立 监控和报警机制，确保系统的健康状况能够被实时监控。

3.6 构建度量考核

度量考核是研发效能提升的反馈机制。它为团队提供了衡量成果和改进的依据，帮助团队识别问题、跟踪进度，并调整优化策略。没有量化的度量，研发效能的提升就缺乏方向和依据。

同时，度量可以让战斗力这个概念可视化出来，更明确什么是有战斗力，什么是没有战斗力。

我们可以用如下的方式落地：

建立科学的度量体系：用一套符合团队实际情况的指标体系来衡量效能，覆盖项目进度、产品质量、团队效率等方面。常见的度量指标包括 需求交付周期、缺陷率、代码覆盖率、部署频率 等。
定期审视数据：定期对这些指标进行审查，分析趋势和异常，找出影响效能的主要原因，并制定改进措施。
将度量结果与激励机制挂钩：通过绩效考核，确保团队成员的贡献能够被量化和认可，并通过奖励机制激励团队不断提升效能。

实际操作：

建立 研发效能仪表盘，实时监控团队的效能指标。
每月定期召开 效能回顾会议，根据数据分析报告，制定下一步的改进计划。
将 研发效能指标 纳入团队的 OKR 或绩效考核体系，确保团队成员的目标与效能提升保持一致。

4 小结

提升研发团队的战斗力是一个体系化、系统化的工程，涉及到组织文化、组织结构、技术架构、流程设计、工程系统和度量考核等多个层面。通过在这些维度上进行持续优化，可以显著增强研发团队的战斗力，提升产品交付的速度、质量和创新能力。

如果要真正的解决研发团队没有战斗力的问题，在上面界定问题、分析问题和解决问题的基础上，还需要有如下的一些操作和逻辑：

建立目标和成功判断
制定详细的解决方案
设定里程碑
制定详细的工作计划
风险判断和未来改进

只有完整落地详细的工作计划，完成里程碑，一步一个脚印，才能真正的打造出有战斗力的研发团队。

每个企业的实际情况不同，因此在执行时需要根据具体场景进行灵活调整。最终目标是帮助研发团队在高速变化的市场环境中，更高效、更稳定地交付高质量的产品，创造更大的商业价值。

关于研发效能在组织层面的一些思考和总结

组织结构决定了信息流动、资源分配和决策过程的效率。在研发效能的提升中，扁平化的管理层级、跨功能的团队配置以及灵活的人员动态管理，都能够促进创新和加速决策过程。

最近在思考关于软件研发效能的事情，而其中关于组织层面有一些想法和总结，如下：

康威定律和逆康威定律

在 1968年，梅尔·康威在《Datamation》杂志发表文章《How Do Committees Invent?》，探讨了组织结构和系统设计的关系。其中一句话后来被总结为康威定律:「任何组织所设计的系统架构，都不可避免的反映为该组织沟通结构的副本。」

康威在开发早期电子计算机系统的组织中观察到，组织的真实沟通路径(即价值创造架构)与最终的软件架构之间存在强相关性。这种同态力将软件架构和团队结构塑造成相同的「形状」。也就是说，构建软件需要理解团队沟通路径，以更加实际地考虑什么样的软件架构是可行的。如果理论上的系统架构与组织模型不符，就需要对其中之一做出改变。

当组织结构变化时，系统架构就会被影响，身在局中的我们感触非常深刻，本来负责 A 业务，调整后负责 B 业务，原来的工作就不想动了；本来在重构某块技术，想把历史的债务还清先，调整后也没有了动力。

作为一个技术人面对这种情况，有时也无能为力，调整后大量的时间是投入在当前的业务中，而看到的历史问题不在你的工作边界之中，只能看着历史债务越集越多，直到某一天，雪崩。

特别是后端，作为业务核心的技术部分，一个 24×7 要在线的，其稳定性，可用性都是非常重要的。

如何通过系统化的机制保障后续架构的稳定演进，并且不会随着组织结构的频繁变动而频繁变动？

要想抵抗组织结构对系统架构的影响，一种办法是适度隔离，比如采用内部开源的方式，让系统脱离具体业务组织而存在，代码由核心小组统一维护。这种虚拟组织不会随业务变动而变动，适用于底层框架、中间件等非业务模块。

但对于业务属性较高的模块，内部开源并不可行。因为其开发和维护需要对业务有深入理解，跨部门的认知成本太高。这时就需要换一个思路：利用康威定律，通过优化团队架构来引导系统架构，减少沟通和认知成本，实现理想的、高内聚低耦合的架构闭环。这就是逆康威定律的应用。

逆康威定律是 2015 年微服务兴起之际，ThoughtWorks 技术总监 James Lewis 提出的概念，即组织要根据他们想得到的软件架构来设计团队结构，而不是期望团队盲从一个被设计好的团队结构。。

其中的核心观点在于，将软件架构看作一个独立的概念，认为它可以被孤立设计，然后交由任何团队来实现，这从根本上就是错误的。软件架构和团队结构的差异在所有架构类型中比比皆是，无论是客户端-服务端、SOA 还是微服务架构。这也是为什么为了让团队聚焦，单体架构需要拆分的原因。

通过逆康威定律的应用，我们可以先设计出理想的软件架构，然后根据这个架构来调整和优化团队结构。这样做的好处是可以更好地匹配业务需求，提高系统的内聚性和可维护性，减少不必要的沟通和协调成本。

具体来说，我们可以采取以下措施：

根据业务领域划分微服务，每个微服务由一个独立的团队负责开发和维护。这样可以让团队对自己的服务有更清晰的认知和掌控，减少跨团队沟通。
建立跨团队的架构治理机制，制定统一的架构原则、接口规范、质量标准等，确保微服务之间的一致性和互操作性。
加强团队内部的自治和责任心，鼓励团队自主决策、快速迭代、持续改进。同时赋予团队端到端的交付职责，避免因职责割裂导致推诿扯皮。
建设公共的技术平台和工具链，提供标准化的开发、测试、部署、监控等功能，减轻团队的基础设施负担，提高研发效率。
营造开放协作的文化氛围，打破部门墙，鼓励团队之间主动沟通和知识共享，形成学习型组织。

康威定律揭示了组织结构与系统设计的同构关系，而逆康威定律则为我们指明了一条突破之路：从组织架构入手，持续优化团队分工，才能推动系统架构向理想方向演进。这需要我们在组织设计上投入更多思考，用系统思维来对待研发效能问题。

团队的认知负载

认知负载是指在特定时间内，工作记忆中的信息负荷。对于个人而言，认知负载就是大脑需要同时处理的信息量。当我们将视角拓展到团队层面时，认知负载就变成了团队在执行任务时所承担的信息处理总量。

一个团队的认知负载并不等于团队成员认知负载的简单加总。团队协作过程中产生的交流、同步、协调等活动，都会带来额外的认知负载。同时，团队成员之间知识和技能的差异，也会影响到认知负载在团队内部的分配。

团队的认知负载也是影响软件研发效能的重要因素。

当系统复杂度超出团队的认知极限时，就会导致生产力下降、质量恶化等问题。

控制认知负载的关键，在于团队内部的”通晓全局”程度，即每个成员对系统的整体理解。

那如何判断团队是否处于认知过载状态？

可以从任务执行、团队氛围、个人状态三个维度来观察。

从任务执行的角度看，如果团队在面对新需求时响应速度明显变慢，对变更的适应能力下降，出现更多交付物质量问题，需要更多的返工和修复，这就是认知过载的典型信号。团队投入了更多的时间和精力，但产出的绩效却在下降，说明认知资源已经难以支撑高质量高效率的工作。

从团队氛围的角度看，如果团队成员之间的沟通变得低效和困难，产生更多的误解和冲突，知识共享和协作的意愿下降，整个团队的创新能力和解决问题的能力下降，团队士气低落，抱怨和消极情绪在蔓延，这也提示团队正在经历认知过载。当团队的认知资源捉襟见肘时，成员往往会降低对他人和整体的关注，转而专注应对自己的工作压力。

从个人状态的角度看，如果团队成员普遍感到疲惫和倦怠，对工作失去热情和主动性，工作与生活难以平衡，出现失眠、健康问题等身心状况，这往往是认知过载的结果。当个人长期处于高认知负荷状态，既要应对本职工作，又要参与大量协调和沟通，还要不断学习新知识，就很容易产生持续的压力感，陷入职业倦怠。

团队认知过载不是孤立的问题，而是会从任务执行、团队氛围、个人状态等方面综合反映出来。作为团队管理者，需要保持敏锐的洞察力，及时捕捉这些危险信号，采取针对性的优化措施，从而保障团队的可持续发展。

为了降低认知负载，我们可以从组织设计和架构设计时都做一些考虑。

在组织设计时，可以考虑如下几点：

适度聚焦。每个团队应该有明确的、聚焦的职责范围，避免过度分散精力。职责范围要与团队的认知能力相匹配，既不能太窄导致产能不足，也不能太宽导致认知过载。
职责自治。团队对自己的职责范围应该有较大的自主权，可以独立做出决策和优化。过多的外部依赖会增加认知负载。
边界清晰。团队之间、系统模块之间应该有清晰的边界和接口，减少耦合和认知依赖。
知识共享。鼓励团队之间主动分享知识和经验，建立共同的认知基础。但要注意，知识共享不等于职责共担。
弹性冗余。在关键领域，适当保留一定的冗余和备份，避免单点依赖。这样可以在保证产出的同时，降低认知负载的风险。

在架构设计时，可以考虑如下几点：

模块化和解耦。将系统划分为逻辑清晰、职责单一的模块，并通过松耦合的方式连接，减少模块之间的认知依赖。每个团队只需深入理解自己负责的模块。
接口驱动。通过定义清晰、稳定的接口规范，将模块的内部实现和外部用途解耦。调用方只需了解接口，而无需关心内部细节。
领域建模。从业务领域出发，识别出稳定的核心业务概念和流程，并据此设计系统模型。让软件架构尽量贴近真实世界，减少认知转换。
约定优于配置。通过制定统一的架构原则、编码规范、工具约定等，在团队之间形成一致的认知基础，减少沟通成本。
演进式架构。架构不是一成不变的，而是随着业务和技术的发展而不断演进的。因此要为变化留出空间，通过持续重构等手段，让系统在可控的范围内优化，避免大规模的推倒重来。

通过对认知负载的有效管理，我们可以显著提升团队的工作效率和整体协同能力。

认知负载，说到底是对人的真正尊重。而尊重，恰恰是最好的管理。

三种常见的团队组织

业务交付团队

业务交付团队，是组织中最主要和基础的团队组织。

业务交付团队是围绕清晰目标和职责，匹配持续变化的业务价值交付任务，形成独立高效工作流的长期、稳定、跨职能团队。

一个业务交付团队通常对应一条单一、完整的价值交付流，可以是一个产品、服务、功能集合、用户故事或用户画像等。团队拥有端到端的能力，能够独立完成从概念到交付的全部工作，快速、安全地持续创造用户价值，而无需依赖其他团队。

业务交付团队要尽可能贴近最终用户，通过生产环境实时监控，获得快速反馈，并据此迅速响应变化和问题。团队规模适中，由高素质的跨职能成员组成，保持长期稳定性，而不是随项目起起落落。

组织内通常存在多种业务交付团队，各自负责不同的业务流，如特定用户、业务领域、地理区域、产品条线等。无论承接何种业务流，团队都应围绕明确的待办事项和优先级开展工作，确保工作流的清晰和聚焦。

一个高效能的业务交付团队应该是这样的：

他们的工作就像一条流水线，特性开发的各个环节衔接顺畅，没有太多卡壳和浪费
团队时刻关注用户反馈和业务变化，能够灵活调整开发计划和优先级
他们勇于尝试新事物，通过小步快跑的试错方式来推动改进，并善于从成功和失败中吸取教训
团队内部各司其职、协同高效，很少需要跟其他团队交接工作
他们交付的速度又快又稳，代码质量也有保障，还能兼顾技术升级和团队成员的健康
团队会投入时间优化系统架构和代码，「修修补补」以防「房子」越来越破
他们懂得借助专业团队的力量，定期跟架构、基建、工具等团队沟通，补齐短板，让自己更专注
团队成员有足够的自主权，在技能上精益求精，工作目标明确，从而获得成就感和价值感

业务交付团队是组织的一线力量和价值核心，其他辅助型团队如技术智囊团和基建平台等，都是为了补齐能力短板、降低认知负载，让业务交付团队得以更高效地运转和创新。这种以业务交付为中心的团队组织模式，是相对于传统的职能式、项目式组织的一种进化。

组建长期、稳定、高度自治的业务交付团队，打造清晰的端到端业务流，是实现快速、频繁、可靠价值交付，适应快速变化的关键所在，代表了现代软件开发组织的进化方向。

平台团队

平台团队的目标是赋能业务交付团队，使其能够高度自治地交付工作。平台团队提供的内部服务，使业务交付团队无须开发底层服务，降低了认知负荷。这里的平台是指其作为公司内部的基础产品，向开发团队提供自服务的 API、工具、服务、知识和支持。借助平台，业务交付团队获得了自主性，可以更快地交付产品特性，减少开发过程中的各种协调、沟通。

业务交付团队可以方便地使用平台团队提供的自服务的网站门户和/或编程API（而非厚厚的使用手册）。「方便使用」是采纳平台的基本要求，并且平台团队必须将他们所提供的服务视为一种产品，无论这些服务是被内部还是外部用户所使用，要具有可信赖的、易用的、量身定做的特征。

平台团队可以提供不同级别的服务，但如果所有业务交付团队都要求高等级服务（如零停服务时间、自动扩缩容、自动修复），平台团队则难以支持。为避免人人都要求高等级服务，可以为这些内部基础设施和服务定价，向使用团队收费。

作为基础设施工程团队，平台团队需要聚焦于开发团队的工作流，以及应用和基础设施的改变如何影响用户。为了帮助开发团队用户更高效地使用平台，平台团队需要做到：

把内部平台视为线上/生产系统，计划和管理维护时间
引入软件产品管理和服务管理技术

一个高效能的平台团队应该有以下行为和产出：

与业务交付团队密切协作，理解其需求
依赖快速原型，尽早引入业务交付团队以获得快速反馈
重点关注服务的可用性和可靠性，将平台视为产品，定期回访用户以确认服务是否满足需求
自己也应是所提供服务的用户，与业务交付团队并肩战斗
明白新的内部服务将像创新曲线那样被逐步引入，而非一蹴而就

平台团队和传统的基础设施团队略有不同，突破了传统基础设施团队与业务团队之间的隔阂，通过提供自助式的平台服务，赋能业务团队快速构建和交付应用。与传统基础设施团队相比，平台团队更加贴近业务，团队成员除了技术能力外，还需要具备产品管理、用户体验设计等技能。

专业系统团队

在软件开发过程中，有一些模块或逻辑涉及高深专业领域知识而显得特别复杂，开发和维护都需要相关领域的资深专家（人也特别贵），对于这样的专业系统，我们通常会单独构建团队，称为为「专业系统团队」。

专业系统团队的成员都是某个领域的能手，精通子系统涉及的核心技术。比如 AI 算法模型、视频编解码、特定数学模型、实时交易算法、财务报表系统、人脸识别引擎等，都是典型的复杂子系统，需要专业系统团队来专门负责。

组建专业系统团队的主要目的，是为了给使用这些核心子系统的业务团队减负。本来这些「绝世武功」需要专业系统团队的「武林高手」倾囊相授，现在业务团队只管安心用就行了，不必自己还得练上几年。这样不仅能让每个团队专注自己最擅长的事情，也能节省组织的时间和成本。

需要注意的是，专业系统团队和传统的「组件团队」有本质区别。后者的设立往往是为了让多个团队共用同一个组件，而专业系统团队纯粹是为了「解决疑难杂症」，和代码复用无关。

那么，一个高效能的专业系统团队应该是什么样的呢?

在子系统的设计开发阶段，专业系统团队要和相关业务团队齐心协力，共同定义需求、制定计划、开发功能、测试验证，即「同进同出、战略合作」。到了后期子系统逐渐稳定了，专业系统团队就可以相对独立，专注于系统演进、接口优化等核心工作，和其他团队的互动会少一些。
有了专业系统团队的加持，子系统的开发质量和速度都要明显好于单靠业务团队的情况。这可以作为考核专业系统团队绩效的一个重要指标。
专业系统团队的工作安排要以服务好业务团队为宗旨。要紧贴一线，及时响应需求，灵活调整计划，按业务优先级来排期交付。

一些观点

并非所有的沟通和协作都是有价值的。
保持团队规模的相对稳定。
在实现软件交付之前，先统一团队语言和共同协作方式。
团队的代码所有权并非是在划分地盘。团队对代码的责任，不应该是「这是我的地盘，别人不能进来」，而应该是「这是我负责打理的一亩三分地，要让它生机勃勃」。
软件设计不是非黑即白的选择题，而是一种平衡，如在选择架构时，不是要在单体架构和微服务架构之间做出选择，而是要适配团队的最大认知负载。

以上。