6 tipos de dívida técnica: dívida técnica não é um fardo, mas uma ferramenta estratégica para o sucesso

xguru · 2023-03-20T11:21:01+09:00

O que é necessário para enxergar a dívida técnica como uma ferramenta estratégica Reconhecer e resolver suposições negativas sobre dívida técnica Classificar os 6 tipos de dívida técnica e responder de forma diferente a cada um Entender a escala da dívida técnica Como decidir a prioridade da dívida técnica How to Not Manage Tech Debt 4 suposições que levam a uma má gestão da dívida técnica Suposição #1: dívida técnica = algo ruim Nem toda dívida técnica deve ser classificada como "ruim" É muito melhor nomear cada uma, medir o tamanho da dor e classificar as dívidas técnicas Existem dívidas técnicas que vale a pena ter, e toda equipe deveria ter alguma dívida técnica O caso do Twitter, que teve "boa dívida técnica": usou storage público e depois desenvolveu seu próprio banco de dados distribuído, o Manhattan Perguntas para responder à suposição de que "dívida técnica = algo ruim" O que ganhamos se assumirmos essa dívida técnica agora e resolvermos isso no próximo mês? Em que situação a liderança se importaria com essa dívida técnica? Como devemos apresentar informações que ajudem o CTO a fazer o pitch para a liderança? Como essa iniciativa pode se conectar à visão maior da empresa ou à direção estratégica? Suposição #2: toda dívida técnica = trabalho complexo Assim como em qualquer trabalho difícil, existem várias formas de lidar com tarefas complexas, e isso também vale para a dívida técnica Especialmente no caso de dívida técnica, existe uma forma de abordar trabalho Defined/Undefined (definido/indefinido) Defined = o trabalho tem começo e fim Undefined = o trabalho tem começo, mas o fim não é claro Para responder à suposição de que dívida técnica = complexidade Deixar claro se a dívida técnica em questão é Defined ou Undefined No caso de Defined, entender o tempo estimado para concluir o trabalho e deixar um pequeno buffer No caso de Undefined, listar as partes pouco claras e comunicá-las aos stakeholders para que entendam por que o trabalho é complexo e não tem uma data de término clara, pedindo opinião sobre a melhor forma de avançar Dividir dívida técnica Undefined em partes menores e mais fáceis de executar para reduzir a complexidade Quando se transforma um trabalho grande e complexo em tarefas menores, ainda complexas mas executáveis, a equipe pode se sentir mais motivada a resolver parte da dívida técnica dentro de um sprint ou trimestre Perguntas para responder à suposição de que "dívida técnica = trabalho complexo" Que suposições erradas existem sobre o sistema? Se trouxermos alguém experiente ou familiarizado com essa área, quais perguntas precisamos fazer sem falta? Nossa equipe tem as pessoas e o conhecimento adequados para executar esse trabalho? Se não, como devemos pensar em redistribuir informação e quando seria o momento ideal para resolver isso? Qual é a melhor forma de explicar a complexidade dessa dívida técnica para alguém que não a entende de forma alguma? Suposição #3: dívida técnica ≠ trabalho de produto As organizações costumam ter clareza sobre como trabalho de produto melhora métricas da empresa Normalmente, a dívida técnica fica fora dessa conversa Resolver dívida técnica no momento certo pode ser importante para impulsionar o crescimento da empresa, mesmo que isso não seja quantificável imediatamente Para responder à suposição de que dívida técnica ≠ trabalho de produto Mesmo que uma área específica de dívida técnica não esteja diretamente ligada a métricas, pensar de forma ampla em como isso pode ajudar a experiência do usuário ou do produto Em vez de enfatizar só benefícios técnicos, dar o mesmo peso aos benefícios para usuário e produto facilita que outras pessoas entendam por que a equipe deveria se importar com esse trabalho Reservar tempo para garantir que liderança de negócio e liderança técnica estejam alinhadas Perguntas para responder à suposição de que "dívida técnica ≠ trabalho de produto" Qual é a razão mais importante para fazer esse trabalho agora? Quem precisa entender o impacto desse trabalho? Por que essa pessoa deveria se importar com isso? O que estou tentando dizer? Isso está alinhado com o que o stakeholder quer ouvir? Se não, como posso resolver o problema dele? O que eu ou a equipe consideramos um resultado razoável vs. excelente? Estamos prometendo demais em relação aos resultados? Dá para nivelar as expectativas separando o que seria um resultado excelente do que seria um bom resultado? Suposição #4: dor individual = dor organizacional Engenheiros próximos da dívida técnica costumam repetir regularmente que lidar com ela é doloroso em nível pessoal Para a pessoa pode parecer o fim do mundo, mas o restante da organização não sente a mesma dor Isso é comum em pessoas no início da carreira e normalmente vem da falta de contexto estratégico mais amplo Para responder à suposição de que dor individual = dor organizacional Ao encontrar uma área de dívida técnica com alta prioridade, parar um pouco para avaliar se isso é uma dor em nível individual ou organizacional Em geral, problemas em nível organizacional afetam diretamente clientes ou negócio de alguma forma Tentar pensar pela perspectiva de alguém com mais contexto organizacional do que você. Também pode ser útil explicar isso para alguém de outro time Perguntas para responder à suposição de que "dor individual = dor organizacional" Quantos times se beneficiam ao classificar e resolver essa dívida técnica? Quando a empresa reconheceu ou recompensou alguém por assumir um trabalho de dívida técnica? Que tipo de dívida técnica era e por que isso era necessário naquele momento? Dá para falar sobre como essa pessoa posicionou esse trabalho? Meu engineering manager entende o valor do trabalho de dívida técnica? Ele vai defender minha contribuição nesse trabalho durante a performance review? 6 tipos de dívida técnica Maintenance debt (dívida de manutenção) Quando a equipe não consegue acompanhar as atualizações da tecnologia Também inclui não remover dead code após início de experimento / rollout de feature / rollback de deploy, além de não atualizar bibliotecas, comentar código de contexto ou documentar decisões de implementação Ex.) A equipe experimentou a funcionalidade "log in with Spotify" e, quando cancelou, não removeu o código correspondente Developer efficiency debt (dívida de eficiência de desenvolvedores) Quando a empresa não tem testes, monitoramento e sistema de alertas adequados para o produto É um tipo comum de dívida em que o workflow de engenharia é muito ineficiente, deploy/build leva horas ou dias, e desenvolvedores não conseguem detectar problemas técnicos antes de chegar à produção Ex.) A organização cresceu de 15 para 50 pessoas em 1 ano, com experimentos demais acontecendo ao mesmo tempo. Releases para corrigir bugs encontrados em produção estão atrasadas em 2 ou 3 ciclos. Novos testes para a experiência de compra acabam ficando para trás Stability debt (dívida de estabilidade) Quando vários tipos de dívida técnica se acumulam e passam a afetar a estabilidade da infraestrutura da organização Em vez de gerenciar on-call de forma preventiva, surgem cenários em que especialistas são chamados depois que o problema acontece, ou o time inteiro entra em on-call Isso é um grande problema para engenheiros e para a equipe do rodízio de on-call, mas para o restante da empresa é difícil até entender e explicar o problema A dívida de estabilidade também afeta a confiabilidade do produto, gerando problemas enfrentados por clientes Ex.) O time mobile tem mais desenvolvedores iOS e por isso prioriza iOS em relação ao app Android. Como resultado, o app Android fica sem guidelines de produto para fluxos importantes para o negócio e ainda carrega código frágil (kryptonite) criado inicialmente por terceiros. Isso faz usuários Android sofrerem crashes ao acessar funcionalidades antigas, piorando a nota na Google Play Security debt (dívida de segurança) Quando se usa uma stack com vulnerabilidades de segurança, como brute force, vazamento de dados etc. Muitas organizações acumulam dívida de segurança porque é difícil planejar e avaliar coisas que podem acontecer — ou talvez nunca aconteçam Ex.) Por falhas em processos internos, a empresa não atualizou sistemas a tempo e deixou de aplicar patches para vulnerabilidades conhecidas, causando vazamento de dados pessoais de clientes (de empresas pequenas até casos como o da Equifax, que impactou 140 milhões de pessoas) Technical product debt (dívida técnica de produto) Quando o impacto negativo no produto se torna visível É a dívida mais fácil de identificar e mais conveniente de resolver, porque afeta usuários e todos os times da organização conseguem ver impacto em vendas/receita Ex.) Um usuário leva vários segundos para realizar uma tarefa específica dentro do produto. Isso pode vir de vários tipos de dívida, mas afeta a experiência central do produto Decision debt (dívida de decisão) Quando se paga o custo de uma decisão técnica anterior que estava errada em X% ou que exigiu trade-offs em escopo, tempo ou recursos É a forma mais comum de dívida técnica Ex.) Para um experimento específico no site, a equipe usou uma solução third-party. Depois de alguns anos de enorme crescimento, agora milhões de usuários visitam o site. Como resultado, times de tecnologia, dados e produto sofrem sempre que tentam executar experimentos complexos Isso aconteceu porque o time tomou uma decisão de trade-off entre third-party e solução própria, gerando dívida de decisão. Na época pode ter sido a escolha certa, mas agora os impactos começaram a aparecer Definindo a escala da dívida técnica: Acute vs Systemic Depois de entender os tipos de dívida técnica, é preciso definir a escala do custo para compará-la com o que será ganho Quando o time pergunta "quando vamos ter tempo para trabalhar em dívida técnica?", muitas vezes é difícil saber, em termos de tempo, reflexão e esforço, se isso é pequeno ou grande Dívida técnica Acute (aguda) Dívida técnica relativamente pequena Ex.) Para lançar uma nova funcionalidade, a equipe pulou trabalho para plataformas/navegadores com baixa escala de uso. Se não houver mais nada, isso pode ser adicionado facilmente em 1 dia Dívida técnica Systemic (sistêmica) Dívida técnica de grande a enorme escala Ex.) O CTO/fundador tomou uma decisão sobre o produto (e indiretamente sobre tecnologia) há 5 anos, e a empresa construiu muita coisa em cima disso. Se isso for alterado, vai impactar diversas áreas. Essa dívida técnica não é fácil de resolver e pode levar de meses a anos para ser mudada Priorizando dívida técnica de forma estratégica Uma forma flexível de considerar e avaliar Confidence: qual a probabilidade de isso levar a um problema sério? baixa/alta Time: quando isso vai virar um problema? não urgente/urgente Impact to User: se isso não for feito, haverá problema de velocidade/qualidade que prejudique a experiência do usuário? baixo/alto Sequence: isso atrapalha chegar a um milestone importante? pequeno impacto/bloqueio Accumulated debt: quanta dívida já decidimos acumular? pouca/muita Portfólio estratégico de dívida técnica conforme o estágio de crescimento da empresa Traction: Antes do product-market fit Decisões de engenharia devem privilegiar velocidade em vez de precisão, estabilidade e processo. Grande escala de dívida de eficiência de desenvolvedores Em geral, isso significa escolher frameworks full stack como Django, Rails, PHP etc. para desenvolver rapidamente Inflection: Momento em que surgem sinais de PMF e o produto entra em um loop escalável A equipe percebe que precisa de alguns processos (a dívida de eficiência de desenvolvedores começa a ser resolvida), mas como ainda está ajustando o equilíbrio entre processos internos e experiência do usuário, a dívida técnica de produto aumenta Scale: Período de hyper-growth da empresa Ao encontrar equilíbrio entre práticas/processos internos e experiência do usuário, a dívida técnica de produto e a dívida de eficiência de desenvolvedores começam a cair e se estabilizar Como resultado do crescimento muito rápido, aumentam dívida de segurança, dívida de manutenção e dívida de decisão Há muitas mudanças e ajustes em automação de testes, sistemas de deploy, monitoramento e alertas, logging e instrumentation, ambientes de teste e staging, ETL etc. Expansion: Início da saturation. O negócio se torna mais maduro Por causa da grande quantidade de código antigo e decisões passadas, dívida de manutenção e dívida de decisão continuam aumentando À medida que a equipe busca novas oportunidades de crescimento, a dívida de eficiência de desenvolvedores volta a começar a crescer Dívida técnica de produto, dívida de segurança e dívida de estabilidade estão entrando em equilíbrio após o período anterior Dicas para gerenciar um portfólio de dívida técnica Processos para reduzir a dívida técnica que está sendo criada Embora acumular dívida técnica possa ser estratégico, em alguns casos faz sentido implementar processos desde cedo para evitar que ela seja criada Isso é especialmente verdade nos estágios de Inflection e Scale, em que a dívida de eficiência de desenvolvedores deveria diminuir à medida que mais engenheiros entram Quando a dívida de eficiência de desenvolvedores cai, ela pode ser substituída por aumento de dívida de decisão e dívida de manutenção Exemplos desses processos: revisão de código/PR, padrões de monitoramento, aprovação de QA e revisão técnica/de design Ferramentas para evitar a formação de certos tipos de dívida Investir em ferramentas básicas pode impedir que alguns tipos de dívida se formem Isso é especialmente importante no estágio de Scale para evitar problemas de segurança (dívida de segurança), bugs que afetam a experiência do usuário (dívida técnica de produto) e inconsistência de código (dívida de eficiência de desenvolvedores) Exemplos dessas ferramentas: linter e pipelines de CI/CD Trabalho de sprint para dívida técnica Reactive & Acute Quando a organização chega a uma escala que exige on-call, sprints de on-call devem ser usados para apagar incêndios atuais ou para trabalho reativo ligado à dívida técnica Isso permite que a organização trate itens urgentes de dívida técnica e execute ações reais sobre problemas atuais/passados por meio do time de on-call Permitir on-call para trabalho reativo é especialmente importante nos estágios de Scale/Expansion do crescimento. Tratar dívida técnica urgente permite que outros times criem novas features/produtos e lidem com dívida adicional Trabalho de roadmap para dívida técnica proativa e sistêmica Colocar dívida técnica no roadmap exige alinhamento entre muitos times Exemplos de dívida técnica no roadmap: grandes reescritas, reorganização do sistema de dados de funcionalidades muito usadas por clientes, definição e implementação de alertas para fluxos críticos, migração de sistema de pagamento etc. Como transformar dívida técnica de fardo em ferramenta estratégica A partir da dívida técnica acumulada, a equipe pode tomar decisões estratégicas mais amplas sobre quais iniciativas deve executar Pensar nas suposições comuns sobre dívida técnica que a equipe enfrenta. Você discorda de "dívida técnica = algo ruim" ou "dívida técnica ≠ trabalho de produto"? Está ouvindo colegas que pensam que "dor individual = dor organizacional"? Não usar o termo genérico "dívida técnica". Dar nomes como dívida de manutenção, dívida de eficiência de desenvolvedores, dívida de estabilidade, dívida de segurança, dívida técnica de produto e dívida de decisão Definir a escala da dívida técnica para reduzir ambiguidade. É Acute ou Systemic? Priorizar dívida técnica estrategicamente em comparação com outras áreas da empresa. Definir prioridades com base em vetores como confiança, tempo e impacto para o usuário Evoluir e manter equilibrado o portfólio de dívida técnica conforme as mudanças e demandas do crescimento da empresa

