Construa Seu Próprio Technology Radar

Ao longo os anos 90 e no início dos anos 2000, eu fui o Diretor-Chefe de Tecnologia de uma pequena empresa de treinamento e consultoria. Quando comecei, a plataforma primária era o Clipper, que era uma ferramenta rápida de desenvolvimento de aplicações para gerar aplicações DOS em arquivos dBASE. O Clipper era baseado em objetos; alavancamos uma biblioteca de extensões chamada  Class(y) para torná-lo completamente orientado para objetos e imediatamente avançamos sobre a concorrência porque criamos um framework extenso orientado para objetos para gerar aplicações. Estávamos bem felizes com uma empresa de treinamento e consultoria indo muito bem.

Um dia, porém, tudo desapareceu. Notamos o avanço do Windows e a maioria de nós já havia experimentado e até usado algumas de suas ferramentas primitivas para criar coisas. Mas o mercado ainda usava DOS... e de repente parou. Em um aparente passo de mágica, nossos negócios desapareceram. Tivemos que nos esforçar para achar ferramentas e plataformas equivalentes no mundo Windows. Essa lição deixou uma impressão duradoura: ignore o progresso da tecnologia por sua própria conta e risco.

Isso também me ensinou uma lição importante sobre bolhas de tecnologia. Ao se envolver pesadamente em uma tecnologia, você entra em uma bolha memética, que também funciona como uma câmara de eco. Bolhas criadas por distribuidores são especialmente perigosas, porque você não recebe opiniões honestas de dentro da bolha. Mas o maior risco de Viver na Bolha é quando ela começa a estourar – você nunca percebe até que seja tarde demais. Isso aconteceu conosco com o Clipper e pode acontecer com você também. Nós não tínhamos um radar de tecnologia: um documento usado para avaliar os riscos e recompensas de tecnologias novas ou já existentes. Aprendi que precisamos de dois radares: um para você, que oriente suas decisões profissionais, e outro para a sua empresa, ajudando em decisões de compras e direções tecnológicas. Irei discutir como desenvolver ambos os tipos de radares, mas antes descreverei como esse conceito foi criado.

Você precisa de dois radares: um para você, orientando suas decisões profissionais, e outro para a sua empresa. 
Twite isso

O Technology Radar da Thoughtworks

O TAB (Technology Advisory Board – Conselho Consultivo de Tecnologia) da Thoughtworks é um grupo de líderes de tecnologia sênior da Thoughtworks, criado para auxiliar a diretora de tecnologia, Rebecca Parsons, a decidir quanto a direções e estratégias tecnológicas para nós e nossos clientes. A Thoughtworks tenta ser proativa em suas escolhas de tecnologia, avaliando objetivamente os usos de tecnologia com problemas que vemos no mundo. Por exemplo, fomos os proponentes iniciais de Ruby on Rails para empresas, porque entendemos os méritos técnicos do Rails e quando ele era aplicável. Sou membro do TAB, que se reúne em uma videoconferência internacional – com horários terríveis – a cada duas semanas e, pessoalmente, algumas vezes por ano.

Um dos resultados da reunião presencial é o Technology Radar. Ele começou como o resultado do que foi (para muitos de nós) a parte mais divertida da reunião presencial – a discussão sobre Tecnologias Legais. Uma vez que a Thoughtworks é uma entidade complexa, o TAB tem um cronograma bem cheio quando nos reunimos em pessoa. Mas, no fundo, somos todos geeks. Desde o início, reservamos um espaço na agenda para falar sobre coisas pelas quais somos apaixonados. Ao longo do tempo, ele tornou-se o Technology Radar semestral, cuja versão mais recente está no www.thoughtworks.com/radar.

Ele ficou mais popular do que jamais poderíamos imaginar. Não temos certeza do porquê, mas talvez seja porque somos uma das poucas empresas de consultoria que dá pareceres sinceros sobre tecnologia. Somos pessoas apaixonadas por tecnologia e não temos medo de dar nossas opiniões. Ele também é popular porque incorpora uma estrutura metafórica útil para avaliar tecnologias. Embora não seja uma metáfora perfeita, é uma metáfora, e às vezes tudo de que os memes precisam para florescer é uma estrutura na qual podemos pendurar ideias.

