A gestão das dívidas técnicas é um dos grandes desafios para líderes e equipes de Desenvolvimento de Software. Elas surgem quando tomamos a decisão de entregar código em produção abrindo mão de alguns compromissos técnicos e de qualidade em prol de atingir algum objetivo maior de negócio a curto prazo.

Neste artigo, vou  explorar como as equipes de tecnologia do Méliuz, uma empresa focada na geração de tráfego qualificado para lojas e marcas parceiras, conseguiram reduzir significativamente o volume de dívidas técnicas e aumentar a cobertura de testes em apenas uma semana, utilizando uma abordagem divertida chamada "Fix It Week". 

A importância de eliminar dívidas técnicas

As dívidas técnicas no Desenvolvimento de Software podem surgir de várias formas:

• Código que não segue todos os padrões previamente definidos;
• Código que precisa ser simplificado ou reescrito para evitar problemas de desempenho, segurança e escalabilidade;
• Código sem a devida documentação;
• Código com uma cobertura de testes inadequada, aumentando o risco de bugs;
• Dentre outros exemplos.

Analogamente com dívida financeira, dívidas técnicas são implementações rápidas e menos criteriosas que "emprestam" tempo no curto prazo, mas "cobram" juros no futuro. E esses “juros” são duros e podem vir na forma de:

• Aumento da complexidade, tornando o código difícil de se entender e aumentando o tempo necessário para adicionar novas funcionalidades;
• Maior probabilidade de erros e bugs;
• Limitação na capacidade de escala;
• Aumento de custos, uma vez que mais tempo e pessoas são necessários para resolver os problemas;
• Impacto na experiência do usuário;
• Introdução de vulnerabilidades de segurança, que podem ser exploradas por hackers;
• Frustração e desmotivação para as pessoas desenvolvedoras.

Logo, o melhor seria não contrair esse tipo de dívida, mas uma vez que isso tenha ocorrido, é importante que as correções sejam feitas o quanto antes, pois esses “juros” são compostos e crescem em uma velocidade assustadora!

Em consequência, conseguir tempo para o pagamento dessas dívidas em meio à pressão por entregas de novos produtos e features passa a ser o grande desafio. E o único meio de conseguirmos isso é através de uma forte parceria e confiança entre times de engenharia, gerentes de produto e a diretoria da empresa. 

Estrutura e proposta da Fix it Week

Aqui no Méliuz, posso dizer que existe um ambiente favorável para negociações entre as áreas de negócio e tecnologia no momento de decidir pela criação de uma dívida técnica e posteriores “pagamentos” em parcelas ao longo de futuras sprints.

Porém, sabemos que existem períodos em que o espaço para refatorações mais constantes se torna menor em favor de objetivos de curto prazo maiores e a dívida fica difícil de ser paga em “suaves prestações” depois.

Muitas vezes, é necessário um projeto mais focado e intensivo para reduzir essas dívidas e aumentar a qualidade do software. Assim, surgiu a ideia de criarmos a Fix it Week!

A proposta da Fix It Week veio a partir de discussões sobre a promoção de um hackathon interno, com o objetivo de promover a integração e resolver problemas técnicos entre os três times de uma das áreas de engenharia da empresa.

Além disso, conforme aprendi durante a aula de Máquina de Talentos da Mentoria CTO do IFTL, a realização de eventos, como hackathons e treinamentos, é uma excelente estratégia para reter e impulsionar o desenvolvimento técnico das pessoas, uma vez que um dos maiores motivos de pedidos de demissão de devs é o fato de não se sentirem evoluindo tecnicamente.

Assim, durante uma semana intensiva de trabalho, as equipes se reuniram para enfrentar três tipos de problemas principais: 

• Cobertura de testes, uma métrica que avalia o quanto do código de um software está sendo testado (por códigos específicos para testes), comumente obtida através de ferramentas como o Sonarqube.
• “Crashes”, falhas no aplicativo que causam o seu fechamento de forma abrupta;
• Exceções, situações inesperadas em que são lançadas mensagens de erro, captadas por nossas ferramentas de monitoria e que não tinham o devido tratamento.

