于是今天就聊聊 OKR，聊下 OKR 是为组织解决什么问题，如何生成 OKR，写 OKR 过程中对于上线时间这种要不要写进去，以及 OKR 和 OGSM 有什么关系。

先想一下一个组织为啥要用 OKR 这个工具，其解决的是什么问题？

OKR 是一种帮助组织设定、追踪和实现目标的目标管理工具。

其解决的主要问题包括以下 4 点：

一，聚焦和优先级的问题，因为组织经常面临资源有限的问题，需要确定优先关注的领域。OKR 通过设定明确的、优先级排序的目标，帮助团队和个人集中精力在最重要的任务上。

二，透明度和对齐的问题，通过公开共享 OKR，组织内的每个团队和成员都可以对其他部门和同事的目标有所了解，从而确保所有人的工作都朝着相同的方向推进，实现组织目标的一致性和对齐。

三，衡量和追踪过程的问题，OKR 提供了一种衡量进展的机制，通过定期检查关键结果，组织可以实时了解他们是否接近既定目标，从而及时调整策略或努力方向。

四，激发员工参与和动力，OKR 通过设定具有挑战性的目标来激励员工，同时关键结果的实现也让员工感受到成就感，从而激发他们的积极性和参与度。

除以上 4 个以外，OKR 在提高执行力也能发挥比较大的作用。

当一个组织用 OKR 来做战略执行，来管理目标时，我们作为一个技术团队的管理者，应该如何生成 OKR？

OKR 的生成是一个从上到下，再从下到上，反复进行的过程。

从上到下的逻辑是组织负责人先要确定组织的愿景和年度或季度战略目标，第一版的 OKR 应该是负责人先写，提供一个清晰的方向和预期的成果。这样才能有聚焦的方向，让参与的每个人或团队都有自己明确的目标。

从下往上的逻辑是下一层管理者和团队成员根据自己的角色和对业务的了解，对这些目标进行评估和反馈。这样做是发挥每个人的主动性，让他们感到自己在为明确的目标而战，而不是单纯服从领导的指令。

在生成的过程中，管理层和团队成员之间就 OKRs 进行多次探讨和沟通，根据实际情况和团队输入进行调整。这个过程确保了 OKRs 的共同所有权和承诺，每个人对结果都有责任感。

这样结合了管理层的指导和团队成员的具体知识，创造出既具有挑战性又实际可行的目标。还促进了全组织的参与和承诺，每个人都对共同的成功负责。

在具体写 OKR 的过程中，有一个点有时会有点纠结，上线时间要不要写到 OKR 里面来？取决于什么？

是否将项目的上线时间放入 OKR 中取决于该目标如何与组织的更广泛目标和优先级相结合。OKR 的关键在于设定可以推动组织向前发展的目标和可以量化结果的关键成果。在决定是否将项目上线时间纳入 OKR 时，可以考虑下面 3 个点：

1. 目标关联性：项目上线时间是否与目标紧密相关，是否能显著推动业务价值或用户价值？
2. 可衡量性：上线时间是否是衡量成功的关键指标？
3. 控制性：团队是否有控制上线时间的能力？如果上线时间受到外部因素影响，是否有相应的应对策略？

如果项目上线时间符合上述考量点，并且可以帮助团队或组织专注于关键的业务成长和客户价值提供，那么将它作为一个关键结果（KR）是合适的。然而，如果上线时间是一个单纯的截止日期，并不直接映射到可衡量的业务成果，那么它可能不适合作为 KR。在这种情况下，上线时间可能更适合作为团队的里程碑将业务的上线时间放入 OKR 中可能不太合适，因为 OKR 更倾向于衡量结果而不是活动或任务完成情况。上线时间更像是一个项目管理里程碑，而不是一个战略级的关键结果。

如果上线时间背后有更深层的战略目的，那么可以将这个目的转化为 OKR。如目标是：

• 目标（Objective）: 成功推出新产品，以增加市场份额。
• 关键结果（Key Result）: 新产品上线后的前三个月内达到10万用户。

在这个例子中，上线时间是实现关键结果的一个步骤，但关键结果本身关注的是上线后的用户增长情况，这是一个可以量化的结果。

如果上线时间对于业务战略至关重要，比如市场时机对于产品成功非常关键，那么可以把它与关键结果联系起来，如：

• 目标（Objective）: 抓住市场先机，快速响应市场需求。
• 关键结果（Key Result）: 在 XX 日期之前完成产品上线，以满足季节性市场需求。

在这种情况下，上线时间成为了实现目标的关键一步，但更重要的是，它与市场需求和产品成功的战略目标相联系。

聊完了 OKR，再聊一下 OGSM，OGSM 和 OKR 一样，都是战略规划和执行的框架，都旨在帮助组织设定目标并衡量进度，并且 OGSM 略早于 OKR 出现。

OGSM 的英文全称是：Objectives, Goals, Strategies, and Measures

• 目的（Objectives）：与 OKR 中的目的类似，是组织希望实现的宏伟愿景或方向。
• 目标（Goals）：通常是一系列的定量目标，它们定义了实现目的所需要达成的具体成果。
• 策略（Strategies）：描述了将如何达到上述目标和目的的具体方法或途径。
• 衡量标准（Measures）：用于跟踪策略执行情况和目标完成情况的指标。其中 Measures 包括 Dashboard 和 Plans。

和 OKR 的快速迭代相比，OGSM 通常用于年度规划，具有更长期的视角，侧重于持续的战略执行。

在写 OGSM 的过程中，有以下的点要注意：

• Objective 要设定某个特定对象，能正确反映了组织、个人的愿景
• Goal 要对应 Objective 的关键词
• Goal 要符合 SMART 原则
• Strategies 要承接 Goal 的达成
• Measures 要对应 Strategies 的达成情况
• Dashboard 要能够正确衡量如何执行策略，比如 如何找到策略资源？如何使用策略资源？能够衡量这些才是关键。
• 要避免混淆 Dashboard 和 Plans

用一句话来说就是：先有目的（O），再有目标（G）来衡量 O 的达成，S 是用来支撑 G 的达成的，每个 S 都会有对应的 M 指标来衡量，而每个 M 指标都会有 Plan 来支撑。

所以顺序是  O –> G –> S –> M（KT）

OGSM 是一个更为全面的战略规划工具。OGSM 的力量在于它的结构性和层次性，它不仅帮助团队设定目标，还指导他们如何实现这些目标。OGSM 的一个关键优势是，它将策略和衡量标准结合起来，从而为实现长期愿景提供了一条清晰的道路。

通过使用 OGSM，组织可以确保其战略规划不仅仅停留在高层次的目标上，而是拥有一套清晰的行动计划和衡量标准。这种方法提供了一个框架，可以帮助团队在整个执行过程中保持关注，并及时调整策略以应对不断变化的市场和业务环境。

不管是 OKR 还是 OGSM，当我们在使用这些工具的时候都需要理解这些工具背后的逻辑，确保它和我们的组织文化、工作流程等相匹配。它们不仅仅是目标和结果的清单，而是组织文化、战略思维和团队协作的催化剂和润滑剂。

作为一个技术团队的管理者，此时除了面对业务的诉求，从技术架构、从团队管理、从未来发展应该做些什么呢？

以下是最近一段时间来，个人的思考。

从经营的角度来看，研发团队成本对于软件企业来说是成本的大头，作为团队的负责人需要在满足业务需求的前提下，提高研发团队的产出和产出的价值，同时尽量降低过程中的成本，也就是在之前文章中所说的研发价值。

这里的研发价值可以具象到研发效能这个概念，在我们做技术规划和 OKR 时，底层思考中的研发效能不仅仅是衡量研发资源使用的效果，更进一步，是指研发团队达成既定目标和结果的能力，换句话说，就是提升当前研发团队的核心竞争力。

研发效能不仅包括了技术层面的各种实践，如代码复用、自动化测试、持续集成（CI）和持续交付（CD），还包括了效能度量、流程优化，团队协作、项目管理、需求理解和用户反馈的及时整合等多个方面。

研发效能的核心目的是优化交付的价值链，通过提高效能来缩短产品从构思到市场的时间，提升产品质量，降低开发成本，以及增强对市场变化的响应能力。这不仅能提高客户满意度和用户体验，还能为企业带来更大的经济效益和更强的市场竞争力。