Aos poucos, o TAB fixou sua produção de radares duas vezes por ano. Então, como costuma acontecer, surgiram alguns efeitos colaterais. Em algumas conferências das quais participei, os participantes me procuraram para me agradecer por ter ajudado a produzir o radar, dizendo que suas empresas começaram a produzir o seu próprio radar. Não havíamos pensado em sugerir este exercício para os outros, mas seria até meio óbvio. Desde então, realizamos este exercício com muitos dos nossos clientes. Foi um sucesso.

Percebi também que esta é a melhor resposta para a eterna pergunta de conferências: “Como vocês (palestrantes) acompanham a tecnologia? Como vocês sabem o que buscar?”. A resposta é que todos temos uma espécie de radar interno. Usando as ferramentas apresentadas, você pode formalizar esse processo, o que o ajudará a decidir onde você quer gastar seu precioso tempo de pesquisa e desenvolvimento que pode levar a uma nova carreira mas que subtrai o tempo com a família.

Você precisa de dois radares: um para si e outro para a sua empresa. Descreverei como e por que criá-los, mas antes preciso passar pelos detalhes do documento em si.

Mecânica

A metáfora do radar fornece os círculos concêntricos mostrados aqui:

O radar é dividido em quatro quadrantes (somos uma empresa de consultoria e temos o estranho impulso de produzir coisas com quadrantes): Técnicas, Ferramentas, Plataformas e Linguagens
& Frameworks.

Anéis

O radar tem quatro anéis, do mais externo ao mais interno: evite, avalie, experimente e adote.

Evite

A intenção original do anel evite era “evite por enquanto”, representando tecnologias que eram novas demais para serem avaliadas. Estávamos pensando em tecnologias que estavam gerando certo estardalhaço mas que ainda não estavam comprovadas. O anel evite evoluiu para tornar-se o nosso modo de dizer “não inicie nada novo com esta tecnologia”. Não há problema em usá-la em projetos já existentes, mas pense duas vezes antes de usar essa tecnologia para novos desenvolvimentos. Evite é o mais próximo que temos de uma categoria evitar, que Rebecca não nos permite usar. Acabamos notando a sabedoria dessa decisão: como na metáfora, o seu radar deve ter coisas pelas quais você anseia e não recriminações do passado.

Avalie

O anel avalie indica uma tecnologia que vale a pena explorar com o objetivo de entender como seu impacto. Você deve investir algum esforço (como picos de desenvolvimento, projetos de pesquisa, presença em sessões de conferência etc.) para ver se ela afetará a sua organização. Por exemplo, muitas empresas de grande porte passaram por esta fase ao formular uma estratégia para dispositivos móveis.

Experimente

O anel experimente é para tecnologias que você (e/ou os seus pares) decidiram que valem a pena buscar. É importante entender o desenvolvimento dessa capacidade. Chegou a hora de pilotar um projeto de baixo risco para “se sujar” com a tecnologia de modo a entendê-la profundamente. Queríamos critérios objetivos para que a Thoughtworks passasse algo do avalie para o experimente e decidimos que o teste definitivo é o uso sério: precisamos usar essa tecnologia em projetos. Acreditamos que é impossível avaliar plenamente uma tecnologia se você não a utilizou para resolver problemas reais – isso ajuda a entender suas forças e suas fraquezas. Frequentemente a fase avalie demonstra benefícios e não limitações, enquanto resolver problemas reais traz uma perspectiva holística. Afinal de contas, toda tecnologia visa convencê-lo a usá-la, insistindo nos benefícios mas ocultando deficiências. Você é responsável por descobrir as fraquezas em novas tecnologias.

Adote

Para tecnologias no anel adote, sentimos que a indústria deveria adotar estes itens. Nós o usamos nos nossos projetos conforme for apropriado; é o mais próximo de uma solução “fácil” possível.

