Como vender uma dívida técnica do ponto de vista DevOps?

Muitas vezes argumenta-se de forma dramática e patética que é melhor não criar dívida técnica. Sim, é melhor sem ele, claro. Mas as consequências ainda podem ser eliminadas.

Refiro-me a dívida técnica como todas as mudanças e melhorias, modificações de infraestrutura e mudanças de processos, mudanças nas estruturas das equipes que visam eliminar lacunas (feitas de forma consciente ou não no âmbito do lançamento de produtos) e funcionalidades que interferem muito ao longo do tempo.

E como essas coisas não podem ser resolvidas sem uma equipe firme e confiante dos departamentos de produção e operações, esta história é diretamente sobre DevOps.

Dívida técnica – de quem é?

Mas primeiro, a raiz do problema – por que estou falando de dívida técnica? Porque estou muito ofendido porque a empresa não reserva tempo para isso. Esse fio vermelho percorre todos os relatórios, encontros e comunicações entre desenvolvedores e operações.

Negócios maus, ruins e terríveis não reservam tempo para trabalhar com dívidas técnicas. Até surge uma pergunta justa: "Eles não precisam de qualidade?" Olhando para o futuro, direi: “Ninguém precisa de qualidade”. Mas revelarei esse pensamento um pouco mais tarde.

Para analisar esta situação, vamos considerar por que as empresas fazem isso conosco. E para obter uma resposta, precisamos pensar em quem é a dívida técnica. Quem é o responsável por isto?

Depois de anos de envolvimento, percebi que éramos como Frodo, que ofereceu um anel a todos. É como: "Ajude-me a carregar esse fardo!" Estamos esperando que as empresas queiram (queiram exatamente) que lidemos com dívidas técnicas. Mas a causa raiz do nosso mal-entendido mútuo com as empresas é que elas nunca vão querer isso.

Para nós, é um desafio de engenharia, uma forma de melhorar a excelência do produto ou até mesmo um mecanismo para aumentar o orgulho pelo nosso produto. Mas para os negócios, é sempre um incômodo, um mal necessário (ou necessidade) no qual você deve dedicar tempo.

Imagine que você entra em um táxi e o motorista pergunta: “Posso parar no lava-jato?”

A empresa nesta situação é um cliente e os desenvolvedores são o motorista de táxi.

• O empresário fica indignado: "Como assim?! Estou pagando o tempo de viagem e você vai ao lava-jato!"

• Ao que o taxista responde razoavelmente: "Você não quer andar em um carro limpo e com cheiro bom?"

• A empresa responde: "Cara, claro que sim! Mas eu espero isso por padrão e não estou pronto para parar no lava-rápido agora só por fazer!"

É assim que as empresas tratam a dívida técnica. É como uma sugestão para passar num lava-rápido. Eu escolho a categoria apropriada ao pedir um táxi para ter um salão limpo ou luxuoso. Na fase de pedido estou disposto a investir nisso, mas passar no lava-rápido não.

Porque, como disse antes, ninguém quer qualidade. Mas é esperado por padrão.

É obrigatório. As empresas não podem resignar-se a não ir à lavagem de carros, e as empresas não podem ir até lá às custas do seu próprio tempo. Então, o que fazemos? Uma empresa é uma locomotiva. Ele precisa de recursos, vendas e clientes. É impossível vender a dívida técnica a uma empresa através do nosso “eu quero” e “eu desejo”. Mas é possível motivar os negócios de outra forma.

Ao longo de minha jornada, formei 3 categorias de motivação empresarial para “comprar” dívida técnica:

• Indiferença "gorda". Quando há um investidor rico, o CEO pode pagar a equipe de desenvolvimento de geeks estranhos. É como, “Bem, deixe-os fazer isso! O principal é fazer o produto, e o espírito de equipe é uau, está tudo bem e seríamos o melhor escritório do mundo”.

  
  

  Na minha opinião, é um estilo livre legal que muitas vezes leva ao desastre porque a dívida técnica exige pragmatismo. Quando não fazemos isso de forma pragmática, criamos um Leviatã de arquitetura pseudo-legal.

• Temer. Este é um dos modelos mais eficazes, difundidos e eficientes de dívida técnica. De que tipo de “querer” podemos falar aqui quando é assustador? É sobre quando algo acontece, como um cliente que saiu devido a uma falha ou hack. E tudo por causa de baixa qualidade, freios ou qualquer outra coisa. Mas vender sem rodeios por medo também é ruim. A especulação com medo funciona contra a confiança. Você precisa vender com cuidado e da forma mais honesta possível.

