Como o próprio nome já nos dá uma noção, falar de débito técnico nos leva para um viés mais técnico mesmo. Mas, fique por aqui. Prometo que vou tentar deixar o conteúdo mais leve e o mais didático possível.
Débito Técnico
O débito técnico é normalmente identificado pelo arquiteto de soluções, que durante a sua análise da arquitetura do produto, mediante sinais negativos, identifica sérios problemas no seu desenvolvimento.
Trata-se do custo implícito de retrabalho adicional causado pela escolha de uma solução fácil, em vez de usar uma abordagem melhor que levaria mais tempo, mas não implicaria em problemas posteriores.
O débito técnico no desenvolvimento de produtos acontece devido a tomadas de decisões que priorizam a velocidade da implementação, ao invés de optar por escolhas estruturais que resolvam o problema por completo.
Geralmente é resultado da implementação de ações rápidas (eXtreme Go Horse), não considerando uma solução mais adequada a longo prazo. E aqui precisamos lembrar que Velocidade é diferente de Agilidade.
E ainda dentro desse tema sugiro a leitura do conteúdo: Não aceitamos Go Horse! Entenda o que é o eXtreme Go Horse que vai te dar uma ideia mais profunda dessas soluções.
Sinais de que pode haver um débito técnico:
Entre os muitos problemas que apontam para um possível débito técnico, os 3 a seguir se destacam:
Lentidão;
Não responder aos comandos;
Linguagens de programação que não se conversam.
Dito isso, vamos à parte prática: se o produto apresenta alguns desses sinais acima é preciso solicitar ao arquiteto de soluções uma análise completa e detalhada de toda a sua estrutura. Não tem como fugir disso.
É débito técnico: O que fazer?
Bruna, foi realizada a análise e estamos mesmo com débitos técnicos. O que fazemos?
Nesse caso a resposta é uma só: Reestruturação. ISSO É: o produto precisa ser refeito pelo menos no que diz respeito a sua arquitetura. Pois só assim ele conseguirá responder às novas funcionalidades, proporcionando uma boa experiência ao usuário.
E o que podemos entender com isso que estou colocando aqui é: muitas vezes, será preciso que o PO escreva estórias técnicas, além das tradicionais estórias do usuário e até mesmo refaça a estrutura para que o produto possa continuar entregando funcionalidades de valor para o usuário final.
Falando de forma menos técnica e mais clara: Faz parte sim do trabalho do PO estar atento a débitos técnicos.
E para ficar ainda mais claro, vou trazer aqui 2 exemplos.
1° Exemplo de débito técnico: site ou app lento
Digamos que você tem como resultado do seu produto um site ou um aplicativo extremamente lento, que fica apenas naquele loading eterno e nunca carrega nada. É lógico que tem algum ou muitos problemas na arquitetura da informação.
Acontece que o usuário não sabe desses problemas e nem quer saber. O que ele quer mesmo é ter uma boa experiência, um carregamento rápido. E para que ele tenha isso será preciso reestruturar.
O que significa que esse trabalho de reestruturar, aprimorar ou dar um upgrade na parte estrutural do produto também faz parte da entrega de valor do ponto de vista do usuário final. Deu para perceber isso?
2° Exemplo de débito técnico: Nesse exemplo vou falar de forma mais técnica, então foca aqui.
Todo produto digital gera métricas, ou deveria gerar rs. Se você não sabia disso, agora tá sabendo. Aliás, acho que é uma boa ideia salvar esse artigo nos seus favoritos para consultar e também compartilhar com o seu time.
Voltando às métricas geradas pelos produtos digitais, quem as acompanha é o Product Owner, através da instalação de scripts no produto e, por meio do Google Analytics ou do Firebase (que são as duas principais ferramentas do mercado quando se fala em métrica de produtos digitais/aplicativos). No entanto, pode acontecer mudanças nessas ferramentas.
Por exemplo:
O Google Analytics já anunciou que a partir de 2023, a captação de tráfego e matérias será feita através do GA4 - Google Analytic 4.
E nós precisamos entender que embora isso não mude nada para o ponto de vista do usuário final, fazer a instalação do script do GA4 é o que vai dar insumos para que o Product Owner possa ter a visão de como fazer a melhoria contínua para o usuário.
Ou seja, o GA é um dado técnico que precisa ser atualizado para o novo Script de acompanhamento do Google, o GA4, para que com base no acompanhamento feito através dele, se possa gerar o aprimoramento do produto e se não for feito assim, será um problema maior depois.
Conclusão: débitos técnicos precisam ser observados e resolvidos porque no final das contas tudo o que diz respeito a arquitetura é também parte do produto e ignorar esse fato resultará em prejuízo a experiência do usuário e ao resultado final do produto no mercado.
Entendido?
Lembre-se de que caso haja dúvidas, você pode deixar nos comentários, que eu responderei.
Fique bem e até o próximo conteúdo!!