Perguntas frequentes

O Radar é um documento que define as mudanças que consideramos serem atualmente relevantes no desenvolvimento de software — tendências que achamos que você deve prestar atenção e considerar usar em seus projetos. Ele reflete a opinião idiossincrática de um grupo de tecnologistas experientes e é baseado em nosso trabalho e experiências do dia-a-dia. Embora seja algo interessante, ele não deve ser tomado como uma análise profunda de mercado.

O Radar é escrito pelo Conselho Consultivo de Tecnologia da Thoughtworks, conhecido como TAB.

O TAB é um grupo de 20 ou mais tecnologistas experientes da Thoughtworks. O TAB se reúne mais ou menos duas vezes por ano presencialmente e quinzenalmente por telefone. Seu principal papel é ser um grupo consultivo para Rebecca Parsons, CTO da Thoughtworks. O TAB funciona como uma extensão analisando temas que afetam à tecnologia e a tecnologistas na Thoughtworks.

Rebecca Parsons (CTO) • Martin Fowler (Chief Scientist) • Bharani Subramaniam • Birgitta Böckeler • Brandon Byars • Camilla Falconi Crispim • Erik Doernenburg • Fausto de la Torre • Hao Xu • Ian Cartwright • James Lewis • Marisa Hoenig • Maya Ormaza • Mike Mason • Neal Ford • Pawan Shah • Scott Shaw • Selvakumar Natesan • Shangqi Liu • Sofia Tania • Vanya Seth

Construímos o Radar em nossas reuniões presenciais. Essas reuniões duram cerca de quatro dias, sendo que um dia consiste em fazer o desenho do Radar. Outros tópicos que podem ser discutidos são possibilidades de carreira para pessoas que desenvolvem software, revisão do processo de recrutamento de pessoas desenvolvedoras, como ampliar nossa capacidade para novas tecnologias, e nossas experiências com arquiteturas de microsserviços.

Rebecca escolhe os membros do TAB tendo em vista a formação de um grupo capaz de representar uma gama tão ampla quanto possível de líderes de tecnologia dentro da Thoughtworks. Os membros do grupo estão em diferentes partes do mundo (o que torna bastante árdua a tarefa de agendas reuniões pelo telefone). Rebecca busca conselhos de muitas pessoas sobre quem ter no TAB, mas a escolha final é dela. O TAB não deve ser visto como o topo do quadro de pessoas desenvolvedoras da Thoughtworks — há uma uma grande quantidade de pessoas importantes que não estão nele — mas como uma seleção representativa da liderança tecnológica. Os membros do TAB mudam ao longo do tempo, de modo que cada Radar é escolhido por um grupo um pouco diferente de pessoas em relação ao anterior. Normalmente, vemos duas ou três pessoas mudarem entre as reuniões, embora não haja nenhum termo de serviço formal.

O objetivo do Radar é rastrear tecnologias interessantes, o que chamamos de blips. Organizamos os blips no radar usando dois elementos de categorização: os quadrantes e os anéis. Os quadrantes representam diferentes tipos de blips. Os anéis indicam o estágio do ciclo de adoção que enxergamos para cada item.

Um blip é uma tecnologia ou técnica que desempenha um papel no desenvolvimento de software. Blips são coisas que estão "em movimento"— o que significa que sua posição no Radar está mudando — normalmente indicando que nossa confiança neles está crescendo, à medida que eles se movem através dos anéis.

Os quadrantes são uma categorização do tipo de blips:

• Linguagens de Programação e Frameworks: (Começou sendo apenas linguagens, mas incorporamos frameworks no Radar de outubro de 2012).
• Ferramentas: Podem ser componentes, como bancos de dados, ferramentas de desenvolvimento de software, como sistemas de controle de versões; ou categorias mais genéricas de ferramentas, como a noção de persistência poliglota.
• Plataformas: São as bases sobre as quais construímos software, por exemplo as tecnologias móveis como Android, plataformas virtuais como a JVM ou tipos genéricos de plataformas como nuvens híbridas.
• Técnicas: são elementos de um processo de desenvolvimento de software, tais como design de experiência e formas de estruturar software, como microsserviços.

Não damos muita importância aos quadrantes -— eles são realmente apenas uma maneira de dividir o Radar em áreas temáticas. Não achamos que seja importante para qual quadrante um blip vai, ao contrário dos anéis -— que geram muita discussão.

A metáfora de um radar diz que quanto mais perto do centro um item está, mais cedo ele estará junto de você. Como a maioria das metáforas, não podemos levar esta muito a sério, mas ela tem bastante fundamento.

