Semelhante à pergunta sobre a equipe dedicada à inovação, esta é outra pergunta que tenho recebido muito em minhas sessões de coaching, por isso acredito que sua resposta também pode interessar a mais pessoas. Neste caso, a resposta curta é NÃO. Este tema não tem espaço para uma resposta do tipo “depende”. Vamos mergulhar mais fundo.

Seu código, seus bugs

Se você constrói algo, você é o único responsável por sua qualidade. Se o que você construiu não está funcionando como esperado, você é responsável por corrigi-lo. É tão simples quanto isso. Não faz sentido ter uma equipe diferente para corrigir bugs feitos por pessoas diferentes. As pessoas mais capazes de corrigir um bug são as pessoas que criaram o bug. Aliás, esse é o melhor incentivo para as pessoas criarem menos bugs.

E os sistemas legados?

Em um sistema legado, a equipe herda um código que não escreveu. Normalmente, as pessoas que escreveram o código não estão mais na empresa. Nesse caso, faz sentido ter uma equipe dedicada a corrigir seus bugs? O ideal é NÃO. O sistema legado deve ser responsabilidade de uma equipe, que resolverá os bugs, mas também trabalhará na melhoria e evolução do sistema legado. Uma estratégia muito comum para lidar com sistemas legados é a estratégia de estrangulamento, ou seja, drenar lentamente a vida de um sistema legado substituindo gradualmente partes dele por uma implementação moderna.

Outro aspecto importante do sistema legado é que não precisamos necessariamente corrigir seus bugs. Às vezes, corrigir um bug em um sistema legado pode custar muito, pois ninguém tem conhecimento suficiente para depurar o sistema. Em alguns casos, em vez de corrigir o bug corrigindo sua causa raiz, podemos aplicar alguma correção alternativa que faz o sistema legado entregar o resultado esperado. Nesses casos, podemos aplicar uma estratégia chamada “monitorar e aplicar workaround”, ou seja, assim que descobrirmos uma solução paliativa para um determinado bug, provavelmente desenvolvido fora do sistema legado, monitoramos o comportamento indesejado e, assim que o comportamento aparece, aplicamos automaticamente a solução paliativa. É a ideia de que, dependendo do estado geral de saúde do paciente, algumas doenças são mais bem tratadas com remédios do que com cirurgia.

Devemos dedicar X% do tempo à correção de bugs?

Novamente, a resposta é um simples NÃO. Já expliquei como é importante entregar produtos de boa qualidade:

Qualquer usuário prefere usar um produto de boa qualidade que se comporte conforme o esperado. Esta é uma condição sine qua non para proporcionar uma boa experiência ao usuário.

Além da experiência do usuário, há outro aspecto importante a ser considerado quando falamos de qualidade e bugs. Sempre que alguém precisa trabalhar para resolver um bug que foi encontrado em um produto digital, essa pessoa precisa parar de trabalhar no que estiver trabalhando no momento para resolver o bug. Esta é uma interrupção no fluxo de trabalho. Se essa pessoa fosse capaz de entregar o software sem esse bug, ela poderia continuar trabalhando em coisas novas sem interrupção, o que a tornaria mais produtiva.

Neste mesmo artigo há um gráfico interessante sobre o número de bugs corrigidos como percentual do total de entregas em Conta Azul. Passou de 45% para 65%, bem mais que os 20%. Quando vimos isso, trabalhamos para diminuir esse percentual, melhorando a qualidade do que implantamos.

Em outra equipe, rastreamos a porcentagem de novos itens implantados e criamos deliberadamente OKRs para aumentar essa porcentagem. Em 2 anos conseguimos passar de 50% de novos itens implantados para 90% de novos itens implantados:

Na minha experiência, em vez de corrigir o % de esforço dedicado à correção de bugs, é mais produtivo focar na criação de código de qualidade, sem bugs. Para fazer isso, devemos rastrear a porcentagem de trabalho gasto na correção de bugs e gerenciar ativamente diminuir esse número.

Resumindo

• Semelhante à pergunta sobre a equipe dedicada à inovação, esta é outra pergunta que tenho recebido muito em minhas sessões de coaching, portanto, sua resposta também pode interessar a mais pessoas. Neste caso, a resposta curta é NÃO. Seu código, seus bugs.
• Se você herdar um sistema legado, terá que gerenciar um código que não escreveu. Gerenciar significa não apenas corrigir seus bugs, mas também trabalhar na melhoria e evolução do sistema legado, o que provavelmente incluirá uma estratégia de estrangulamento para mover gradualmente os recursos do sistema legado para a nova arquitetura.
• Também não devemos usar porcentagem fixa de tempo alocada para corrigir bugs. É mais produtivo focar na criação de código de qualidade, sem bugs. Para fazer isso, devemos rastrear a porcentagem de trabalho gasto na correção de bugs e gerenciar ativamente esse número para diminuir.

Educação, treinamento e aconselhamento em gestão de produtos digitais

Tenho ajudado empresas a conectar negócios e tecnologia por meio de educação, treinamento e aconselhamento em gestão e desenvolvimento de produtos digitais. Ajudo líderes de produto (CPOs, heads de produtos, CTOs, CEOs, tech founders, heads de transformação digital) a extrair mais valor e resultados de seus produtos digitais. Veja aqui como posso ajudar você e a sua empresa.

Newsletter

Escrevo reguIarmente sobre gestão de produtos, desenvolvimento de produtos, liderança de produtos digitais e transformação digital. Vc pode receber uma notificação por email sempre que eu publicar algo novo, sem depender dos algoritmos de notificação de redes sociais. Basta assinar minha newsletter.

Gestão de produtos digitais

Você trabalha com produtos digitais? Quer saber mais sobre como gerenciar um produto digital para aumentar suas chances de sucesso, resolver os problemas do usuário e atingir os objetivos da empresa? Confira meu pacote de gerenciamento de produto digital com meus 3 livros, onde compartilho o que aprendi durante meus mais de 30 anos de experiência na criação e gerenciamento de produtos digitais. Se preferir, pode comprar os livros individualmente:

• Liderança de produtos digitais: A ciência e a arte da gestão de times de produto.
• Gestão de produtos: Como aumentar as chances de sucesso do seu software.
• Guia da Startup: Como startups e empresas estabelecidas podem criar produtos de software rentáveis.