Estávamos tentando chegar a um bom critério para quando uma coisa pode ser considerada totalmente no adote, e meu colega Mike Mason desenvolveu o que chamamos de Navalha de Mason: para todas as tecnologias no anel adote, eu darei risada de você no bar se você não as usar. Uma adição recente foi a Segunda Lei de Mason: suspeite de qualquer coisa que você queira levar diretamente para o adotar – você realmente entende dela bem o suficiente?

Ícones

Nós usamos um conjunto simples de ícones. Triângulos representam itens novos ou alterados, enquanto círculos indicam a ausência de mudança. Também mostramos vetores ilustrando o movimento nos quadrantes isolados.

Quando um ícone não mudar por dois radares (um ano), deixamos que esmoreça, reduzindo o acúmulo visual. Se houver algo interessante para se dizer sobre um item, nós o ressuscitaremos (ou trazemos de volta para o radar)

Como o construímos

Para cada quadrante:

• todas as pessoas usam post-its para anotar suas nomeações e os colocam no quadro branco nas 4 faixas desenhadas para representar os anéis (evite, avalie, experimente, adote)
• a pessoa facilitadora (um membro do TAB) agrupa notas parecidas (inevitavelmente haverá alguma sobreposição naquilo que todo mundo acha legal)
• em grupo, discutimos cada tecnologia, se ela deve permanecer no radar e onde
• uma pessoa apaixonada é escolhida para escrever uma descrição em poucas frases que dê contexto à decisão (parte dela aparecerá no white paper)

Também fazemos isso para inserções existentes no radar, decidindo se elas devem mudar, esmorecer ou ser “ressuscitadas”.

Uma força benéfica que impulsiona o nosso radar vem do meu colega e membro do TAB Erik Doernenburg, que sempre exerce pressão para nos encorajar a nomear tecnologias específicas. Por exemplo, em vez de adotar uma categoria ampla (por exemplo, ferramentas de agregação de logs), usar nomes de tecnologias específicas: recentemente citamos logstash e Greylog2 nesse espaço como exemplares dessa nova categoria de ferramentas que esperamos que as pessoas adotem. A especificidade traz concretude ao radar.

Chegando a um consenso

Uma das coisas mais incríveis que notamos somente em um momento posterior foi a rapidez com que o TAB chega a um consenso. Especialistas em Tecnologia sênior tendem a ser apaixonados, mas chegamos a conclusões rapidamente, e dificilmente a Rebecca precisa dar seu voto de minerva. Outros grupos semelhantes, dentro ou fora da Thoughtworks, parecem levar muito tempo para chegar a um eventual consenso. Uma teoria afirma que, enquanto especialistas em tecnologia, estamos acostumados a defender nossas posições e submetê-las à aprovação dos outros, respeitando o resultado e seguindo adiante sem nos machucar. Ao trabalhar com projetos de software em grandes organizações, você desenvolve suas habilidades de aceitação. Inesperadamente nos beneficiamos da nossa prática nesta área; escolher quais tecnologias aparecem no nosso radar costuma ser uma empreitada conjunta.

Pedacinhos de Visualização Open Source

Devido ao clamor popular, a Thoughtworks lançou em novembro de 2016 uma ferramenta para ajudar especialistas em tecnologia a desenvolver a sua própria visualização em radar. Quando fazemos este exercício para empresas, capturamos o resultado da reunião em uma planilha, com uma página para cada quadrante. A ferramenta Build Your Own Radar da Thoughtworks usa uma planilha do Google como input e gera a visualização em radar usando um canvas de HTML 5. Assim, embora a parte importante do exercício sejam as conversões geradas, você pode facilmente gerar a visualização adequada usando esta ferramenta

O exercício de criação do Tech Radar convida você a conversar com todos os níveis da organização.
Twite isso

Radar da Thoughtworks

Muitas pessoas se enganam quanto ao propósito do radar Thoughtworks, então criamos um FAQ para responder perguntas comuns. Para nós, trata-se de uma imagem no tempo sobre o que um grupo de especialistas em tecnologia invocados acham legal. Não é uma ferramenta de avaliação do ciclo de vida de tecnologias – algumas tecnologias que amamos, como o GitHub esvaneceram há muito tempo na nossa categoria adotar. A metáfora é apta: um radar rastreia objetos vindouros no curto prazo.