Nosso Radar tem quatro anéis, que iremos descrever a seguir, começando pelo centro:

• O anel Adote representa itens que nós achamos que você deve considerar seriamente usar. Não dizemos que você deve usá-los em todos os projetos; toda ferramenta deve somente ser usada em contexto adequado. Por outro lado, nós acreditamos que um item no anel Adote representa algo que, sem sombra de dúvida, se mostrou maduro para uso.
• O anel Experimente é para itens que consideramos prontos para uso, mas não tão completamente estabelecidos quanto os que estão em Adote. Assim, para a maioria das organizações, acreditamos que seja mais adequado experimentar com essas tecnologias, com o intuito de decidir se ela deve fazer parte de seu ferramental. Tipicamente, nós já usamos itens neste anel em produção, mas entendemos que algumas pessoas podem querer ser mais cautelosas que nós.
• O anel Avalie contém itens para serem analisados de perto, mas não necessariamente para serem experimentados ainda - a menos que você ache que eles são significativamente adequados para você. Normalmente, itens em Avalie representam coisas que consideramos interessantes e em que vale à pena prestar atenção.
• O anel Evite é para coisas que, embora sejam aceitas pela indústria, não nos proporcionaram boas experiências. Nossa intenção é alertar que você pode enfrentar dificuldades também. Em alguns casos, considerarmos os itens irremediavelmente problemáticos; em outros, podem estar apenas sendo mal aplicados. Os itens que classificamos como Evite são coisas que gostaríamos que a indústria não usasse.

Diferentemente dos quadrantes, nós temos discussões bastante acaloradas sobre qual o anel em que um item deve ser colocado. Não brigamos, mas discussões sobre os anéis são as mais energéticas. Com nossa experiência de construir o Radar, chegamos em algumas regras úteis que nos ajudam a classificar os itens nos anéis.

Colocamos itens em Experimente somente quando temos experiência com aquele item em um projeto real. Isso pode significar um pouco de atraso com relação à curva de novas tecnologias, porque podemos gostar de determinado item, mas ainda não convencemos um cliente a experimentar com a tecnologia - e até que isso aconteça, o item não pode passar para o anel Experimente.

Com relação ao anel Adote, apenas incluímos itens nele quando acreditamos que, dado o contexto apropriado de projeto, pensaríamos que seria uma má (e potencialmente irresponsável) escolha não o utilizar.

Considerando que um mesmo blip poderia ser incluído em diferentes quadrantes, não nos preocupamos muito com o quadrante em que um blip será adicionado, e não damos importância à sua posição angular dentro do quadrante.

Por outro lado, a posição radial é importante. Se colocamos um blip no anel Experimente, mas próximo ao anel Adote, isso significa que estamos cada vez mais confiantes de seu potencial.

Há várias razões possíveis para que algum item não tenha sido incluído:

• Nenhum dos membros do TAB teve contato com a tecnologia.
• Alguns membros do TAB examinaram, mas não acharam interessante o suficiente.
• Incluímos em nossa lista inicial, mas tivemos que reduzir o número de blips para que coubessem no Radar. Este item foi uma das vítimas — o que significa que consideramos menos importante do que outros.
• Já falamos sobre em uma edição anterior e não temos nada de novo a dizer sobre isso agora. Se um blip não se move, ele desaparece do Radar.
• Incluímos algo mais genérico, para abordar um conceito de forma mais ampla. Por exemplo, não falamos especificamente sobre bancos de dados NoSQL em nossa primeira edição do Radar, mas mencionamos "bancos de dados não-relacionais". Posteriormente, criamos blips específicos para bancos de dados NoSQL.

O Radar apresenta tecnologias que estão em nossa pauta de discussão no momento. Dada a velocidade de evolução da tecnologia, a regra padrão é que os blips apareçam no Radar somente por uma edição, a menos que se movam entre anéis de uma edição para outra. No entanto, os membros do TAB (o Conselho Consultivo de Tecnologia da Thoughtworks), podem defender que um blip seja mantido, por exemplo, quando algo digno de nota acontece, resultando em uma atualização do artigo. Os blips mais antigos podem ser encontrados pela busca de A a Z.

Achamos importante manter os blips mais antigos na busca, pelo registro histórico e pela visibilidade, mas ressaltamos que não seguimos atualizando esses itens. Em alguns casos, os times da Thoughtworks podem seguir usando e recomendando essas tecnologias. Em outros, a recomendação pode estar desatualizada. Tenha isso em mente ao navegar pelos blips do nosso arquivo.