A escolha desses três tipos de problemas foi feita para facilitar a metrificação dos resultados.

A importância da pontuação em hackathons‍

‍Cada pull request (submissão de código para um repositório central para ser revisado antes de ir para produção) que solucionasse um desses problemas recebia uma quantidade de pontos preestabelecida.

Isso foi importante para que a competição tivesse uma equipe campeã de forma clara e justa, sem gerar questionamentos entre as pessoas participantes. Também foi importante essa escolha para que pudéssemos avaliar numericamente a evolução da qualidade dos repositórios de código após a semana.

Por último, foi estabelecida uma banca avaliadora externa aos times envolvidos para resolver questões não previstas nas regras que porventura surgissem.

Alinhamento com as áreas de negócio

Para garantir o máximo de engajamento possível dos times, foi alinhado previamente com todas as pessoas de produto e áreas de negócio relacionadas que naquela semana nenhuma demanda seria tratada pelos times, a não ser casos urgentes de operação. Como disse, a parceria entre tecnologia e negócio é fundamental!

Regras estabelecidas para a Fix it Week

As regras da competição foram as seguintes:

• Somente seriam aceitas pull requests criadas durante os dias da competição;
• A banca examinadora avaliaria essas PRs para contabilização dos pontos;
• Os times somente poderiam enviar código para os repositórios de suas responsabilidades;

A pontuação foi distribuída da seguinte forma:

Sendo que para estar elegível à disputa, o time teria que atingir no mínimo 300 pontos.‍

Caso houvesse empate na primeira colocação, o desempate seria feito pelo time que tivesse mais pontos pela ordem das categorias:

1. Crashes no aplicativo;
2. Resolução de exceções não tratadas;
3. Aumento da cobertura de testes.

Se ainda se mantivesse o empate, a banca avaliaria as documentações criadas a partir desses novos códigos, ganhando aquele time que melhor documentou as alterações realizadas.

Resultados obtidos com a Fix it Week

Além de aumentar a qualidade dos repositórios, a competição tinha como objetivo aumentar o engajamento dos times e a integração entre as pessoas.

Isso ficou evidente durante e após o evento, com times engajados para garantir o primeiro lugar na competição. Foi muito bacana ver todas as pessoas totalmente focadas se comunicando, alinhando pontos em que avançaram, o que faltava cobrir e definindo estratégias para atuação. E claro, o desenvolvimento de um ambiente saudável de trabalho, fazendo brincadeiras e provocações entre os times. Foi incrível!

Já, ao final da semana, no dia tão esperado, tivemos uma equipe vencedora em uma disputa super acirrada, por apenas 25 pontos de diferença da segunda colocada!

O melhor desse tipo de dinâmica é que não é somente o time vencedor que leva o prêmio, mas sim toda a empresa que acaba ganhando com produtos mais estáveis e times mais integrados e felizes.

Trazendo os resultados em números, tivemos:

• Redução de 71% do número de repositórios com níveis baixos de cobertura de testes (abaixo dos 90% de cobertura)
• Redução de 57% do número de repositórios com níveis médios de cobertura de testes (entre 90% e 95% de cobertura)
• Aumento de 62% no número de repositórios com níveis altos de cobertura de testes (acima de 95% de cobertura)
• Redução de 15% de exceções não tratadas
• 100% das situações de crashes ocorridas no mês anterior ao evento foram resolvidas. 

Outro resultado que foi super interessante foi ter a confirmação de várias pessoas que participaram de que o esforço para realizar essas ações diariamente ao longo do desenvolvimento das features não é tão alto como pensam. 

Isso reforça o discurso de que o ganho de tempo ao retirar essas ações durante o desenvolvimento de uma nova feature/produto é pequeno frente ao esforço futuro para corrigi-las. Logo, para abrirmos mão de qualidade durante a implementação tem que ser realmente uma situação exceção.  

Posso dizer honestamente que, como engenheiro de software, até me “dói” escrever sobre as vezes que subimos código para produção assumindo algum tipo de dívida técnica.

