menu

A cada seis meses aproximadamente, a ThoughtWorks publica o Technology Radar. O que começou como um experimento interessante se transformou em uma publicação de grande destaque, bastante valorizada por clientes e demais internautas.

Perguntas Frequentes

Com a repercussão cada vez maior do Radar, nos deparamos com uma série de dúvidas que surgem sobre ele: por que ele tem esse formato e como ele é criado? Reunimos neste FAQ respostas para algumas das perguntas mais frequentes que recebemos.

O que é o Technology Radar da ThoughtWorks?

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.

Quem é o TAB?

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.

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.

Qual é a estrutura do Radar?

O Radar é o produto do monitoramento de tecnologias interessantes, que nos referimos como blips. Nós organizamos os blips na Radar usando dois elementos de categorização: os quadrantes e os anéis. Os quadrantes representam diferentes tipos de blips. Os anéis indicam em que fase do ciclo de vida de adoção achamos que eles devem estar.

Pessoas decidindo a estrutura do radar

O que conta como um blip?

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.

O que são os quadrantes?

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.

O que são os anéis?

A metáfora de um radar diz que quanto mais próximo um blip está de você, mais cedo ele se tornará um problema para você. Como a maioria das metáforas, você não pode levá-la muito a sério, mas há um sentido substancial.

Nosso Radar tem quatro anéis, que iremos descrever a partir do centro:

  • O anel Adote representa blips que achamos que você deveria estar usando agora. Nós não afirmamos que você deve usá-los em todos os projetos, qualquer ferramenta só deve ser usada em um contexto apropriado. No entanto, acreditamos que um blip no anel Adote representa algo que sem dúvida provou seu valor e maturidade para uso.
  • O anel Experimente é para blips que pensamos estarem prontos para uso, mas que ainda não têm maturidade comprovada como os do anel Adote. Assim, para a maioria das organizações, achamos melhor usá-los de forma experimental, para decidir se eles devem ser parte do seu conjunto de ferramentas. Normalmente, temos resultados satisfatórios usando blips do anel Experimente, mas notamos que a maioria das pessoas que nos leem será mais cautelosa do que nós.
  • No anel Avalie estão coisas que você deve examinar com cuidado, mas não necessariamente experimentar ainda — a menos que você ache que elas possam ser particularmente boas soluções para você. Normalmente, blips no anel Avalie são itens que estamos atualmente experimentando em nossos projetos.
  • O anel Evite é para as coisas que estão recebendo atenção na indústria, mas nós não achamos que estejam prontas para uso. Às vezes isso acontece porque não consideramos que elas estejam maduras o suficiente ainda; às vezes significa que achamos que elas sejam irremediavelmente falhas. Não temos um anel "Não use", mas colocamos no anel Evite coisas que desejamos que nossas clientes não usem.

Ao contrário do que acontece com os quadrantes, nós temos algumas discussões apaixonadas sobre para qual o anel um blip deve ir. Nós não costumamos ter discussões acaloradas, mas os anéis geram as discussões mais energéticas. Ao longo do processo de fazer o Radar, criamos algumas regras úteis para nos ajudar a distribuir os blips em anéis.

Nós só podemos colocar um blip no anel Experimente quando não temos experiência com ele em um projeto real. Isto significa que algumas vezes podemos parecer estar atrás da curva de tecnologia, porque podemos gostar de uma tecnologia, mas ainda não convencemos uma cliente a testá-la — e até fazermos isso um blip não pode passar para o anel Experimente.

Para o anel Adote, só incluímos itens quando achamos que seria uma escolha ruim e potencialmente irresponsável não usá-los quando em um contexto de projeto apropriado.

Qual é o significado da posição de um blip em seu quadrante e anel?

Nós não gastamos muita energia decidindo para qual quadrante um blip deve ir, e nenhuma decidindo sua posição angular dentro do quadrante. Dessa forma, a coordenada angular de um blip é decidida pelas pessoas que fazem o design visual e não tem significado semântico.

