负责任的技术规划 —— 不仅仅是技术

分享嘉宾 | 许晓斌

编辑 | Kitty

策划 | QCon 全球软件开发大会

无论是为了更好的支撑业务，还是凝聚并激发团队，技术规划都是技术管理者的核心职责之一。管理者往往需要结合行业的趋势、团队的构成、遗留系统的状态、组织的激励和文化机制，去制定并迭代合理的技术规划。在 10 月 18-19 日举办的 QCon 全球软件开发大会上，阿里巴巴技术总监许晓斌作了题为“负责任的技术规划 —— 不仅仅是技术”的专题演讲，以阿里巴巴内部研发和运维平台产品的建设为背景，介绍技术规划的思考和实践路径。

2025 年 4 月 10 - 12 日，QCon 全球软件开发大会将在北京召开，我们策划了「大模型驱动的组织管理创新」专题，如果你有 AI 深度赋能帮助团队降低认知负担，提升团队效率相关实践案例想要分享，欢迎点击链接提交演讲申请。

内容亮点

• 学习到技术规划的一种可行的方法论。

• 以技术的背景进入产品思维。

• 理解组织和激励设计对技术的影响。

以下是演讲实录（经 InfoQ 进行不改变原意的编辑整理）。

在今天的演讲中，我们将深入探讨技术规划的重要性。首先，我们要问自己，技术人员是否必须了解业务？如果每个人都需要懂业务，那么谁来执行？是否只有领导者需要掌握这些知识？如果需要，那么他们应该了解哪些业务知识？为什么要了解？这些问题将在今天的讨论中得到解答。

首先，我们将从技术规划的起源开始，探讨为什么要进行技术规划。接着，我们将讨论业务、产品和技术目标之间的相互关系。然后，我们将转向 OKR，这是许多大型企业都在使用的目标设定框架。我们将探讨 OKR 的正确和错误用法，以及如何在实际工作中有效应用。最后，我们将讨论如何建立一个团队文化和氛围，以支持这些技术规划和业务理解的发展。这个话题可能相对学术一些，因为我在准备 PPT 之前，已经在内网发表了一篇长文。基于那篇文章，我稍作修改，将其转化为今天的分享内容。

背景、技术规划源头

我负责的业务领域是基础设施，这是一个容易出现故障的部分。一旦基础设施出现问题，内网中就会响起一片抱怨声，同事们会感叹：“哎呀，又挂了。”我们还有一个答疑群，这个群规模相当大，大约有七八千人。由于群成员数量庞大，群每年都需要走审批流程才能继续使用，以避免舆情风险。这个群是我们内网中最大的群之一，每当基础设施出现问题时，群里就会充斥着各种表情包，大家纷纷表示终于可以暂时休息，不用编码了。

我们的业务是一个内部的研发运维平台，这个平台覆盖了后端、前端、算法、测试、运维 SRE 等多个领域，每月有数万人在使用，是一个规模相当大的平台。值得一提的是，在脉脉上，有人讨论阿里的内部基础设施的时候，有人表示虽然在公司时经常抱怨，但离开后却发现自己很怀念，这说明我们的基础设施做得还算不错。

我们的业务背景特点是，并没有一个特定的业务方，而是服务于各大部门。各个部门的 CTO 会向我们提出需求，比如在海外建立站点、支持海外发布部署、应对外籍工程师的特殊需求、在极端情况下临时扩容等。比如，高德可能会在十一期间遇到高峰，而淘宝则会在双 11 遇到高峰，因此我们面临着各种各样的需求。但更多的还是日常的开发者需求，他们每天在编写代码时，都希望能够不受基础设施问题的影响，这就是我们产品需要满足的需求。

