Tag: dev

Página 328

Continuando com o exemplo de administrar a pilha em camadas, outra técnica eficiente de comunicar os princípios do design é com explicações gráficas sobre em que a equipe de desenvolvimento pode tomar decisões ou não. A ilustração na Figura 22-13 é um exemplo de gráfico (além de orientação) para controlar a pilha em camadas.

Figura 22-13. Dando orientação para a pilha em camadas Na Figura 22-13, um arquiteto daria exemplos do que cada categoria da biblioteca de terceiros conteria, então a orientação (o princípio do design) em termos do que os desenvolvedores podem ou não fazer (o limite descrito na primeira seção do capítulo). Por exemplo, há três categorias definidas para qualquer biblioteca de terceiros:

Finalidade especial São as bibliotecas específicas usadas para coisas como apresentação em PDF, escaneamento de códigos de barras e circunstâncias que não garantem a escrita de um software personalizado.

Finalidade geral Essas bibliotecas são camadas adicionadas sobre a API da linguagem e incluem coisas como Apache Commons e Guava para Java.

Framework Essas bibliotecas são usadas para coisas como persistência (Hibernate) e inversão de controle (Spring), ou seja, elas compõem uma camada inteira ou uma framework da aplicação, e são altamente invasivas.

Uma vez colocadas em categorias (as categorias anteriores são só um exemplo, podem haver muito mais definidas), o arquiteto cria o limite em torno do princípio do design. No exemplo da Figura 22-13, note que para essa aplicação ou projeto em particular, o arquiteto especificou que, para as bibliotecas de finalidade especial, o desenvolvedor pode tomar a decisão e não precisa consultar o arquiteto quanto a essa biblioteca. Mas observe que, para a finalidade geral,

Página 329

o arquiteto indicou que o desenvolvedor pode realizar uma análise de sobreposição e justificativa para fazer a recomendação, mas a categoria da biblioteca requer aprovação do arquiteto. Por fim, para as bibliotecas do framework, isso é decisão do arquiteto, isto é, as equipes de desenvolvimento não devem nem realizar uma análise dessas bibliotecas; o arquiteto decidiu assumir a responsabilidade para esse tipo de biblioteca.

Resumo

Fazer com que as equipes de desenvolvimento se tornem eficientes é um trabalho complicado.

Requer muita experiência e prática, além de fortes habilidades pessoais (que veremos nos capítulos posteriores neste livro). Dito isso, as técnicas simples descritas neste capítulo sobre liderança elástica, utilização de checklists e dar orientação por comunicar com eficiência os princípios do design, de fato, funcionam e se mostraram eficientes ao tornar o trabalho das equipes de desenvolvimento mais inteligente e eficaz.

Alguém poderia questionar o papel de um arquiteto para tais atividades, atribuindo ao gerente de desenvolvimento ou de projeto o esforço de fazer com que as equipes se tornem eficientes.

Discordamos dessa premissa. Um arquiteto de software não só fornece orientação técnica para a equipe, como também lidera a equipe na implementação da arquitetura. A relação próxima de colaboração entre um arquiteto de software e uma equipe de desenvolvimento permite ao arquiteto observar a dinâmica da equipe, daí facilitar as mudanças para tornar a equipe mais eficaz. É exatamente isso que diferencia um arquiteto técnico de um arquiteto de software eficiente.

Página 330

23. Habilidades de Negociação e Liderança

CAPÍTULO 23 Habilidades de Negociação e Liderança É difícil ter habilidades de negociação e liderança. Leva anos de experiência em liderança, prática e “lições aprendidas” para obter as habilidades necessárias para se tornar um arquiteto de software eficiente. Sabendo que este livro não transforma um arquiteto em um especialista em negociação e liderança da noite para o dia, os técnicos introduziram este capítulo para dar um bom ponto de partida para obter essas habilidades importantes.

Negociação e Facilitação

No começo deste livro, listamos as expectativas essenciais de um arquiteto, e a última delas foi:

um arquiteto de software deve entender o clima político da empresa e conseguir lidar bem com a política. O motivo para essa expectativa principal é que quase toda decisão que um arquiteto de software toma será questionada. Elas serão questionadas por desenvolvedores que acham que sabem mais que o arquiteto e têm uma abordagem melhor, além de outros arquitetos na organização que acham que têm uma ideia ou um modo melhor de abordar o problema. Por fim, as decisões serão questionadas pelos stakeholders, que argumentarão que a decisão é cara demais ou levará muito tempo.

Considere a decisão de um arquiteto em usar o cluster do banco de dados e a federação (usar instâncias separadas do banco de dados com escopo no domínio físico) para mitigar o risco relacionado à disponibilidade geral em um sistema. Embora seja uma boa solução para o problema de disponibilidade do BD, ela também é cara. Nesse exemplo, o arquiteto deve negociar com os principais acionistas da empresa (aqueles que pagam pelo sistema) para chegar a um acordo sobre o trade-off entre disponibilidade e custo.

A negociação é uma das habilidades mais importantes que um arquiteto de software pode ter.

Os arquitetos de software eficientes entendem a política da organização, têm fortes habilidades de negociação e facilitação e conseguem superar os desacordos quando eles ocorrem, criando soluções com as quais todos os stakeholders concordam.

Negociando com os Acionistas da Empresa

Considere o seguinte cenário real (cenário 1) envolvendo um principal acionista da empresa e o arquiteto responsável:

Cenário 1 O patrocinador sênior e vice-presidente do projeto insiste que um novo sistema de trading deve dar suporte a cinco noves de disponibilidade (99,999%). Porém, o arquiteto responsável está convencido, com base em pesquisa, cálculos e conhecimento do domínio do negócio e da tecnologia, que três noves de disponibilidade (99,9%) seriam suficientes. O problema é que o patrocinador do projeto não gosta de estar

Página 331

errado ou ser corrigido e realmente odeia pessoas que são condescendentes. O patrocinador não é muito técnico (mas acha que é) e, como resultado, tende a se envolver nos aspectos não funcionais dos projetos. O arquiteto deve convencer o patrocinador do projeto, com a negociação, de que três noves (99,9%) de disponibilidade seriam suficientes.

Nesse tipo de negociação, o arquiteto de software deve ter o cuidado de não ser egoísta e forçar demais em sua análise, mas também assegurar que nada mostre que estão errados durante a negociação. Há várias técnicas de negociação principais que um arquiteto pode usar para ajudar nessa negociação com o acionista.

Aproveite o uso da gramática e do jargão para entender melhor a situação.

Frases como “devemos ter zero tempo de inatividade” e “precisei desses recursos ontem” em geral são irrelevantes, mas dão informações valiosas ao arquiteto sobre como entrar em uma negociação. Por exemplo, quando é perguntado ao patrocinador do projeto quando certo recurso é necessário e ele responde “precisei dele ontem”, isso indica para o arquiteto do software que a entrada no mercado é importante para esse stakeholder. Do mesmo modo, a frase “o sistema deve ser muito rápido” significa que o desempenho é uma grande preocupação.