Criamos várias maneiras para mostrar as mudanças dos blips de um Radar para outro. Em primeiro lugar, apresentamos novos blips de forma diferente em relação a blips que já apareceram antes. Nós permitimos que blips se movam entre anéis. Blips podem se desmembrar quando uma categoria geral irrompe em diferentes elementos particulares, ou se aglutinar quando achamos possível tratar várias coisas como uma. Normalmente fazemos a divisão e a combinação quando observamos de diferentes partes do blip mais abrangente devem ficar em diferentes pontos dos anéis.

Às vezes movemos blips de um quadrante para outro. Isso indica que nossa opinião sobre como classificar o blip mudou, já que os quadrantes não são tão importantes, não achamos que essa mudança seja digna de nota e, portanto, não merece qualquer comentário no texto.

As mudanças na composição do TAB afetam o processo de criação dos blips. Se um membro responsável por um blip deixa o TAB, é bem possível que seus temas de interesse recebam menos atenção no futuro.

Nós tentamos limitar o número de blips que temos no Radar, por isso, se achamos que está ficando muito cheio, discutimos quais blips devem ficar e quais não vão caber, muitas vezes por meio de votação para ajudar a manter o foco do conselho. A decisão final sobre os blips que vão entrar é da Rebecca Parsons.

Não.

O Radar capta itens que estão em movimento — por isso só transformamos esses em blips se observamos uma mudança significativa na forma como enxergamos uma tecnologia através dos anéis. Há diversas tecnologias que gostamos e usamos o tempo todo que não estão no Radar porque consideramos que estejam estabelecidas e tenham conquistado seu lugar há muito tempo.

Você vai encontrar muitas dessas tecnologias em edições anteriores do Radar, particularmente aquelas do anel Adote que desapareceram. Mas nem mesmo esta é uma lista longa, uma vez que estamos sempre lutando por espaço no Radar.

Nós nos reunimos duas vezes por ano — de preferência presencialmente — para discutir o Radar. Antes da reunião, os membros do TAB (Conselho Consultivo de Tecnologia da Thoughtworks) costumar conversar com várias pessoas e refletir sobre o que deve virar blip. Thoughtworkers que não fazem parte do TAB podem sugerir coisas que consideram interessantes. Embora o Radar seja do TAB, buscamos opiniões de muitas fontes, dentro e fora da Thoughtworks.

Na reunião, os membros do TAB passam várias horas discutindo sobre o Radar. Nosso principal objetivo durante a reunião é decidir quais blips incluir, em quais anéis eles se encaixam e o que devemos dizer sobre eles.

Começamos colocando candidatos a blips em um mural, cada um em seu quadrante e anel sugeridos. Muitas vezes, diferentes pessoas sugerem os mesmos blips, às vezes em anéis diferentes. Depois de colocar os candidatos no mural, passamos por um longo processo de avaliação de cada blip. Escolhemos um de cada vez e discutimos se deveriam estar no Radar e, em caso afirmativo, onde. Essa discussão é sempre divertida, sempre há muitas opiniões e experiências diferentes na sala, mas também um senso de respeito mútuo que torna as discussões bem menos desagradáveis do que esse tipo de discussão costuma ser.

Nota: escute este podcast para entender como adaptamos esse processo durante a pandemia de Covid-19.

Uma vez que temos os blips escolhido e posicionados, precisamos escrever os textos de cada um deles. Para cada blip, atribuímos uma pessoa responsável por escrever, o que normalmente acontece após a reunião. O TAB conta com uma pessoa product owner, que tem o trabalho nada invejável de nos gerenciar para garantir que nossos blips sejam redigidos. Com os blips escritos, damos início a um processo de feedback interno na Thoughtworks e trabalhamos com representantes regionais para iniciar as traduções. Ao mesmo tempo, uma pessoa do nosso time de design trabalha na criação gráfica.

Tradicionalmente, o formato principal do Radar é o PDF, pelo fato de ser um documento rico em design que gostamos de enviar para as pessoas. Para Radares mais recentes, construímos uma versão HTML interativa com o objetivo de proporcionar uma melhor experiência de exploração, pesquisa e integração entre blips.

Sim, nós encorajamos as pessoas a construir seus próprios Radares. É uma ótima maneira de visualizar uma estratégia de tecnologia e podemos ajudar você a começar. Como exercício, incentiva as pessoas a pensar sobre quais tecnologias elas devem investigar e também ajuda a evitar os perigos de viver dentro de uma bolha tecnológica.

Para entrar no Radar você precisa para obter a atenção dos membros TAB, particularmente no contexto dos nossos projetos. Se você impressionar um membro TAB, isso pode significar uma entrada no anel Avalie, mas precisamos ter uma experiência real para progredir ainda mais.