在讨论技术规划的重要性时，我们常常听到一些常见的理由。比如，有人问为什么要做技术规划，有人会回答说，财年结束了，新的财年要开始了，所以我们需要做技术规划。还有人会说，如果没有规划，怎么进行考核，怎么给员工打分。另外，还有老板要求做技术规划的情况，这些答案虽然常见，但仔细推敲起来，它们并不充分，更多是组织惯性的体现，仅仅因为以前这么做，现在也跟着做，这并不是一个坚实的理由。我们需要更深入地思考为什么要做这些事情，认真考虑这些答案背后的含义。

归根结底，技术规划的核心还是业务。业务目标通常分为两类：一类是直接与经营和财务相关的，比如年度收入、利润、运营成本等。这些成本包括硬件成本、资源成本，人力成本等，所以大家需要思考自己和团队一年花费多少，为公司创造了多少利润。这些目标在业务规模较小、能够全局掌控商业、产品、运营和技术的情况下比较清晰。但对于大多数人来说，由于远离决策链和商业环境，这些目标并不清晰。比如，对于基础架构的员工来说，他可能并不清楚双 11 的策略和盈利情况，也没有决策权。

另一类是间接的业务目标，包括用户规模、市场占有率、月付费用户数、渗透率、留存率等。在开放的商业市场中，这些指标非常重要，对内也同样重要，比如我所在的团队也需要关注这些指标。在决策团队的工作方向时，需要考虑是投入还是不投入，是重投还是轻投，需要砍掉哪些业务。例如，Aone Copilot 是一个代码生成工具，类似于 GitHub Copilot。我们会设定一些目标，比如内部渗透率，即活跃写代码的人中有多少比例在使用我们的产品。这是一个非常清晰的业务目标，我们希望从百分之十几提升到 20% 或 30%，并为此设定时间表。再比如，我们支撑的一些前端资源站点，我们可以计算单位 PV 的成本，然后通过技术优化降低成本。

对外产品面向的是公开市场，我们可以使用经济学的方法来衡量其成功与否，因为市场会直接告诉我们产品是否成功。然而，内部产品并不完全遵循市场逻辑，它们往往受到关键干系人需求的影响，这些需求可能会直接转化为业务目标。例如，我们可能会遇到海外合规风险的问题，海外部门的 CTO 可能会要求我们解决这个问题，比如实现多云部署。从财务和经营的角度来看，这样的投入可能并不划算，因为它可能需要我们投入 20% 的团队力量，并对现有系统产生较大冲击。但关键在于，这位 CTO 可能是能够影响我们关键投资人决策的人。如果他对我们的工作不满意，可能会影响对我的团队的评价，进而影响团队的未来发展，在我看来，这也是业务。

业务、产品、技术目标

实现业务目标的方法

在理解了业务目标之后，我们需要考虑如何将这些业务目标与产品、技术和运营相结合，以实现这些目标。实现业务目标的方法多种多样，特别是在 ToB 的场景中，我们更多地是支撑人们完成工作，而不是消费，这与 ToC 场景有所不同，后者更多关注于消费者的直接体验。

首先，我们可以通过产品目标支撑业务目标的实现。比如，Copilot 的用户采纳率（用户采纳的代码次数 / 产品推荐的代码次数）就是一个非常好的产品指标，采纳率越高说明用户更因为产品的能力而提高了他编写代码的效率。

其次，通过销售、运营、资源优化等方式也能达成目标。比如，通过技术的性能优化，降低服务单位用户量的硬件资源成本。比如，为了实现 Aone Copilot 渗透率的目标，我们可以增加运营的投入，给新安装的用户发咖啡券激励，这就很可能对增加新用户起到很大的作用。

我认为，用产品的方法来实现业务目标通常是最难的，但对 ToB 业务来说，这是一条有效的路径。而对于 ToC 业务，运营方法也是比较有效的，因为消费者容易受到运营活动的影响。

产品目标——对用户的影响