(reforge.com)

47 pontos por xguru 2023-03-20 | 2 comentários | Compartilhar no WhatsApp

O que é necessário para enxergar a dívida técnica como uma ferramenta estratégica
- Reconhecer e resolver suposições negativas sobre dívida técnica
- Classificar os 6 tipos de dívida técnica e responder de forma diferente a cada um
- Entender a escala da dívida técnica
- Como decidir a prioridade da dívida técnica

How to Not Manage Tech Debt

4 suposições que levam a uma má gestão da dívida técnica

Suposição #1: dívida técnica = algo ruim

Nem toda dívida técnica deve ser classificada como "ruim"
É muito melhor nomear cada uma, medir o tamanho da dor e classificar as dívidas técnicas
Existem dívidas técnicas que vale a pena ter, e toda equipe deveria ter alguma dívida técnica
O caso do Twitter, que teve "boa dívida técnica": usou storage público e depois desenvolveu seu próprio banco de dados distribuído, o Manhattan
Perguntas para responder à suposição de que "dívida técnica = algo ruim"
- O que ganhamos se assumirmos essa dívida técnica agora e resolvermos isso no próximo mês?
- Em que situação a liderança se importaria com essa dívida técnica? Como devemos apresentar informações que ajudem o CTO a fazer o pitch para a liderança?
- Como essa iniciativa pode se conectar à visão maior da empresa ou à direção estratégica?

Suposição #2: toda dívida técnica = trabalho complexo

Assim como em qualquer trabalho difícil, existem várias formas de lidar com tarefas complexas, e isso também vale para a dívida técnica
Especialmente no caso de dívida técnica, existe uma forma de abordar trabalho Defined/Undefined (definido/indefinido)
- Defined = o trabalho tem começo e fim
- Undefined = o trabalho tem começo, mas o fim não é claro
Para responder à suposição de que dívida técnica = complexidade
- Deixar claro se a dívida técnica em questão é Defined ou Undefined
  - No caso de Defined, entender o tempo estimado para concluir o trabalho e deixar um pequeno buffer
  - No caso de Undefined, listar as partes pouco claras e comunicá-las aos stakeholders para que entendam por que o trabalho é complexo e não tem uma data de término clara, pedindo opinião sobre a melhor forma de avançar
- Dividir dívida técnica Undefined em partes menores e mais fáceis de executar para reduzir a complexidade
  - Quando se transforma um trabalho grande e complexo em tarefas menores, ainda complexas mas executáveis, a equipe pode se sentir mais motivada a resolver parte da dívida técnica dentro de um sprint ou trimestre
Perguntas para responder à suposição de que "dívida técnica = trabalho complexo"
- Que suposições erradas existem sobre o sistema?
- Se trouxermos alguém experiente ou familiarizado com essa área, quais perguntas precisamos fazer sem falta?
- Nossa equipe tem as pessoas e o conhecimento adequados para executar esse trabalho? Se não, como devemos pensar em redistribuir informação e quando seria o momento ideal para resolver isso?
- Qual é a melhor forma de explicar a complexidade dessa dívida técnica para alguém que não a entende de forma alguma?

