技术雷达是如何建立的？

ThoughtWorks一年发布两次技术雷达，在每次雷达的准备期，TAB（ThoughtWorks技术顾问委员会）成员都会全力以赴的投入其中，以至连睡觉都会变成一件奢侈的事情。

言归正传，到目前为止我已经参与了几次技术雷达的构建。在这之前我曾疑惑于一个问题——“技术雷达是如何建立的？”这也是如今我常常被他人询问的问题，在本篇文章中，我将从内部人员的视角就技术雷达的产生机制、准备方式和决策方式给予一些介绍。文章从一次为期四天的会议开始。

第一天

为了制定下一期技术雷达，来自全球的ThoughtWorks TAB成员一大早就汇集在了一起。每次我们都会从四个办事处中选择一处碰面——这次我们定在了去年刚成立的巴塞罗那办事处。如果你觉得初来乍到和时差问题会拖慢进程，那就错了。团队一旦聚在一起，稍作提神后，立马就投入战斗了。

首先给大家介绍一下我们的技术顾问委员会，它是由来自全球的ThoughtWorks资深技术人员组成的，其中包括首席科学家Martin Fowler。此次线下会议由我们的全球CTO Rebecca Parsons主持。

开始的第一天，技术顾问委员会的每一位成员都准备了不少他们认为可以纳入下一期雷达的想法——也就是我们在技术雷达中看到的具体条目。

这次在巴塞罗那，团队要对180个备选条目进行投票表决。这就意味着要达成共识，大家需要进行审慎的考虑和热烈的讨论。

候选条目按雷达象限（技术、工具、平台、语言与框架）归类，再分为几个环（暂缓、评估、试验和采用）。这便于提醒我们每个环所表示的意思，有助于决定条目的归属范畴。

• 暂缓。这一环包含我们认为客户应当放弃或者需要等待时机成熟的条目。
• 评估。我们认为有希望且值得研究一番的事物。
• 试验。强烈推荐的技术，仅当我们预见能成功部署于生产时，才会将条目归于这一环——非常罕见的情况除外。
• 采用。对于特定应用情形，我们认为这是唯一最好的方案。

为了确定最终能够登上本期雷达的100个条目，我们每次分析一个象限，每个象限从采用到暂缓由内而外地进行。条目的推荐人负责向团队进行介绍，然后展开讨论和表决。每个人有三张不同颜色的牌子：绿色表示“是，我希望将其纳入雷达”；红色表示“不，不可能将其纳入雷达”；黄色则表示他们有疑问或意见。这四天会议上将大量用到这些牌子。

红牌用完后，用橙牌表示新的红牌。

这次我们从技术象限开始——不仅因为这是我最喜欢的方式，也因为这样讨论将更加细致。如此一来，下一期技术雷达就有了起点。

第二天

直到第二天凌晨，雷达墙才略微显露出一些秩序——但区别也不是很大。一名团队成员负责逐一检查雷达墙，而我则负责确保跟踪所有决定——到后来几乎不可能记住所有的东西。检查雷达墙时，他们明确我们下一步即将探讨的提议，并将便利贴移到团队表决的位置。有些情况下，要将便利贴置于指定的环内——但后来可能移到其他环或象限，或者完全遭到拒绝。

偶尔我们会遇到一些条目，迸发激烈的争论，甚至会由于一些细微差别而陷入僵局。这些问题我们视为“太过复杂而无法成为条目”——这并不表示它们会被抛诸脑后；这些问题仍然很重要而且值得注意。只是不适合在技术雷达上探讨。

有这么多条目需要讨论和表决，让讨论继续进行才是关键。Rebecca负责监督程序的进展。介绍条目时，她会留意黄牌的出现，并告诉团队下一个发表意见或提问的人是谁。期间没有人会插嘴。每个人必须在轮到自己的时候才能发言。

第一轮表决进度很快。先介绍条目，再快速讨论，最后表决。这里有一个棘手的问题。已经有一些人发表了一些意见，但团队里仍有不少人举黄牌。为了保持程序正常进行，Rebecca拟制了发表意见的名单并提示我们：“乔尼发言后开始表决。”

表决票数经常比较接近，所以要一直举着牌直至统计完所有绿/红牌。当有黄牌出现时，讨论继续。达成决定后，进入下一步。这里不掺杂任何个人因素，我们进行地很快。

第三天

到了第三天，我们基本已经完成了新条目最主要的部分。但离完成还相差甚远。从许多方面而言，艰难的工作才刚开始。

之前，每一次表决都将决定是否将某个新条目纳入雷达。现在，我们得回顾上一期雷达的条目，加起来通常会有100个左右。他们是否仍然关系重大？哪些应当去掉？哪些条目需要重写？如果我们对一个条目的看法连续两期雷达都没有发生改变，就让其“淡出”。因为还有很多有趣的事情值得探讨！有些时候，为了腾出雷达空间，我们必须强制淡出一些条目——即提前删除这些条目。

即便如此，我们还有大量的条目。现在的讨论就变得激烈了。技术雷达诞生于全球充满热情的技术人员所组成的ThoughtsWorks社区。它基于我们的客户工作经验。我们认为这是我们的优势之一。但只要大家对技术怀抱热情，难免会存在异议。我们的雷达讨论也不例外。

接下来，我们检查所有人一致同意理应纳入雷达但不如其他条目价值高的条目。这种剔除过程非常艰难，好几次我们不得不停下来问自己：团队有没有什么建议？如果团队对某个条目没有明确的建议或一致的意见，那这个条目便不会被纳入雷达。

第四天

连续三天的讨论——除了雷达，偶尔下班消遣时也会与同事互动，挑起技术谈话——大伤元气。现在会议室里几乎每个人都很疲惫了，但仍需进行最后调整，落实到位。

为了确保在计划时间内结束，我们采用了许多方式。例如，Rebecca确保不让讨论无休止地继续。我们也明白有时候个别人会不同意团队的决定。这时候，有一个可以改变团队的决定机会——我们称之为救生艇。一旦雷达基本落实到位，各技术顾问委员会成员可选择一个条目恢复——但他们必须说服团队该条目值得纳入雷达。或者说服大部分人即可，无需所有人一致同意。

最后，只有所有人尊重其他人的意见时，会议才能顺利开展。Rebecca协调会议时确保所有人都具有发言权，能表达自己的想法、经验和关注点。看到一群热情的人以相互尊重的方式表达有力的观点，展开高质量的讨论，这是令人高兴的事。所以即使团队出现分裂，表决票数相当，我们也能进入下一轮讨论。

到第四天结束时，我们对雷达的内容做出了最终决定。每次参加技术雷达会议，现场的讨论都令我折服——有幸参加会议让我深感荣耀，我一直惊叹于大家的技术意见、意见产生的过程、意见的评估方式以及团队谈论的各种背景。

这仅仅是雷达建立过程的起点。随后我们必须详细编写每一个条目、讨论产生的主题及主要报告。敬请期待！

新一期雷达将于11.30日与你见面！点击【阅读原文】提前订阅。

文／Camilla Falconi Crispim