产品目标并不是简单地增加几个功能就能实现的。它通常与用户行为的改变有关。如果你开发了很多功能，但用户的行为没有任何变化，那么这些并不能算是实现了产品目标，而只是完成了一些工作而已。在我的团队中，我们每个月都会召开产品会议，在这些会议中，我会回顾过去一个月我们上线了哪些功能，以及接下来一个月我们计划做什么，上线哪些新功能。在每次会议中，我都会询问团队成员：上线新功能后，用户的行为发生了什么变化？

在这些讨论中，我们会列出一些具体的改变，比如用户从不能做什么到现在能做什么，从看不到什么到现在能看到什么，等待时间是否缩短，遇到失败的概率是否降低，以及满意度、推荐率是否提高。关注这些变化对用户的影响是至关重要的。产品目标的核心在于它是否真正改变了用户的行为，提升了用户体验，或者提高了操作的成功率。

产品生命周期对目标的影响

不同的产品会经历不同的生命周期阶段，通常包括引入期、增长期、成熟期和衰退期。

1. 对于引入期的产品，不宜制定规模类的业务目标，这个时候产品目标应该关注是否可以提供目前竞争市场上不具备的关键特性。

2. 对于增长期的产品，应该制定增长的业务目标，这个时候产品目标可以关注提供更丰富的功能，并重视性能和可靠性。

3. 对于成熟期的产品，通常用户数已经见顶了，这个时候业务及产品目标应该围绕用户粘性，以及降低服务单位用户的成本展开。

4. 对于衰退期的产品，应该制定减少投入的目标。

根据我的经验，对于内部产品，我每个季度、每半年或每年都会进行一次深入的思考，以评估产品的状态是否发生了变化。我需要判断产品是否已经进入了增长期、衰退期，或者是否是时候引入新产品。这些判断对于技术管理者来说至关重要，但同时也非常具有挑战性。一旦做出这样的判断，它将影响到团队的调整和资源的重新分配。因为每个决策都可能带来重大的变化，包括人员配置、项目优先级、预算分配等。

规划中的假设，以及假设的验证

在任何决策过程中，错误是不可避免的。如果有人认为自己的决策绝对正确，那么这本身就是一个需要警惕的问题。所有的决策都存在失败的风险，这是一个基本的事实。业务目标和产品目标之间存在一种承接关系，但这并不意味着完成了产品目标，业务目标就一定会提升。

以 Copilot 为例，即使我们提升了用户的采纳率，也不能保证用户数量一定会增加。有可能竞争对手提供了更好的服务，即使我们的采纳率提高了，用户还是会选择离开。或者我们的判断可能是错误的，用户并不关心采纳率，而是关心其他的目标，这意味着我们的目标可能定义错误了。在这些情况下，我们的假设可能失败，比如我们曾经增加了许多产品功能，但后来被证明是无效的。比如，我们可能将模型从 3B 提升到 7B，理论上这应该能提高推荐的准确性，但如果这导致产品变慢，用户可能就会拒绝使用，这样的假设就失败了。

这些问题反映了团队文化的问题。如果团队成员认为他们的工作必须成功，并且这直接与他们的绩效挂钩，那么他们可能会否认错误的可能性，他们可能会把错误的事情说成是正确的，或者将失败归咎于上级的决策。作为管理者，我们需要认识到从业务到产品再到技术，每一步都充满了假设。技术做得好并不代表产品一定成功，产品做得好也不代表业务一定成功。这是一个需要不断学习和验证的过程。

产品假设实际上是规划过程中的核心组成部分。如果在制定规划时能够深入思考这些假设，那么规划的质量和有效性将大大提高。通常，我们会说通过建设 ABC 能力来实现业务的 XYZD 增长。但在这个过程中，我们必须认真思考，是否真的完成了 ABC 之后，XYZD 就一定会增长。为了做出更准确的规划，你需要尽你所能，进行充分的调研。你需要根据对你所在领域的理解，对你所掌握的技术和团队能力做出判断，然后基于这些信息做出决策。这个决策有可能是错误的，但即使如此，做出决策也比完全不做决策要好。

产品和技术的关系