每个企业，每个团队在做规划时，应该是基于现况，基于客观事实来做规划，明确当下最重要，最需要解决的问题是什么，确认目标，一个个去解决。比如当前大家意识层面有所欠缺，那就想办法拉齐认知「共读一本书」；又或者当前研发流程混乱或者效率不高，那就梳理研发流程，把研发的过程一个个掰碎了，揉散了看哪里有问题，该去掉去掉，该优化优化；又或者当前无法看到效能情况，没有体系化的指标和系统支撑，那就去构建，去实践……

各家不同，各有章法，这里我们从研发效能的定义出发，扩展出其要解决的问题，再到具体包含的内容来思考整个过程，不会大而全，也不会特别深入，只是一个思路。

1 概述

在《软件研发效能权威指南》中对于研发效能的定义是指更高效、更高质量，更可靠、可持续的交付更优的业务价值。

将其拆解开来，可以分为三个方面：一是高效和交付更优化的业务价值，关注的是价值交付，二是可持续，关注的是能力构建，三是高质量和可靠，关注的是成本控制。延展开来可以分为效能认知、组织结构、效能度量、研发流程、工程体系、架构能力、技术能力、质量管理和稳定性管理九大模块。整体如下图：

2 效能认知

关键词：老板工程、规模化

研发效能是一个从上往下的老板工程，就算是一线的员工想要做并且努力做了，达到的效果也有限。

其一定是实现了规模化后才有着明显的效果，从度量的效果上看，在规模化之后才能更好的发现和解决问题，个体差异在这里会被规模化效应所取代。

研发效能要解决的是三个方面的问题：价值交付、能力构建、成本控制。

• 价值交付主要关注交付的过程，通过过程中流程的梳理和优化，以及对软件自动化工具的建设提升研发的效能。
• 能力构建主要关注通过研发能力的构建，保证交付的可持续性。
• 成本控制主要关注研发过程中产生非正常成本的点，如质量、故障等等。

以上只是概念性的简要的内容，基本上就是开头那张图了，可以把这些逻辑在团队内达成一致，知道全局是怎样的，现在正在哪里。

再深化一些，可以就每个模块做一个指向性的成熟度模型，明确当前在哪里，以及将来要去哪里。强调一点，就算我们做了成熟度模型，我们也并不是追求成熟度模型指标上的成长，这只是一个过程，我们更看重的是研发效能的提升和价值的交付。

3 组织结构

关键词：信息流动、决策、协同

组织结构决定了信息流动、资源分配和决策过程的效率。组织结构是研发效能的基座和架子，一个合适的组织架构可以更好的提升研发的效能。

以研发效能平台落地为例，如果提出需求的人在一个部门，实现需求的人在一个部门，两个部门的目标可能就会有一些不一致的地方，沟通上跨部门沟通的成本也会比较高一些，那这个项目的研发效率就会比较低。

在一个组织内，信息流动的顺畅程度直接影响到研发的响应速度和能力。理想的组织结构应该是信息高度透明和流动性强的结构，这样可以最大限度地减少知识的壁垒和信息的延迟。创建开放的沟通渠道和建立跨部门的协作团队是关键，这样能够确保从需求提出到需求实现各个环节都能迅速连接，实现信息的快速传递。

决策的速度和质量在很大程度上取决于组织结构。在一个层级过多的组织中，决策往往需要经过漫长的审批流程。扁平化管理模式有助于缩短决策链条，提高决策效率。在扁平化的组织结构中，决策权下放到更接近实际工作的团队和个人，这样不仅可以加速决策过程，还能提高决策的准确性，因为决策者能够直接获取到一手资料和反馈。任正非有提过：让听得见炮声的人做决策，这个论点在研发效能的提升上也同样有效。

4 效能度量

关键词：可视化、全局思维、机制

说到研发效能，大家都会想到搞一套指标，搞一堆系统，然后各种报告，觉得没有啥用。如果只搞这些，确实没啥用，甚至有些本末倒置。

度量是为了什么？是为了可以看见，是为了消除系统性瓶颈。

因为除度量外的操作都已经融入实际的研发管理工作，或多或少，而度量是一个将这些研发管理工作的成效可视化的过程，让人们更直接的感受到优化后的效果。

效能度量只是研发效能中的一小部分，只是辅助效能提升的一种基础性的模块，我们过去对于其投入较少，缺少体系化的度量，当下要补足这个模块。并且这个模块是我们研发效能提升的眼睛，通过度量实现效能的可视化和研发效能提升过程中的反馈机制。它提供了衡量成果和改进的依据，帮助团队识别问题、跟踪进度，并调整优化策略。

