当年写newsletter质问别人“为什么不做技术雷达”，现在轮到我了

2022年，我和Francisco Edilton（圈内叫他Chico，AWS社区英雄）每周二巴西时间晚上七点准时碰头，为的是写一份名叫HeroBuzz的newsletter。他在里斯本，我在圣保罗。newsletter是表面由头，我们真正在做的事情，其实是“浪费时间”。

多数人看到日历上定好的一小时，第一反应是问这件事要耗多久。但我和Chico之间，问题永远是：怎么把这一个小时用得更尽兴。正是在那种看似不务正业的闲聊里，HeroBuzz的选题一个一个冒了出来。我们聊见过的一模一样搞垮团队的死法，聊那些事后看来再明显不过、当时却没人拍板的技术决策，聊八竿子打不着的两家公司偏偏跌进同一个坑。偶尔某个故事太精彩，不写出来不甘心，就会有一个人冒出一句：“要不，咱们就写这个？”

2022年4月，第33期newsletter就这么来的。前一周我们刚讨论过ThoughtWorks的技术雷达，聊它的象限和圆环是怎么组织的。顺着那个话头，我们把话题推进一步：一家组织为什么要费劲去建自己的技术雷达？我们把多年观察到的问题全摆了出来——知识高度集中在少数人脑子里，一旦他们休假或离职，组织就失忆；团队之间靠“复制粘贴”传递工程实践，A团队刚踩过的坑，B团队原封不动再踩一遍；技术栈野蛮生长，没人在意版本老化，直到有一天变成安全黑洞。结尾，我们给读者抛了一个问题：

“我认识一些组织，如果能拥有自己的技术雷达，收益会很大。你呢，你的组织适合这样干吗？你设想的雷达会包含哪些圆环和象限？”

写下这句话的时候，太轻松了。因为我们站在岸上，看着水里的人游泳。

45天前，我加入Dati，出任AI与现代化方向负责人，同时主导Dati Labs的各项计划。那个两年前被自己亲手丢出去的问题，原封不动弹回到我面前。

接下来我想说的不是“我有了答案”，而是眼前这个局面让我认出了一幅曾经反复撞见的场景。一个好想法是怎么死掉的？不是被否决，不是资源不够，而是停在产生它的人手里，再也没有走出去过。

这幅场景在不同公司、不同团队之间一再重演，我花了好几年才看清，它们其实都是同一幅画面。有人在技术讨论里提出，技术X比公司现有方案好得多。证据呢？没有。那是一个有能力的人形成的专业直觉，但它既没有数据锚点，也没有一个可以存放它并被别人检索到的地方，于是它成不了任何人的决策依据。另一种版本是，有人启动了一项探索，而另一个团队其实早就在干同样的事，已经推进了几周。注意，这里没人做错什么。两个团队都展现出了组织希望看到的自主性和速度。浪费却在沉默中发生了。

个体速度一旦缺乏彼此感知的渠道，就会转化为集体的损耗。更棘手的是，这种局面从不以“故障”的形态示人，它戴着“繁忙”的面具。所有人都在交付，所有人都很忙，但组织的整体位移却小于预期。这是协调缺位的典型症状。

要管理工程规模，简化来看就两条路。第一条是“意见型团队”。技术栈已经敲定，工程实践有明确的偏好，技术选择更多体现为一种自上而下的共识。第二条是“发现型团队”。多个小组并行探索，用各自的方式解决问题，再把实践证明合并成集体资产。这两条路没有绝对好坏，但它们的共同前提是：组织内部需要一个活的技术知识目录。没有它，第一条路会退化成僵硬的教条，第二条路会退化成重复造轮子的狂欢。

这就是技术雷达真正要解决的问题。它不是一个好看的图表，也不是一次性的技术盘点项目。它是组织那块看得见的白板，让“我们试过什么”“我们踩过什么坑”“我们现在相信什么”变成可以持续更新的公共记录。圆环代表了技术成熟度的梯度——采纳、试用、评估、暂缓；象限则把你真正关心的维度锚定下来，比如语言与框架、工具、平台、技术实践。关键是它必须由工作在一线的工程师维护，且每次条目变更都要附带一句话Context：当时为什么判它进这个环。

少了这个Context，雷达就是一堆没有时间戳的图标，三个月后新人看着它只会问：“当时谁加的？怎么想的？”然后转身继续在各团队的wiki坟场里考古。Context保住了技术决策的可追溯性，而当决策变得可追溯，那些散落在聊天记录里的高质量直觉，才有机会进入组织级决策流程。

所以当这个问题重新砸回我面前，我没有急着去画象限。我先做了一件事：把过去45天里我和Dati Labs团队做出的每一个技术判断记录下来——不是结论，是判断过程。什么信息触发了决策？当时替代选项是什么？我们愿意为这个选择付出的验证成本是多少？这份记录本身就是雷达的雏形。它现在不漂亮，但它活着。

如果你问我，一个团队到底什么时候该开始建自己的技术雷达，答案不是“规模到了50人”，也不是“技术债已经爆了”。而是你第一次听到团队说出“我不知道这个已经有人做过了”的那一秒。在那之前开始，是投资；在那之后才追，是还债。而我，正在还两年前亲手写下的那道债。