打造你自己的技术雷达
20世纪90年代的大部分时间以及21世纪初，我一直都在一家小型培训咨询公司担任CTO。在这份工作开始之初，主流平台是Clipper——一个基于dBase文件构建DOS程序的应用程序快速开发工具。Clipper是基于对象的，我们给它补充了一个扩展库Class(y)，来让它变得完全面向对象，正是由于创建了这个广泛的面向对象的框架来辅助程序开发，我们迅速地击溃了竞争对手。蓬勃的培训和咨询业务让我们非常开心。
直到有一天一切都变了。我们注意到了Windows的兴起，我们中的大多数都用过它，甚至用它的原生工具来构建过一些小程序。但是产业市场依然还是DOS的天下……直到它突然被替换掉。几乎就在一夜之间，所有业务都没了。我们只好争先恐后地在Windows的世界里寻找对应的工具和平台。这次教训给我留下了深刻的印象：不能忽略日新月异的技术发展。
这件事也给了我一个关于技术泡沫的教训。当在一项技术上投入太多时，你就进入了模因（memetic）泡沫（也叫回音室）。由卖方制造的泡沫尤其危险，因为在泡沫里面你永远听不到坦诚的评价。而最大的危机是当泡沫开始破灭的时候，在泡沫里的你不会注意到破灭的来临；等你注意到的时候，一切都晚了。我们在Clipper上遭遇过这种情况，你也有可能会遇到。
我们缺少的是一个技术雷达：一份评估既有技术与新生技术的风险和利益的动态文档。我相信你会需要两个雷达：一个自己的雷达，用来帮助指导你的事业决策；另一个是公司的雷达，帮助你们在做购买决定和选择技术方向时保持理智。我会讨论如何创建这两种雷达，但是首先，我想先谈谈为什么我会产生这样的想法。
ThoughtWorks技术雷达
ThoughtWorks TAB（技术顾问委员会，Technology Advisory Board）由ThoughtWorks一群资深技术领导者组成，他们的使命是协助CTO Rebecca Parsons，一起为我们以及我们的客户制定技术方向和战略。
ThoughtWorks尽力保持在技术选择上先发制人，就我们实际遇到的问题来客观地评估技术的用途。例如，我们是企业级Ruby on Rails的早期提倡者，因为我们了解Rails的技术优点以及它适用的场景。我是TAB的一员，我们两周进行一次严格把控时间的国际电话会议，此外，一年中还会有几次面对面谈话。
面对面会议的其中一项产出就是最新的技术雷达。刚开始，它是面对面会议中大多数人觉得最有趣的环节——酷炫技术讨论——的产出物。ThoughtWorks是一个复杂的实体，TAB成员会面时的日程安排十分紧张。但是本质上，我们都是些极客。刚开始，我们在日程中留出了一小段时间来讨论当前热衷的事情。随着时间的推移，它逐渐发展成了一年两次的技术雷达大会。技术雷达的最新情况请参考：www.thoughtworks.com/radar
技术雷达的流行程度已经极大地超出了我们的想象。确切的原因并不清楚，或许是因为我们是罕见的愿意诚实地给出技术意见的咨询公司。我们酷爱钻研技术，并且不惧怕说出自己的想法。技术雷达流行起来的另一个原因是因为它用了一个实用的类比来评估技术。虽然这个类比并不完美，但却十分形象。而且有时只需要一个可以展示想法的框架就可以让文化基因（memes）蓬勃发展。
TAB渐渐地习惯了以一年两次的节奏推出技术雷达。然后，就像通常那样，意外的副作用发生了。在一些我参与演讲的会议上，与会者们找到我并且感谢我帮助推出技术雷达，并说他们的公司已经开始在创建他们自己的技术雷达了。我们还没有考虑过将这种实践推广出去，但是回首时这却是显而易见的事实。自此之后，我们与几个客户开展了这项实践，都取得了巨大的成功。
我还发现，这可以回答那个在所有会议中演讲者提问部分常常出现的问题：“你（演讲者）是如何紧跟技术的发展的？你怎么知道下一步应该追求的技术是什么呢？”答案当然是我们都有某种形式的内部雷达。使用这里介绍的工具，你可以自己规范这一流程，帮助你决定在哪些方面投入宝贵的研究和开发时间，这也许会引导你进入一个全新的事业，但同时也会占用你的家庭时间。
你需要两个雷达：一个给自己，一个给公司。我会谈到如何以及为何创建它们，但首先我需要谈谈技术雷达本身。
技术细则
技术雷达是由一些同心圆组成的：
它被分割成4个象限（作为一家咨询公司，我们习惯于把东西按象限划分，这是种奇怪的强迫症）：技术、工具、平台，和语言和框架。
环
技术雷达中有4个环，从外到内：暂缓、评估、试验、采用。
暂缓
暂缓环的本意是“目前暂缓使用”，用来表现那些新推出，还无法进行合理评估的技术。我们考虑的是那些有大量动态更新，但是尚未得到验证的技术。暂缓环逐渐演化成了“别用这项技术启动任何新项目”。在已有项目上使用它没有坏处，但是想在新开发的项目上使用这个技术的话需要三思而行。暂缓是最靠近避免范畴的，但Rebecca不同意我们加入避免环。这个决定十分明智：使用雷达这种形式真正的目的在于，雷达应该是侦测你的期望，而不是责怪过去。
评估
评估环里出现的条目表示的是值得研究一番的技术，以确认它将对你产生何种影响。你应该投入一些精力（例如开发调查、科研项目、参加会议讲座等等）来确定它是否会对你所在的组织产生影响。例如，许多大型企业在制定移动战略的时候都明显经历过这段时期。
试验
试验环列出的技术是你（和同事）认为值得去追求的。理解如何建立这种能力十分重要。现在是时候在一个低风险的项目上试点，实践这项技术，这样你就可以真正的了解它。我们希望在将某个技术从评估环移动到试验环时ThoughtWorks能有一个客观的标准，我们必须在实验项目上认真地使用这项技术。
我们坚信只有当真正使用了一项技术来解决真实问题之后，你才能全面地评估这项技术，理解它的缺点和优势。通常情况下，评估阶段你会看到好处，却很难看出限制，而解决实际问题则让你对这项技术有了一个全面的了解。毕竟，每个技术都在试图吸引人们的使用，它们鼓吹自己的优势，同时会掩藏不足。这就需要你自己去发现新技术中的缺点。
采用
对于采用环里的技术，我们强烈主张业界采用它们。如果适合我们的项目，我们就尽量毫不犹豫地使用。
我们尝试找到一个好的标准，来衡量什么时候一项技术明显地应该被移入采用环，我的同事Mike Mason找到了一个标准，我们叫它Mason的剃刀：如果你没有使用采用圈里的技术，我一定会嘲笑你。最新的一条附加条件是Mason的第二法则：当你想要把某个技术移到采用环里时先质疑一下——你是不是真的足够了解它了？
图标
我们采用一套简单的图标。三角形代表新出现或位置发生过变化的技术，而圆形表示没有变化的项。我们也会用向量来说明各个点在每个象限中的移动。
如果一个图标在一年内的两期技术雷达上都没有移动，我们就把它略去，以减少混乱。如果对某项技术又有了一些有趣的话题，我们会让它在雷达上复活（或者让它又“昙花一现”）。
如何创建雷达
对于每个象限：
在白板上画出4个维度来代表4个环（暂缓、评估、试用、采用），所有人在便利贴上写下自己提名的技术，并把它们贴到白板上相应的维度中。
主持人（TAB的某个成员）把相似的便利贴归类（我们认为酷的技术必然会出现重合）
作为一个团队，我们就每一个技术进行讨论，决定它是否应该留在雷达上，以及应该在哪个环内。
选择一个充满激情的人，写几句话描述做此决定的背景（有些看起来像是白皮书上的心得体会）
对现有雷达上的条目我们也会这样做，以决定它们是应该移动、移除，还是被“复活”。
我的同事Erik Doernenburg，TAB成员之一，也提供了有益的推动力量，他总是施加压力，鼓励我们提名某种技术。例如，使用具体的技术名称，而不是采用广泛的一类技术（比如：日志聚合工具）。我们最近在这个新领域内选出了两个典型的工具，logstash和Greylog2，希望大家可以采用它们。明确的技术名称使技术雷达更加具体了。
达成共识
我们在事后才注意到的一件难能可贵的事情是，TAB能快速的达成一致。资深技术人员往往都充满了激情，但是我们很快就能达成一致，很少需要Rebecca来投出决胜票。而其他类似的团队，无论是在ThoughtWorks内部还是外部，似乎都会花费一段长得令人沮丧的时间，才能最后达成一致。
有一种理论说，作为技术人员，我们习惯于说明理由，然后等待认可；就算获得的结果是否定的，也会尊重这个结果而不会耿耿于怀。一旦在大型组织的软件项目上工作过，你就会磨练出接受的技巧。我们意外地从这项来之不易的实践中获益，决定我们的雷达上会有什么样的技术，是我们之间最意气相投的事。
开源可视化工具
我的一位前同事Brett Dargan开发（并开源）了基于JSON和Javascript的雷达可视化工具：https://github.com/bdargan/techradar。
要使用这个工具，你必须把技术及其在雷达中所处的位置填入一个JSON数据结构中。我们为雷达布局的时候并不操心在一个环内的细微区别。因此不要因为一个点更靠近中心几毫米而去解读编辑的想法，我们只是努力让每个标签不要重合，使它们可以清楚地被看到。由于使用了极坐标，Brett的雷达工具会在显示雷达之前做位置信息的转化，从而可以精确地控制每个点在环内出现的位置。
ThoughtWorks雷达
许多人错误的解读了ThoughtWorks技术雷达的目的。我们的首席科学家Martin Fowler建了一个FAQ页面来回答一些常见的问题。对我们来说，雷达是当前我们这群固执己见的技术人员共同认为很酷的技术的缩影。它不是一个用来评估某个技术生命周期的工具——许多我们十分喜爱的技术，例如GitHub已经在我们“不费脑子”的采用类中消失很久了。关于雷达的比喻十分恰当：雷达跟踪的是将要到来的事物。
我们从未期望技术雷达会流行起来，不过依然有许多人在自己的个人事业发展中开始使用雷达，并且用它来支撑很多企业所缺少的完整反馈环。
个人雷达
当你踏入软件开发行业时，你跟自己签订了一个契约：承诺会跟上这个世界的变化。这一开始很有趣，因为总是有新的东西可以去探索和尝试。但是随着时间推移，学到的东西变成了事业，这时技术就有了更多的价值，而不单单只是本身的酷炫了。投入精力去透彻地研究当前正在使用的技术栈是明智的（并且好的方面是，如果你发现这个技术还很酷，你依然可以称之为“工作”）。
但我们永远不可能在成就面前停止脚步。技术世界飞快地变化着。我的一个前同事曾是世界闻名的Clipper专家，他哀叹自己不能将现已无用的大量Clipper知识替换为其他的东西。他还推测：历史上有没有其他一群人会像软件开发者一样，一生中学了很多详细的知识，然后又把它们抛到一边？（这个问题依然没有答案）
以放任自由的态度对待技术事业是非常危险的。大多数技术人员在选择技术的时候都或多或少地基于某种特定的基础：什么技术比较酷，或是你的雇主正在推行什么技术。创建自己的技术雷达可以帮助你确定想法，并且平衡各种技术（炫酷却小众，还是乏味但好找工作）。
应该像对待你的金融投资组合一样对待技术组合：在许多方面，它们是相同的。你的理财规划师是怎么跟你说的？分散投资！ 选择一些有广泛需求的技术和技能，并持续跟踪这类需求。同时你或许也想尝试一些高风险/高回报的技术策略，例如，开源或移动开发。
我认识几个开发者通过开源项目成功地把自己从格子间劳役中解救了出来：他们在开源项目上辛勤工作到深夜，这项开源项目开始受到大家的欢迎，有人愿意购买，并且最后成为了事业的目标。移动开发目前被闪亮的光环围绕，这很合理，但是也非常困难。
抽点时间，开发一些实验性项目来帮助你选择技术，并且创建一个雷达。你可以用我们的象限，也可以创造属于自己的象限。请注意，练习过程和结果一样重要，所以请安排时间在一年内多次回顾你的技术雷达。我在每年年底都会自然而然地重新审视自己的雷达，因为年底正是我萌发新想法的时间；夏天我也会重温雷达，因为这个时候我会开始考虑明年的新话题。创建一个物理雷达（一个粗略的雷达图表+心得体会）可以帮助你规范想法、理性决定，温故而知新。
企业雷达
个人雷达的价值显而易见，而企业雷达看上去似乎没那么重要，但实际上它要有价值得多。 你的公司为什么需要技术雷达？原因有5条：
1、风险 vs 采用
对于任何一项特定的技术，它一定在你公司里处于如下曲线中的某个位置：
创新者、早期采用者、早期众多跟进者、后期众多跟进者、滞后者
创新采纳周期
但是你面对的不只是一项技术，而是很多技术：开源框架、商业产品、自制工具等等。对于其中的每一个，你都可以在曲线上画出它现在的以及希望达到的位置，并在风险和收益之间进行权衡。虽然这是个很有用的实践，但是对每一个技术都这么做实在是过于复杂和缓慢。尝试构建一个可以综合评估技术所有维度的矩阵注定是要失败的。
相反，你需要一个粗粒度的分类系统，像是广口的桶，而不是精细的小孔，例如我们雷达上的环。 对于特定的技术，它在你组织的创新曲线上都有一个理想的位置，让风险和收益相平衡。我的同事Darren Smith想出最初的雷达比喻，就是通过将使用的技术和理想的采用时期可视化出来，然后又将它们放入二维雷达环中。雷达是一幅个个时间点的快照，展示每项技术在你的采用曲线上的位置。正如许多的隐喻一样，“雷达”在很多层面都是有效的。
2. 持续分析的平台
在有了框架之后，这项实践就变得更容易重复了。所以，你需要创建一个平台来让你可以持续地估算对技术的反应能力和喜好。技术永远不会一成不变，你必须不断地重新评价它们，否则就有可能大大落后于竞争对手。一个标准的框架可以帮助你建立一个有关本实践的历史记录，随着时间推移，可以帮你提高洞察力。
3.从技术人员向感兴趣的非技术人员传递统一信息
你的CTO或CIO或"制定软件购买决策的人”可能会时常四处走动，和大家聊技术，或许还会询问每个人的看法。但是CTO很少会召集会议，让他手下的人对他们每天要使用的工具进行评级。许多C级别的领导者会更多地从销售人员，而不是他们自己的员工那听取意见。
为什么呢？首先，没有人想要负面的反馈，特别是当这些反馈并非必须时。第二，当出现提供反馈的机会时，大部分反馈都是负面的，并以抱怨的形式呈现出来。你有没有对你的CTO说“X技术选得非常好！”或是“你知道吗，换成Y之后我们的生产力提高了很多。”
有效的技术是无形的，但是有缺陷的技术对于使用它的人来说就非常扎眼。大部分组织并没有从技术使用者到技术选择者的反馈闭环。技术雷达是一个免责工具，可以让所有的技术使用者向技术决策者提出他们的建议。在一些我们帮助其创建雷达的公司里，有许多基础设施的变化都是开发人员倡导了一年多的时间，但是直到掌权者意识到了普遍需求的时候才会立即开始执行。
4.借此激发热烈的技术讨论
曾经有一个项目经理对我抱怨，说他项目上的技术人员经常争吵。我纠正他说他们只是在热烈的讨论，这种讨论是因为激动而不是气愤。对技术充满热情的技术人员们多久能聚在一起一次，热烈地讨论大家每天都要打交道的技术？创建一个雷达就能成为很好的理由，让大家在一个（希望是）没有敌意的环境中。这些技术人员应该来自不同的项目，并且涵盖所有的技术栈。通常情况下，编程语言壁垒和自然语言一样，具有相同的社会影响，不同的语言会把大家隔离成不同的小团体。雷达给了所有人一个聚集到一起的机会，谈论他们之间的相似之处，而不是不同点，这样的讨论常常会得到意想不到的结果。
我们发现这是雷达实践中最美好的部分，因为你可以针对某项随时可能用到的技术进行深刻的讨论，而且这也是唯一的办法。例如，大部分程序员大概都认为他们知道运营负责人对Puppet的看法，但是正式的交谈往往能够产生意想不到的效果。
5.帮助协调业务人员和技术人员对技术的看法
雷达可以帮助你决定什么时候可以更激进（或较柔和）地推进一项新技术，并且提供了一个可读的、精简的技术图景，即便是非技术人员也可以理解它。如果公司对于当前和未来的技术形势有共同的认识，你们就能做出更加明智的决定，以及更好的事业规划。
通常来说，你希望业务人员和技术人员对技术的看法能够吻合，但却时常事与愿违。例如，你的公司和另一家公司合并了，这能带来非常理想的业务成效，然而技术上却不尽人意。有一个明确的发展规划图能够帮助所有人（技术人员及非技术人员）来评估战略思想并制定计划。
机制
每个公司都会以不同的方式来做这件事，并且也应该有自己的风格。用以下建议来帮助你们开始，并适当修改细节。
象限
你或许想要为公司的雷达更改象限。当我为公司做这件事的时候，我有时会把语言象限移到工具里（因为在大多数大型公司中，语言的选择已经不幸被提前决定了），增加一个软件包象限来取代语言。这对许多用一个巨大的鲁布·戈德堡装置与COTS（商业现货供应）软件集成的公司来说是一件大事。你也可以创建其他的象限，比如合伙公司、顾问，或其他特定领域。
何人？何物？何时？
何人可以分成生产者（制作雷达的人）以及消费者。生产者应该是一群资深技术人员代表（同事推荐或提名），以及公司中任何一个对技术选择有兴趣的人。如果超过了30个人或者在不同的地方，那就需要做多次谈话，然后将结果汇总起来。消费者可以是任何一个感兴趣的人，因此产出物（文档、演讲、视屏广播）必须假设消费者为非技术人员。雷达的目的之一是让利益相关方了解技术决策，所以应该让他们看得懂雷达。虽然首席级别的领导参加这样的会议没有什么问题，但是整个流程应该由技术人员主导。
你生产的是何物？有可能是10页纸长的文档，像ThoughtWorks的技术雷达；也可能是雷达小组的作者们向大家做的一次演讲。它可以像一个wiki页面一样只需要你定期更新。过程远比产出物要重要，所以输出可以是极小的。我们由一个白板开始，在上面画上用来表示象限的线条，以及贴上代表当前雷达项的便签。
收集结果的方法很简单，当我们为公司执行这一实践的时候，通常会用一个电子表格来统计结果。写心得体会是其中最麻烦的部分，但是也是雷达创建之后最有价值的部分，因为这些体会让雷达上的各个点有了更具体的意义。我们的雷达因受印刷的限制，只能为每项技术写几句话的介绍，但是当你在创建公司雷达的时候，应该鼓励更加详细的介绍，来总结团队是如何讨论并达成共识的。
何时制作雷达也取决于你的公司以及它与技术之间的相互影响。我的推荐是至少每年做一次，最好是一年两次。因为技术发展相当迅速，一年的时间就可能发生翻天覆地的变化。
总结
当选择技术事业的时候，你其实也默认了会管理你的技术事务。用技术雷达这样的形式来管理这个过程，能帮助你做出更好的决定。类似的，为你的公司创建一个雷达还能提供丢失已久的反馈闭环。有些人每天都在接触你的软件， 为什么不利用他们丰富的知识和经验呢？
有这两个雷达在手也是一件非常有用的事业发展工具。正如在上面的文章中看到的，当你是CTO的时候，做技术选择的过程就完全不一样了。记住，雷达是一个防御工具……但它也可以成为进攻武器。研究一下你的雷达和公司雷达的区别，然后看看这个工具能不能帮你更好的地统一协调你的职业目标。
我有一个疯狂的幻想，如果将交换技术雷达（个人和公司的）作为面试中的一个环节，并以此作为互相评估和选择的基础，会不会很棒呢？
点击［阅读原文］至查看文章全部内容