在效能度量过程中，我们会以一种相对科学的方式收集和清洗数据，建立一套和当前团队贴合的指标体系，涵盖项目进度、产品质量、团队效率等各个方面，建立机制定期审视这些指标，并根据数据进行决策和改进。

度量的过程，从传统的大量质量指标，到体系化的效能指标，再到结构化的效能报告，有逻辑，更直观。

在这个过程中，看见系统性的指标只是第一步，根据指标来进行决策和改进才是度量的关键逻辑。也就是说度量只是我们研发效能的开始，是结果的一种呈现，我们所追求不仅仅是这个结果，而是这个结果带来的效能提升和研发团队的价值提升。

在度量时始终需要有全局性思维，不要为了指标而指标，将其变为一个数字游戏，也不要陷入到局部的细节指标中而忽略了为什么要做度量。

注意，度量是有成本的，在实施的时候，不要追求度量的大而全，不要一开始就搞一个完整的度量体系，这是一个长期的渐进式的工作，从业务、产品、开发、QA 各方都需要介入的过程，并且最终需要落地到系统上来。

5 研发流程

关键词：有序、标准、端到端的流程

研发流程是为了确保研发活动有序进行的关键。良好的流程设计能够最大程度地减少不必要的工作，清晰地定义每个阶段的输入和输出，以及相应的质量标准。

如果把软件开发比作一个生产产品的流水线，那么研发流程就类似于产品的生产工艺——它是定义产品从原料到成品的所有转换步骤的详细规划。

工艺的好坏决定了产品的好坏。

在整个软件开发的「生产工艺」中，每一步都不是孤立的，而是与前后过程紧密相连，通过反馈和持续改进来提升最终产品质量。敏捷方法论和持续交付的实践强调了在整个研发流程中不断地评估和调整工艺步骤，以适应变化的需求和市场条件。

从技术团队规划的角度，还是要拆解整个研发流程，或者说拆解整个工艺，引入敏捷开发方法和精益思想，持续迭代流程，以消除浪费，并通过自动化工具或系统减轻重复性工作负担。

我们知道研发的好坏，以及研发的价值往往是由源头决定的，产品需求，甚至业务需求。因此，在我们做研发流程优化的时候，尽量把业务方、产品侧都纳入进来，做到从业务中来，到业务中去，实现端到端的控制和优化。

6 架构能力

关键词：复杂度、关系和结构

架构能力关注的是软件架构中的关系和结构，关注的是整个架构的复杂度。而不仅仅是搞个啥架构。

在软件企业发展过程中，架构会随着业务的不断发展而呈现劣化、复杂化等趋势。

我们在架构复杂度提升，规模不断增加、人员不断变化的前提下如何通过对架构的优化实现效能的提升是这里要做的命题。

架构能力的提升包括三个方面：架构规划、架构审查和架构治理。

架构规划是架构能力的首要环节，其必须综合考虑系统的功能需求、性能目标、安全性要求、可维护性及扩展性等多个维度。这种规划类似于建筑领域的城市规划，不仅要考虑当前的建设需求，还要预见未来的扩张和变革。在软件架构的世界里，这意味着设计时要有前瞻性，能够在不牺牲现有系统稳定性的基础上，适应快速变化的业务需求和技术革新。

一个有效的方法是采用模块化设计，即将系统分解为多个相对独立、功能明确的模块。这样不仅有助于降低整体复杂度，还能够使团队能够并行工作，提高开发效率。但是，需要明确一点是不要过度，模块化的结构需要和当前业务状态、团队规模匹配，防止无意义的扩大，从而增加整个系统的复杂度。

架构审查有点类似于医生的定期体检，它可以帮助团队识别潜在的问题，并在问题成为危机之前进行干预。这个过程中，我们可以利用各种架构评估方法，如 ATAM 评估方法（架构贸易分析方法）、CMAM 评估方法（组件建模评估方法或架构评估框架，以确保架构符合业务的目标和制约。

架构审查也可以根据自身企业的情况，构建自身的标准，如类似于成熟度模型之类的来评估当前的架构状态。

在评估审查中，应收集关键利益相关者的反馈，并结合各项指标和用户数据来做出决策。