A frase “zero tempo de inatividade” significa que a disponibilidade é essencial na aplicação. Um arquiteto de software eficiente utilizará essa gramática sem sentido para entender melhor as preocupações reais e, como consequência, aproveitar o uso dela durante a negociação.

Considere o cenário 1 descrito antes. Aqui, o principal patrocinador do projeto deseja cinco noves de disponibilidade. Utilizar essa técnica informa ao arquiteto que a disponibilidade é muito importante. Isso leva a uma segunda técnica de negociação:

Reúna o máximo de informação possível antes de entrar em uma negociação.

A frase “cinco noves” é uma gramática que indica alta disponibilidade. Contudo, o que são exatamente cinco noves de disponibilidade? Pesquisar isso com antecedência e reunir conhecimento antes da negociação produz as informações mostradas no Quadro 23-1.

Quadro 23-1. Noves de disponibilidade Porcentagem do tempo ativo Tempo inativo por ano (dia) 90,0% (um nove) 36 dias 12h (2,4h) 99,0% (dois noves) 87h46min (14min)

Página 332

Porcentagem do tempo ativo Tempo inativo por ano (dia) 99,9% (três noves) 8h46min (86seg) 99,99% (quatro noves) 52min 33seg (7seg) 99,999% (cinco noves) 5min 35seg (1seg) 99,9999% (seis noves) 31,5seg (86ms) “Cinco noves” de disponibilidade são 5 minutos e 35 segundos de tempo inativo por ano ou 1 segundo por dia de tempo inativo não planejado. Bem ambicioso, mas também muito caro e desnecessário para o exemplo anterior. Colocar as coisas em horas e minutos (ou nesse caso, em segundos) é um modo muito melhor de conversar do que ficar preso no vocabulário dos noves.

Negociar o cenário 1 incluiria validar as preocupações do acionista (“entendo que a disponibilidade é muito importante para esse sistema”), então trazer a negociação do vocabulário dos noves para a linguagem das horas e dos minutos razoáveis do tempo inativo não planejado. Três noves (que o arquiteto considerava bons o suficiente) têm uma média de 86 segundos de tempo inativo não planejado por dia, certamente um número razoável, dado o contexto do sistema de trading global descrito no cenário. O arquiteto sempre pode recorrer a esta dica:

Quando tudo mais falhar, declare as coisas em termos de custo e tempo.

Recomendamos guardar essa tática de negociação por último. Vimos muitas negociações começarem com o pé esquerdo devido a declarações abertas como “Isso custará muito dinheiro” ou “Não temos tempo para isso”. Tempo e dinheiro (e esforço envolvido) certamente são os principais fatores em qualquer negociação, mas devem ser usados como um último recurso para que outras justificativas e raciocínios mais importantes sejam tentados primeiro.

Assim que um acordo é feito, então custo e tempo podem ser considerados, caso sejam atributos importantes para a negociação.

Outra técnica de negociação importante é sempre lembrar do seguinte, sobretudo nas situações descritas no cenário 1:

Aproveite a regra “dividir e conquistar” para qualificar as demandas ou os requisitos.

O antigo guerreiro chinês Sun Tzu escreveu no livro A arte da guerra (Novo Século): “Se suas forças estão unidas, separe-as.” Essa mesma táctica de “dividir e conquistar” também pode ser aplicada por um arquiteto durante as negociações. Considere o cenário 1 descrito antes. Nesse

Página 333

caso, o patrocinador do projeto insiste nos cinco noves (99,999%) de disponibilidade para o novo sistema de trading. Porém, o sistema inteiro precisa de cinco noves de disponibilidade?

Qualificar o requisito para a área específica do sistema que realmente requer cinco noves de disponibilidade reduz o escopo dos requisitos difíceis (e caros) e o escopo da negociação também.

Negociando com Outros Arquitetos

Considere o seguinte cenário real (cenário 2) entre um arquiteto responsável e outro arquiteto no mesmo projeto:

Cenário 2 O arquiteto responsável em um projeto acredita que a mensageria assíncrona seria a abordagem certa para a comunicação entre um grupo de serviços para aumentar o desempenho e a escalabilidade. Mas o outro arquiteto novamente discorda e insiste que REST seria uma escolha melhor, pois o REST sempre é mais rápido do que a mensageria e pode escalar também (“veja você mesmo fazendo uma pesquisa no Google!”). Não é o primeiro debate acalorado entre os dois arquitetos nem será o último. O arquiteto responsável deve convencer o outro de que a mensageria é a solução certa.

Nesse cenário, certamente o arquiteto responsável pode dizer para o outro arquiteto que a opinião dele não importa e ignorá-la com base na posição hierárquica no projeto. Porém, isso só levará a mais animosidade entre os dois e criará uma relação pouco saudável e sem colaboração, com a consequência de acabar tendo um impacto negativo na equipe de desenvolvimento. A seguinte técnica ajudará nessas situações:

Lembre-se sempre de que a demonstração vence a discussão.

Em vez de discutir com o outro arquiteto sobre o uso de REST versus mensageria, o arquiteto responsável deve demonstrar para o outro como a mensageria seria uma escolha melhor em seu ambiente específico. Todo ambiente é diferente, sendo por isso que uma simples pesquisa no Google nunca produzirá a resposta correta. Fazendo uma comparação entre as duas opções em um ambiente de produção e mostrando ao outro arquiteto os resultados, provavelmente a discussão seria evitada.

Outra técnica importante de negociação que funciona nessas situações é:

Página 334

Evite ser muito questionador ou levar as coisas para o lado pessoal em uma negociação; uma liderança calma combinada com raciocínio claro e conciso sempre vencerão uma negociação.

Essa técnica é uma ferramenta muito poderosa ao lidar com relações adversas como a descrita no cenário 2. Assim que as coisas ficam muito pessoais ou questionadoras, o melhor a fazer é parar a negociação e voltar mais tarde quando ambas as partes se acalmarem. Discussões ocorrerão entre arquitetos; contudo, lidar com essas situações com uma liderança calma em geral forçará a outra pessoa a recuar quando as coisas esquentarem demais.

Negociando com os Desenvolvedores

Os arquitetos de software eficientes não utilizam seu título como arquiteto para dizer aos desenvolvedores o que fazer. Ao contrário, eles trabalham com as equipes de desenvolvimento para ganharem respeito para que, quando uma requisição for feita pela equipe de desenvolvimento, ela não acabe em discussões ou ressentimentos. Trabalhar com as equipes de desenvolvimento pode ser difícil às vezes. Em muitos casos, essas equipes se sentem desconectadas da arquitetura (e também do arquiteto) e, como resultado, se sentem deixadas de lado em relação às decisões que o arquiteto toma. É um exemplo clássico do antipadrão da arquitetura Torre de Marfim. Os arquitetos na torre de marfim são aqueles que simplesmente ditam do alto, falando o que fazer para as equipes de desenvolvimento sem consideração com a opinião ou com as preocupações delas. Em geral, isso leva à perda de respeito do arquiteto e a uma eventual quebra da dinâmica da equipe. Uma técnica de negociação que pode ajudar a lidar com essa situação é sempre dar uma justificativa:

Ao convencer os outros desenvolvedores para que adotem uma decisão da arquitetura ou façam uma tarefa específica, dê uma justificativa em vez de “ditar do alto”.

Dar um motivo, explicando por que algo precisa ser feito, aumenta as probabilidades de que os desenvolvedores concordem com a requisição. Por exemplo, considere a seguinte conversa entre um arquiteto e um desenvolvedor em relação a fazer uma consulta simples em uma arquitetura com n camadas tradicionais:

Arquiteto: “Você deve passar pela camada de negócio para fazer a chamada.”

Desenvolvedor: “Não. É muito mais rápido só chamar o banco de dados direto.”

Existem várias coisas erradas nessa conversa. Primeiro, note o uso das palavras “você deve”.

Essa voz de comando não é só humilhante, mas uma das piores maneiras de começar uma negociação ou uma conversa. Note também que o desenvolvedor respondeu à demanda do arquiteto com um motivo para contrapor a demanda (passar pela camada de negócio será mais lento e levará mais tempo). Agora considere uma abordagem alternativa para essa demanda:

Arquiteto: “Como o controle de mudanças é mais importante para nós, formamos uma arquitetura em camadas fechadas. Isso significa que todas as chamadas para o BD precisam vir da camada de negócio.”

Página 335

Desenvolvedor: “Certo, entendi. Mas, nesse caso, como lidarei com os problemas de desempenho para as consultas mais simples?”

Observe aqui que o arquiteto está dando a justificativa para a demanda de que todas as requisições precisam passar pela camada de negócio da aplicação. Dar a justificativa ou o motivo primeiro sempre é uma boa abordagem. Na maioria das vezes, assim que uma pessoa ouve algo do qual discorda, ela para de ouvir. Por declarar o motivo primeiro, o arquiteto assegura que a justificativa será ouvida. Observe também que o arquiteto removeu a natureza pessoal da demanda. Sem dizer “você deve” ou “você precisa”, o arquiteto transformou a demanda em uma simples declaração do fato (“isso significa…”). Agora veja a resposta do desenvolvedor. Note que a conversa mudou de desacordo nas restrições da arquitetura em camadas para uma pergunta sobre como aumentar o desempenho para as chamadas simples.

Agora arquiteto e desenvolvedor podem interagir em uma conversa de colaboração para encontrar meios de tornar mais rápidas as consultas simples, ainda preservando as camadas fechadas na arquitetura.

Outra tática de negociação eficiente ao negociar com um desenvolvedor ou tentar convencê-lo a aceitar certo design ou decisão da arquitetura em desacordo é fazê-lo chegar à solução sozinho.

Isso cria uma situação de ganho mútuo, em que o arquiteto não pode perder. Por exemplo, suponha que um arquiteto escolha entre duas estruturas: X e Y. O arquiteto vê que a Estrutura Y não atende aos requisitos de segurança para o sistema e naturalmente escolhe a X. Um desenvolvedor na equipe discorda e insiste que a Estrutura Y ainda seria a melhor escolha. Em vez de discutir o caso, o arquiteto fala para o desenvolvedor que a equipe usará a Estrutura Y se ele puder mostrar como lidar com os requisitos de segurança se tal estrutura for usada.

Acontecerá uma das duas coisas:

1. 1. O desenvolvedor não conseguirá demonstrar que a Estrutura Y atenderá aos requisitos de segurança e entenderá de imediato que ela não pode ser usada. Fazendo o desenvolvedor chegar à solução sozinho, o arquiteto automaticamente consegue adesão e acordo para a decisão de usar a Estrutura X basicamente tornando-a a decisão do desenvolvedor. É uma vitória.
2. 2. O desenvolvedor encontra um modo de lidar com os requisitos de segurança com a

Estrutura Y e o demonstra para o arquiteto. É uma vitória também. Nesse caso, o arquiteto não viu algo na Estrutura Y e também acabou sendo uma estrutura melhor que a outra.

Se um desenvolvedor discorda de uma decisão, faça-o chegar à solução sozinho.

Só com a colaboração da equipe de desenvolvimento é que o arquiteto consegue ter o respeito da equipe e formular soluções melhores. Quanto mais os desenvolvedores respeitarem um arquiteto, mais fácil será para o arquiteto negociar com os desenvolvedores.

Página 336

Arquiteto de Software como um Líder

Um arquiteto de software também é um líder, alguém que pode orientar uma equipe de desenvolvimento na implementação da arquitetura. Afirmamos que cerca de 50% de ser um arquiteto de software eficiente é ter boas habilidades pessoais, de facilitação e liderança. Nesta seção, veremos várias técnicas principais de liderança que um arquiteto de software eficiente pode utilizar para liderar as equipes de desenvolvimento.

Os 4 Cs da Arquitetura

Todo dia, as coisas parecem ficar cada vez mais complicadas, com uma complexidade aumentada nos processos comerciais ou uma complexidade aumentada dos sistemas e até da arquitetura. Existe complexidade na arquitetura e no desenvolvimento de software, e sempre existirá. Algumas arquiteturas são muito complexas, como as que suportam seis noves de disponibilidade (99,9999%) — que equivale ao tempo de inatividade não planejado de cerca de 86 milissegundos por dia ou 31,5 segundos por ano. Isso é conhecido como complexidade essencial, ou seja, “temos um grande problema”.

Uma das armadilhas em que muitos arquitetos caem é adicionar uma complexidade desnecessária às soluções, aos diagramas e à documentação. Os arquitetos (assim como os desenvolvedores) parecem amar a complexidade. Citando Neal:

Os desenvolvedores são atraídos pela complexidade como moscas pelo mel; com frequência tendo o mesmo resultado.

Considere o diagrama na Figura 23-1 que ilustra os maiores fluxos de informação dos sistemas de processamento de back-end em um banco global muito grande. Essa complexidade é necessária? Ninguém sabe a resposta porque o arquiteto tornou isso complexo. Isso se chama complexidade acidental, ou seja, “criamos um grande problema”. Às vezes os arquitetos fazem isso para provar seu valor quando as coisas parecem muito simples ou assegurar que sejam sempre mantidos no ciclo de discussões e decisões tomadas em relação ao negócio ou à arquitetura. Outros arquitetos fazem isso para manter a segurança do trabalho. Seja qual for o motivo, introduzir uma complexidade acidental em algo que não é complexo é um dos melhores modos de se tornar um líder ineficiente como arquiteto.

Página 337

Figura 23-1. Introduzindo uma complexidade acidental em um problema Um modo eficiente de evitar a complexidade acidental é o que chamados de os 4 Cs da arquitetura: comunicação, colaboração, clareza e consciência. Esses fatores (mostrados na Figura 23-2) funcionarão juntos para criar um comunicador e um colaborador eficientes na equipe.