Suposição #3: dívida técnica ≠ trabalho de produto

As organizações costumam ter clareza sobre como trabalho de produto melhora métricas da empresa
Normalmente, a dívida técnica fica fora dessa conversa
Resolver dívida técnica no momento certo pode ser importante para impulsionar o crescimento da empresa, mesmo que isso não seja quantificável imediatamente
Para responder à suposição de que dívida técnica ≠ trabalho de produto
- Mesmo que uma área específica de dívida técnica não esteja diretamente ligada a métricas, pensar de forma ampla em como isso pode ajudar a experiência do usuário ou do produto
- Em vez de enfatizar só benefícios técnicos, dar o mesmo peso aos benefícios para usuário e produto facilita que outras pessoas entendam por que a equipe deveria se importar com esse trabalho
- Reservar tempo para garantir que liderança de negócio e liderança técnica estejam alinhadas
Perguntas para responder à suposição de que "dívida técnica ≠ trabalho de produto"
- Qual é a razão mais importante para fazer esse trabalho agora?
- Quem precisa entender o impacto desse trabalho? Por que essa pessoa deveria se importar com isso?
- O que estou tentando dizer? Isso está alinhado com o que o stakeholder quer ouvir? Se não, como posso resolver o problema dele?
- O que eu ou a equipe consideramos um resultado razoável vs. excelente?
- Estamos prometendo demais em relação aos resultados? Dá para nivelar as expectativas separando o que seria um resultado excelente do que seria um bom resultado?