接下来就是架构治理，架构治理可能涉及到技术栈的变更、新技术的采纳、旧系统的淘汰等。这些调整应该是渐进的，并且与业务战略紧密对齐，确保每一步都朝着增强软件可交付性和业务价值的方向迈进。

这里特别要强调一下关于架构评估过程中对于技术债务的偿还，在快速发展的企业中，这种债务特别明显，因为随着业务的发展，技术债务往往逐渐累积，这对架构的可持续性构成了威胁。技术债务可能源自早期的决策，当时的快速实现为了满足眼前的需求而牺牲了长期的可维护性。

处理技术债务并不总是意味着需要进行大规模的重构，有时候持续的小步改进更为有效。通过持续集成和持续部署(CI/CD)的实践，可以在日常的开发流程中逐步减轻债务负担。此外，编码标准和代码审查可以预防新的技术债务的产生，这对于保持架构整洁和可管理至关重要。

7 技术能力

关键词：复用、标准、前瞻性

技术能力和架构能力相比更关注技术能力本身的上限或边界，是指用技术来提升产品竞争力的能力，如跨端复用能力、技术框架、业务框架、业务组件或能力，其本质是通过构建能力的复用实现能力的提升。

技术能力构建的关键逻辑在于复用性与标准化、以及技术的前瞻性。

复用性意味着开发者可以在多个项目中使用同样的代码或组件，而无需重新发明轮子。通过创建通用的库、框架或服务，组织可以减少冗余劳动，加快开发流程，并降低出错的概率。

而标准化则为这种复用打下基础。它确保了不同团队开发的组件能够无缝集成，无论是内部接口，还是面向外部的 API。标准化还涉及到编码规范、文档标准以及工具链的一致性，这些都是确保技术团队能够高效协作的要素。为了实现这些标准，组织往往需要建立起一套严格的质量保证流程，包括代码审查、自动化测试和持续集成。

复用性和标准化看到的是当下，通过现有业务和技术能力，提升复用率。而技术前瞻性则是面向未来，通过对技术发展的趋势预测，提前布局。

技术前瞻性的构建需要团队的管理者刻意去构建，常用策略包括允许工程师在工作时间探索新技术；建立内部分享会，鼓励知识的交流；甚至与外部研究机构或高校合作，共同进行技术研究项目等等。

同时，奖励那些能够带来创新思路和解决方案的个人和团队。这种机制可以是奖金，也可以是职业发展上的机会。同时，组织应该提供必要的资源支持，如投资先进的工具和技术、提供专业培训等，以确保团队成员能够不断提升自己的技术能力，并把这些能力转化为企业的持续竞争优势。

8 质量管理

关键词：永远的质量、全员参与

质量管理包括过程质量和结果质量（线上质量），最终目的都是结果质量。

质量管理的目的是想通过质量控制减少因为质量问题带来的成本，如果一个产品问题到了用户反馈的程度，那将会卷入技术支持，QA、研发等同学，甚至会有客户成功的同学，将会有一个长长的流程把这些同学串起来以解决问题。如果这个产品问题在最前置开发的时候或者产品需求的时候，将会大大减少成本，提升整个的效率。

其中，过程质量关注的是从产品设计到最终交付整个生产流程的各个环节。控制过程质量的目的是为了确保每一步骤都按照既定标准执行，从而预防质量问题的发生。在软件开发中，这可能会涉及代码审查、持续集成、自动化测试等实践。这些实践能够及早发现问题，防止它们在开发周期后期扩大。

为了提升过程质量，我们都会建立一套完善的质量管理体系，这包括制定明确的质量目标、过程标准以及评估机制。例如，采用敏捷开发模式可以通过短周期迭代确保产品的持续改进和质量控制。通过将开发过程分解为更小的部分，团队可以更快地识别并解决问题，从而降低风险和成本。

结果质量或线上质量主要指产品发到线上环境，直接服务于用户时的表现。这是质量管理最终的评判标准，直接关系到用户体验和产品的市场表现。因此，结果质量的衡量不仅仅是产品交付后的一个阶段，而是一个持续的过程。这要求我们在产品发布后继续监控其性能，收集用户反馈，并根据这些数据不断优化产品。

为了确保结果质量，我们需要采取多种方法来监测产品性能，比如使用应用性能管理（APM）工具监控软件运行状况，或者设置用户反馈渠道收集用户意见。同时，定期进行用户满意度调查也是评估和保障结果质量的有效手段。

