Perguntas frequentes

O Technology Radar é baseado nos insights que obtivemos por meio das experiências e aprendizados dos Thoughtworkers ao trabalhar com algumas das principais empresas do mundo. O resultado é a abrangência de tecnologias, indústrias e geografias. Como uma consultoria de software com histórico de pioneirismo em práticas de desenvolvimento de software personalizado, acreditamos que ele representa uma amostra razoável, mas não há nenhuma tentativa em ser abrangente ou de representar uma pesquisa de mercado em geral.

Não publicamos o Tech Radar com o objetivo de aquisição de receita, nem aceitamos solicitações de fornecedores para influenciar o que incluímos. Compartilhamos nossas opiniões na crença de que vencer em tecnologia não significa ter a resposta certa; significa estar aberto e atento às opções em um ecossistema em rápida evolução.

O Technology Radar é desenvolvido pelo Conselho Consultivo de Tecnologia  da Thoughtworks (em inglês, Technology Advisory Board - TAB). 

O TAB é um grupo formado por 20 tecnologistas experientes da Thoughtworks, que se reúnem duas vezes por ano pessoalmente e quinzenalmente por videochamada. Sua principal atribuição é ser um grupo consultivo grupo consultivo para Rachel Laycock, CTO da Thoughtworks. O TAB representa uma gama ampla de líderes de tecnologia - de diferentes países, áreas de especialização e tempo de contribuição.

Rachel Laycock (CTO) • Martin Fowler (Chief Scientist) • Rebecca Parsons (CTO Emerita) • Bharani Subramaniam • Birgitta Böckeler • Camilla Falconi Crispim • Erik Doernenburg • James Lewis • Ken Mugrage • Maya Ormaza • Mike Mason • Neal Ford • Pawan Shah • Scott Shaw • Selvakumar Natesan • Shangqi Liu • Sofia Tania • Thomas Squeo  • Vanya Seth • Will Amaral

O objetivo do Radar é rastrear tecnologias e técnicas, que chamamos de blips. Organizamos os blips no radar usando dois elementos de categorização: os quadrantes e os anéis. Os quadrantes representam os diferentes tipos de blips. Os anéis indicam nossa recomendação para utilizar essa tecnologia ou técnica.

Um blip é uma tecnologia ou técnica que desempenha um papel no desenvolvimento de software. Os blips estão ‘‘em movimento’’ - suas posições no radar estão constantemente mudando — geralmente indicando que nossa confiança em recomendá-los tem crescido à medida que se movimentam entre os anéis.

Os quadrantes são uma categorização dos tipos de blips:

• Técnicas. São elementos de um processo de desenvolvimento de software, tais como design de experiência; e maneiras de estruturar software, como microsserviços.

   

• 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.

   

• Ferramentas. Podem ser componentes, como bancos de dados, ferramentas de desenvolvimento de software, como sistemas de controle de versão; ou categorias mais genéricas de ferramentas, como a noção de persistência poliglota.

   

• Linguagens e Frameworks. São as linguagens de programação como Java e Python, mas atualmente se concentra principalmente em frameworks como Gradle, Jetpack e React.js.

   

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 em qual quadrante um blip vai, ao contrário dos anéis, que geram muita discussão.

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

• O anel Adote representa blips que nós achamos que você deve considerar seriamente usar. Não estamos dizendo que você deve usá-los em todos os projetos; toda ferramenta deve somente ser usada em contexto adequado. Entretanto, 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 blips que consideramos prontos para uso, mas que não estão completamente estabelecidos quanto aqueles que mencionamos em Adote. Por isso, para a maioria das organizações, acreditamos que seja mais adequado experimentar essas tecnologias, com o intuito de decidir se ela deve fazer parte de seu ferramental. Geralmente, nós já testamos os blips que estão neste anel em produção, mas entendemos que algumas pessoas preferem 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, blips em Avalie representam coisas que consideramos interessantes e que vale a pena prestar atenção.
  
  

• O anel Evite é para itens que,  já talvez tenham sido aceitos pela indústria, mas não nos proporcionaram boas experiências. Nossa intenção é alertar que você pode enfrentar dificuldades também. Em alguns casos, consideramos 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 utilizasse.

Nós temos discussões bastante agitadas sobre qual o anel em que um blip deve ser colocado. Com a experiência de construção do Radar ao passar dos anos, chegamos em algumas regras úteis que nos ajudam a classificar os blips nos anéis.

Só colocamos blips em Experimente 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 uma cliente a experimentar com a tecnologia — e até que isso aconteça, um blip não pode passar para o anel Experimente.

Com relação ao anel Adote, apenas incluímos os blips que, dado o contexto apropriado de projeto, acreditamos 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 Thoughtworker recomendou o blip.

   

• 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 que deve ser destacado acontece, resultando em uma atualização do conteúdo.  