Embora não esperássemos que a nossa metáfora se popularizasse, outros começaram a usá-la para desenvolvimento de carreira pessoal e para abarcar um loop de feedback que faltava em muitas empresas.

Radar pessoal

Ao iniciar uma carreira em desenvolvimento de software, você assina um pacto que promete que você acompanhará as mudanças neste mundo. No começo, é divertido porque há sempre algo novo para descobrir e experimentar. Ao longo do tempo, porém, as coisas que você aprende se transformam em uma Carreira – aí, tecnologias têm mais valor do que seu fator “legal”. É sábio investir em aprender a tecnologia atual de maneira aprofundada (a parte boa é que, se essa tecnologia também for “legal”, você ainda assim pode chamar isso de “trabalho”).

Você jamais pode repousar sobre os próprios louros. O mundo tecnológico muda de maneira assombrosamente rápida. Um dos meus ex-colegas era um especialista de renome mundial no Clipper. Ele lamentou que não poderia pegar o conjunto imenso de conhecimento sobre o Clipper (que tornou-se inútil) e trocá-lo por outra coisa. Ele também especulou o seguinte (que continua em aberto): algum grupo na história aprendeu e jogou fora tantos conhecimentos detalhados em suas vidas quanto desenvolvedores de software?

É perigoso adotar uma atitude Laissez-faire quanto ao seu portfólio tecnológico. A maioria dos especialistas escolhe tecnologias de modo relativamente ad-hoc, com base no que é “legal” ou no que o seu empregador está usando. Criar um radar de tecnologia para você mesmo o ajuda a formalizar o seu pensamento e a ponderar algumas tecnologias (maior fator “legal”, menor probabilidade de gerar trabalho x mercado de trabalho imenso, mas trabalho desinteressante). Você deve tratar o seu portfólio tecnológico como uma carteira de finanças: de várias maneiras, elas são a mesma coisa. Qual é o conselho de sempre de consultores financeiros? Diversifique!

Escolha algumas tecnologias e/ou habilidades que estão em alta demanda e rastreie essa demanda. Você também pode experimentar alguns atalhos tecnológico de alto risco/alta recompensa, como desenvolvimento open source ou mobile. Conheço alguns desenvolvedores que se libertaram da servidão dos cubículos virando noites em projetos open source que se tornaram populares, compráveis e, eventualmente, fizeram suas carreiras. O desenvolvimento para aplicações móveis atualmente tem a aura brilhante de “da garagem para o sucesso”, o que é válido mas também é incrivelmente difícil.

Separe algum tempo. desenvolva testes que o ajudem a escolher tecnologias e crie um radar. Você pode usar os nossos quadrantes ou desenvolver os seus próprios quadrantes. Perceba que o exercício é tão importante quanto o resultado, então agende algum tempo para revisitá-lo algumas vezes por ano. É natural para mim revisitar o meu no final do ano porque é quando eu penso em coisas novas – no verão também, quando começo a falar de ideias para o próximo ano. Criar as peças físicas (uma visualização de radar rudimentar + anotações) o ajuda a formalizar o seu pensamento e contextualiza suas decisões para que você as entenda ao revisitá-las.

Radar empresarial

Embora o valor de um radar pessoal seja evidente, uma versão empresarial parece menos valiosa. O oposto é verdade.

Motivos

Aqui estão os cinco motivos pelos quais a sua empresa precisa de um radar de tecnologia

1. Ponderar risco x adoção

Para qualquer tecnologia específica, sua empresa está em alguma parte da curva de difusão da inovação:

​

No entanto, você não tem só uma tecnologia, mas sim várias: todo framework de código aberto, produto comercial, ferramentas caseiras etc. Para cada uma delas, você pode desenhar sua posição na curva de adoção e onde você acha que deveria estar, ponderando o risco e a recompensa. Embora isso seja um exercício útil, fazê-lo para cada tecnologia é trabalhoso. Tentar criar uma matriz abrangente que avalie todas as dimensões das tecnologias é um empreendimento destinado ao fracasso. Em vez disso, você precisa de um sistema de categorização bruto que gere linhas amplas e não traços finos, como nossos anéis de radar.