Não temos um processo formal para pessoas externas nomearem tecnologias, ou para organizar demonstrações. Mas Thoughtworkers estão sempre procurando maneiras de melhorar o processo de criação de software e somos membros ativos de diversas comunidades de tecnologia.

Principalmente porque os usamos. Muitas vezes, estes projetos são o resultado de uma necessidade que temos em uma situação da cliente, frequentemente quando sentimos que estamos recriando a mesma coisa novamente.

Nós sempre organizamos um webinar com dois membros do TAB algumas semanas antes de lançar um novo volume.

Além disso, frequentemente realizamos palestras sobre o Radar nas várias regiões da Thoughtworks. O conteúdo é uma escolha individual de cada palestrante. Geralmente, as pessoas preferem se concentrar nos blips que consideram mais interessantes, embora respondam a perguntas sobre todos os itens. Normalmente as palestras são dadas por um ou dois membros do TAB, algumas vezes com outras pessoas da Thoughtworks que também conheçam bem o Radar.

Se você tem interesse em conseguir alguém para falar sobre o Radar, ou em obter mais informações sobre esses tópicos, entre em contato com o escritório da Thoughtworks mais próximo.

Nós não procuramos fornecer uma lista de referências abrangente, devido a limitações tanto de tempo quanto de espaço. Então, nós apenas incluímos referências a coisas que consideramos serem um pouco mais difíceis para as pessoas procurarem, coisas que achamos particularmente interessantes ou em casos em que elas apresentem visões diferentes.

Ajey Gore (2010-12) • Anne J Simmons (2015-16) • Badri Janakiraman (2011-17) • Brain Leke (2014-16) • Cassie Shum (2020-22) • Chris Stevenson (2010) • Claudia Melo (2013-15) • Cyndi Mitchell (2010-11) • Dave Elliman (2015-16) • David Rice (2010-11) • Evan Bottcher (2011-21) • Graham Brooks (2010-12) • Ian Robinson (2010-11) • James Fischer (2010-13) • Jiaxing Chen (2016) • Jeff Norris (2010-15) • Jim Webber (2010-11) • Jonny LeRoy (2014-20) • Ketan Padegaonkar (2017-19) • Lakshminarasimhan Sudarshan (2017-22) • Marco Valtas (2016-19) • Ni Wang (2018-20) • Nick Hines (2010-12) • Perla Villarreal (2020-22) • Pramod Sadalage (2010-12) • Rachel Laycock (2013-21) • Ronaldo Ferraz (2012-13) • Sam Newman (2012-16) • Samir Seth (2010-11) • Scott Conley (2010) • Srihari Srinivasan (2012-17) • Thiyagu Palanisamy (2012-16) • Wendy Istvanick (2010-12) • Zhamak Dehghani (2016-22)

Na verdade, o objetivo do Radar é nos ajudar a acompanhar as tendências tecnológicas. É inevitável na nossa profissão o fato de que sempre existem coisas novas aparecendo, e não conseguimos acompanhar tudo. Você pode considerar o Radar a nossa opinião sobre como você deve priorizar suas investigações.

• Comece olhando para o anel Adote. Você conhece (e está usando) todos os blips aqui? Se você não sabe muito sobre um blip desse anel, procure saber se ele é relevante para o que você faz. Em caso afirmativo, você deveria estar estudando isso agora mesmo — e colocá-lo em uso o mais rapidamente possível. Se um blip do anel Adote é relevante para o seu trabalho e você não o estiver usando, reflita bem sobre o porquê disso.
• Uma vez que você se familiarizar e começar a usar tudo que se encontra no anel Adote, mova-se para o anel Experimente. Aqui, você deve olhar para cada blip e considerar quais são relevantes para você. Procure se familiarizar com esses temas — faça pesquisas na web, arranje alguns livros, construa um protótipo usando os itens mais promissores. Você também pode começar a pensar sobre o que seria necessário para testá-los em sua organização.
• O anel Avalie é a última prioridade, o qual você pode começar a investigar uma vez que souber sobre o que está no Experimente. Dependendo do seu contexto, pode ser mais importante conhecer algo neste anel do que se aprofundar nos outros anéis. O fato de não termos usado ainda não significa que seja menos importante. Mas em termos de priorizar seu aprendizado, os anéis são um bom caminho a percorrer.
• Coisas no anel Evite você pode ignorar, pelo menos por enquanto.

Claro que isto é apenas a nossa opinião sobre suas prioridades. Nós não esperamos que todo mundo concorde com a gente, mas pelo menos é um ponto de partida.

Assine o Technology Radar