Esse post é baseado em um dos melhores artigos que li esse ano e que tenho tentado seguir. Sim, é um exercício constante e para mudar esse comportamento leva tempo. Afinal, somos humanos e reclamar é inerente.

No texto do Marc Brooker, ele toca em um ponto que a maioria das pessoas prefere ignorar (ou que não se atentaram ainda), que são as pessoas e grupos que você escolhe ouvir, dar atenção e participar moldam de forma silenciosa a sua ambição, a sua energia e a sua capacidade de evolução.

E uma grande verdade é que se você passa tempo demais em ambientes e/ou grupos onde o normal é reclamar, você vira parte do problema, mesmo achando que está só desabafando.

Evitando o ruído negativo

“If I could offer you a single piece of career advice, it’s this: avoid negativity echo chambers.”

Grupos onde a reclamação reina vão drenar sua capacidade de pensar com clareza e será criada uma distorção onde todo desafio parece muito complicado, toda empresa é tóxica e todo líder é incompetente.

Você pode não perceber, mas a sua ambição é enfraquecida por osmose.

E a verdade é simples, pessoas que vivem reclamando não progridem e também não querem que você progrida.

E é aí que o pessimismo em grupo vira identidade.

“Sometimes, it becomes a cultural norm… pessimistic people end up dominating.”

Essa é a real, quando a negatividade vira a linguagem comum, quem tenta construir algo novo se torna o ingênuo que não conhece o ambiente que trabalha.

E na minha opinião, esse tipo de grupo/comunidade é bem confortável para quem desistiu silenciosamente da própria evolução. Se você está cercado disso, você com certeza já sabe. E sabe também que, quanto mais tempo passa, mais difícil se desligar dessas comunidades.

Outra grande verdade é que reclamar com pares também não adianta e essa é uma das frases mais verdadeiras do texto:

“DMing away about how much things suck doesn’t make change.”

Sair mandando mensagem privada para seus pares pode criar a sensação de ação, mas a real é que não. Ainda mais se é um problema cultural e/ou estrutural da empresa. No fim, é autoengano com um custo emocional alto.

Quando você passa um tempo demais alimentando essas conversas de bastidores, está tentando dizer para si mesmo que está tentando melhorar… mas, na prática, só está mantendo o status quo. É um vício que parece inofensivo, mas destrói clareza e motivação.

Vale ressaltar que o oposto também é prejudicial:

“Positive echo chambers can be bad too.”

Sim, entusiasmo e positivismo cego é tão tóxico quanto o pessimismo crônico. O ponto central não é ser positivo e good vibes o tempo todo. É ter clareza da situação.

Todo esse otimismo sem ação gera ilusão e a negatividade sem ação gera corrosão e entre esses dois extremos está o único caminho que importa, a realidade com movimento.

E como sair desse ciclo?

O Marc propõe algo bem direto:

“If more than 20% of the content is negative, I move on.”

Marc também define um limite objetivo para se livrar desses ambientes e você não precisa se explicar, não precisa convencer ninguém, é só sair. Se você está consumindo e interagindo de forma negativa mais de 20% do seu tempo ou mais de 20% das conversas são só reclamações, você já sabe o que isso está fazendo com seu cérebro e com seu ânimo.

Meu conselho aqui é fazer uma reflexão do que você consome em mídias sociais (principalmente LinkedIn) e em grupos/comunidades que você participa hoje e se você achar que é tóxico, saia. Novamente, você não precisa se explicar, nem convencer ninguém.

Outra saída é onde você vai e deve colocar sua energia:

“Spend your energy at work doing great work and improving. Or, do the minimum and disconnect.”

Em uma tradução livre “Gaste sua energia no trabalho fazendo um trabalho bacana e sempre melhorando, ou faça o mínimo e desconecte” e ponto final.

Esse clima morno onde você nem cresce, nem descansa e nem se preserva não leva a nada, só estagnação.

Se quer evoluir, aprenda, construa, se exponha ao que te desafia. Se aproxime de pessoas que constroem, que tentam, que erram, que corrigem e que seguem nesse ritmo. Isso vale para pessoas no seu trabalho ou de comunidades.

O que não dá é tentar justificar essa estagnação com discursos sobre “como o mercado é cruel” ou “como ninguém sabe o que faz”. Infelizmente, esse discurso só te faz continuar na mesma.

Pontos finais

Como disse inicialmente, é difícil quebrar esse ciclo e a maioria das pessoas subestima o impacto das comunidades que fazem parte e o conteúdo que consomem.

Você pode ser super competente, ser ótimo tecnicamente, mas se a sua referência diária são grupos onde as pessoas são frustradas e beiram o cinismo, não existem atalhos, mentoria e nem ajuda profissional que ajude.

Meu conselho é, se quiser evoluir, remova todo o ruído negativo, saia de grupos, faça uma boa limpa em suas redes sociais, não dê bola para aquele colega de trabalho que só sabe ver o lado negativo das coisas e comece a se aproximar de quem está construindo e evoluindo.

Imagine você, como Engenheiro/a DevOps ou Engenheiro/a de Software, como você mediria seu desempenho, do seu time ou da engenharia como um todo? Existe algum framework ou método para isso? A resposta é “sim”, como o SPACE e o DevEx, mas o framework que vou abordar hoje é o DORA Metrics.

Medir a eficácia das práticas de DevOps vai além de apenas implementar CI/CD e afirmar que se está praticando DevOps. As DORA Metrics, desenvolvidas pela DevOps Research and Assessment, são fundamentais para obter uma visão precisa e baseada em dados sobre o desempenho de entrega de software. Elas se concentram em quatro métricas principais que revelam o desempenho real das equipes de engenharia, destacando de forma clara as áreas que precisam de melhorias. Com essas métricas, você consegue ir direto ao ponto, identificando gargalos e oportunidades para otimizar processos e entregar mais valor.