Acreditamos que é importante manter os blips mais antigos arquivados, pelo registro histórico e pela visibilidade, mas alertamos 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 aos blips que já apareceram antes. A mudança mais comum é a movimentação dos blips entre anéis. Um blip que cobre uma categoria ampla pode ser dividido em elementos particulares à medida que essa categoria amadurece.

Às vezes movemos blips de um quadrante para outro, o que indica uma alteração na classificação desse blip mudou. Não acreditamos que essa mudança seja significativa, portanto, não destacamos no texto.

Todos os blips disponíveis no Radar são propostos por nossas Thoughtworkers ao redor do mundo. Antes de nossas reuniões do Radar, nossas equipes indicam coisas que descobriram durante seu trabalho em projetos de clientes. Para entrar no Radar, as Thoughtworkers devem argumentar que observaram algo relevante e que merece ser compartilhado. 

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 terão espaço, muitas vezes por meio de votação para ajudar a manter o foco do conselho. 

Não, porém o Radar é utilizado pelas Thoughtworkers como uma ferramenta de compartilhamento de conhecimento entre projetos e experiências.

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 dedicam várias horas para discutir 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: ouça nossos podcasts para entender como desenvolvemos o Radar presencialmente e remotamente. 

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  no design e PDF.

O Radar é disponibilizado em duas versões: um interativo no nosso site e o PDF. A versão interativa do site permite que você explore, pesquise e faça conexões entre os blips. Já o formato em PDF é uma ótima opção para ler todos os blips em um lugar só. 

Sim, incentivamos as pessoas a construírem a sua própria versão do Radar. É uma ótima maneira de obter uma avaliação objetiva de todo o seu portfólio de tecnologia,  avaliar o que está funcionando bem e onde você tem oportunidades de melhoria. Criamos uma ferramenta online que pode ajudá-lo a começar.

Para entrar no Radar, você precisa chamar a atenção das pessoas da Thoughtworks, principalmente no contexto do nosso trabalho em projetos. Se você conseguir engajar uma equipe da Thoughtworks, a proposta pode chegar ao anel Avalie, mas precisamos de experiência em um projeto real para progredir 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.

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.

Ajey Gore (2010-12) • Anne J Simmons (2015-16) • Badri Janakiraman (2011-17) • Bharani Subramaniam (2016-present) • Birgitta Boeckeler (2020-present) • Brain Leke (2014-16) • Brandon Byars (2020-24) • Camilla Falconi Crispim (2016-present) • Cassie Shum (2020-22) • Chris Stevenson (2010) • Claudia Melo (2013-15) • Cyndi Mitchell (2010-11) • Darren Smith (2010-14) • Dave Elliman (2015-16) • David Rice (2010-11) • Erik Doernenburg (2010-present) • Evan Bottcher (2011-21) • Fausto de la Torre (2016-24) • Graham Brooks (2010-12) • Hao Xu (2010-24) • Ian Cartwright (2010-23) • Ian Robinson (2010-11) • James Fischer (2010-13) • James Lewis (2012-present) • Jiaxing Chen (2016) • Jeff Norris (2010-15) • Jim Webber (2010-11) • Jonny LeRoy (2014-20) • Ken Mugrage (2024-present) • Ketan Padegaonkar (2017-19) • Lakshminarasimhan Sudarshan (2017-22) • Marco Valtas (2016-19) • Marisa Hoenig (2022-24) • Martin Fowler (2010-present) • Maya Ormaza (2023-present) • Mike Mason (2010-present) • Neal Ford (2010-present) • Ni Wang (2018-20) • Nick Hines (2010-12) • Pawan Shah (2023-present) • Perla Villarreal (2020-22) • Pramod Sadalage (2010-12) • Rachel Laycock (2013-21, 2023-present) • Rebecca Parsons (2010-present) • Ronaldo Ferraz (2012-13) • Sam Newman (2012-16) • Samir Seth (2010-11) • Scott Conley (2010) • Scott Shaw (2011-present) • Selvakumar Natesan (2023-present) • Shangqi Liu (2018-present) • Sofia Tania (2023-present) • Srihari Srinivasan (2012-17) • Thiyagu Palanisamy (2012-16) • Thomas Squeo (2024-present) • Vanya Seth (2023-present) • Wendy Istvanick (2010-12)  • Will Amaral (2024-present) • Zhamak Dehghani (2016-22)

Na verdade, o objetivo do Radar é, em parte, 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.
  
  

• Preste bem atenção aos blips no anel Evite. Estamos apontando coisas que podem ser mais prejudiciais do que úteis, dependendo do contexto. Se você estiver fazendo uso do item em questão, deve refletir sobre o porquê disso e se faz sentido começar a planejar para se afastar. Educar outras pessoas ao seu redor também pode ser uma boa ideia. A ferramenta BYOR (Build Your Own Radar) pode ser útil para começar essas discussões.

• 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 explorar 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, para priorizar o que faz sentido para o seu aprendizado, os anéis são um bom caminho a percorrer.

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