• Confiar. É quando uma empresa lhe dá o tempo necessário para trabalhar na dívida técnica. A confiança funciona e é preservada apenas quando você é cuidadosamente pequeno em relação à participação total e tão pragmático quanto possível ao aproveitar esse tempo. Caso contrário, a confiança é destruída. Além disso, não acumula. Um processo constante ocorre em ondas: a confiança aumenta e depois desaparece.

A seguir, discutirei minha experiência e o que está funcionando para mim e minha incrível equipe.

Qual é a profundidade da toca do coelho com a dívida técnica?

Quando entrei na nova empresa, há 3 anos, precisava entender o quanto era essa dívida técnica. Eu sabia que existia pelas estatísticas de solicitações, inclusive de empresas e parceiros. Eu precisava descobrir com o que estava lidando em geral.

Este é um primeiro passo normal e obrigatório no trabalho com dívida técnica. Você não deve se apressar em fazer a primeira coisa que encontrar. Você deve analisar a situação como um todo.

Com base no que vi então, presumi que uma das raízes do problema é um grande acoplamento de código. Agora envolvo menos todo mundo nesse processo, mas naquela época reuni toda a equipe de produção para definir quais camadas queríamos enfatizar em nosso conjunto de aplicativos.

Nosso aplicativo tinha pelo menos 80 componentes diferentes (distribuições, não instalações). Depois de descobrir a situação, ela teve que ser resolvida.

Fase 1. Equipes Virtuais

Sendo tão inteligente, tive a ideia de fingir que todos tinham tempo e formar uma equipe virtual em torno de cada componente. Parecia: “Gente, quem vai assumir qual componente? Dêem sugestões de como melhorá-lo”. Mas para manter o foco, formulamos todos juntos os critérios para otimizar a primeira fase:

• Acoplamento solto
• Escalabilidade econômica
• Fácil conexão de novos desenvolvedores (princípios simples e claros: o que exatamente pode ser feito neste componente e o que não pode, além de isolamento de código que não pode ser “tocado” por todos)
• Capacidade de usar uma API externa onde for necessário
• Acessibilidade da pilha de tecnologia proposta
• Otimizações QuickWin em soluções atuais
• Facilidade de monitoramento e solução de problemas
• Princípios de auditoria + pureza de licença
• Princípios de versionamento e obsolescência

É claro que este não era um foco, mas um conjunto de critérios para quase todos os aspectos do desenvolvimento de software. A lista inteira pode ser substituída por uma frase: “Conserte tudo”.

Esta fase terminou num fiasco, no sentido de que simplesmente nada aconteceu. Fizemos muito pouco progresso na implementação de algumas coisas porque eu estava tentando planejá-las por meio de um backlog compartilhado. As tarefas eram incompreensíveis. Eles foram colocados em trabalho manualmente. Rapidamente percebi que era difícil para mim e para a equipe, além de que os conflitos e discussões cresciam constantemente.

Então, passei para a fase 2.

Fase 2. A dívida técnica é minha

Na fase 1, combinei com o CEO da nossa empresa que introduziríamos uma cota de pendências. Gastaríamos 70% em questões comerciais, 15% na eliminação de defeitos e 15% na dívida técnica.

Em segundo lugar, na fase anterior, percebi que se todos são responsáveis por uma questão, ninguém é responsável por essa questão. Esta não é uma declaração turquesa. Eu não gosto disso. Mas o contrário exige um nível muito elevado de maturidade e trabalho em equipe. É por isso que decidi formar um sistema de líderes técnicos.

Mas não nomeei apenas uma pessoa para ser o líder técnico de um componente. Expliquei minhas expectativas tanto quanto possível, defini seu caminho de desenvolvimento e os responsabilizei pela situação da produção. Os especialistas em OPS não estão acordados se o seu componente estiver atrapalhando a produção. É você quem está tentando resolver a situação.

E assim partimos. Existem líderes técnicos (os responsáveis) e uma cota de 15% para dívida técnica (há tempo). Mas como era a realidade no final?