Figura 23-2. Os 4 Cs da arquitetura Como líder, facilitador e negociador, é fundamental que um arquiteto de software consiga se comunicar com eficiência e de um modo claro e conciso. É igualmente importante que um

Página 338

arquiteto também consiga colaborar com os desenvolvedores, os acionistas da empresa e outros arquitetos para discutir e formular soluções juntos. Focar os 4 Cs da arquitetura ajuda um arquiteto a ter o respeito da equipe e se tornar o braço direito no projeto, alguém que todos procuram não só para dúvidas, mas conselhos, mentoria, coaching e liderança.

Seja Pragmático, Mas Visionário

Um arquiteto de software eficiente deve ser pragmático, mas visionário. Isso não é tão fácil quanto parece e requer muita maturidade e grande prática para conseguir. Para entender melhor essa afirmação, considere a definição de visionário:

Visionário Pensar sobre ou planejar o futuro com imaginação ou sabedoria.

Ser visionário significa aplicar pensamento estratégico em um problema, e é exatamente isso que um arquiteto deve fazer. Muitas vezes, arquitetura é sobre planejar o futuro e assegurar que a vitalidade arquitetural (a validade de uma arquitetura) permaneça assim por muito tempo.

Porém muitas vezes os arquitetos se tornam teóricos em seu planejamento e design, criando soluções que se tornam muito difíceis de entender ou até implementar. Agora considere a definição de pragmático:

Pragmático Lidar com coisas de modo sensível e realista, baseado em considerações práticas, não teóricas.

Embora os arquitetos precisem ser visionários, eles também precisam aplicar soluções práticas e realistas. Ser pragmático é levar em consideração todos os fatores e as restrições a seguir ao criar uma solução da arquitetura:

Restrições no orçamento e outros fatores de custo Restrições de tempo e outros fatores de tempo Habilidades e nível de habilidades da equipe de desenvolvimento Trade-offs e implicações associadas a uma decisão da arquitetura Limites técnicos de um design ou uma solução proposta da arquitetura Um bom arquiteto de software é alguém que tenta encontrar um equilíbrio adequado entre ser pragmático ainda tendo imaginação e sabedoria para resolver problemas (veja a Figura 23-3).

Por exemplo, considere a situação em que um arquiteto tem um problema difícil para lidar com a elasticidade (aumentos repentinos e importantes desconhecidos na carga de usuários simultâneos). Um visionário pode propor um modo elaborado de lidar com isso usando uma malha de dados complexa, que é uma coleção de bancos de dados distribuídos e baseados em domínio. Na teoria, pode ser uma boa abordagem, mas ser pragmático significa aplicar raciocínio e praticidade na solução. Por exemplo, a empresa já usou antes uma malha de dados?

Quais são os trade-offs de usar tal malha? Isso realmente resolveria o problema?

Página 339

Figura 23-3. Bons arquitetos encontram equilíbrio entre ser pragmático, mas visionário Manter um bom equilíbrio entre ser pragmático, mas visionário, é um excelente modo de ter respeito como arquiteto. Os acionistas da empresa gostarão das soluções visionárias que se encaixam nas restrições e os desenvolvedores gostarão de ter uma solução prática (ao invés de teórica) para implementar.

Um arquiteto pragmático primeiro veria qual é o fator de limitação quando precisa de altos níveis de elasticidade. O banco de dados é o gargalo? Talvez seja um gargalo em relação a alguns serviços chamados ou outras fontes externas necessárias. Encontrar e isolar o gargalo seria a primeira abordagem prática para o problema. Na verdade, mesmo que seja o banco de dados, alguns dados poderiam ser colocados em cache para que o banco de dados não precise ser acessado?

Liderando as Equipes Dando o Exemplo

Os arquitetos de software ruins utilizam seu título para obrigar as pessoas a fazerem o que eles querem que façam. Os arquitetos eficientes pedem que as pessoas façam coisas não utilizando seu título como arquiteto, mas liderando com o exemplo, não com o título. Isso é sobre ter o respeito das equipes de desenvolvimento, dos acionistas da empresa e de outras pessoas na organização (por exemplo, o responsável pelas operações, os gerentes de desenvolvimento e os proprietários do produto).

A clássica história de “liderar dando o exemplo, não com o título” envolve um capitão e um sargento em uma batalha militar. O capitão de alta patente, que em grande parte fica separado das tropas, comanda todas as tropas para elas avançarem durante a batalha e tomarem uma montanha bem difícil. Contudo, em vez de ouvir o capitão, os soldados, cheios de dúvidas, olham para o sargento de patente menor para saberem se devem tomar ou não a montanha. O

Página 340

sargento examina a situação, balança a cabeça de leve e os soldados imediatamente avançam sentindo confiança para tomar a montanha.

A moral da história é que a patente e o título significam muito pouco em relação a liderar pessoas. O cientista da computação Gerald Weinberg ficou famoso por dizer: “Não importa o problema, as pessoas são o problema.” A maioria acha que resolver problemas técnicos não tem relação com as habilidades das pessoas, mas com o conhecimento técnico. Embora ter conhecimento técnico certamente seja necessário para resolver um problema, é apenas parte da equação geral para resolver qualquer um. Suponha, por exemplo, que um arquiteto esteja em reunião com uma equipe de desenvolvedores para resolver um problema que apareceu na produção. Um dos desenvolvedores faz uma sugestão e o arquiteto responde com:

— Bem, é uma ideia tola.

Não só o desenvolvedor deixará de dar mais sugestões, como nenhum outro ousará dizer nada.

Nesse caso, o arquiteto encerrou de fato a colaboração da equipe inteira na solução.

Ter o respeito e liderar equipes é sobre ter habilidades pessoais básicas. Considere o seguinte diálogo entre um arquiteto e um cliente ou equipe de desenvolvimento quanto a um problema no desempenho da aplicação:

Desenvolvedor: “Como resolveremos esse problema no desempenho?”

Arquiteto: “O que você precisa fazer é usar um cache. Isso corrigiria o problema.”

Desenvolvedor: “Não me diga o que fazer.”

Arquiteto: “O que estou dizendo é que isso corrigiria o problema.”

Usando as palavras “o que você precisa fazer é…” ou “você deve”, o arquiteto força sua opinião no desenvolvedor e basicamente encerra a colaboração. É um bom exemplo de usar a comunicação, não a colaboração. Agora considere o diálogo reformulado:

Desenvolvedor: “Como resolveremos esse problema no desempenho?”

Arquiteto: “Já considerou usar um cache? Isso pode corrigir o problema.”

Desenvolvedor: “Hmmm, não tínhamos pensado nisso. O que você acha?”

Arquiteto: “Bem, se colocarmos um cache aqui… Observe o uso das palavras “você considerou…” ou “o que você acha…” no diálogo. Fazendo uma pergunta, o controle volta para o desenvolvedor ou o cliente, criando uma conversa de colaboração em que arquiteto e desenvolvedor trabalham juntos para formularem uma solução.

O uso da gramática tem vital importância ao tentar criar um ambiente colaborativo. Ser líder como arquiteto não é apenas ser capaz de colaborar com outras pessoas para criar uma arquitetura, mas também ajudar a promover a colaboração na equipe agindo como facilitador.

Como arquiteto, tente observar a dinâmica da equipe e notar quando ocorrem situações como no primeiro diálogo. Chamar de lado os membros da equipe e treiná-los no uso da gramática como um meio de colaboração não só criará uma dinâmica melhor da equipe, mas também ajudará a gerar respeito entre os membros dela.

Outra técnica básica de habilidades pessoais que pode ajudar a gerar respeito e relações saudáveis entre um arquiteto e a equipe de desenvolvimento é sempre tentar usar o nome da pessoa na conversa ou na negociação. Elas não apenas gostam de ouvir seu nome durante uma conversa, como isso também ajuda a gerar familiaridade. Pratique lembrar os nomes das pessoas e usá-los com frequência. Como alguns nomes são difíceis de pronunciar, faça a pronúncia certa, então pratique até ficar perfeita. Sempre que perguntamos o nome de alguém,

Página 341

repetimos para a pessoa e perguntamos se é o modo certo de pronunciar. Se não estiver correto, repetimos o processo até acertar.

Se um arquiteto se encontra com alguém pela primeira vez ou apenas às vezes, sempre aperte a mão dela e faça contato visual. Um aperto de mãos é uma habilidade pessoal importante que remonta à época medieval. A ligação física que ocorre durante um aperto de mãos simples permite que as duas pessoas saibam que são amigas, não adversárias, e forma um vínculo entre elas. Contudo, por vezes, é difícil acertar até em um simples aperto de mãos.

Ao apertar a mão de alguém, seja firme (mas não esmagador) enquanto olha a pessoa nos olhos. Desviar o olhar enquanto cumprimenta é sinal de desrespeito e a maioria das pessoas notará isso. E mais, não demore apertando as mãos. De dois e três segundos, um aperto de mãos firme é tudo que é necessário para iniciar uma conversa ou cumprimentar alguém. Há também o problema de exagerar na técnica do aperto e deixar a outra pessoa desconfortável o bastante para não querer se comunicar ou colaborar com você. Por exemplo, imagine um arquiteto de software que chega toda manhã e começa a apertar a mão de todos. Não só é um pouco estranho, como cria uma situação de desconforto. Mas imagine um arquiteto que deve se encontrar com a responsável pelas operações todo mês. É a oportunidade perfeita para ficar de pé e dizer “Olá, Rute. Feliz por ver você de novo”, e dar um aperto de mão rápido e firme.

Saber quando apertar as mãos ou não faz parte da arte complexa das habilidades pessoais.

Um arquiteto de software, como líder, facilitador e negociador, deve ter o cuidado de preservar os limites que existem entre as pessoas em todos os níveis. O cumprimento, como descrito antes, é uma técnica eficiente e profissional de formar um vínculo físico com a pessoa com quem você se comunica ou colabora. Mas embora o aperto de mãos seja bom, um abraço em um cenário profissional não é, independentemente do ambiente. Um arquiteto pode achar que ele é um exemplo de mais conexão física e vínculo, mas tudo que faz é deixar a outra pessoa no trabalho mais desconfortável e, o mais importante, pode levar a possíveis questões de assédio no local de trabalho. Evite abraçar, independentemente do ambiente profissional, e fique com o aperto de mãos (a menos, é claro, que todos na empresa se abracem, o que seria… estranho).

Por vezes, é melhor transformar uma solução em um favor como um modo de fazer alguém realizar algo que poderia não querer fazer. Em geral, as pessoas não gostam de receber ordens sobre o que fazer, mas, em grande parte, elas querem ajudar os outros. É da natureza humana.

Considere a seguinte conversa entre um arquiteto e o desenvolvedor em relação ao esforço de refatorar uma arquitetura durante uma iteração corrida:

Arquiteto: “Preciso que você divida o serviço de pagamentos em cinco serviços diferentes, com cada um tendo funcionalidade para cada tipo de pagamento que aceitamos, como crédito na loja, cartão de crédito, PayPal, cartão-presente e pontos de recompensa, para fornecer uma melhor tolerância a falhas e escalabilidade no site. Não deve levar muito tempo.”

Desenvolvedor: “Não mesmo, cara. Há muita coisa acontecendo na iteração para isso.

Sinto muito, não posso.”

Arquiteto: “Ouça, é importante e precisa ser feito nessa iteração.”

Desenvolvedor: “Sinto muito, não dá. Talvez um dos outros desenvolvedores possa fazer. Estou muito ocupado.”

Observe a resposta do desenvolvedor. É uma rejeição imediata da tarefa, mesmo que o arquiteto a justificasse para uma melhor tolerância a falhas e escalabilidade. Nesse caso, note que o arquiteto está dizendo ao desenvolver para fazer algo que ele simplesmente está ocupado

Página 342

demais para fazer. Note também que a demanda nem inclui o nome da pessoa! Agora considere a técnica de transformar a requisição em um favor:

Arquiteto: “Oi, Sridhar. Ouça, estou com um problema. Realmente preciso que o serviço de pagamento seja dividido em serviços separados para cada tipo de pagamento e ter uma melhor tolerância a falhas e escalabilidade, e esperei muito para fazer isso. Há um jeito de você encaixar isso nessa interação? Isso me ajudaria muito.”

Desenvolvedor: “(Pausa)… Estou muito ocupado nessa iteração. Mas quer saber? Verei o que posso fazer.”

Arquiteto: “Obrigado, Sridhar. Agradeço muito sua ajuda. Fico devendo essa.”

Desenvolvedor: “Tudo bem. Verei se pode ser feito nessa iteração.”

Primeiro, observe o uso repetido do nome da pessoa na conversa. Usar o nome torna a conversa mais pessoal, familiar, em vez de uma demanda profissional. Segundo, note que o arquiteto admite que tem um “problema” e que dividir os serviços realmente “ajudaria muito”. Essa técnica nem sempre funciona, mas recorrer à natureza humana básica de ajudar uns aos outros tem uma maior probabilidade de sucesso que na primeira conversa. Experimente a técnica na próxima vez em que tiver essa situação e veja os resultados. Na maioria dos casos, os resultados serão muito mais positivos do que dizer para alguém o que fazer.

Para liderar uma equipe e se tornar um líder eficiente, um arquiteto de software deve tentar se tornar o braço direito dela, ou seja, a pessoa que os desenvolvedores procuram com suas questões e problemas. Um arquiteto de software eficiente agarrará a oportunidade e tomará a iniciativa de liderar a equipe, independentemente do título ou da função na equipe. Quando um arquiteto de software observa alguém com um problema técnico, ele deve intervir e oferecer ajuda ou orientação. O mesmo acontece nas situações não técnicas. Suponha que um arquiteto observe um membro da equipe que chega no trabalho parecendo deprimido e chateado; claramente tem algo acontecendo. Nesse caso, o arquiteto eficiente notaria a situação e se ofereceria para conversar, algo como “Ei, Antonio, estou indo pegar um café. Por que não vamos juntos?”, então, durante o percurso pergunta se está tudo bem. Isso pelo menos dá mais abertura para uma discussão pessoal; e melhor, é uma oportunidade para orientar e instruir em um nível mais pessoal. Porém um líder eficiente também reconhecerá quando não ser muito insistente e recuar, lendo vários sinais verbais e expressões faciais.

Outra técnica para começar a ter o respeito como líder e se tornar o braço direito na equipe é promover almoços informais periódicos para falar sobre uma técnica ou uma tecnologia específica. Todos que leem este livro têm uma habilidade ou um conhecimento em particular que os outros não têm. Promovendo uma sessão de almoço informal periódica, o arquiteto não só consegue mostrar sua capacidade técnica, como também pratica suas competências oral e de mentoria. Por exemplo, promova um almoço na revisão dos padrões de projeto ou nos últimos recursos do lançamento da linguagem de programação. Isso não apenas fornece informações valiosas para os desenvolvedores, como também começa a identificá-lo como líder e mentor na equipe.

Integração com a Equipe de Desenvolvimento

Em geral a agenda de um arquiteto está cheia de reuniões, com a maioria se sobrepondo, como a agenda mostrada na Figura 23-4. Se a agenda de um arquiteto de software é assim, então quando o arquiteto tem tempo para se integrar na equipe de desenvolvimento, ajudar a orientar

Página 343

e instruir e está disponível para dúvidas ou preocupações quando elas surgem? Infelizmente, as reuniões são um mal necessário no mundo de TI. Elas acontecem com frequência e sempre acontecerão.

Figura 23-4. Uma agenda típica do arquiteto de software O segredo para ser um arquiteto de software eficiente é ter mais tempo para a equipe de desenvolvimento, e isso significa controlar as reuniões. Existem dois tipos de reuniões das quais um arquiteto pode participar: as impostas a ele (o arquiteto é convidado) e as impostas por ele (o arquiteto chama para a reunião). Essas reuniões são mostradas na Figura 23-5.

Figura 23-5. Tipos de reunião

Página 344

As reuniões impostas a ele são as mais difíceis de controlar. Devido ao número de stakeholders com quem um arquiteto de software deve se comunicar e colaborar, os arquitetos são convidados para quase toda reunião agendada. Quando convidado, um arquiteto de software eficiente sempre deve perguntar ao organizador por que ele é necessário na reunião. Muitas vezes, os arquitetos são convidados simplesmente para mantê-los no ciclo das informações sendo discutidas. É para isso que servem as notas da reunião. Perguntando o motivo, um arquiteto pode começar a qualificar quais reuniões devem ter sua presença e quais podem ser ignoradas. Outra técnica relacionada que ajuda a reduzir o número de reuniões com a participação do arquiteto é pedir a pauta dela antes de aceitar o convite. O organizador da reunião pode achar que o arquiteto é necessário, mas vendo a pauta, o arquiteto consegue decidir se realmente precisa participar dela ou não. E mais, muitas vezes não é preciso ficar na reunião inteira. Examinando a pauta, um arquiteto pode otimizar seu tempo aparecendo quando as informações relevantes são discutidas ou sair depois que uma discussão importante termina. Não perca tempo em uma reunião se você pode passar esse tempo trabalhando com a equipe de desenvolvimento.

Peça a pauta da reunião antes para ajudá-lo a decidir se você é realmente necessário nela ou não.

Outra técnica eficiente para manter uma equipe de desenvolvimento nos trilhos e ter o seu respeito é colocar alguém da equipe em uma reunião quando os desenvolvedores são convidados. Em vez de ter o responsável técnico participando da reunião, vá no lugar dele, em particular se o responsável e o arquiteto são convidados. Isso mantém a equipe de desenvolvimento focada na tarefa em mãos, em vez de participar continuamente das reuniões também. Embora tirar as reuniões dos membros úteis da equipe aumente o tempo de um arquiteto nas reuniões, isso também aumenta a produtividade da equipe de desenvolvimento.

As reuniões que um arquiteto impõe aos outros (o arquiteto chama para a reunião) às vezes também são uma necessidade, mas devem ser mantidas no mínimo absoluto. São as reuniões que um arquiteto controla. Um arquiteto de software eficiente sempre perguntará se a reunião para a qual ele chama é mais importante do que o trabalho que está sendo retirado dos membros da equipe. Muitas vezes, um e-mail é suficiente para comunicar alguma informação importante, economizando a todos o tempo perdido. Ao chamar para uma reunião como arquiteto, sempre defina uma pauta e siga-a. Muitas vezes, as reuniões para as quais um arquiteto chama saem dos trilhos devido a algum outro problema, e esse outro problema pode não ser relevante para os outros na reunião. E mais, como arquiteto, preste muita atenção no fluxo do desenvolvedor e verifique se não o atrapalha chamando para uma reunião. O fluxo é um estado de espírito que os desenvolvedores muitas vezes têm, quando o cérebro está 100% envolvido em certo problema, permitindo total atenção e máxima criatividade. Por exemplo, um desenvolvedor pode estar trabalhando em um algoritmo ou parte do código muito difícil, e literalmente passam-se horas, mas que parecem apenas minutos. Ao chamar para uma reunião, um arquiteto sempre deve tentar agendar para a primeira coisa na manhã, logo depois do almoço ou perto do fim do dia, mas não durante o dia, quando a maioria dos desenvolvedores vivencia o estado de fluxo.

Página 345

Além de gerenciar as reuniões, outra coisa que um arquiteto de software eficiente pode fazer para se integrar melhor na equipe de desenvolvimento é sentar com essa equipe. Sentar em uma baia distante da equipe envia a mensageria de que o arquiteto é especial, e essas paredes físicas em torno da baia são uma mensageria clara de que ele não deve ser chateado nem perturbado.

Sentar junto com uma equipe de desenvolvimento envia a mensageria de que o arquiteto é uma parte integral da equipe e está disponível para perguntas ou preocupações conforme elas surgem. Mostrando fisicamente que ele faz parte da equipe de desenvolvimento, o arquiteto consegue mais respeito e ajuda melhor a orientar e instruir a equipe.

Por vezes, não é possível que o arquiteto sente com uma equipe de desenvolvimento. Nesses casos, o melhor que ele pode fazer é circular continuamente para ser visto. Os arquitetos que ficam em um andar diferente ou sempre em seus escritórios ou baias, e nunca são vistos, possivelmente não podem ajudar a orientar a equipe de desenvolvimento durante a implementação da arquitetura. Separe o tempo na manhã, depois do almoço ou no final do dia, e reserve-o para conversar com a equipe, ajudar nos problemas, responder às perguntas e fazer o coach e a mentoria básicos. As equipes de desenvolvimento gostam desse tipo de comunicação e o respeitarão por conseguir tempo para ela durante o dia. O mesmo acontece com os outros stakeholders. Parar para dizer “olá” para o chefe de operações enquanto vai pegar mais café é um excelente modo de manter a comunicação aberta e disponível com os acionistas da empresa e outros principais stakeholders.

Resumo

As dicas de negociação e liderança apresentadas e examinadas neste capítulo são para ajudar o arquiteto de software a ter uma relação de colaboração melhor com a equipe de desenvolvimento e outros stakeholders. São as habilidades necessárias que um arquiteto deve ter para se tornar um arquiteto de software eficiente. Embora as dicas apresentadas aqui sejam boas para iniciar a jornada para se tornar um líder eficiente, talvez a melhor dica de todas venha de uma citação de Theodore Roosevelt, o 26º presidente dos EUA:

O ingrediente mais importante para a fórmula de sucesso é saber como lidar com as pessoas.

— Theodore Roosevelt

Página 346

24. Desenvolvendo uma Trajetória Profissional

CAPÍTULO 24 Desenvolvendo uma Trajetória Profissional Tornar-se arquiteto requer tempo e esforço, mas pelos muitos motivos descritos neste livro, gerenciar a trajetória profissional depois de se tornar arquiteto é igualmente arriscado. Embora não possamos traçar uma trajetória específica para você, podemos indicar algumas práticas que vimos que funcionam bem.

Um arquiteto deve continuar a aprender durante sua carreira. O mundo da tecnologia muda em um ritmo vertiginoso. Um dos ex-colegas de Neil era um renomado especialista em Clipper. Ele lamentava não poder pegar o enorme conhecimento (agora inútil) em Clipper e substituí-lo por outra coisa. Ele também especulava (e isso ainda é uma questão aberta): algum grupo na história aprendeu e descartou tanto conhecimento detalhado em sua existência quanto os desenvolvedores de software?

Todo arquiteto deve ficar de olho nos recursos relevantes, em tecnologia e negócios, e adicioná-los ao seu estoque pessoal. Infelizmente, recursos vão e vêm rapidamente, sendo por isso que não listamos nenhum neste livro.

Conversar com colegas ou especialistas sobre quais recursos eles usam para se manterem atuais é um bom modo de buscar as últimas novidades, sites e grupos que são ativos em certa área de interesse. Durante seu dia, os arquitetos também devem ter um tempo para manter a amplitude utilizando esses recursos.

Regra dos 20 Minutos

Como mostrado na Figura 2-6, a amplitude da tecnologia é mais importante para os arquitetos do que a profundidade. Porém manter a amplitude requer tempo e esforço, algo que os arquitetos devem incorporar em seu dia. Mas como alguém no mundo tem tempo para acessar vários sites para ler artigos, assistir a apresentações e ouvir a podcasts? A resposta

Página 347

é… poucas pessoas têm tempo para isso. Desenvolvedores e arquitetos tentam equilibrar o trabalho normal, passar um tempo com a família, ficar disponível para os filhos, conseguir um tempo pessoal para interesses e passatempos e tentar desenvolver suas carreiras, ao mesmo tempo que tentam acompanhar as últimas tendências e palavras da moda.

Uma técnica que usamos para manter esse equilíbrio é algo que chamamos de regra dos 20 minutos. A ideia dessa técnica, como visto na Figura 24-1, é dedicar pelo menos 20 minutos por dia à sua carreira como arquiteto aprendendo algo novo ou se aprofundando em um tópico específico. A Figura 24-1 mostra exemplos de alguns recursos nos quais passar 20 minutos por dia, como InfoQ, DZone Refcardz e ThoughtWorks Technology Radar (conteúdos em inglês). Passe no mínimo 20 minutos no Google pesquisando palavras da moda diferentes (“as coisas que você não sabe que não sabe”, do Capítulo 2) para aprender um pouco sobre elas, promovendo conhecimento para as “coisas que você sabe que não sabe”.

Ou talvez passe 20 minutos se aprofundando em certo tópico para conhecer um pouco mais sobre ele. A intenção dessa técnica é conseguir um tempo para desenvolver uma carreira como arquiteto e ter uma amplitude técnica contínua.

Figura 24-1. Regra dos 20 minutos

Página 348

Muitos arquitetos adotam o conceito e o plano de reservar 20 minutos no almoço ou à noite após o trabalho para isso. O que vivenciamos é que raramente funciona. A hora do almoço está cada vez menor, tornando-se mais um momento para colocar a conversa em dia no trabalho, em vez de um tempo para pausar e comer. As noites são ainda piores; as situações mudam, planos são feitos, o tempo com a família fica mais importante e a regra dos 20 minutos nunca acontece.

Recomendamos utilizar a regra dos 20 minutos como a primeira coisa na manhã, quando o dia está começando. Mas há um problema nesse conselho também. Por exemplo, qual é a primeira coisa que um arquiteto faz depois de chegar no trabalho de manhã? Bem, a primeira coisa é pegar uma incrível xícara de café ou chá. Certo, nesse caso, qual é a segunda coisa depois de pegar a xícara — verificar o e-mail. Assim que ele verifica o e-mail, acontece uma distração, as respostas dos e-mails são escritas e o dia acaba. Portanto, recomendamos fazer a regra dos 20 minutos como a primeira coisa da manhã, logo depois de pegar a xícara de café ou chá, e antes de verificar o e-mail. Vá trabalhar um pouco mais cedo. Fazer isso aumentará a amplitude técnica do arquiteto e ajudará a desenvolver o conhecimento requerido para se tornar um arquiteto de software competente.

Desenvolvendo um Radar Pessoal

Em grande parte dos anos 1990 e no começo dos anos 2000, Neal foi CTO de uma pequena empresa de treinamento e consultoria. Quando ele começou nela, a plataforma primária era o Clipper, uma ferramenta de desenvolvimento de aplicações rápida para criar aplicações DOS com arquivos dBASE. Até o dia em que desapareceu. A empresa viu o surgimento do Windows, mas o mercado de negócios ainda era em DOS… até deixar de ser de forma brusca. Essa lição deixou marcas: ignore o progresso da tecnologia por sua conta e risco.

Também ensinou uma importante lição sobre as bolhas da tecnologia.

Quando investido pesadamente em uma tecnologia, um desenvolvedor entra em uma bolha mimética, que também serve como câmara de eco. As bolhas criadas pelos fornecedores são muito perigosas, pois os desenvolvedores nunca ouvem elogios honestos de dentro delas. Contudo,

Página 349

o maior perigo de Viver na Bolha é quando ela começa a estourar, e os desenvolvedores dentro dela só percebem isso quando é tarde demais.

O que eles não tinham era um radar da tecnologia: um documento vivo para avaliar os riscos e as recompensas das tecnologias existentes e nascentes. O conceito de radar vem da ThoughtWorks; primeiro descreveremos como esse conceito surgiu, então como usá-lo para criar um radar pessoal.

Radar da Tecnologia da ThoughtWorks