在产品与技术的关系中，有几个关键点常被忽视。技术人员往往不如产品和运营人员那么强势，他们通常比较内敛，不擅长争辩，因此很多时候只是埋头苦干，但这样可能会导致工作成果不尽如人意，或者没有发挥出应有的作用。以下是几个产品与技术关系中的关键点。

1. 技术决定产品交付的可行性。在大模型出现之前，没有人能够做出可用的代码生成工具。技术的进步决定了产品的可能性，这也是为什么那么多人研究 AI，因为他们看到了其中的可能性。

2. 技术理解决定产品的洞察力。例如，许多公司使用云服务时会遇到账号安全问题。我们公司内部开发了一个产品，允许用户在不接触云账号凭证的情况下使用云资源，这改变了开发者的行为习惯，同时确保了安全目标的实现。实现这样的产品需要深入理解云账号、RAM、OSS 以及运维系统的运作方式。

3. 领域模型是产品和技术共享理解的基础。如果你的产品经理不懂领域模型，那么他可能不太靠谱；同样，如果技术领导不能画出领域模型，他也可能不太靠谱。

4. 技术目标也是产品目标。许多技术方案中都会包含非功能性需求，如性能、可用性和成功率，这些也是云产品的核心竞争力。

5. 交付效率是影响产品和业务的关键因素。产品需要验证假设，而验证需要尝试，尝试需要成本，主要是时间成本。如何保证系统能够以健康的状态不断迭代，这是技术能够影响产品和业务的关键因素。

规划的承载 - OKR

撰写 OKR 无非就是将前面的讨论内容整理成一个正式的格式，清晰地写出业务目标、产品目标和技术目标。因此，OKR 的制定实际上依赖于大量的前期分析工作，而不是随意拍脑袋决定的。在我第一次参加规划脑暴会时，我感到有些困惑。会议中，大家随意地提出自己的想法，最后由老板决定我们要做哪些事情。但实际上，要制定出有效的 OKR，你需要进行定量分析、定性分析、技术分析和行业分析。

我想举几个例子来说明，上周，我的 HR 找到我，说我们要开规划会。我同意了，但要求看一下日程安排。当我看到那些常见的日程时，我表示需要调整，我们需要提前布置作业，给大家留出两周的时间来完成这些作业。我需要制定作业框架，让大家回答这些问题并进行充分的调研。如果没有调研，会议上的讨论就会显得空洞无物。

OKR 对齐

随着公司规模的扩大，内部的复杂问题也会随之增加，比如争夺资源、保护领地等现象。这些问题在人员众多的大型组织中是难以避免的。作为管理者，需要有意识地去调节这些冲突，理解流程和人际关系对工作的影响。

透明地对齐 OKR 可以减少许多不必要的内部纷争。当每个人都清楚他人在做什么，以及彼此之间的关系是竞争还是合作时，就可以减少误解和冲突。如果是竞争关系，可以讨论如何进行良性竞争；如果是合作关系，则可以探讨如何更有效地合作。同时，明确个人与上级、下属之间的承接关系也是非常重要的。

在大型组织中，需要通过 OKR 对齐讨论会来聚焦和一致化研发活动。在这些会议中，每个人都会展示自己的 OKR，即全年的目标。如果相互之间需要支持或协助，都可以在会议上提出并寻求解决方案。这样做的目的是增加信息的透明度，确保每个人都清楚自己的目标和如何与他人的目标协同工作。

KR 的度量方法

OKR 的度量方法应该是多样化的，不应该完全量化，也不应该完全等同于 KPI。如果将 OKR 当作 KPI 来处理，那么结果往往会变得过于保守，因为大家都会确保自己能够完成设定的目标。OKR 的度量应该包含以下几种类型：

1. 基线型：在业务场景并不成熟的时候，首先要建立业务的数据基线，例如第一个 Q 的关键 KR 可以是：“建立扩容成功率的基线数据。”

2. 正向度量型：积极性的描述，如“提升扩容成功率从 90% 到 99%〞