A primeira coisa que encontramos foi que temos FinTech, compliance e segregação de funções, ou seja, eu e o desenvolvimento não temos acesso à produção e não podemos tê-la por definição. E ainda assim eu digo: "Pessoal, vocês são os responsáveis pela situação na produção!"

Dê às pessoas os registros!

Quando você atribui responsabilidades às pessoas, dê-lhes uma ferramenta em suas mãos. E essa foi a primeira coisa que fizemos com os especialistas em OPS, fornecendo registros aos técnicos para que pudessem ver os registros de seus componentes.

E tivemos um esforço realmente colaborativo – nosso primeiro passo em direção ao DevOps, onde operações e desenvolvimento trabalham juntos. A exploração configurou a transferência de logs (Kibana, etc.), enquanto o desenvolvimento teve que garantir que os logs não continham informações confidenciais (dados pessoais, etc.).

5% é considerado sortudo...

A realidade é que apesar da cota de 15%, existem algumas crises empresariais e injeções urgentes em cada sprint porque “O parceiro precisa agora ou vai embora!” É claro que essa dívida técnica é primeiro eliminada do sprint - como resultado, tivemos sprints com 0%.

Também houve sprints com 15%, mas tivemos apenas 5-8% de dívida técnica em média. Este é um grande problema porque um programador não pode saber quanto tempo terá para implementação.

De minha parte, tentei ajudar nessa situação empinando pipa incansavelmente sobre todas as equipes. Aprendemos a coletar métricas detalhadas para cada sprint e observei o sprint no final.

Sprint hacking ocorre quando a cota de dívida técnica é sistematicamente violada. Se a cota não for atingida em um sprint, não significa que tudo está ruim. Na verdade, existem situações diferentes e você precisa ser flexível.

Mas quando isso foi repetido sistematicamente, reuni os especialistas em produção, argumentei e expliquei o quão importante e inaceitável era porque a cota foi acordada. Foi meu trabalho diário mover o processo nesse modelo.

E mudou, mas agora acredito que esta abordagem tem as suas próprias deficiências significativas.

Limitações da abordagem

Os Product Owners estão acostumados com o fato do backlog ser todo deles e todas as tarefas serem coordenadas por eles: “A cota é boa, mas só nós decidimos o que o time vai fazer nessa cota de dívida técnica!”

E quando os desenvolvedores surgiram com tarefas (lembre-se da conectividade forte) como refatorar, eliminar padrões, etc., eles obtiveram uma reação lógica: "O quê?! De que padrão? Do que estamos falando?!"

Como resultado, as tarefas foram substituídas por aquelas que poderiam ser chamadas de dívida técnica, mas que eram condicionalmente benéficas para o fornecedor. Por isso tive que tomar uma postura dura e dizer: “A dívida técnica é minha! E afirmo que ela estará incluída na dívida técnica de cada equipe de produto na cota de dívida técnica de cada sprint”.

É assim que vivíamos. Embora vivêssemos e trabalhássemos normalmente, a desconfiança ficou mais forte. Quando fazemos algo e não contamos a ninguém o que é, e o tempo não é gasto em tarefas de negócios, não fica claro para todos qual resultado trazemos.

Como as estatísticas sobre a utilização das quotas da dívida técnica disparavam, enfrentámos o facto de que não podíamos realizar grandes projectos. Além disso, grandes projetos geralmente exigem diversas equipes. Isso também era impossível porque cada equipe de produto está focada em seu produto e vive de sua realidade. É impossível encaixá-los em um tema complexo.

Além disso, ninguém incluiu operações nos sprints. Eles não têm sprints e pendências como a produção. Eles estão sobrecarregados com tarefas de produção, mas isso não foi incluído nos planos gerais. E quando o desenvolvimento vinha com algo feito dentro desses pequenos pedaços de dívida técnica para ser implementado em produção, isso poderia permanecer nas solicitações do OPS por um bom tempo.

Porque eles realmente não tinham tempo, estavam sobrecarregados com tarefas adicionais e eram impedidos de trabalhar.

Mas apesar dos aspectos negativos desta abordagem, conseguimos bastante.

O que conseguimos com esta abordagem?

Primeiro, aumentamos a massa muscular dos autotestes. Ao redesenhar substancialmente todo o processo de CI, tornámo-lo num processo civilizado do qual não nos envergonhamos.

Em segundo lugar, implementamos com sucesso a luta contra o código espaguete em muitos componentes.