Para qualquer tecnologia, sua organização tem uma localização ideal na curva de inovação, ponderando o risco e a recompensa. Meu colega Darren Smith criou a metáfora original do radar visualizando o conjunto de tecnologias que você usa, sua fase de adoção ideal e “achatando-as” em um círculo de radar bidimensional. Como muitas metáforas ricas, o “radar” faz sentido em muitos níveis

2. Uma plataforma de análise contínua

Quando você desenvolver a estrutura, o exercício torna-se de fácil repetição. Você terá uma plataforma que o ajudará a avaliar sua reação e o seu apetite por tecnologia continuamente. A tecnologia jamais estaciona; você deve (re)avaliá-la constantemente, senão correrá o risco de ser ultrapassado pela concorrência. Um formato padrão o ajudará a desenvolver um histórico com esse exercício, usando-o para obter insights ao longo do tempo

3. Mensagem unificada do técnico ao interessado-mas-não-técnico

A pessoa que é diretora de tecnologia, ou que toma decisões de compra de software” provavelmente conversa com as pessoas sobre tecnologia regularmente, talvez até pedindo opiniões. Mas são raros os Diretores tecnológicos que convocam reuniões para que seus subordinados avaliem seu processo de decisão em relação às ferramentas que usam todos os dias. A maioria dos executivos de nível C recebe mais conselhos de vendedores do que de seus funcionários. Por que? Para começar, ninguém quer feedback que possa ser negativo, especialmente quando esse feedback for opcional. Em segundo lugar, quando as oportunidades de feedback surgem, a maior parte é negativa e na forma de reclamações. Com que frequência você diz para a pessoa diretora de tecnologia “Ei, você mandou bem escolhendo a tecnologia X” ou “Sabe, a nossa produtividade aumentou bastante desde que começamos a usar Y”. A tecnologia eficaz é invisível, mas a tecnologia defeituosa é bastante evidente para quem a utiliza. Na maioria das organizações, não há loop de feedback entre as pessoas que usam a tecnologia e as pessoas que a escolhem. Um radar de tecnologia é uma ferramenta sem culpa que permite que todos os consumidores de tecnologia mandem suas mensagens sobre tecnologia ao tomador de decisões. Em algumas das empresas nas quais ajudamos a produzir um radar, uma mudança de estrutura que os desenvolvedores defendiam há mais de um ano aconteceu quase imediatamente quando os Poderosos perceberam sua demanda universal

4. Desculpa para ter conversas apaixonadas sobre tecnologia

Certa vez, um gestor de projetos reclamou para mim que os desenvolvedores de um projeto discutiam demais. Eu o corrigi dizendo que eles meramente tinham conversas apaixonadas, que demonstram animação e não raiva. Com que frequência temos oportunidades para que especialistas apaixonados por tecnologia se juntem e tenham conversas apaixonadas sobre as tecnologias com as quais interagem todos os dias? Criar um radar é uma dessas desculpas, em (esperamos) um ambiente sem hostilidade. O grupo de especialistas deve ser composto por membros de todos os projetos de todos os ramos de tecnologia. Frequentemente, barreiras de linguagens de programação têm o mesmo impacto de idiomas orais, isolando seus membros em panelinhas. O exercício do radar faz com que todos se juntem para falar de suas semelhanças, e não suas diferenças. O resultado costuma surpreender.

Descobrimos que este aspecto é a parte mais benéfica do exercício porque você pode ter conversas importantes sobre a tecnologia que você usa a qualquer momento, mas não chega a fazê-lo. Por exemplo, a maioria dos desenvolvedores provavelmente acha que sabe a opinião do seu superior sobre Puppet, mas a conversa formal sempre traz resultados surpreendentes

5. Ajuda a alinhar as visões de negócios e de TI sobre tecnologia

Ter um radar ajuda a decidir quando ser mais (ou menos) agressivo sobre implantar uma nova tecnologia e traz uma visão legível e condensada que leigos podem entender. Ter uma opinião pública sobre o estado atual e futuro da tecnologia na sua empresa ajuda a tomar decisões e planejar carreiras de maneira mais inteligente.

