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.
O post inteiro está ótimo, mas é incrível, incrível mesmo, como os três últimos paragrafos fazem tanto sentido no mercado onde me encontro. A maioria das empresas realmente agrupam essa “elite” quando deveriam distribuí-los.
Ótimo post Shoes!
Hahhahaha, muito bom Phillip,
Eu me lembro exatamente deste episodio e das pessoas envolvidas. O que meu deixa triste é que essa pessoa continua lá, apesar de não agregar nada a empresa há alguns anos.
De qq forma depois desta implementação de servicos nesta dada empresa, tudo passou a ser mais receptivo quanto a servicos, e hoje boa parte da arquitetura é ancorada nisso.
Abs,
Antonio
Tudo e a maneira que voce coloca as coisas. Nao ha nada de errado em ter um tech lead em cada time pra fazer um trabalho de mentoring com os desenvolvedores menos experientes, como sentar com o cara e implementar uma feature fazendo pair programming, tdd, etc…nao ha nada de errado nisso e fazemos muito por aqui. O problema eh o rotulo, a parte psicologica. Todo ser humano, por default, tem a necessidade de ser reconhecido/importante, isso eh essencial, e nao ha nada mais desagradavel que saber que alguem vai chegar e dizer se o que voce esta fazendo ou nao eh certo ou errado. Da impressao de que:
1 - Seu time eh incapaz e esta fazendo um trabalho ruim.
2 - O time vai estar insatifeito, ja que nao serao mais reconhecidos/importantes
3 - Nao vai dar certo.
Esse “post” realmente é um grande retrato da realidade.
É incrivel como as empresas tem o habito de reunir os melhores, ao invés de distribuilos para maximizar o conhecimento de todos os desenvolvedores da empresa.
ótimo post, Shoes!
cada vez vejo maior necessidade, do desenvolvedor em si,
ter que estar acima da média… e que para isso, tem desafios como esses em projetos por ai.
Mas será essa realidade tbm acontece em “grandes” empresas?
valew.
Mais um excelente post, Philip.
É impressionante como as empresas ainda teimam em fazer este tipo de Ivory Towers, seja criando um time de Arquitetos Super Mega Blaster Power ou seja criando um SEPG que quer conduzir todos os projetos com um processo padrão e esquecem da característica da unicidade dos projetos.
E o mais engraçado é que há muito tempo este tipo de abordagem - Ivory Tower - é tida como falha. No Planejamento Estratégico já se viu que isso não dá certo, mas - como sempre - os CIOs teimam em repetir os erros dos CEOs de 20 anos atrás.
“(…) 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.”
hauhauahuhuahuahuahhahaahahaa…genial.
É Phillip, tiro na mosca mais uma vez. Ter um time de super astros e um monte de segunda divisão realmente não é o ideal.
Faz sentido dividir os melhores entre os times. Muito boa a forma como coloca sua opinião, e saudades de vc cara :)
Abraços,
Bruno Carvalho
Idéias muito boas, Philip. Mas é bom tomar cuidado para que as maçãs boas não sejam estragadas pelas demais. As pessoas tendem a atacar e fagocitar os membros da equipe com o desempenho acima do normal. É possível protegê-los contra isso usando algum tipo de autoridade como blindagem: dando a eles um título, um cargo, um salário maior ou algo parecido. Mas nesse caso a liderança deles só vai ser aceita porque foi imposta e voltamos ao mesmo problema de não conseguir descobrir os novos talentos que acabam ficando mascarados embaixo dos experts eleitos.
No fim das contas, acho que estamos procurando mesmo é por gente que não seja babaca. Se você juntar um monte de babacas em um time de elite, o que vai obter é um tipo de hiper-babaquismo concentrado. Se você colocar um babaca como chefe de uma equipe, ele não vai escutar o que os outros têm a dizer do mesmo modo. Se o babaca for bom e você colocá-lo sem um título numa equipe de gente mediana, os demais vão acabar escanteando ele. Tire o babaquismo da jogada e tudo se resolve.
A história se repete mas a força dessa história é mal contada. Precisamos tomar mais um daqueles choppes (coca-cola) no citta pra rirmos da perplexidade…
Bixo, nao tem meios de dizer o quao voce acertou. Porem certas brigas tem que ser brigadas, tem que acontecer… embora tenhamos menos dor de cabeca tem que se brigar pelo o que eh correto.
Agradar chefe eh uma coisa, agradar arquiteto de sistemas eh suicidio, a unica coisa que achei “errada”, de resto foi simplesmente retrato do que rola aqui na empresa
att
Allen
Existe o lado da “Tropa de Elite” ser sempre a equipe mais cara que o resto dos desenvolvedores e de tempos em tempo um gerente ou diretor que não sabe a necessidade do time e faz por destruir o time…
Recentemente sai de um time que era uma “SWAT” mas o pronto crucial é que os membros acabam virando parte do processo e donos de muitas coisas, reduzindo o tempo livre para inovações.
Concordo com boa parte do seu post.
No caso sou a pessoa do outro lado da corda.. :) Não exatamente com a mentalidade que você desenhou, mas carrego esse título de líder de um time de arquitetura. Confesso que diversas vezes tentei argumentar com a diretoria em relação a aproximar mais a arquitetura da “fábrica de software” pois tenho plena consciência de que essa divisão departamental não contribui em nada no processo de desenvolvimento de software. Muito pelo contrario! Porém até hoje não consegui achar um contra-argumento coerente ao que me foi apresentado:
“Essa é a estratégia da empresa!”.
É ai que as generalizações vão por água abaixo e é por isso que disse que concordava em termos com boa parte do seu post pois afirmações como essa:
“A solução me parece óbvia: não concentre, distribua.”
não são verdades e nem possíveis de serem adotadas uma vez que não estejam alinhadas com a (certa ou errada) estratégia da empresa. Mas o que quero dizer com estratégia da empresa? Acho que um simples exemplo pode resolver essa possível dúvida.
Imagine uma empresa onde o seu core business não seja desenvolvimento de softwares mas obviamente precise de um excelente apoio tecnológico. Essa empresa tem uma equipe de desenvolvimento interna e deseja expandir sua capacidade de delivery de soluções. Dessa forma ela opta por trabalhar com mais duas consultorias (Uma de três letrinhas e a outra de várias letrinhas). A solução que parecia obvia agora já não é tão obvia assim pois não é tão simples distribuir seus arquitetos(ou programadores de alto nível.. como preferir), com um cenário desses. Aqui em São Paulo tem uma consultoria a cada esquina, mas e se fosse mais barato, por exemplo, trabalharmos com uma consultoria na Índia? Ai sim a solução óbvia fica totalmente inviável.
Agora, se você trabalha em uma consultoria que entrega software a seus clientes, talvez essa seja uma boa solução..
Só rodando pra saber!
[]’s
-l30-
Olá Phillip,
Muito bom seu post. Enquanto estava lendo passava um filme pela minha cabeça, e um filme que já vi várias vezes.
Impressionante como as empresas continuam cometendo os MESMOS erros. Não aprendem com os fracassos, não evoluem, gastam rios de dinheiro em coisas desnecessárias e com “politicagem” ao invés de pensar no bem comum e principalmente no bem do sistema.
Mas infelizmente este “filme” está mais para documentário do que ficção…
[]’s
Andou lendo Jack Welch?
O pior é quando a tropa de elite não é nem tão elite assim. ;)
Belo post!Parabéns.
Cara, você escreveu exatamente tudo o que eu penso sobre o assunto. Já participei de uma equipe dessas (acho que já te contei isso uma vez). Os problemas são muitos e você já os colocou muito bem. Um grande abraço !!!
Escrevi um post sobre esse assunto a alguns meses. Meu foco foi mais em distribuir talentos e compartilhar conhecimentos e experiências.
Mas eu não tinha percebido a ligação entre: a falta de um contexto ligando esses arquitetos a uma equipe, com a comum falta de comprometimento deles para com o sucesso de um sistema. Esse é um dos motivadores para frio e desconfiado relacionamento entre essas duas equipes.
Mandou bem!
Rapaz, eu acho que se a própria equipe tenta “fagocitar” alguém que esteja afim de trabalhar e por a casa em ordem, tem é que desfazer a equipe.
Não tem coisa pior do que trabalhar num ambiente onde em vez das pessoas se ajudarem elas tentam detonar umas com as outras. E se a empresa não toma uma decisão, o melhor que a vítima tem que fazer é buscar outro lugar mesmo.
Post muito bom, não pude deixar de lhe dar os parabéns!
As pessoas com um ego maior que elas são batendo cabeça uma com as outras e não pensam no melhor da organização e, muito menos, nas espectativas de vida dos seus funcionários.
Ótimo post.
Até pensei em como isso poderia ser aplicado na Universidade. O problema é juntar um bom desenvolvedor que um péssimo que acha que é bom e comece a teimar com o bom de verdade.
Abraço.
Olá Shoes, muito bom o seu relato.
mas chato ainda é ter uma “tropa de elite” que não inova nada e que não compartilha nada.
Usar Comunidades de Práticas é excelente em qualquer situação, ajuda na formação de liderança e permite as pessoas criarem um ambiente de colaboração. Boa dica.
Impressionante!
Esse é um relato de quase todos os “lugares” por onde eu passei. Ao longo desse tempo cheguei a conclusão, de que quanto mais alta a torre de marfim maior é o tombo. E mesmo assim os “caveiras” não aprendem.
“Paz a todos!”
De facto este retrato é dum realismo impressionante. Só senti uma diferença da minha realidade: infelizmente na minha experiência (ao contrário da tua, como parece) as tropas de elite não são constituídas pelas melhores cabeças técnicas. Pelos melhores subidores da escada corporativa talvez. (Não faço juízos de valor. Um talento é tão bom como outro.) Talvez as coisas em Portugal e Brasil (Austrália?) sejam diferentes.
Cadê as batatas?
Olá, boa noite ! Primeiramente gostaria de parabenizá-lo pelo seu blog, mt interessante e bem escrito e agradecer pelo comparilhamento de experiência que você possibilita através de seus posts. Li alguns posts seus e vi que vocês trabalham utilizando metodologias ágeis.
Gostaria de saber como vocês fazem com a operação de produtos já estão em produção. A opção adotada pela nossa equipe foi que separamos 30% (Seria 6 dias em um sprint de 20 dias) de apenas um membro do time para descontar nos pontos que “entrarão” no sprint. Temos tbm um gráfico separado do burndown para mensurasmos a manuntenção do sprint corrente… vocês tem um modelo parecido ou a operação/manutenção fica com equipe separadas ?
Cara, show de bola esse post.
É exatamente isso que acontece em muitas empresas. E o título diz tudo, rsrsrsrsrsrs… Não vai subir ninguém!!! :-D
Abraços!
Faço parte da “tropa de elite”, mas como o Leo Luz, não tenho esta mentalidade descrita acima. O core business da empresa é produzir e fabricar carnes, não desenvolver software. Então, ela mantém uma equipe de super programmers para os projetos mais importantes ( que aqui resumem-se projetos detinados exclusivamente para usuários da diretoria, não necessariametne mais importantes para o core-business :) ).
Apesar de sermos ’separados’, incentivei e discuti muito sobre coaching e programação em par com os outros analistas ( plenos/juniores ), e a aceitação de críticas e sugestões destes mesmos, e temos tido êxito, com um ambiente muito colaborativo e muito amigável.
Simplesmente sensacional seu post! Parece que você estava descrevendo o meu local de trabalho.
É muito pajé pra pouco índio!
Parabéns!
Post muito bom! retrata bem a realidade, como funciona um departamento de TI na pratica.
Muito interessante e real o post, parabéns. Eu constantemente cito os seus posts para amigos e colegas por concordar e pensar da mesma forma sobre esses assuntos “polêmicos” que vc aborda com extrema competência, porém, não achei ainda o seu perfil (quem é vc, currículo e etc) e sempre me perguntam: Quem é esse cara? o que ele faz? Parece que as pessoas precisam mais do que uma opinião de bom senso, precisam saber se essa opinião de bom senso vem de algum lugar confiável… enfim…
Vc tem um perfil público??
Mais uma vez, parabéns pelas opiniões de bom senso, precisamos de mais profissionais com esse tipo de atitude.
É o motivo pelo qual estou saindo da empresa onde trabalho! Agora só falta decidir se eu mando este link para a tropa ou não.
parabéns
Shoes isso é uma grande realidade e infelizmente atinge as empresas de pequeno e médio porte também.
Isso é frustrante e genial : ” … justificar para aquela pessoa que não quer nada além de arrumar algo que justiique seu cargo … ”
Muitas pessoas passam por isso todos os dias =/
Ótimo post !
Muito bom!!!
Quem não concorda, certamente é porque está do outro lado da força.
“Quantos jovens teremos que perder para o tráfico só para um plaboy poder rolar um baseado”.
“Quantos bons desenvolvedores terá que sair para o mercado só porque um arquiteto que mostrar que é o melhor”
Eu sou mexicano…e temos o mesmo problema la.
E o que fode a gente….a cultura tercermundista, eu moro nos estados unidos e o americano nao e asim (eles tem muitos defeitos, mais os viados sao organizados)
…pelo menos a gente sabe dancar.
[...] longe das equipes que “sujam” as mãos no código no dia-a-dia. Ora, isso, por si só, cria as Torres de Marfim e uma certa animosidade latente entre as diferentes equipes – que deveriam trabalhar em conjunto todos os [...]