质量永远是技术规划或 OKR 的一部分，持续的去优化去实践。

并且质量管理并不只是 QA 部门的责任，而是需要全公司上下共同努力的结果。这要求每个员工都要有质量意识，从每个人的日常工作中都要考虑质量管理。

特别是管理者，是质量管理的关键，管理者需要持续的参与和支持质量管理，通过资源投入，策略制定甚至亲自参与到质量活动中来，以展现我们对质量的承诺。

9 稳定性管理

关键词：多维度、高可用、控制

稳定性管理是成本控制的另一个关键点，每一次稳定性的问题都会对用户产生影响，甚至可能对公司的品牌和财务状况造成长期的负面影响。

关于稳定性管理我们可以从多个维度来解构它的实施路径，一般会包括运维合规、高可用架构治理、变更管控、容量管理、风险管理、故障管理等 6 个方面。

• 运维合规：运维合规能够确保所有操作都符合既定的政策和标准。这意味着从数据中心的物理安全到云服务的配置，每一个环节都需要规划好并遵循明确的标准和最佳实践。合规化有助于减少人为错误，同时确保系统在面对审计时能够展示其稳定性和安全性。实践中，这常常涉及定期的审计和评估，以确保所有操作都在控制之下。
• 变更管理：变更管理是确保系统稳定性的关键组成部分。在这个过程中，所有的系统变更——无论是软件更新、硬件替换，还是配置调整——都需要经过严格的审查和测试流程。这是为了确保任何变更不会对现有系统造成不可预测的影响。变更管理的核心在于减少不经意的后果，通过详细的记录、评审、批准、测试和监控变更流程，来提高系统的整体稳定性。
• 风险管理：风险管理过程涉及对可能影响系统稳定性的潜在风险进行识别、评估和优先排序，并制定缓解措施。这个过程需要不断地进行，因为新的风险总是在不断出现。通过建立一个全面的风险管理框架，组织可以对付潜在的问题，减少未知因素带来的冲击，从而保持系统稳定。
• 高可用架构治理：高可用架构的设计是为了确保系统即使在部分组件失败的情况下也能继续运行。这通常通过冗余、负载均衡、故障转移和分布式系统设计等技术实现。高可用架构的目标是减少单点失败的可能性，并且在出现问题时能够快速恢复服务，保证系统的连续运行。
• 故障管理：故障管理关注的是如何有效地识别、响应、记录和分析故障。它包括建立一个透明的过程来处理故障，以及确保足够的资源用于故障恢复和后续的预防措施。通过彻底的根因分析，可以从故障中学习并防止未来的重复，从而提高系统的稳定性。
• 容量管理：容量管理确保系统有足够的资源来满足日常运行和未来增长的需求。这包括对硬件、软件和服务的需求进行预测和规划，以避免过载导致的性能瓶颈。通过对现有资源的有效管理和对未来需求的精准预测，容量管理能够确保系统即便在负载增大时仍能保持稳定。

10 小结

在实际做规划时，并不需要在年度规划中把所有的项写上，而且也没有这么多的资源来做这个事情。

在选取时规划时主要考虑当前业务所在的生命周期和团队规模。

不同业务生命周期阶段对研发的要求有所差异。在业务启动阶段，研发团队应集中于快速且高质量地满足业务需求的交付。随着业务进入发展阶段，重点转向通过效能指标促进产品功能的标准化和业务能力的沉淀，为规模化复制做好准备。当业务成熟，研发应专注于提升稳定性和效率，降低成本，并通过技术创新寻求新机会。而在业务消亡阶段，关键在于资产的沉淀复用，以保留组织的长期投入价值。

团队规模对研发效能策略同样有显著影响。小型团队，通常规模较小、专注领域单一，应聚焦于提升研发过程效率，而非任务交付量。中型团队面临着更复杂的业务和紧密的合作需求，应将研发效能建设集中在流程和标准化上，以简化协作并确保产出质量。大型团队则需要重视不同小团队之间的协调和合力，注重在宏观层面的业务影响，并聚焦于结果评估和效果衡量。

我们当前需要基于公司战略和方向，根据团队的实际情况，明确资源和目标的匹配度，选取一些当下特别痛的点来突破。以全面的思考为整体技术规划的方向指引，以单点突破的方式逐步推进，从而达到整体研发效能提升的目的。

以上，只是一个思路。