Fizemos modularização e reduzimos clichês. Essas tarefas não podem ser vendidas à empresa, mesmo com medo. Se as lacunas tecnológicas em seu produto contêm esses problemas e você precisa corrigi-los (se existirem, precisam ser resolvidos primeiro), você nem precisa tentar vendê-los. Isso só pode ser feito através do modelo “Dívida técnica – é minha”, somente através de cotas.

Já vi muitas tentativas e tentei fazer diferente na primeira fase. Não deu certo.

Na verdade, trabalhar neste modo não pode durar muito tempo. É uma carta branca limitada que a gestão lhe dá, confiando em você como CTO e líder de equipe.

Fase 3. Projeto Legítimo

Então, iniciamos a fase 3 – um projeto “legítimo” para trabalhar na dívida técnica. A suposição era que estávamos nos afastando de uma cota fechada, planejando através de um backlog de produto comum (ou seja, os proprietários do produto aceitam que esses projetos precisam ser realizados) e indo para uma venda limpa. Para que isso acontecesse, fizemos duas coisas:

• Reduzi ao máximo o âmbito do trabalho que começámos a realizar no âmbito deste projecto.

• Formei expectativas concretas sobre o que lutaremos na produção. Foi uma rejeição total do idealismo porque as nossas tarefas deveriam ser tão pragmáticas quanto possível, compreensíveis e úteis para o serviço do ponto de vista empresarial.

Um ponto importante é que temos uma certa ilusão de que estamos tentando calcular o valor comercial da dívida técnica, embora isso raramente seja possível. E se ainda puder ser calculado, então temos uma dívida técnica de pesadelo!

O valor positivo funciona melhor para os negócios do que o valor negativo. Se você disser: “Este cliente vai embora. Ele traz muito dinheiro”, então, até que ele vá embora, não funcionará. Não é um valor comercial. Além disso, a cultura de trabalhar com riscos ainda não é muito elevada, por isso a modalidade é: “Sem perdas até que eles saiam”.

Também não é necessário mostrar valor comercial. Onde você pode mostrar, mas pode mostrar o valor tecnológico, só que deve ser calculado.

Guia sobre como vender dívida técnica

Aqui está todo o fluxo de trabalho desta fase de venda de dívida técnica.

Escolha uma área de foco (apenas uma)

Como isso é vender pelo medo, escolha uma área que realmente afete o seu negócio. As áreas podem ser diferentes: disponibilidade, velocidade de retrabalho, segurança de testes e experimentos A/B e custo de retrabalho. Há um grande número de áreas e tópicos.

No meu caso, optei pela acessibilidade porque ela estava no radar do negócio e teve algum impacto no nosso atendimento. É vital não se espalhar e escolher apenas um tema.

Faça análise integral

Analisei as estatísticas de disponibilidade e incidentes do ano e analisei detalhadamente todos os postmortems de todas as situações ocorridas ao longo do ano. Depois disso, formei um entendimento de alto nível sobre o que precisamos trabalhar tanto quanto tecnicamente possível, mas novamente - substantivamente.

A primeira regra da disponibilidade não é tentar construir um sistema que estará sempre disponível, mas sim estar pronto quando ocorrer um incidente. É isso que temos que garantir.

A segunda questão e regra básica de disponibilidade é o acordo de degradação: algo está prestes a acontecer algum dia, e você deve estar preparado para preservar seu serviço, talvez ao custo de abrir mão de alguma funcionalidade que você fornece. Este acordo tem de ser mantido, inclusive a nível do programa.

A terceira questão diz respeito à monitorização e à observabilidade. Esta é a rápida localização das fontes de incidentes e o tempo de detecção de resposta. Se você tiver muitos testes instáveis, terá que parar de confiar no seu monitoramento. Se seus testes de produção tiverem instruções para reações do service desk, como "Se não sair em 5 minutos, me ligue" - você não está monitorando a situação da produção. O teste deve ser o mais inequívoco possível: "Isso mostra - significa que há problemas em algum lugar, vamos lá!"

Faça análise componente por componente

Para isso, formamos exatamente o que faremos para cada direção e componente. Queremos dizer para onde iremos arrastar a malha de serviço, como iremos agitar o monitoramento e com base em quê. Aqui listamos cerca de 15%, mas na verdade há muitas melhorias no programa.

Já explicamos tudo, mas ainda não é comercializável. Para sair e mostrar abertamente agora, fizemos o seguinte para cada projeto desta fase.

Formular indicadores substantivos e quantitativos

Temos muito medo dos indicadores quantitativos: como podemos medir a qualidade do trabalho dos desenvolvedores em indicadores quantitativos? Temos muitos argumentos contra os indicadores quantitativos, mas não devemos enfrentá-los de frente.

O valor não deve ser considerado apenas como valor comercial. Eles podem ser formulados, por exemplo, como “não mais do que X falsos positivos”.

Você pode listar um conjunto específico de componentes para os quais é fundamental fornecer versões canário ou a capacidade de garantir a reversão garantida de patches. A disponibilidade global deveria, evidentemente, ser um indicador quantitativo. É obrigatório.

Defesa dos Projetos

Com esse conjunto de projetos pragmáticos, as métricas mais claras possíveis e os resultados que precisamos alcançar, eu disse: "Gente, preciso de uma cota de dívida técnica. Preciso que vocês incluam esses projetos no seu pool para acelerá-los para que eles entrar no planejamento geral em uma base totalmente legal, juntamente com os objetivos de negócios."

Foi ouvido, fizemos e funcionou. Acho que é como o vídeo de como desenhar uma coruja: “Desenhe uma forma oval e dois traços”. No final - mágica - você ganha uma coruja! Mas toda a mágica é que você tem que acertar todo esse projeto e levá-lo até o fim.

Não apenas para fazer algumas coisas nesse sentido, mas para levar ao resultado. Ou seja, chegar aos indicadores quantitativos declarados e mostrá-los. Este abismo não pode ser saltado 95% das vezes. Deve ser saltado completamente.

Vantagens da abordagem

Então começamos a pular (sobre o abismo). Estamos fazendo isso com sucesso. Agora, estamos na segunda rodada deste projeto. Ou seja, arrastamos o primeiro conjunto de projetos e concordamos com o segundo conjunto de projetos. O que mudou?

Aumentando a confiança

A confiança aumenta poderosamente através da abertura se mostrarmos métricas reais e quantificáveis. Mas a verdade é que a venda técnica de dívida surge através do medo. Esta etapa não pode ser evitada. Mas você também não precisa ter medo ou vergonha disso. O principal não é especular sobre o medo, mas sim analisá-lo realmente, como demonstrei em diferentes fases (análise integral, análise componente por componente).

Fazendo grandes projetos

Como agora são projetos legitimados, podemos sincronizar as equipes e realizar projetos realmente grandes. Alguns projetos foram feitos sequencialmente de sprint a sprint. Somos acompanhados regularmente (uma vez por semana) dentro desse projeto pela composição da equipe de tecnologia e entendemos quem está onde (em que fase).

Esta informação é tão aberta e transparente quanto possível. O andamento dos projetos e o status atual são publicados e disponibilizados aos proprietários do produto (e a qualquer pessoa que queira vê-lo).

Operadores de OPS no Projeto

Mais importante ainda, percebemos que tínhamos muitas coisas para redesenhar na infraestrutura e no processo de implementação. Os OPS'ers foram explicitamente incluídos neste projeto.

Na minha opinião, isso é mais DevOps do que Kubernetes e Docker quando os profissionais de OPS discutem com os desenvolvedores como alterar a arquitetura de um componente, e os desenvolvedores discutem com os profissionais de OPS a melhor forma de alterar a infraestrutura.

Por que não fiz isso imediatamente?

Aqui voltamos ao que eu estava falando no final da fase 2: não teria funcionado antes. Porque o que fizemos na Fase 2 (código espaguete que redesenhamos, o fortalecimento dos testes e o redesenho dos processos de CI) teria sido impossível de vender para a empresa em relação a métricas mensuráveis.

Essa situação não foi mapeada para nenhum medo específico, e nosso argumento padrão, "Estamos demorando muito para codificar porque o código espaguete" - ninguém no ramo escuta. Portanto, não teríamos sido capazes de arrastar essa abordagem.

Do meu ponto de vista, se você tem uma plataforma tecnológica que exige um retrabalho infraestrutural tão profundo, não pode evitar a fase 2.

Você tem que ir em frente, mas tem que estar pronto não apenas para flutuar como uma pipa o tempo todo, mas também para fechar esta loja com rapidez suficiente para não perder a confiança em sua empresa.