#技术雷达设计

2011 年，ThoughtWorks 发布了一份内部报告，介绍他们如何追踪和评估技术趋势。这份报告后来演变成了 Tech Radar（技术雷达）——一个用四象限和四种状态来组织技术评估结果的工具。

10 年后的今天，技术雷达已经成为全球范围内最流行的技术选型沟通工具之一。Netflix、Spotify、 Zalando 等公司都有自己的技术雷达。技术雷达的价值在于：它把散落在个人头脑中的技术判断，变成了团队共享的技术认知地图。

#技术雷达是什么

技术雷达是一种可视化技术评估结果的工具。它把一个组织对各类技术的态度，用位置信息表达出来：

• 象限代表技术的类别
• 位置代表技术的成熟度或推荐程度

当你打开一张技术雷达图时，你可以快速回答几个问题：

• 我们团队目前在用哪些技术？
• 哪些技术我们正在评估？
• 哪些技术我们应该开始尝试？
• 哪些技术我们应该逐步替换？

技术雷达的输入是一系列技术评估，输出是一个所有人都能理解的可视化结果。

#技术雷达的结构

#四个象限

技术雷达的四个象限代表技术的分类维度：

quadrantChart
    title 技术雷达四象限
    x-axis 新兴技术 --> 主流技术
    y-axis 底层技术 --> 应用技术
    "Serverless": [0.8, 0.6]
    "React": [0.7, 0.8]
    "Kubernetes": [0.9, 0.7]
    "gRPC": [0.6, 0.5]
    "WebAssembly": [0.3, 0.4]
    "GraphQL": [0.5, 0.6]

#三种状态

每个技术在雷达上的位置代表团队对该技术的态度：

#技术雷达的演进过程

技术雷达不是一次性的产物，而是持续演进的知识库。一个技术的状态会随着时间变化：

stateDiagram-v2
    [*] --> 评估: 新技术出现
    评估 --> 试验: 团队开始关注
    试验 --> 采用: 验证成功
    试验 --> 搁置: 验证失败
    采用 --> 搁置: 发现问题
    采用 --> 评估: 重新评估
    搁置 --> [*]

技术雷达的演进体现了团队技术认知的成长。今天认为是「采用」的技术，可能两年后变成「搁置」——不是因为判断错了，而是因为技术环境发生了变化。

#如何在团队中推行技术雷达

技术雷达的价值只有在「被使用」时才能体现。如果只是制作了一份漂亮的雷达图，然后束之高阁，就完全失去了意义。

#推行步骤

第一步：建立共识。在推行技术雷达之前，先与团队核心成员沟通，确认以下几点：

• 技术雷达能解决什么问题？
• 团队当前在技术选型上有哪些痛点？
• 技术雷达的维护成本是否可接受？

如果团队认为技术选型没有混乱到需要工具来解决，那么推行技术雷达的时机可能还不成熟。

第二步：定义流程。技术雷达需要有人维护，需要有评估流程。至少需要回答以下问题：

• 谁负责更新雷达？
• 一个技术的状态如何确定？需要评审吗？
• 状态变更后，谁需要被通知？

第三步：从小开始。不要一开始就构建一个包含 100 个技术的完整雷达。选择团队最关心的 10-20 个技术开始，随着流程成熟再逐步扩展。

第四步：与日常工作集成。技术雷达只有在日常工作中被引用时才有价值。在技术评审、方案设计、技术分享等场景中，主动引用雷达中的状态，让团队成员习惯「查雷达」。

#技术雷达的维护机制

技术雷达最大的敌人是「过时」。一份半年前更新的技术雷达，可能已经无法反映团队的真实技术状态。

#维护节奏

#维护责任人

建议采用「轮值制」：团队成员轮流负责技术雷达的维护，而不是固定一个人。这样做的好处是：

1. 分散维护成本，避免单点依赖
2. 让更多人了解技术评估的过程
3. 引入多元视角，避免「一言堂」

#避免的误区

误区一：雷达即标准。技术雷达是参考工具，不是强制标准。团队成员有权在雷达之外探索新技术，技术雷达的价值是「提供共识」，而不是「限制探索」。

