DevOps, quando as coisas não acontecem

'DevOps - quando as coisas não acontecem’ conta em forma de narrativa como é difícil mudar a cultura de organizações, lições aprendidas e quando deves seguir adiante pelo bem maior, sua carreira.


Aos que leem a publicação, não é uma publicação de caso de sucesso. Estamos em tempos onde todos querem contar uma história de sucesso, onde tudo dá certo e afeta positivamente a todos com valor para o negócio. Bacana! Mas não podemos esquecer que o PPT aceita tudo quando vira uma apresentação bonita. Demonstrações onde tudo é preparado e maquiado para não apresentar débitos técnicos e códigos chumbados. 

Meio pessimista, não? A publicação não é técnica, ainda que o técnico e a cultura tenham sido os fatores que nos levaram ao abandono no final. 

Começando com a história do Gabriel (isso, estamos nos citando em terceira pessoa), não mencionando aqui todo histórico desde que nasceu da barriga da sua mãe, mas sim, o que o motivou a ingressar na empresa do caso em questão. 
Já viram aquelas vagas que utilizam palavras chamativas como ‘desafio’, ‘squads’, ‘métodos ágeis’ e ‘ambiente dinâmico’? Elas são ótimas e uma delas chamou a atenção dele.

Gabriel já tinha uma carreira sólida, estabilidade financeira, trabalhava em projetos de bons clientes em uma empresa de consultoria, tinha contas a pagar por gastar demais, logo tornava-se mercenário e sedento por qualquer cinco pratas a mais no valor hora. 

A vaga em questão pagava melhor e como atrativo tinha palavras no anúncio como as citadas no parágrafo anterior. Ele contatou o recrutador que marcou uma entrevista com o cliente, o arquiteto principal do projeto. Entusiasmado, mas com medo de julgamentos, foi a tal entrevista temeroso por perguntas técnicas profundas. As abordagens foram vagas, nada técnico, o que deixou o Gabriel apreensivo. A empresa era do ramo financeiro, de grande porte e isso não causou receio. Ao perguntar sobre o projeto recebeu como resposta a palavra “plataforma”. Palavra que foi sondada com: “uma plataforma de um time SRE (https://landing.google.com/sre/)?” E obteve resposta incerta “É, isso aí!”. 

Aqui vai a primeira lição aprendida: Para qualquer projeto com palavras de impacto, sonde os seus publicadores para saber se de fato as entendem, isso lhe mostrará com um perfil interessado e pode lhe livrar de projetos sem dados, sem objetivos e repleto de palavras bonitas que na prática não se aplicam. 

Deixamos sugestões para mitigar essas “armadilhas”: 

• O que vocês entendem por time de SRE?
• Quais são as práticas de engenharia que já estão disseminadas nos times de desenvolvimento?
• O que já existe na plataforma atual e qual é o roadmap de curto, médio e longo prazo?
• Quantas pessoas fazem parte do time SRE e quais são os perfis delas?
• A empresa tem uma visão de produto para tratar a plataforma?

Muitas empresas brasileiras tentam aplicar conceitos e inovações de TI (tecnologia da informação) sem saber muito bem o que estão fazendo e o que aqueles conceitos realmente significam. 
Começa aí então a frustração generalizada dos profissionais em cascata que acreditaram que aquilo - agora - seria “diferente”.

Segunda lição aprendida: Normalmente recrutadores desconhecem a realidade do projeto e farão a vaga parecer ser mais desafiadora do que na verdade é, afinal, o trabalho deles é recrutar pessoas. 


Ao Ingressar no projeto, Gabriel entendeu que a vaga era para atuar dando play em job de Jenkins (https://jenkins.io/), e a plataforma ao que o arquiteto se referia era o nome do projeto em si e não o conceito de plataforma em SRE.  

O cenário visualmente era agradável, um prédio parecido com garagem, puffs bacanas, mas todo e qualquer processo técnico era feito por GMUD, engessado. Um servidor novo e uma tecnologia nova eram coisas de meses de espera. Distante do conceito de plataforma self-service que um time de SRE deve buscar e implementar.

Em menos de um mês Gabriel queria retornar ao seu emprego antigo, tentou outras oportunidades, enfim, bateu o desespero. Foi quando conheceu Inácio, que já estava há mais tempo na empresa.  

Vamos fazer uma pausa e contar a história do Inácio, da sua chegada a empresa ao momento dos acontecimentos desta publicação. 

Este projeto de transformação digital necessitava de alguém que pudesse contribuir com experiência em soluções de software, estruturação de times e também ter experiência com tecnologias mais atuais. Então o Inácio foi chamado para atuar nesta transformação. 

Inicialmente foi muito produtivo, os times de desenvolvimento foram reestruturados, a arquitetura e algumas tecnologias foram definidas.

A primeira release foi projetada e o software começou a ser desenvolvido. Estava tudo indo muito bem, Inácio tinha alinhamento com o time do cliente. Ambos com a mesma expectativa. Tinham o aval e a abertura da empresa para implementar as mudanças e realizar a construção de um software com escalabilidade, observabilidade e sustentabilidade.

Até que chegou o momento de construir a arquitetura e implementar as tecnologias. Então foi onde Inácio e o time foram surpreendidos, pois esbarraram na dificuldade de que aquela liberdade era ilusória. 

Existiam setores dentro da empresa que não estavam efetivamente trabalhando para fazer a transformação digital (sendo um dos aspectos colocar o cliente no centro). O que realmente faziam era trabalharem para manterem os seus empregos. Usavam seus cargos importantes para garantir que não mudassem as tecnologias, mantendo-se como tutores e influenciadores dos seus silos.

Gabriel conhecia Inácio de vista, de um grupo de arquitetos os quais mantinham uma comunidade chamada ArqTI (http://arqti.org/). Ambos estreitaram contatos quando o arquiteto principal pediu para que ele, Gabriel, fizesse a análise de um problema que se passava em um projeto de outra unidade da organização, no caso, a unidade em que Inácio trabalhava. Eram somente algumas horas e tinha que ser superficial e objetivo na tal análise. Gabriel viu no momento, ao conhecer o PO (product owner) a oportunidade de mudar o cenário em que se encontrava, pois este PO era alguém que tinha sangue nos olhos e dedicação pelo que fazia, ainda que as coisas não acontecessem na velocidade e qualidade que ele (product owner) desejava. Então resta citar a terceira lição. 

Terceira lição aprendida: Fique próximo de pessoas que fazem a diferença, e dadas as oportunidades, faça o seu melhor sempre, independente da motivação atual. Nos inspiramos no dia a dia em uma entrevista do Waldez Ludwig (http://www.ludwig.com.br/), a qual menciona um jogador de futebol em começo de carreira: ele não faz gol contra quando as coisas não estão bem, é aí que ele marca mais gols e joga melhor - com o objetivo claro de que um clube grande o encontre.

Gabriel fez o seu melhor no relatório, e o tempo que passou nesta unidade (02 dias) usou para estreitar seus laços interpessoais e levantar dores e demandas que ninguém queria ouvir. As colocou em uma lista de demandas.

Quarta lição aprendida: Seja gentil e educado com todos. Criar boas relações aumentam suas possibilidades futuras. E veja: deves ser justo, sendo educado e gentil do porteiro que lhe atende sorrindo até o diretor da empresa. Isto lhe permitirá encontrar possibilidades e demandas que algumas pessoas não compartilharão com o comercial da empresa, mas com o técnico que entende o problema. 

Neste ponto entra o Inácio novamente, o Gabriel sempre fala que esse cara é 10!!! Inácio ajudou na montagem da lista de demandas e como já estava há mais tempo na organização tinha maior influência para que estes pontos, que eram deveras relevantes, chegassem a quem realmente precisava, e chegou! Chegou a uma gerente que entendia do negócio como poucos ali. Sua postura? Ímpar. Ela priorizou as demandas e os alocou focados para esta unidade. De largados e players de Jenkins passaram a recursos vitais para que o lançamento do novo produto do cliente fosse realidade, Inácio e Gabriel, o time de DevOps, como falavam. 

Agora a situação dava uma reviravolta para Gabriel na empresa: eles podiam implementar tecnologias inovadoras. A experiência do Inácio na arquitetura de software e a bagagem que Gabriel trazia da área de operação não tinha como dar errado. 

No meio do percurso constataram que as demandas aumentavam, e somente dois não seriam suficientes para atender o prazo desejado. Então lhes possibilitaram a alocação de mais um recurso e assim o fizeram, eles chamaram um colega, em especial amigo, para trabalharem juntos no projeto. 

A entrega foi feita de exatamente todos os itens e, uma migração feita completamente dentro da expectativa do cliente. 

Então o leitor deve se perguntar: mas não é uma história de DevOps que não aconteceu? Sim, e foi depois da entrega que as coisas começaram a dar errado. 

A sustentação do ambiente deve ser do time do produto, certo? Mas esse não é um conto de fadas. Muitas organizações que dizem estar em processo, ou já fizeram a transformação digital, mantém times de NOC que são responsáveis em sustentar e serem plantões de produtos e tecnologias que desconhecem. 

Foi aí que começam a ligar para o Gabriel, para o Inácio, pedindo que atendesse e resolvessem "a arte" instaurada por amor a camisa. Começaram também a pressionar eles por usarem tecnologias que não eram homologadas pela organização. Uma lista foi criada de tecnologias suportadas por profissionais que desconheciam tools de DevOps. Veja, isso não limita o conceito de inovação?! 

Inácio e Gabriel colocaram-se à disposição de sustentar o produto, a opção foi desconsiderada pela gestão e somente um repasse foi feito aos sysadmins da empresa (NOC) que estavam operando ainda monólitos.  

Vários fatores os levaram a desistir de uma luta cultural: 

• Assédio por ter que responder por escolhas tecnológicas inovadoras;
• Responsabilidade por soluções que não eram enterprise;
• Por ter que seguir políticas de segurança de 1990;
• Por entrar em um processo de GMUDs;
• A obrigação de manter um modelo on-premises onde servidores demoravam 01 mês para ficarem prontos;
• Medo de retornar ao projeto e dar play em Jenkins.

E aí vai a quinta e última lição! 

Quinta lição aprendida: Aceite desafios e lutas que pode vencer enquanto elas não lhe fazem menor, enquanto elas não lhe trancam a processos legados. Seja o dono da sua carreira e faça dela o ponto mais importante. Busque objetivos que te façam sentido e principalmente aprenda a ver o momento de seguir em diante, ou seja, pular fora. Muitas vezes nos deparamos em situações onde algumas pessoas da organização possuem interesses diferentes, ou seja, metas distintas que não contribuem para o objetivo em comum da empresa. Empresa que deveria, a seu turno, ser focada em seu consumidor final. Infelizmente existem coisas que não podem ser mudadas de baixo para cima. É  necessário que exista uma força de cima para baixo também para fazer a transformação acontecer. 

Quando identificaram a ausência deste cenário, foi quando Inácio e Gabriel perceberam que estavam perdendo tempo naquele lugar, foi então que optaram por procurar algo que agregasse mais valor em suas carreiras. Tudo então virou passado. Estava aberto o horizonte para novos e positivos desafios profissionais.

Fontes e Citações

SRE - https://landing.google.com/sre/
CICD Jenkins - https://jenkins.io/
ArqTI - http://arqti.org/
Waldez Ludwig - http://www.ludwig.com.br/

Agradecimentos 

Felipe Santos, nosso amigo, e ainda que hoje ele more distante faremos um bom churrasco juntos. 

Gediel Luchetta, pela disponibilidade, sugestões e revisão da publicação.

Sara Gabriela Dhein, pela disponibilidade e revisão da publicação.

Isaías Prestes, pela disponibilidade, sugestões e revisão da publicação. 

Sobre os autores

* Gabriel Prestes, formado em Gestão da Tecnologia da Informação, DevOps Engineer da ilegra, é um entusiasta de carros antigos que cultiva em sua garagem um Gurgel Supermini funcionando.

* Inácio Klassmann, Head of strategy and innovation na South System, homem de 2 paixões, sua moto e sua família.