- Uma organização de engenharia com cerca de 45 pessoas interrompe, a cada trimestre, roadmap, design e reuniões por uma semana para realizar a “Semana Fixit”, focando em resolver pequenos bugs e problemas de produtividade
- Neste Fixit, 189 bugs foram corrigidos, com 40 participantes; a mediana foi de 4 correções por pessoa, com máximo de 12 bugs fechados
- Regras como limite de 2 dias por correção, sistema de pontos e leaderboard e recompensas com camisetas ajudam a motivar e elevar o moral da equipe
- O uso de ferramentas de IA acelerou a exploração do código e as sugestões de correção, reduzindo o custo de troca de contexto
- O Fixit contribui para melhorar o acabamento do produto e fortalecer a coesão da equipe, sendo visto como uma cultura que resgata a alegria de resolver pequenos problemas
O conceito de Fixit e como ele funciona
- Fixit é uma semana intensiva de correção de bugs realizada a cada trimestre, com interrupção total do trabalho regular de roadmap, design e reuniões
- Os engenheiros resolvem pequenos erros ou fatores que reduzem a produtividade e que vinham incomodando usuários e desenvolvedores
- Exemplos: uma mensagem de erro pouco clara há 2 anos, um glitch ao usar scroll e zoom ao mesmo tempo, atrasos no CI por causa de testes lentos
- Há duas regras
- Nenhum bug deve levar mais de 2 dias
- O trabalho deve se concentrar em melhorias para o usuário final ou aumento da produtividade dos desenvolvedores
- Um sistema de pontos e leaderboard é usado para tornar visível a participação, e há camisetas como recompensa em categorias como “primeiro bug corrigido” e “bug mais irritante corrigido”
Resultados do Fixit
- Resultado deste Fixit
- 189 bugs corrigidos, 40 participantes, mediana de 4 por pessoa, máximo de 12
- Casos de destaque
Efeitos do Fixit
-
No produto: atenção aos detalhes e acabamento
- Uma característica de bons produtos é a atenção aos detalhes e a consistência
- O Fixit é uma oportunidade de elevar a qualidade do produto ao remover pequenos incômodos que o usuário talvez nem perceba conscientemente
-
No nível individual: satisfação orientada à execução
- É uma forma de recuperar a sensação imediata de realização dos primeiros anos de carreira: “encontrar um problema → corrigir → publicar”
- Durante o Fixit, o foco fica mais em “como melhorar” do que em “o que construir”, acumulando sensação de progresso em ciclos curtos
-
Na equipe: reforço de moral e colaboração
- Com 40 pessoas em dois fusos horários corrigindo bugs ao mesmo tempo, há um aumento de energia em toda a organização
- Ocorrem interações ativas como compartilhamento de correções em tempo real no chat, postagem de screenshots e demonstrações
- Todas as manhãs, são compartilhados número de correções, quantidade de participantes e posição no leaderboard, reforçando a motivação
Requisitos para operar um Fixit bem-sucedido
-
Preparação prévia
- Ao longo do ano, os bugs recebem a tag “good fixit candidate” e, na semana anterior ao Fixit, são classificados em pequeno, médio e grande (0,5·1·2 dias)
- Cada tamanho recebe 1, 2 e 4 pontos, respectivamente, e é criada uma lista de bugs prioritários
- Esse processo de preparação é o elemento-chave para evitar confusão no primeiro dia
-
Regra do limite de 2 dias
- No passado, houve um caso em que um bug era mais complexo do que o esperado e consumiu toda a semana do Fixit
- Depois disso, foi adotado o princípio de interromper e mover para o backlog se passar de 2 dias, com o objetivo de manter uma sensação contínua de realização
-
Escala de participação
- Na fase inicial, com 7 pessoas, houve resultados, mas faltava adesão do restante da organização
- Em torno de 40 pessoas, forma-se a massa crítica, com máxima energia coletiva e imersão
-
Gamificação
- Os pontos priorizam diversão, não precisão absoluta (1/2/4 pontos)
- O reconhecimento é amplo: primeiro bug corrigido, bug mais irritante etc.
- É separado da avaliação de desempenho, preservando a motivação genuína para participar
- Graças às normas sociais e ao tamanho da equipe, quase não há abuso do sistema
O papel das ferramentas de IA
- A IA reduz o custo de troca de contexto, um dos principais desafios do Fixit
- Ela encontra e resume rapidamente arquivos relacionados, reduzindo a carga cognitiva
- Exemplos
- Como resultado, ficou mais rápido chegar ao ponto de partida e, em alguns casos, foi possível corrigir imediatamente
Críticas ao Fixit e respostas
-
“Isso não significa ignorar bugs no dia a dia?”
- Em parte, sim, mas o Fixit compensa a realidade em que pequenos incômodos (
papercut bugs) acabam ficando para trás na priorização
- O Fixit é uma forma de reservar tempo explicitamente para resolver “problemas pequenos, mas importantes”
-
“Parar o trabalho de roadmap não é desperdício?”
- O investimento de uma semana de 40 pessoas é grande, mas é compensado por mais acabamento no produto e maior satisfação do usuário
- Ganhos de produtividade como melhora na velocidade dos testes, mensagens de erro mais claras e workflows mais curtos continuam no longo prazo
-
“Isso não só funciona em empresas grandes?”
- Equipes menores também podem adaptar o modelo com “Fixit Friday” ou um mini Fixit de 2 dias
- O essencial é garantir tempo concentrado e protegido e uma atividade coletiva de melhoria
O valor essencial do Fixit
- O objetivo oficial é melhorar a qualidade do produto e a produtividade dos desenvolvedores
- A razão não oficial é “a alegria de consertar alguma coisa”
- É visto como um elemento essencial para resgatar a satisfação de tempos mais simples e manter uma cultura de desenvolvimento de produto cuidadosa e caprichada
2 comentários
Isso me lembra a cultura do Pit Stop da Baemin. Ouvi dizer que isso não existe mais hoje em dia.
Comentários do Hacker News
Gosto da ideia, mas a frase “um bug não deve levar mais de 2 dias” parece estranha
Na prática, é quase impossível prever quanto tempo vai levar antes de corrigir o bug
Ainda assim, acho que, se não exigir um grande refactor, quase nunca deveria levar mais de um dia
Eu normalmente trato bugs de acordo com a gravidade ou prioridade. Quanto mais grave o bug, mais frequentemente ele acaba sendo surpreendentemente fácil de encontrar
Quando se descobre a causa, a solução costuma ser rápida
Analisamos os logs por anos sem encontrar a causa, até descobrir que dava para reproduzir 100% com uma combinação específica de estado do DB e commits
Assinamos um NDA e criamos um binário mínimo de reprodução, automatizado com um script em PowerShell, e a Microsoft corrigiu em um mês
Internamente, parecia algo como um buffer overflow, mas não tenho certeza
Se eu passasse a semana inteira só corrigindo bugs e não acumulasse story points no Jira, vários gerentes vinham perguntar por que a velocidade estava baixa
Então a lição que aprendi foi: é melhor evitar bugs difíceis e desistir cedo de trabalhos que não geram pontos
Você não sabe se o problema está no código, no compilador ou no hardware, e bugs compostos, causados por vários fatores ao mesmo tempo, nem sequer podem ser reproduzidos isoladamente
Nesses casos, quando paliativos rápidos vão se acumulando, depois uma correção de bug de verdade acaba virando um retrabalho enorme
Além disso, em ambientes de baixa confiança, até bugs pequenos às vezes não podem ser corrigidos de imediato por causa do processo no Jira
Quando trabalhei na Meta, fazíamos Fix-it Week a cada trimestre
No começo, achei que a liderança se importava com qualidade, mas na prática era um período autorizado para acumular dívida técnica
Tentávamos corrigir bugs durante uma semana, mas por causa da dívida já acumulada quase nada era resolvido
Caso contrário, código novo vai se acumulando em cima do bug e cria uma base instável
No vídeo da palestra de John Romero, ele enfatiza a mesma filosofia
Os desenvolvedores resolviam TODOs deixados no passado e aumentavam o LOC, e alguns até usavam o truque de escrever código ruim de propósito para depois “corrigir” e assim inflar a quantidade de diffs
Ou seja, é um tempo para lidar com problemas que não são urgentes, mas incomodam
É mais importante que a liderança explique com honestidade as prioridades de negócio e mostre com clareza o impacto dos bugs para o usuário
Já passei por um ciclo vicioso em que, durante o desenvolvimento de funcionalidades, respostas emergenciais e mudanças de prioridade se repetiam sem parar
No fim, o sistema vira uma coleção de workarounds, e tanto clientes quanto desenvolvedores ficam insatisfeitos
Numa situação assim, dá a sensação de que teria sido melhor parar tudo desde o início e fazer uma correção estrutural dos bugs
A comunicação se rompe, e os líderes ficam correndo sem rumo como galinhas, só dando ordens
O desenvolvedor vira bombeiro de todos os problemas, e no fim a única solução é ir embora
Quanto mais a velocidade cai, mais os líderes entram em pânico e começam a remanejar o projeto de qualquer jeito, ampliando a confusão e a cultura tóxica
Sempre trabalhei com a filosofia de que “corrigir bugs vem primeiro”
Se a funcionalidade existente não funciona direito, não crio uma nova
Fazendo isso, dá para manter uma base de código sem bugs e aumentar a produtividade da equipe
Especialmente no front-end, por causa dos vários problemas de ambiente, é quase impossível chegar a um estado completamente sem bugs
Além disso, como a definição de “bug” é ambígua, às vezes funcionalidades desejadas pelo gerente acabam sendo classificadas como bug
Por exemplo, um erro numa página de API quase nunca usada pode ser menos importante do que uma nova funcionalidade
A maioria são problemas leves, então a liderança tende a preferir novas funcionalidades
Eu opero um pequeno produto SaaS e sigo o princípio de “corrigir bugs primeiro”
Resolvo antes os bugs reportados pelos clientes do que desenvolver novas funcionalidades
Fazendo isso, a quantidade de bugs recém-descobertos vai diminuindo aos poucos, e corrigi-los também fica mais fácil
Do ponto de vista do negócio, pode ser ineficiente, mas em termos de qualidade e confiança do cliente é a melhor estratégia
Os clientes adoram quando um bug reportado por eles é corrigido em poucas horas
Mecanismos como a Fix-it Week acabam, na verdade, incentivando o adiamento da correção de bugs
Surge a desculpa de “deixa para a próxima Fix-it Week”
Em vez disso, acho melhor incluir explicitamente tempo de manutenção no planejamento do trimestre ou da sprint
Assim, o desenvolvedor ganha respaldo para corrigir bugs imediatamente, e uma cultura de melhoria contínua se estabelece
A Fix-it Week funcionaria melhor como uma espécie de mini hackathon com pequenas melhorias ou POCs
Na empresa onde trabalhei antes, o ciclo era sempre o mesmo
Esse padrão era um sinal de que a cultura organizacional estava errada. Se você não reserva tempo para corrigir bugs no dia a dia, isso nunca muda
Isso me lembrou o Joel Test, proposto pelo Joel Spolsky
A quinta pergunta era: “Vocês corrigem bugs antes de escrever código novo?”
Mesmo 25 anos depois, continua sendo um critério válido
Link do texto original
Sou da opinião de que não se deve atribuir pontuação nem estimativa de tamanho a bugs
Se realmente precisar de pontos, pode colocar tudo como 2, que na média funciona
Correção de bugs deve ser tratada em Kanban, resolvendo por ordem de importância e concluindo dentro do tempo disponível
Sou o autor do texto. Fico feliz de ver uma discussão tão ativa
Não é substituto para higiene técnica nem para resolver issues grandes