Este artigo sobre débito técnico é uma tradução adaptada de “How do you deal with tech debt as a PM?“, escrito por Aakash Gupta. Por ser um conteúdo de alto valor, consideramos uma boa ideia traduzi-lo para ajudar a comunidade brasileira de Produto a evoluir. Boa leitura!
É tão fácil se concentrar no envio de novas features interessantes que, às vezes, esquecemos a importância de concluir dívidas técnicas e ter o mínimo de débito técnico ao longo do caminho.
Isso vale para engenheiros, designers, gerentes de produto e colaboradores de todos os tipos. Na verdade, pela minha experiência, é mais difícil para os CEOs. É tão fácil para os CEOs conectarem os pontos entre um recurso e mais crescimento, uma avaliação mais forte e maior sucesso para a empresa.
Para o Product Manager, especificamente, uma das partes mais desafiadoras do trabalho é priorizar o débito técnico. Então, solucioná-lo depois é quase tão difícil quanto. Como um de nossos principais stakeholders é o CEO, estamos constantemente tentando construir a visão deles.
Isso cria uma notável compensação entre crescimento de carreira, impacto e dívida de tecnologia no curto prazo.
Então, como você lida com o débito técnico? Neste artigo, estou muito animado para colaborar com Brennan Decker (que escreve regularmente um conteúdo incrível no LinkedIn) e está escrevendo o livro “From People Manager to Product Manager”, além de ter um canal maravilhoso no YouTube.
- O que é débito técnico;
- Impacto do débito técnico;
- Função como Product Manager;
- Estratégias para abordar.
Como PM da JD Sports, Brennan tem ótimas narrativas “nas trincheiras” e conselhos sobre essas áreas. Eu, por outro lado, comecei minha carreira como Engenheiro de Software. Então, vamos nos aprofundar nisso.
O que é débito técnico
Como PM, ouvir as palavras “débito técnico” de um líder de Engenharia pode ser assustador. Independentemente de quão técnico você seja, todos nós sabemos que a dívida é ruim, certo?
Bem, assim como a dívida no mundo real, não é tão fácil resolver, mas às vezes é necessário.
Pense em comprar uma casa. Você prefere economizar o preço total de compra de uma casa ou apenas o pagamento inicial?
Por um lado, você não está comprometido com dívidas, mas em troca está esperando mais tempo para economizar pelo preço total da compra. Por outro lado, você pode se mudar para sua nova casa rapidamente (se estiver colocando apenas uma fração do preço de compra na casa), mas a desvantagem é que a cada mês você tem que alocar uma certa quantia de seu salário para pagar sua dívida hipotecária.
Agora vamos pegar esse mesmo conceito e aplicá-lo aos produtos de software.
Como Product Manager, você está disposto a se comprometer com dívidas técnicas para enviar mais rápido? Voltando à analogia, e se você encontrar a casa perfeita em um ótimo distrito escolar. Você permitiria que outra pessoa (um concorrente) entrasse e o fizesse enquanto você está parado economizando seu dinheiro? Mas, por outro lado, em que ponto seus pagamentos de dívidas consomem uma quantia tão significativa do seu salário que você não pode mais fazer as coisas que ama (trabalhar em novas features)?
Espero que você veja a complexidade agora e entenda que é tudo uma questão de equilíbrio. Nós, como Product Manager, temos que pesar a velocidade de mercado em relação à carga de débito técnico que podemos assumir.
Agora que você entende o que é dívida de tecnologia, vamos mergulhar nos 3 principais tipos de dívida de tecnologia.
3 tipos de débito técnico
Existem 3 tipos principais de dívida de tecnologia. Vale a pena entender o que impulsiona cada um.
Deliberada
Muitas vezes, ao construir, temos um objetivo. Talvez seja um OKR trimestral, a data de lançamento do jogo, um go-to-market mais curto. Esses objetivos nos levam a sacrificar o longo prazo pelo curto prazo. Então, temos uma discussão como uma equipe de desenvolvimento, “devemos seguir o caminho rápido pelo caminho certo?” E às vezes, escolhemos o caminho mais rápido.
Portanto, a dívida de tecnologia não é inerentemente uma coisa ruim. Esta é uma dívida de tecnologia “boa” que contraímos para lançar um MVP. Mas é “ruim” porque há um custo futuro.
Para aqueles que desejam eliminar a dívida de tecnologia, o bom desse tipo de débito é que é uma situação conhecida. A equipe sabe onde existe, quais problemas podem causar no futuro e quando a equipe deve corrigi-lo. Isso geralmente ajuda nas decisões de priorização e descoberta.
Infelizmente, como equipes de desenvolvimento, é extremamente difícil documentar tudo isso. Especialmente quando os membros da equipe seguem em frente, às vezes a dívida tecnológica deliberada se torna acidental.
Como resultado, torna-se útil ter uma compreensão de alguns dos tipos comuns de dívida tecnológica deliberada para poder identificá-la:
- Não excluir dead code após o resultado de um experimento ou decisão de cancelar o envio do produto;
- Não ter os testes, monitoramento e alertas em vigor; como resultado, os bugs são encontrados na produção;
- Os tempos de implementação e compilação levam várias horas ou dias;
- Os desenvolvedores não têm as ferramentas adequadas para permitir que detectem problemas técnicos antes de entrarem em produção;
- A equipe prioriza uma plataforma sobre a outra, então uma tem pontos de código defeituosos que causam bugs e falhas para usuários, deixados de lado na plataforma menor;
- Uma ferramenta de terceiros ou escolha de pilha de tecnologia não é mais dimensionada para a complexidade, as métricas e o número de usuários da organização.
Esses tipos de problemas surgem regularmente ao longo do processo de desenvolvimento rápido de software. Uma boa equipe de desenvolvimento e produto toma essas decisões estrategicamente, mas também volta para abordá-las com inteligência.
Acidental
A natureza da dívida tecnológica acidental é que ela geralmente surge ao longo do tempo. Sempre que você cria uma correção, ela imediatamente fica desatualizada. O aplicativo e a tecnologia subjacente evoluem.
Além disso, às vezes, os requisitos mudam ou o ambiente competitivo se inverte. Isso causa a existência de código, sistemas ou features inteiras que não são mais necessários – ou prejudicam ativamente o produto existente.
A dívida técnica acidental tem o problema insidioso de normalmente ser mais oculta do que a dívida tecnológica deliberada. Por exemplo, pode ser que o iOS tenha atualizado todas as suas funções e os engenheiros móveis precisem refatorar parte do código. Pode ser que o site tenha algo construído em um padrão da web que não seja mais suportado. Essas coisas às vezes só atingem o radar da equipe de produto depois que um usuário passa por problemas.
Podre
O tipo final de dívida técnica é aquele que surge da esteira de features constantes. Nós nos apressamos para adicionar features e mais features a um sistema de tal forma que ele se torne feio, complexo, lento e difícil de atualizar. Isso geralmente acontece quando a equipe original entendeu apenas parte dos requisitos futuros, então eles construíram uma solução que resolveu um caso de uso muito específico. Então, em instâncias futuras, talvez anos depois, as equipes lançaram outras features.
A equipe sente que está pedalando o mais rápido possível, mas, eventualmente, os sistemas chegam a um lugar onde eles pedalam parados.
Todos os recursos de aparafusamento compostos fazem com que as engrenagens gerais do sistema comecem a girar mais lentamente. Eventualmente, as rodas circulares que eram o sistema inicial tornam-se quadradas, difíceis de mover sem o maior esforço.
Impacto do débito técnico
A dívida tecnológica vem de todas as formas e tamanhos. Há uma configuração manual pequena e inócua cada vez que você constrói. Ele adiciona alguns minutos, mas causa problemas se você não fizer isso. Há uma verificação do sistema que não acontece automaticamente, então você precisa fazer manualmente.
O tipo mais desagradável e vigoroso são os sistemas e processos ineficientes maiores, que retardam (ou impossibilitam) o desenvolvimento futuro ou dificultam o dimensionamento.
Retardando o desenvolvimento futuro
Pegue a configuração manual e multiplique por 10. O débito técnico que retarda o desenvolvimento futuro adiciona horas a mudanças futuras. Isso pode ser devido à escolha de tecnologia, arquitetura do sistema ou decisões de esforços anteriores de engenharia.
Esse tipo de trabalho às vezes pode se tornar processos organizacionais aceitos. Como resultado, ele se enraíza ainda mais na cultura, enganando os desenvolvedores de que tem que ser assim.
Digamos que a dívida técnica o torne 10% mais lento na implementação de features. Se uma equipe de 8 desenvolvedores implantam um recurso a cada sprint de duas semanas, a despesa de 10% da dívida tecnológica é de 13 features ao longo do ano. Se levar apenas alguns sprints para ser concluído, o ROI para resolver esse tipo de tecnologia é bem alto.
Tornar o dimensionamento difícil ou impossível
Outra classe de débito técnico estratégico é aquele que torna o dimensionamento difícil ou impossível. Às vezes, essa dívida tecnológica é conhecida, mas, na maioria das vezes, ela precisa ser encontrada.
Quando estávamos realizando eventos de temporada no Fortnite e quebrando recordes temporada após temporada, encontramos um limite de usuários simultâneos a cada temporada. Isso porque estávamos fazendo algo tão inovador, para o qual a tecnologia literalmente não havia sido construída. Em certos níveis de escala, o escalonamento pode ser difícil, a menos que você resolva a dívida técnica.
Função como Product Manager
Para simplificar ainda mais, a dívida de tecnologia é amada pelos stakeholders e odiada pelos desenvolvedores. No fim, está em seus ombros (como Product Manager) descobrir quem fazer feliz.
Então, como você pode ganhar nessa situação? É fácil. Fazendo seu trabalho.
Você conhece aquele diagrama de Venn clássico que ilustra o papel do PM na interseção de UX, Negócios e Tecnologia?
Bem, é aqui que você ganha seu cheque-mate na encruzilhada de Negócios e Tecnologia.
Como PM, você precisa traduzir as necessidades do negócio (e velocidade) para sua equipe de Desenvolvimento (eles geralmente não gostam de cronogramas de negócios) e o estado atual de sua pilha de tecnologia para seus stakeholders de negócios (eles geralmente não gostam de restrições técnicas). Quanto mais animado e alinhado você conseguir fazer com que ambos os grupos tenham uma visão compartilhada, mais fácil será o seu trabalho.
Dito tudo isso, 2 das funções mais importantes para um PM lidar com o débito técnico são:
- Priorizá-lo o suficiente;
- Entender quando “sim” e quando “não”.
Priorize o suficiente
Como a ordem final responsável pelo que os desenvolvedores constroem, cabe ao PM priorizar suficientemente a dívida técnica. Mas há uma quantidade de cachinhos de ouro aqui. Um PM que enfatiza demais a dívida de tecnologia torna-se amado pelos devs, mas não tanto pelos Heads do Produto e pelos stakeholders responsáveis pelo crescimento dos negócios.
Então, como um PM pode priorizar apenas o suficiente, mas não demais? Uma das primeiras coisas a fazer é avaliar adequadamente cada elemento da dívida técnica. É aguda ou sistêmica? Outra coisa a fazer é entender seu impacto estratégico. Pode deixá-lo ali no mesmo lugar e habilitar outros recursos mais importantes, mas e o impacto moral?
Entenda também a confiança da equipe nessas reivindicações, bem como o tempo que levará para corrigir o problema. Depois disso, tente tomar uma decisão de priorização consciente.
Provavelmente, não se pode esperar para acertar. No entanto, a cada ciclo de planejamento, os PMs devem fazer uma pergunta depois de avaliar um resultado preliminar: “estamos priorizando a dívida de tecnologia o suficiente?”
Então, ao final de cada ciclo, promova uma discussão com a equipe de desenvolvimento. Pergunte: “Nós resolvemos a dívida tecnológica certa neste trimestre? Nosso foco foi muito ou pouco? E quais são as principais prioridades para o próximo trimestre?” Essas perguntas ajudam as equipes a se ajustarem ao nível individual que faz sentido para elas, considerando suas capacidades e contexto de negócios.
Entenda quando “sim” e quando “não”
Essas questões de priorização chegam ao cerne da habilidade que é ser capaz de entender quando lidar e quando não lidar com a dívida de tecnologia. Existem alguns fatores-chave a serem considerados:
- Perspectivas dos desenvolvedores;
- Impacto nos negócios;
- Trocas em outras iniciativas.
Parte da razão pela qual a função de PM existe é negociar esses detalhes no nível mais micro. Você deve arregaçar as mangas e escrever o pensamento. O que os devs acham? Qual é o impacto nos negócios? Qual é a troca? Ter essas coisas no papel ajudam todos na equipe a tomar uma decisão melhor.
O PM também deve desenvolver sua própria perspectiva. O objetivo deve ser, como sempre, impulsionar os resultados dos negócios, resolvendo os problemas dos usuários, criando alavancas de crescimento e mantendo a equipe satisfeita. Se a equipe estiver insatisfeita, isso pode significar priorizar a dívida de tecnologia mais do que o normal. Se os resultados de negócios forem críticos, talvez seja necessário esperar.
Estratégias para abordar
Agora que entendemos o que é dívida tecnológica e o que os PMs devem fazer a respeito, como os PMs podem fazer um trabalho melhor? Tudo começa com o rastreamento e os desenvolvedores, indo até a prevenção do acúmulo.
Em cada etapa do papel do PM no processo de desenvolvimento de software, um PM com habilidade em dívidas de técnicas pode se destacar.
Acompanhe no mesmo lugar
Se as tarefas de dívida de tecnologia não terminarem no backlog, elas nunca serão executadas. Acompanhe os problemas de dívida de tecnologia no mesmo backlog que você usa e responsabilize-os segundo os mesmos padrões. Em muitas organizações, isso significa ter uma especificação com os pontos-chave estabelecidos.
Isso também tem o benefício de lembrar constantemente a equipe dos principais problemas de dívida de tecnologia que existem. Caso contrário, eles podem facilmente alimentar o backlog. Mesmo que os itens sejam continuamente despriorizados, pelo menos uma discussão sobre eles está acontecendo.
A última coisa que você deseja é ter uma lista de pendências separada de itens de dívida de tecnologia pouco inspiradores e um conjunto interessante de recursos. Isso torna as decisões de troca muito irreais. No mesmo local, eles são mais facilmente pesados.
Capacite os desenvolvedores
Capacite os desenvolvedores a encontrar, sugerir, priorizar e resolver a dívida de tecnologia. Em cada etapa, eles se sentirão felizes por serem incluídos e se sentirão melhor sobre as decisões que estão sendo tomadas sobre qual dívida de tecnologia priorizar.
Ao encontrar dívidas de tecnologia, dê tempo aos desenvolvedores. Na verdade, faça disso uma tarefa ocasional. Crie processos para entender quais desenvolvedores são os mais eficazes em encontrar dívidas tecnológicas para que possam ser recompensados e reconhecidos.
Além de capacitar os desenvolvedores a encontrar dívidas de tecnologia, forneça ferramentas para capacitar os desenvolvedores a adicionar itens de dívidas de tecnologia à lista de pendências. Dessa forma, eles sentem o menor atrito possível ao sugerir ideias. Em seguida, aplique o mesmo rigor que você normalmente faria ao avaliar o trabalho, o impacto e o risco estimados para priorizar os itens adequadamente.
Em seguida, nas conversas de priorização, peça regularmente aos desenvolvedores que forneçam as estimativas de impacto e trabalho. Em seguida, faça perguntas para ajudá-los a serem rigorosos com isso. Incentive seus outros membros da equipe de desenvolvedores a impulsionar o pensamento. Se são lideranças de tecnologia, apoie-se nelas.
Finalmente, ao resolver, evite ser a pessoa que dá as respostas. Prepare o cenário para que os desenvolvedores pensem em soluções inovadoras, que não estejam apenas na vanguarda do que está disponível, mas que também sejam escaláveis para evitar retrabalho significativo no futuro.
Conversas regulares
Uma coisa comum por aí é tornar a dívida técnica parte de todas as conversas que você tem com sua equipe de Engenharia.
O problema com isso é que é mais uma exibição do que uma praticidade. Os melhores PMs ajudam as equipes de Engenharia a se concentrarem na coisa certa em cada reunião. Não traga tudo à tona em todas as reuniões.
Em vez disso, crie um espaço seguro e uma cadência para discussão, na qual as pessoas estejam preparadas para revisar e discutir itens de débito técnico. Isso ajuda a tornar a dívida técnica um cidadão de primeira classe no processo de ideação e descoberta, semelhante aos recursos para os usuários. Faça perguntas curiosas. Siga os tópicos até os detalhes para entender o que realmente está causando o problema.
Quando você está assumindo uma dívida de tecnologia, entenda quais são os impeditivos. Pergunte qual atalho salva a equipe agora. Acompanhe o impacto estimado para resolver o problema posteriormente. Essas informações permitem que você tome melhores decisões.
Seja um advogado
Nas conversas, seja o PM que se importa. Mergulhe nos detalhes para entendê-los. Em seguida, acompanhe as conversas implementando as outras estratégias para que as ações respaldem suas palavras. Isso ajuda os desenvolvedores a considerá-lo um “defensor” de ótimos sistemas de tecnologia e dívidas técnicas mínimas. Com o tempo, os desenvolvedores vão querer trabalhar em sua equipe.
Além disso, aperte 2 vezes a tecla do Discovery. Assim como você entrevista os usuários por seus problemas, entreviste os desenvolvedores. Em vez de ir para o que os desenvolvedores acham que deveriam construir, comece com o problema. Isso irá ajudá-los a esclarecer seu próprio pensamento também.
Por fim, em conversas com diretores e lideranças de produtos, seja o defensor do trabalho com débito técnico. Em todos os lugares em que sua equipe de desenvolvimento não está, cumpra a missão de ter menos dívidas de tecnologia. Às vezes, isso pode significar criar iniciativas de toda a empresa com executivos. Outras vezes, pode significar ajudar a criar partes protegidas do tempo do desenvolvedor para esse tipo de trabalho.
Avaliar e direcione a equipe sobre isso
Uma das melhores maneiras de otimizar algo é medi-lo. Ao colocar um KPI na dívida de tecnologia, você ajuda a equipe a medir e melhorar seus processos para lidar com a dívida de tecnologia. Isso pode não apenas ser uma maneira única de o PM agregar valor, mas também motivar os membros da equipe. Todo mundo gosta de alcançar um número com um sucesso esmagador.
Para garantir esse compromisso com a métrica, faça dela uma meta de equipe. Coloque em OKRs oficiais se fizer sentido. Esse tipo de objetivo específico ajuda todos a se unirem em torno da causa e evita que os projetos descarrilem no meio do caminho.
Priorize
Com um objetivo específico de KPI em mente, priorizar o trabalho se torna um pouco mais fácil. Mas mesmo que o trabalho não seja um KPI comprometido comunicado aos executivos, certifique-se de que é o PM quem prioriza o trabalho.
Muitos PMs incluem uma certa porção de tempo ou sprints para se concentrar na dívida de tecnologia. Esta pode ser a solução certa para a sua equipa. Considere se eles se sentem à vontade para entrar e sair do trabalho de débito técnico ou preferem um fluxo constante.
Mantenha a priorização
Um dos desafios mais difíceis é não perseguir o próximo objetivo brilhante. Executivos, vendas e outros stakeholders constantemente apresentam opiniões sobre o que a equipe constrói. Bem, o que a equipe deve cortar para se adequar ao novo recurso? A dívida tecnológica é uma das primeiras coisas a surgir.
Por isso é tão importante, então, que o PM use o armamento de suas conversas regulares. Os PMs devem falar sobre os detalhes específicos dos problemas e por que o impacto estimado é do jeito que é.
Evitar que se acumule
Finalmente, pare de criar dívidas técnicas! Primeiro, evite que isso se acumule ajudando a equipe de desenvolvimento a planejar cargas de trabalho razoáveis para sprints. Todo desenvolvedor precisará criar dívida de tecnologia se for solicitado que ele faça o trabalho de um mês em 2 semanas. Mas se os pedidos forem razoáveis, menos dívida de tecnologia se acumulará.
Mas, se parece que as coisas podem estar se acumulando, aja rapidamente. Considere ter sprints completos e dedicados a eliminar os problemas, se necessário. No Google, não era incomum ver as equipes passarem um mês inteiro do ano em escalabilidade e dívida de tecnologia.
Personalizando seu estilo
Nenhuma dessas estratégias ou táticas deve ser aplicada sem considerar seu contexto. A dívida de tecnologia é um tópico grande e variado, e o papel dos PMs na formação varia de empresa para empresa.
Em algumas empresas, líderes de tecnologia e arquitetos vivem para identificar e priorizar o trabalho. Em outros, é mais o papel do PM. Nesse caso, o processo descrito acima pode ser particularmente útil.
Independentemente do tipo de empresa e da função do PM, cada equipe de PM e dev terá uma situação diferente em cada empresa. Para ser um ótimo PM, a chave é identificar as motivações dos stakeholders e trabalhar com eles.
- Por que estamos gerando dívida de tecnologia?
- Os engenheiros acham que estamos lidando com a dívida de tecnologia o suficiente?
- Estamos priorizando a dívida de tecnologia o suficiente?
Fazer perguntas como essas ajudará você a desenvolver uma estratégia para sua equipe. Talvez sua equipe sinta que está fazendo o suficiente com a dívida de tecnologia, mas precisa ser pressionada a pensar maior. Em outros casos, eles podem estar priorizando demais as iniciativas de infraestrutura.
Determine onde a equipe está e para onde ela precisa ir. Algumas dessas estratégias podem ajudar ao longo do caminho.
Rumo à riqueza tecnológica
O inverso do débito técnico é a riqueza tecnológica. Essa é a ideia de priorizar estrategicamente a dívida de tecnologia, bem como construir sistemas e capacidades com antecedência, para habilitar as capacidades de tecnologia como uma vantagem estratégica no mercado. Como PM (especialmente PM de plataforma) você pode considerar ajudar sua equipe a avançar em direção à riqueza tecnológica.
Por exemplo, a equipe pode decidir que construir uma plataforma de experimentação é uma boa decisão para a escala com a qual experimentará nos próximos dois anos. Uma ferramenta simples como o Optimizely pode funcionar para algumas partes do funil e para uma pequena parte dos usuários no curto prazo. Mas a equipe decide construir uma plataforma interna para permitir uma cultura de experimentação rápida. Esta é uma mentalidade rica em tecnologia.
Para habilitar uma mentalidade de riqueza em tecnologia, comece especificando a dívida de tecnologia da qual você está falando. Em seguida, use as ferramentas deste artigo – desde rastreá-lo no mesmo espaço até capacitar os desenvolvedores e o resto – para transformar sua equipe em uma que use conversas de débito técnico para expandir os negócios.
Domine Product Management
Quer ficar por dentro da gestão de produtos digitais e dominar as melhores práticas do mercado?
Aqui na PM3 nós temos como visão tornar o mercado brasileiro de Tecnologia a referência mundial em Product Management. E para fazer isso acontecer, nós levamos a nossa missão a sério: formar os melhores profissionais da área de Produto.
Por isso, reunimos especialistas em Produto para compartilhar cases reais do nosso mercado no conteúdo do Curso de Product Management. Dessa forma, você receberá uma formação completa e no nosso contexto, com exemplos de quem realmente faz produto no Brasil.
Acesse gratuitamente a ementa completa e saiba mais!
Leia também:
