Fragmental

A coisa mais comum em uma empresa é a formação de uma “tropa de elite”, contendo os principais e provavelmente mais talentosos desenvolvedores. O raciocíno é simples. Empresas em geral são uma bagunça tecnicamente, anos e anos contratando desenvolvedores sem muito critério (e não investindo nos mesmos após contratação) fez com que sejam criados sistemas que não se falam, projetos que atrasam, duplicação de esforço além dos odiosos bugs em produção que te acordam na hora em que eu estou almoçando aqui em Oz.

E é claro que as consequências são desastrosas. Não houve uma só grande empresa onde (ou para quem) eu tenha trabalhado onde não existe a elite da tropa. São aqueles technical stakeholders pessoas para quem você bate continência e tem que agradar. São aquelas pessoas que não estão envolvidas com seu projeto mas ainda assim podem acabar com ele. São parte daquele grupinho que age como a polícia e defende a “moral e bons costumes”, matando a inovação no caminho. São aqueles que estampam seu projeto com o “selo de qualidade”, onde qualidade significa concordar com eles.

Lembranças dolorosas não faltam. Certa vez eu cheguei em um projeto muito perto da ida para o ar. A estrela dentre as funcionalidades era um sistema meio estranho que categorizava conteúdo, mas como eu era novo no time deixei para lá e fui resolver os bugs que impediam o release. Na véspera do release nós percebemos que o sistema “estranho” não aguentava nem um terço dos acessos que teríamos.

O líder de desenvolvimento daquele sistema foi extremamente contra qualquer mudança no mesmo. Ele havia sido desenvolvido de acordo com os critérios passados pelo grupo de arquitetura da empresa e o arquiteto havia solicitado uma solução genérica que pudesse ser reutilizada em todos os mais de 100 produtos da empresa.

Um requisito mais que válido. Reinventar aquilo cem vezes seria um desperdício sem tamanho. Mas o projeto deveria ser entregue em alguns meses e desenvolver aquela funcionalidade “pensando no bem da nação” o fez não só atrasar e custar noites em claro bem como resultou em um sistema que sequer atendia o projeto em questão, muito menos todos os outros 99 sistemas.

O problema é que o arquiteto não fazia parte daquela equipe e não entendia seus requisitos e características. Não estava presente no desenvolvimento, não escreveu uma linha de código, não tinha comprometimento com a entrega.

Não importa o quão bom o time seja, conhecimento técnico só tem valor dentro de um contexto e neste caso o contexto é um time ou um projeto. A falta de comprometimento e de “senso de time” faz com que a “tropa de elite” seja vista mais como uma dificuldade a passar do que algo que traz auxílio. Eu não tenho idéia de quanta vezes tive que adicionar e remover caixinhas em diagramas só para agradar alguém que senta em uma torre de marfim e desce apenas para chicotear os incautos.

E em médio prazo as coisas pioram. Um fato claro é que o grupo se fecha: ninguém dos reles desenvolvedores é bom o suficiente para subir para a elite. Os desenvolvedores com potencial acabam saindo da empresa porque são tão cortados pelo time de elite que desistem e vão tentar ser arquitetos em outro lugar. A falta de abertura, o medo que os desenvolvedores têm dos “caveiras” e a auto-confiança que o grupo desenvolve (afinal eles não têm que passar por avaliação técnica nenhuma, eles são a verdade!) faz com que opiniões se tornem leis.

Recentemente eu tive um caso engraçado. Estávamos introduzindo serviços REST em uma empresa e uma das barreiras era este tipo de time. Eles eram os melhores desenvolvedores da empresa, ditavam as leis e odiavam qualquer coisa que lembrasse processamento remoto. Meu então chefe, um excelente técnico mas com uma capacidade acima do normal de perder a cabeça, e eu marcamos uma reunião com este time para apresentar a idéia.

Durante a semana anterior eu fiquei polindo slides e buscando referências para responder qualquer dúvida técnica. No dia da reunião eu estava extremamente nervoso e após 15 minutos de atraso meu chefe saiu da sala para ver porque os arquitetos não haviam chegado ainda. Eu aproveitei os minutinhos para dar uma última revisão quando comecei a ouvir gritos do lado de fora. Ao sair dei de cara com meu chefe e o arquiteto sênior discutindo calorosamente a questão dos serviços.

O arquiteto master argumentava que eles já tentaram EJB e deu errado, já tentaram WS/SOAP e deu errado e que ninguém vai usar mais serviço nenhum. Isso não funciona nesta empresa, já vimos isso e ponto final. Vendo que aquilo não ia ajudar muito eu puxei meu chefe pelo braço e voltamos para o escritório.

Não havia como desistir da tecnologia nem do projeto, então marcamos uma segunda reunião. Desta vez eu mudei todos os slides e fiz questão de não convidar meu chefe. Eu removi todos os slides que falavam de REST e a palavra “serviço”, deixei apenas o HTTP. A reunião foi ótima, o sistema estava abençoado pelo arquiteto master e podíamos seguir em frente. Qual o valor que estas duas reuniões e duas semanas de trabalho trouxeram? Elas alimentaram o ego do arquiteto, ele realmente acreditou que nós mudamos a arquitetura para o agradar. Só isso.

Este tipo de barreira cria medo entre os desenvolvedores. Ainda que você tenha uma excelente idéia para aquele seu projeto vai ter que justificar para aquela pessoa que não quer nada além de arrumar algo que justiique seu cargo. A inovação morre em meio ao medo de propôr algo e ser rechaçado.

É impressionante como este padrão de organização departamental lembra a história da humanidade. Um grupo é oprimido por um governo corrupto e injusto. O grupo é exilado (i.e. pede demissão) une forças, volta e derruba o governo. No próximo passo o grupo forma seu próprio governo, corrupto e injusto como o anterior.

Mas o que fazer? Como falei no início, as empresas são uma zona! É comum que a cada 100, 200 desenvolvedores tenhamos meia dúzia que está acima da média. A solução me parece óbvia: não concentre, distribua.

Se você tem poucos bons desenvolvedores não faz o menor sentido agrupá-los, pelo contrário! Espalhe os desenvolvedores bons entre os times e certifique-se que eles possuem autoridade suficiente para mudar as coisas. Treine seus desenvolvedores como coaches e os faça ocupar o papel de líder técnico em projetos. Crie um programa de mentoria de desenvolvedores e faça com que seus jovens talentos tenham como referencial os melhores.

E como controlar este tipo de atividade por toda a empresa? Crie comunidades de prática. Ao invés de um “departamento” de arquitetura ou de “práticas de desenvolvimento” crie uma comunidade que abrange diversos departamentos e times. Em vê de investir um bolo de dinheiro em um grupo de pessoas invista um pouquinho em cada um dos seus times, deixe eles realizarem atividades para melhorar suas habilidade durante o expediente. Em vez de criar xerifes e a cultura do medo crie uma cultura de melhoria contínua, remova as maçãs podres da sua empresa e crie mecanismos para acompanhar o desenvolvimento de todos os membros do time.