ThoughtWorks Technology Advisory Board (TAB) é um grupo de líderes da tecnologia sênior na ThoughtWorks, criado para ajudar a diretora de tecnologia, a Dra. Rebecca Parsons, a tomar decisões sobre as direções e as estratégias para a empresa e seus clientes. Esse grupo se encontra presencialmente duas vezes ao ano. Um dos resultados desse encontro foi o Technology Radar. Com o tempo, ele foi crescendo e se tornou o Technology Radar semestral.

O TAB aos poucos estabeleceu uma produção do Radar semestral. Então, como sempre acontece, ocorreram efeitos colaterais inesperados. Neal falava em algumas conferências, os participantes o procuravam e agradeciam por ajudar a produzir o Radar, dizendo que a empresa deles tinha começado a produzir uma versão própria.

Neal também percebeu que essa era a resposta para uma eterna pergunta nos painéis dos palestrantes em todo lugar: “Como você (palestrante) acompanha a tecnologia? Como descobre o que buscar em seguida? A resposta, claro, é que todos eles têm alguma forma de radar interno.

Partes O ThoughtWorks Radar consiste em quatro quadrantes que tentam cobrir grande parte do cenário de desenvolvimento de software:

Ferramentas Ferramentas no espaço de desenvolvimento de software, tudo, desde ferramentas do desenvolvedor, como IDEs, até ferramentas de integração no nível da empresa

Página 350

Linguagens e frameworks Linguagens de computação, bibliotecas e frameworks, em geral de código aberto Técnicas Qualquer prática que ajude no desenvolvimento de software em geral; pode incluir processos de desenvolvimento de software, práticas de engenharia e recomendações Plataformas Plataformas de tecnologia, inclusive bancos de dados, fornecedores de serviços em nuvem e SOs Anéis O Radar tem quatro anéis, listados aqui do externo para o interno:

Evite A intenção original do anel evite era “esperar por enquanto” para representar as tecnologias que eram muito novas para serem bem avaliadas ainda, ou seja, tecnologias que estavam chamando muita atenção, mas ainda sem comprovação. O anel evite evoluiu para “não iniciar nada novo com essa tecnologia”. Não faz mal usar nos projetos existentes, mas os desenvolvedores devem pensar duas vezes ao usá-lo para um novo desenvolvimento.

Avalie O anel avalie indica que uma tecnologia vale a pena explorar com o objetivo de entender como afetará uma organização. Os arquitetos devem investir certo esforço (como picos de desenvolvimento, projetos de pesquisa e sessões de conferência) para ver se ele terá impacto na organização. Por exemplo, ficou visível que muitas empresas grandes passaram por essa fase ao formularem uma estratégia para dispositivos móveis.

Experimente O anel experimente é para as tecnologias que valem a pena buscar; é importante entender como desenvolver essa capacidade. Agora é hora

Página 351

de pilotar um projeto de baixo risco para que arquitetos e desenvolvedores possam entender bem a tecnologia.

Adote Para as tecnologias no anel adote, a ThoughtWorks sente que o setor deve adotar esses itens.

Uma visão de exemplo do Radar aparece na Figura 24-2.

Figura 24-2. Um exemplo de Radar da Tecnologia da ThoughtWorks Na Figura 24-2, cada ponto representa uma tecnologia ou uma técnica diferente, com anotações curtas associadas. Embora a ThoughtWorks use o radar para divulgar suas opiniões sobre o mundo do software, muitos desenvolvedores e arquitetos também o utilizam como a ferramenta descrita em “Partes de Visualização Open Source” para criar o mesmo visual usado pela ThoughtWorks como um modo de organizar seu pensamento sobre em que investir tempo.

Página 352

Ao usar o radar para o uso pessoal, sugerimos mudar os significados dos quadrantes assim:

Evite Um arquiteto pode incluir não apenas tecnologias e técnicas para evitar, mas também hábitos que tenta parar. Por exemplo, um arquiteto do mundo .NET pode estar acostumado a ler as últimas notícias/fofocas em fóruns sobre o funcionamento interno das equipes. Embora seja divertido, pode ser uma informação de baixo valor. Colocar isso em espera cria um lembrete para ele evitar coisas problemáticas.

Avalie Os arquitetos devem usar a avaliação para promover tecnologias sobre as quais ouviram coisas boas, mas não tiveram tempo de avaliar ainda; veja “Usando a Rede Social”. Esse anel forma uma área de preparação para uma pesquisa mais séria em algum momento no futuro.

Experimente O anel experimente indica uma pesquisa e um desenvolvimento ativos, como um arquiteto fazendo experimentos de pico em uma base de código maior. Esse anel representa as tecnologias que valem a pena passar um tempo para entender melhor para que um arquiteto possa realizar uma análise de trade-off eficiente.

Adote O anel adote representa as coisas novas que empolgam mais um arquiteto e as práticas recomendadas para resolver certos problemas.

É perigoso ter uma atitude liberal em relação ao portfólio de tecnologia. A maioria dos técnicos escolhe tecnologias de maneira mais ou menos específica, com base no que é popular ou no que seu empregador está promovendo. Criar um radar da tecnologia ajuda o arquiteto a formalizar seu raciocínio sobre a tecnologia e equilibrar critérios de decisão antagônicos (o fator “mais legal” da tecnologia e ser menos provável de conseguir um novo trabalho versus um grande mercado de trabalho, porém com menos trabalho interessante). Os arquitetos devem tratar seu portfólio de tecnologia como se fosse um portfólio financeiro: de muitos modos, são

Página 353

a mesma coisa. O que um analista financeiro fala sobre o portfólio?

Diversifique!

Os arquitetos devem escolher algumas tecnologias e/ou habilidades que têm uma ampla demanda e rastrear essa demanda. Mas também podem querer experimentar estratégias tecnológicas, como a código aberto ou o desenvolvimento para dispositivos móveis. Há inúmeros relatos sobre os desenvolvedores que se libertaram da servidão das baias trabalhando até tarde da noite em projetos de código aberto que ficaram populares, puderam ser comprados e decidiram o destino de suas carreiras. Esse é outro motivo para focar a amplitude, não a profundidade.

Os arquitetos devem reservar um tempo para ampliar seu portfólio de tecnologia e criar um radar fornece uma boa base. Porém o exercício é mais importante que o resultado. Criar a visualização dá uma desculpa para pensar sobre essas coisas, e para os arquitetos ocupados, encontrar uma desculpa para conseguir tempo em uma agenda corrida é o único modo desse raciocínio acontecer.

Partes de Visualização Open Source

Atendendo a pedidos, a ThoughtWorks lançou uma ferramenta em novembro de 2016 para ajudar os tecnólogos a criarem sua própria visualização do radar. Quando a ThoughtWorks faz esse exercício para empresas, ela captura a saída da reunião em uma planilha, com uma página para cada quadrante. A ferramenta ThoughtWorks Build Your Own Radar usa uma planilha do Google como entrada e gera a visualização do radar usando uma tela HTML 5. Assim, embora a parte importante do exercício seja as conversas geradas, também gera visualizações úteis.