Gostaria que isso não fosse uma realidade na nossa vida, mas a vida não é perfeita, vivemos em um mundo complexo, onde o sucesso de um produto e de uma empresa depende de um conjunto grande de variáveis. E não podemos ser os únicos a não fazer concessões. Somos um time! ‍

Como pessoas gestoras de tecnologia temos que ter maturidade e sermos pragmáticos(as) para entender que, às vezes, temos que abrir mão de certos aspectos de uma entrega, para garantir um resultado de negócio, muito bem embasado e que, talvez, seja o que nos dará condições de aprimorar o software futuramente. 

É super importante dizer que assumir dívidas técnicas não pode ser a única ou primeira solução sempre. Essas situações têm que ser exceções e as empresas que não entenderem isso seguramente terão sérios problemas a médio/longo prazo.

Procure conscientizar toda a cadeia hierárquica envolvida para que haja esse comprometimento entre as partes e que, uma vez assumido um débito, já haja um planejamento para a correção em um curto prazo. 

E para finalizar, segue o reforço de mais algumas dicas:

1. Alinhe todas as expectativas previamente com os stakeholders: fale com todas as pessoas que se relacionam com as equipes participantes sobre o evento com antecedência. Essas pessoas precisam saber que naquela semana não poderão contar o time técnico, para que nenhuma estratégia da empresa seja impactada pela ação;
   
   
2. Tenha regras claras, discutidas com as equipes e de fácil acesso: coloque-todas as regras em um mural virtual e, no evento de lançamento (kick-off), diga onde essas regras estarão fixadas;
   ‍
3. Faça os seguintes alinhamentos com todas as pessoas diretamente envolvidas (times e banca):

• Preparação: discuta sobre o evento previamente, apresentando a proposta e discuta as regras com os times;
• Kick off:  ao iniciar o evento, esclareça novamente todas as regras da competição e aproveite para gerar aquela expectativa e motivação para o time que for campeão.
• Encerramento: finalize o evento, mostrando os resultados alcançados e anuncie a equipe vencedora.

4. Tenha uma banca avaliadora: muitos casos omissos às regras aparecerão durante a competição e é importante que ela seja composta de pessoas externas aos times envolvidos para que possam opinar e decidir sobre casos que não estão explicitamente descritos nas regras;

5. Passe orientações diariamente: a semana será muito intensa e será necessário enviar orientações para os times com uma certa frequência. Não deixe de provocar essa interação diária e aproveite para estimular mais uma vez a competição entre os times;
   
   
6. Viabilize formas simples de premiações ao time campeão: por ser uma competição, pensamos em opções de premiação que fossem interessantes ao ponto de motivar e engajar, sem a necessidade de ser suntuosas. Na Fix it Week, as pessoas vencedoras receberam gift cards de Ifood e ficaram super felizes em saber que o jantar/lanche especial do final de semana seria pago com o resultado do esforço delas no evento.
   
   
7. Compartilhe os resultados com a empresa toda: como demonstrado, uma ação como essa traz resultados incríveis nos níveis de qualidade dos produtos. Portanto, não deixe de compartilhar esses resultados com toda a empresa para demonstrar o quanto esse momento foi importante para todos!

8. Vincule a participação em treinamentos/hackathons ao Plano de Desenvolvimento Individual (PDI) do time: essa orientação foi dada na Mentoria CTO e faz muito sentido, uma vez que muitas pessoas acreditam que as empresas somente investem no desenvolvimento delas, quando subsidiam treinamentos formais, o que não é verdade. Em um evento como esse, houve o investimento de tempo por parte das lideranças e banca avaliadora. Inclusive, a interrupção do fluxo de entregas durante uma semana! É super importante trazer essa visibilidade para os times.

Aprenda técnicas avançadas para motivar e engajar times de tecnologia com grandes experts do mercado. Na Mentoria CTO, você aprende a construir uma máquina de talentos para atrair os colaboradores ideais para atender as necessidades, conforme o estágio da sua empresa.

‍(Esse artigo foi escrito em parceria com o Rodrigo Barreto que também idealizou junto comigo a realização desta iniciativa e que conduziu de forma brilhante todas ações na semana do evento. Barreto também foi aluno do Tech Lead Program do IFTL)‍