Por Doug Needham, DataOps.live Por Doug Needham, DataOps.live A dívida técnica é um desafio para qualquer equipe digital. sugestões para evitá-la ficam sobrecarregadas ou ignoradas, e é um trato raro conseguir consertar as coisas que sabemos que precisamos consertar. Compreendemos o que sabemos – como a dívida técnica é realmente aterrorizante – talvez eles empurrassem menos quando lutássemos para construir as coisas da maneira certa. Proprietários de dados Proprietários de dados Acho que encontrei uma maneira de contar. Contos de fadas, parábolas e histórias que nossos avós contam podem não ser factuais, mas eles são “verdadeiros”. A corrida perigosa Você queria que seu carro fosse construído com pressa, e aqui está - oh, mas doze parafusos foram deixados depois que o colocamos juntos. Os gerentes de projeto insistiram que esses parafusos particulares podem esperar pela próxima janela de manutenção. A equipe de vendas garante que esses parafusos não são necessários. A equipe de engenharia sabe o que esses parafusos vão segurar juntos.Eles recomendam tomar o tempo para aplicar os parafusos. A corrida vai começar em breve. O relógio está batendo. Você é o motorista. Você estará tomando decisões de vida ou morte a velocidades incríveis em uma pista de corrida projetada para demonstrar as capacidades do seu carro. Há trinta e nove outros carros na linha de partida, cada um com suas próprias equipes de engenharia, vendas e gerenciamento de projetos. Eles têm todas as partes de seus carros mantidos juntos? Quais partes do seu carro não são mantidas juntas da melhor maneira possível? Ao usar este carro e empurrá-lo para o limite, você vai ganhar a corrida, ou acabar com um puddle no turno 3? A moral da história Esta é uma dívida técnica: uma situação de alto risco que poderia ter sido facilmente evitada ouvindo os especialistas. Se você precisa de uma analogia mais rápida, é como a roleta russa, só que você não sabe o número de câmaras, o calibre da bala, quantas balas estão carregadas, ou em que direção a arma está se dirigindo. As partes interessadas não-técnicas às vezes confundem o refactoring com a dívida técnica.É certamente verdade que há momentos em que arquitetos e engenheiros aprendem maneiras melhores de construir algo depois de ter sido construído. Em ambos os casos, as pessoas que realmente fazem as implementações devem ser capazes de decidir o que precisa ser feito.Ter usuários não técnicos a tomar decisões técnicas sobre como construir uma ferramenta é uma receita para o desastre. Quando seu PM ou proprietário de dados lhe pedir para cortar cantos, lembre-os desta história. Pergunte, “Você confia em sua equipe para tomar as decisões certas? Se assim for, então deixe-os ir.” O dever de avisar Os usuários não entendem os riscos quando nos dizem para cortar cantos.Eles não sabem a importância do driver certo, SQL estruturado, atualizar as subrutinas, adicionar um nó ao cluster, ou atualizar para o nível atual do patch e obter um reboot limpo. Você construiu-lhes um carro maravilhoso, mas eles ditaram alguns atalhos que você sabia que precisavam ser corrigidos mais tarde, só que mais tarde nunca veio. Como nós conhecemos os riscos da dívida técnica, temos a responsabilidade de levantar o alarme. Conte-lhes a história da corrida. Lembre-lhes que eles estão sentados naquele carro. Eles são aqueles que lhe disseram para não consertar a coisa que você sabe que precisa consertar. Espero que esta história se torne uma flecha em seu quiver quando um usuário de negócios ou gerente de projeto tenta reverter você arquitetos e engenheiros que sabem que algo precisa ser feito, e precisa ser feito da maneira certa. A escolha das ferramentas que usamos para mitigar o risco de dívida técnica é uma decisão ainda em nossas mãos. Criar uma arquitetura que garanta Você pode ficar nos ombros desta equipe e descansar facilmente à noite, ou tomar o turno 3 a toda velocidade! DataOps.live O gerenciamento de dados é regido Informações.live O gerenciamento de dados é regido