Por outro lado, damos sim atenção à posição radial. Se colocarmos um blip no anel Experimente, mas próximo ao anel Adote, isso significa que estamos perto de uma recomendação incisiva.

Por que <insira aqui uma tecnologia interessante> não está no Radar?

Há várias razões para que algum item esteja faltando:

  • Nenhum dos membros do TAB se deparou com ela.
  • Algumas pessoas do TAB já avaliaram, mas não acharam interessante o suficiente.
  • Nós colocamos na nossa lista inicial, mas tivemos que reduzir o número de blips para caberem no Radar. Este item foi uma das vítimas — o que significa que sentimos que ele era menos importante que os outros.
  • Já falamos sobre em um Radar anterior, e não temos nada de novo a dizer sobre isso agora. Se um blip não se move, ele desaparece do Radar.
  • Nós transformamos em um blip algo mais genérico, para falar sobre o conceito de maneira mais ampla. Por exemplo, nós não falamos especificamente sobre bancos de dados NoSQL em nossa primeira edição do Radar, falamos sobre "bancos de dados não-relacionais". Em um segundo momento, criamos blips específicos para bancos de dados NoSQL.

Por que blips desaparecem entre Radares?

O Radar representa mudanças sobre as quais temos pensado atualmente. Nossa regra padrão é que qualquer blip só aparece no Radar por duas edições, depois disso, o blip automaticamente desaparece — o que significa que não aparecerá no próximo Radar. Pense nisso como um "arquivamento" do blip — blips antigos que sentimos que não são mais atuais ou dignos de nota não aparecerão na versão mais recente do Radar. Blips mais velhos permanecem pesquisáveis no Radar de A a Z. Achamos importante manter um arquivo completo e visível, mas esteja ciente de que não o atualizamos ativamente. Muitos times da ThoughtWorks podem ainda estar trabalhando com e recomendar essas ferramentas, mas só atualizamos os blips se sentimos que algo novo aconteceu (ou com a ferramenta ou com a nossa experiência com ela). Nesses casos, movemos o blip para o anel apropriado (provavelmente "Adote" ou "Evite").

Se o blip está prestes a desaparecer, mas achamos que vale a pena manter a atenção nele, podemos optar por "reblipá-lo" — essencialmente mantendo-o por mais uma edição. Quando "reblipamos" normalmente explicamos o motivo no texto do Radar.

Se consideramos que um blip mudou para um novo anel, isso conta como um reblip.

Reviewing last edition's blips

Quando um blip aparece pela segunda vez no Radar, nós geralmente não escrevemos sobre ele novamente, a menos que tenhamos algo novo a dizer.

Cada vez mais, estamos removendo blips depois de apenas uma aparição, porque estamos ficando sem espaço. Esse desaparecimento precoce indica apenas seu nível de interesse relativo, não implica qualquer mudança na nossa opinião sobre o valor do blip. Se testamos algo e achamos que não corresponde às expectativas, então movemos para o anel Evite.

Como blips mudam?

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.

Qual é o critério para a criação de um blip?

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.

 TAB voting

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.

O Radar é uma lista de tecnologias aprovadas pela ThoughtWorks?

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.

Como construímos o Radar?

O foco da construção do Radar é o nosso encontro presencial que acontece semestralmente. Antes das reuniões, os membros do TAB geralmente conversam com muitas pessoas e pensam sobre o que deveria virar blip. ThoughtWorkers que não são parte do TAB fazem lobby para coisas que consideram interessantes; embora o Radar seja do TAB, buscamos opiniões de muitas fontes, dentro e fora ThoughtWorks. Durante o encontro, passamos várias horas discutindo o Radar. Nosso principal objetivo durante a reunião é decidir quais são os blips e em quais anéis eles estão. Uma vez que esta é a parte mais controversa do processo, é importante fazer isso enquanto os membros estão juntos.