Suposição #4: dor individual = dor organizacional

Engenheiros próximos da dívida técnica costumam repetir regularmente que lidar com ela é doloroso em nível pessoal
Para a pessoa pode parecer o fim do mundo, mas o restante da organização não sente a mesma dor
Isso é comum em pessoas no início da carreira e normalmente vem da falta de contexto estratégico mais amplo
Para responder à suposição de que dor individual = dor organizacional
- Ao encontrar uma área de dívida técnica com alta prioridade, parar um pouco para avaliar se isso é uma dor em nível individual ou organizacional
  Em geral, problemas em nível organizacional afetam diretamente clientes ou negócio de alguma forma
- Tentar pensar pela perspectiva de alguém com mais contexto organizacional do que você. Também pode ser útil explicar isso para alguém de outro time
Perguntas para responder à suposição de que "dor individual = dor organizacional"
- Quantos times se beneficiam ao classificar e resolver essa dívida técnica?
- Quando a empresa reconheceu ou recompensou alguém por assumir um trabalho de dívida técnica? Que tipo de dívida técnica era e por que isso era necessário naquele momento? Dá para falar sobre como essa pessoa posicionou esse trabalho?
- Meu engineering manager entende o valor do trabalho de dívida técnica? Ele vai defender minha contribuição nesse trabalho durante a performance review?