Além disso, as DORA Metrics podem ser alinhadas com os objetivos estratégicos da empresa, garantindo que as práticas de DevOps estejam em sintonia com as metas de negócio. Por exemplo, ao melhorar a Frequência de Deploys e reduzir o tempo médio de recuperação de um incidente, a empresa pode acelerar o tempo de lançamento de novos produtos no mercado e consequentemente aumentando sua competitividade e satisfação do cliente.

As quatro métricas

Entendido o que são as DORA Metrics, vamos passar por cada uma delas e dar mais contexto:

Deployment Frequency

Deployment Frequency mede quantas vezes novas versões de código sobem para produção em um determinado período. É um indicador que mede a agilidade da equipe de desenvolvimento e da capacidade de entregar valor continuamente aos usuários e ao negócio. Ou seja, uma alta frequência de deploy corresponde a equipes que respondem rapidamente a feedbacks (feedback loops) e mudanças nas regras de negócios.

Para medir, basta calcular o número de deploys realizados em um período específico, como por dia ou semana. Um processo importante, que minimiza dependências e “burocracias” no processo de deploy e que já é bem difundido é o CI/CD. Vale ressaltar que CI/CD não é ter um Jenkins ou GitHub Actions rodando, CI/CD é de fato o processo contínuo e sem intervenções manuais para rodar uma suíte de testes, processo de build e deploy.

Lead Time for Changes

Mede o tempo que leva desde o commit inicial até o deploy para produção. Essa métrica reflete a eficiência das pipelines, fluxos de desenvolvimento e a capacidade e velocidade de entregar valor.

Diferente do deployment frequency, a ideia é ter essa métrica com indicadores baixos, ou seja, subir pequenas alterações para produção e com mais frequência. A utilização de metodologias ágeis, também ajuda muito no processo.

Mean Time to Recovery ou MTTR

O MTTR mede o tempo médio que um time leva para recuperar um sistema após uma falha em produção. É um indicador da resiliência e estabilidade do sistema. Adotar práticas SRE, como a criação de playbooks para incidentes, observabilidade, e chaos engineering, pode melhorar significativamente o MTTR.

Ter um bom processo de gerenciamento de incidentes, com revisão de post-mortems e ferramentas que alertem a qualquer comportamento anômalo e que possam indicar uma possível falha, ajudam na identificação de melhorias e recuperação/correção mais rápida.

Change Failure Rate

Mede a porcentagem de deploys que resultam em falhas em produção. É um indicador importante para avaliar a qualidade do processo de desenvolvimento e a estabilidade do sistema.

Implementar suíte de testes automatizados, realizar revisões de código de forma mais regular e utilizar pipelines de CI/CD para validação contínua são métodos eficazes para reduzir a taxa de falhas.

Como implementar

A maior parte das ferramentas de CI/CD e observabilidade atualmente conseguem demonstrar os indicadores das quatro métricas. Por exemplo, a Datadog possui em beta uma funcionalidade para extração e análise, a Harness tem algo um pouco mais sólido, porém mais simples. Já o GitLab oferece uma análise bem mais completa, porém apenas no plano Ultimate.

Porém, ambas soluções são pagas e isso vai muito da ferramenta que você utiliza, por isso, recomendo uma ferramenta que tenho estudado há algumas semanas, o Apache DevLake. Nela, é possível plugar várias soluções de mercado e centralizar a extração e visualização de métricas em um só lugar. Outro ponto bem positivo, é que caso na sua empresa seja utilizado alguma ferramenta desenvolvida internamente, o DevLake aceita Webhooks.

Além das quatro métricas, o DevLake consolida várias outras adicionais, como tamanho das Pull Requests, duração dos builds, linhas adicionadas ou deletadas em um commit e por aí vai.

Obviamente, que conseguir integrar a medição das métricas no dia a dia, requer práticas e processos bem definidos. Uma dica é incorporar revisar essas métricas durante as dailies ou em retrospectivas. Criar uma dashboard para que todo time possa acompanhar as métricas pode aumentar a transparência e incentivar a responsabilidade compartilhada.

Estabilidade e Velocidade

Todo mundo quer uma baixa taxa de erros e que sistemas sejam restaurados rapidamente em caso de falha, é uma verdade que todo mundo também quer colocar features de forma mais rápida em produção. E inicialmente, parece que há uma divergência entre elas, certo? Se o time colocar mais features em produção sem bons testes ou controle de qualidade, a taxa de erros pode aumentar.

Algo muito importante, é que observabilidade vai muito de encontro com o tema. Quando há um incidente em produção, é possível entender de forma mais rápida, o problema olhando para qual foi a mudança. Com um lead time mais curto, a compreensão da mudança é mais fácil e consequentemente, sabemos qual é o problema. Ou seja, entender a causa raíz reduz o MTTR, que também reduz a taxa de falhas em mudanças (Change Failure Rate).

O contexto e os recursos são importantes nesses momentos. Porém, essas quatro métricas se influenciam mutuamente e muitas vezes ajudam dar insights que seriam mais difíceis de compreender de outra forma. Analisar essa “dualidade” entre velocidade e estabilidade é uma abordagem eficaz para avaliar o desempenho das práticas DevOps.

Vou deixar alguns livros que recomendo demais para quem quer se aventurar mais na melhoria de fluxo de entrega de software e DevOps.

• Accelerate: The Science of Lean Software and DevOps (Versão Kindle)

• The DevOps Handbook (Versão Kindle)

• Measuring Continuous Delivery

• Observability Engineering (Versão Kindle)

Boa leitura e até a próxima.