Começamos colocando blips candidatos na parede, cada um em seu quadrante e anel sugeridos. Muitas vezes pessoas diferentes sugerem os mesmos blips, normalmente em anéis diferentes. Uma vez que temos os candidatos posicionados no quadro, começamos um longo processo de avaliação de cada blip. Passamos por cada blip, um de cada vez, e discutimos se achamos que eles devem estar no Radar e, em caso afirmativo, onde. Essa discussão é sempre agradável, há muitas opiniões e experiências reunidas na sala, mas há também empatia e respeito mútuos que tornam as discussões muito menos irritantes que discussões desse tipo geralmente são. Uma vez que temos os blips escolhido e posicionados, nós então precisamos escrever os textos para eles. Fazemos isso usando o Mingle, para que possamos colaborar com facilidade nas descrições. A cada blip é atribuída uma pessoa responsável por escrevê-lo, o que normalmente acontece após a reunião. O TAB tem uma pessoa coordenadora que tem a tarefa pouco invejável de nos perseguir para obter nossos blips redigidos.

Mais ou menos ao mesmo tempo que estamos escrevendo, uma pessoa designer trabalha na parte gráfica. Nós dizemos à pessoa designer quais blips incluir e sua distância do centro, mas cabe a ela decidir os ângulos dentro de um quadrante.

Nossa pessoa coordenadora extrai os textos do Mingle e organiza os vários formatos do Radar.

Em quais formatos o Radar é publicado?

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.

Posso construir o meu próprio Radar?

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.

Como posso colocar o meu produto no Radar?

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.

 Reviewing last edition 's blips

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.

Por que tantos projetos de código aberto da ThoughtWorks são incluídos?

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.

É possível conseguir alguém para dar uma palestra sobre o Radar?

Damos palestras sobre o Radar frequentemente. Isso depende de cada palestrante, mas a maioria das pessoas gosta de abordar os blips em que elas estão particularmente interessadas, embora elas respondam com prazer a perguntas sobre todos os itens. Geralmente palestras sobre o Radar são dadas por um ou dois membros do TAB, possivelmente com outra pessoa da ThoughtWorks que está familiarizada com ele.

O Neal também tem uma palestra sobre a como criar seu próprio radar.

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

Por que a lista de referências não inclui todas as coisas que vocês mencionam?

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.

Que trabalhou no Radar no passado?

Ajey Gore

Ajey Gore

(2010-12)
Anne J Simmons

Anne J Simmons

(2015-16)
Badri Janakiraman

Badri Janakiraman

(2011-17)
Brain Leke

Brain Leke

(2014-16)
Chris Stevenson

Chris Stevenson

(2010)
Claudia Melo

Claudia Melo

(2013-15)
Cyndi Mitchell

Cyndi Mitchell

(2010-11)
Dave Elliman

Dave Elliman

(2015-16)
David Rice

David Rice

(2010-11)
Graham Brooks

Graham Brooks

(2010-12)
Ian Robinson

Ian Robinson

(2010-11)
James Fischer

James Fischer

(2010-13)
Jiaxing Chen

Jiaxing Chen

(2016)
Jeff Norris

Jeff Norris

(2010-15)
Jim Webber

Jim Webber

(2010-11)
Nick Hines

Nick Hines

(2010-12)
Pramod Sadalage

Pramod Sadalage

(2010-12)
Ronaldo Ferraz

Ronaldo Ferraz

(2012-13)
Sam Newman

Sam Newman

(2012-16)
Samir Seth

Samir Seth

(2010-11)
Scott Conley

Scott Conley

(2010)
Srihari Srinivasan

Srihari Srinivasan

(2012-17)
Thiyagu Palanisamy

Thiyagu Palanisamy

(2012-16)
Wendy Istvanick

Wendy Istvanick

(2010-12)

É tanta coisa! Como posso acompanhar isso tudo?

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