Em geral, espera-se que as visões de negócios e de TI sobre tecnologia estejam alinhadas, mas é comum que haja metas conflitantes. Por exemplo, e se a sua empresa se fundir com outra empresa com um resultado comercial incrível e um departamento de TI fraco? Um mapa bem-delineado ajuda todos (técnicos e leigos) a avaliar o pensamento estratégico e a fazer planos.

Mecânica

Cada empresa fará isso de maneira diferente e deve evoluir o seu próprio estilo. Comece com estas sugestões e não tenha medo de mudar detalhes.

Quadrantes

Você pode mudar os quadrantes para o radar da sua empresa. Quando faço esse exercício com uma empresa, às vezes eu coloco linguagens junto com ferramentas (porque, na maioria das empresas, linguagens não é uma conclusão imediata), adicionando um quadrante de software em pacote no lugar. Isto é importante para muitas empresas, que têm uma estrutura megalomaníaca integrando software COTS (Commercial Off The Shelf). Você também pode ter outros quadrantes, como empresas parceiras ou consultores, ou algo mais específico.

Quem? O que? Quando?

O quem é dividido entre produtores (aqueles que produzem o radar) e consumidores. Os produtores devem ser um grupo representativo de especialistas em tecnologia sênior (talvez com nomeações e insights dos seus colegas), junto com qualquer membro da empresa que tenha interesse nas escolhas de tecnologia. Se o grupo for maior do que 30 pessoas ou for geograficamente disperso, faça múltiplas sessões e agregue os resultados. Os consumidores devem ser todos os interessados, mas o resultado (documentos, apresentações, vídeos) deve presumir que a audiência seja leiga. Uma das finalidades do radar é informar interessados quanto a decisões de tecnologia – eles devem ser capazes de ler o resultado. Embora não haja nada de errado com executivos nível C comparecendo à reunião, os técnicos é que devem conduzir o processo.

O que você produz pode ser um white paper de 10 páginas, como o radar da Thoughtworks, ou pode ser uma apresentação feita pelos autores do grupo do Radar para outras pessoas. Pode ser até mesmo uma página wiki atualizada periodicamente. O exercício é mais importante do que o artefato, então o produto final pode ser mínimo. Começamos nosso processo em um quadro branco, com linhas representando os quadrantes e post-its representando os itens atuais no radar.

A questão de como capturar resultados pode ser bastante simples; usamos uma planilha para os exercícios em empresas. As anotações são a parte mais trabalhosa, mas também a mais recompensadora posteriormente por contextualizar os pontos no radar. Embora estejamos limitados pela impressão a algumas frases por tecnologia, encoraje a elaboração de um parágrafo no seu radar de empresa para resumir a conversa do grupo e o consenso.

O quando também depende da sua empresa e de sua interação com a tecnologia. Recomendo pelo menos uma vez por ano – mas duas vezes é melhor. A tecnologia se move rapidamente; o universo inteiro pode mudar em um ano

Resumo

Ao escolher uma carreira envolvendo tecnologia, você implicitamente concorda em gerenciar seu portfólio tecnológico. Formalizar esse processo usando uma metáfora como o radar de tecnologia permite que você tome decisões melhores. De modo semelhante, criar um radar para a sua empresa traz um loop de feedback que estava faltando há bastante tempo. Por que não alavancar o conhecimento e a experiência das pessoas que mexem com o seu software todos os dias?

Ter ambos os radares à mão é uma ferramenta útil para a sua carreira. Como você pode ver no exercício acima, o processo de decisão relativo a tecnologia é diferente quando você é o Diretor Tecnológico. Lembre-se, o radar é uma ferramenta de defesa... mas também pode ser usado como uma arma. Observe a diferença entre o seu radar e o da sua empresa – veja se a ferramenta permite que você alinhe suas metas de carreira.

Embora isso seja uma fantasia, não seria ótimo se uma das formalidades em entrevistas de emprego fosse a troca de radares, pessoais e de empresa, como método de avaliação mútua?