误区二：雷达不更新。一份几年不更新的技术雷达，比没有雷达更危险——它给新员工虚假的信心。

误区三：雷达过于复杂。如果技术雷达包含了 200 个技术，状态说明有 10 种，这个工具本身就变成了认知负担。保持简洁，只记录真正重要的技术。

#案例：某互联网公司如何用技术雷达统一团队认知

2019 年，国内某中型互联网公司（员工 200 人，技术团队 50 人）遇到了一个典型问题：每个小组都在用自己熟悉的技术，跨组协作时频繁出现「语言不通」的情况——微服务框架有三种、消息队列有两种、缓存方案有三种。

CTO 决定引入技术雷达来解决这个问题。推行过程如下：

第一个月：建立基础。技术委员会（由各组架构师组成）选取了团队最关注的 30 个技术，发布了第一版技术雷达。状态定义如下：

• 采用：各组新项目必须优先选择
• 试验：可以在非核心项目中尝试
• 评估：保持关注，不强制要求
• 搁置：逐步淘汰，已有项目给出迁移计划

第三个月：建立流程。制定了技术评估流程：当团队需要引入新技术时，需要先提交评估报告，说明该技术的优势、劣势、适用场景，由技术委员会评审后决定是否加入雷达。

第六个月：与招聘同步。在招聘 JD 中引用技术雷达，候选人可以清楚了解团队的技术栈。降低了「入职后发现技术栈不符合预期」的离职率。

一年后：技术雷达从最初的 30 个技术扩展到 60 个，各组的技术选型统一度显著提升。跨组协作时，「用什么技术」的争论明显减少——「查一下雷达」成了团队的口头禅。

量化效果：

• 新技术引入的平均评审时间：从 2 周降低到 3 天
• 技术选型争议的解决速度：提升 60%
• 跨组代码复用率：提升 40%

#技术雷达与 ADR 的配合

技术雷达记录的是「当前的技术状态」，ADR（Architecture Decision Records）记录的是「决策的过程」。两者配合使用，可以实现「知其然」与「知其所以然」的结合。

#典型配合场景

场景一：技术升级决策。当需要升级 Java 版本时，技术雷达会告诉你「当前推荐 Adopt 的版本是 17」，ADR 则记录「为什么选择 17 而不是 21」。

场景二：技术废弃决策。当需要废弃某个老旧框架时，技术雷达会告诉你「这个框架已经标记为 Hold」，ADR 则记录「为什么这个框架不再适合我们」。

场景三：新成员 onboarding。新成员可以通过技术雷达快速了解团队的技术全景，然后通过 ADR 深入了解关键决策的背景。

#文档结构建议

docs/
├── radar/
│   ├── index.mdx          # 技术雷达总览
│   ├── adopt.mdx         # 采用列表
│   ├── trial.mdx         # 试验列表
│   ├── assess.mdx        # 评估列表
│   └── hold.mdx          # 搁置列表
└── adr/
    ├── 001-why-java-17.mdx
    ├── 002-why-k8s.mdx
    └── ...

#技术雷达的扩展应用

除了基本用法之外，技术雷达还有几个扩展应用值得关注。

#按团队分层雷达

大公司可能有多个技术团队，每个团队的技术栈和关注点不同。可以为每个团队维护自己的技术雷达，同时维护一个「公司级技术雷达」作为共识基线。

#技能差距分析

技术雷达可以与团队技能评估结合使用。将「团队当前使用的技术」与「雷达上推荐的技术」对比，可以识别出团队的技术差距，为培训计划提供依据。

#项目级技术选型

在为具体项目做技术选型时，可以在项目目录中放一个「本项目技术雷达」，说明该项目选择了哪些技术、为什么选择、与公司级雷达的关系是什么。

#思考题

问题 1：假设你的团队有 5 个人，技术雷达维护会占用一定时间。你会如何设计维护机制，让成本可接受的同时保持雷达的时效性？

问题 2：你的团队中有一位资深工程师，坚持使用一个已经被标记为「搁置」的老技术，理由是「这个技术我熟悉，没问题」。作为架构师，你如何处理这个情况？

问题 3：你正在为公司建立技术雷达，CEO 问你「技术雷达能带来什么商业价值？」你会如何回答？