3. 负向度量型：这些往往涉及到时间的降低，如“构建 P90 时常从 3 分 10 秒降低到 2 分以内”

4. 里程碑量化型：如果遇到一些事情绞尽脑汁也难以客观量化，也应该定义清晰的里程碑。如：1） 评分 1.0：在所有国家成功发布消息推送功能 2）评分 0.7：在加拿大及另外两个国家发布消息推送功能 3）评分 0.5：只在加拿大发布消息推送功能 4）评分 0.3：消息推送功能通过验收测试，且在加拿大完成了测试

5. 健康度量型：如 NPS，用户满意度

上下文环境分析

常见的规划错误

在前面讨论了应该如何实施 OKR 和相关策略之后，需要指出的是，这些做法的前提是组织环境必须是健康的。如果组织文化存在问题，那么这些策略是无法有效运行的。例如，存在唯技术论的文化，特别是在底层技术团队中，如中间件、调度和系统团队，这种文化可能导致团队成员忽视产品价值。他们可能认为用户的问题不值得关注，而不是思考如何改进自己的产品。

另一个问题是激励方式的错误。如果一个组织不允许犯错，那么员工可能会提供虚假信息，以避免责任。因此，组织应该允许犯错，但同时也要确保从错误中学习。过于僵化的考核制度会导致员工行为失真，因此绩效考核应该是综合和灵活的，不能仅仅基于 OKR 的完成情况来评分。

不做量化和数据分析也是不可行的。在制定规划时，必须进行大量的前期工作，包括行业分析、用户调研、技术研究以及系统现状和用户行为变化的分析。这些数据分析对于制定有效的 OKR 至关重要。

在中国，所谓的“河马现象”（highest paid person’s opinion）比较常见，即最高薪酬者的意见主导决策。这种老板一言堂的文化可能会导致团队成员的偏见、过度自信和傲慢，从而做出不合逻辑的决策。管理者应该克制，充分吸取团队的意见，并用更好的方法和制度引导正确的决策。

需要建立怎样的组织文化

在构建组织文化方面，虽然听起来可能比较抽象，但实际上它对于团队的成功至关重要，尽管实施起来并不容易。以下是建立有效组织文化的几个关键点：

• 建立丰富的团队背景，综合技术、产品和业务能力。

• 鼓励相互沟通增强理解。

• 更科学的考核方式，不要把 OKR 等同于 KPI

• 从长期主义看，重视量化和量化积累，并积极投入

• Leader 以身作则

随着管理的团队越来越多样化，成员们的价值观和偏见也会随之增加，这使得建立一个既有文化共识又充分包容的团队变得极其复杂。在这个过程中，管理者需要做出许多决策，与团队成员进行大量沟通，并提供正面和负面的反馈。有时，甚至需要做出艰难的决定，比如请某些人离开团队。一旦建立了这样的文化，团队成员就会理解和执行前述的要求。但如果文化缺失，团队成员可能表面上同意，背后却开始拆台，导致团队效能下降。因此，建立和维护一个健康的组织文化可能是管理中最难也是最抽象的部分，但它对于实现团队目标和维持长期成功至关重要。

演讲嘉宾

许晓斌，阿里巴巴技术风险和效能部技术总监，负责研发和基础设施平台，有五年以上管理经验。《Maven 实战》作者，关注技术管理，在 DevOps、软件架构、云原生、Serverless 等技术领域也有丰富的经验。

会议推荐

在 AI 大模型技术如汹涌浪潮席卷软件开发领域的当下，变革与机遇交织，挑战与突破共生。2025 年 4 月 10 - 12 日，QCon 全球软件开发大会将在北京召开，以 “智能融合，引领未来” 为年度主题，汇聚各领域的技术先行者以及创新实践者，为行业发展拨云见日。现在报名可以享受 8 折优惠，单张门票立省 1360 元，详情可联系票务经理 18514549229 咨询。