Como tratar e priorizar itens técnicos?

Meu time tem demandas técnicas e histórias para entregar para o cliente. O que fazer? O Product Owner (PO) deve priorizá-las? O PO precisa ser técnico? Costuma ser um dilema e muitas pessoas têm um grande desafio com isso. Já vi soluções bem interessantes e algumas que causaram disfunções piores do que o problema que queriam resolver.

Este artigo não é um estudo científico aprofundado, mas uma observação do que encontrei nas empresas por onde passei. Aqui estou utilizando a definição de Product Owner (PO) segundo o Scrum Guide e que você pode entender melhor conhecendo mais a fundo o papel de PO.

Outro ponto importante é que quero separar itens/demandas técnicas dos itens de valor. Este último é um incremento do produto ou serviço que o time entrega para o usuário, cliente ou consumidor. Normalmente, mas não obrigatoriamente, ele é descrito no formato de História de Usuário (User Story).

Já uma demanda técnica é um item que o cliente não percebe que está ali, porém a função dele é habilitar que o time crie os itens de valor. Imagine uma casa. Os itens de valor seriam: sala, quarto, cozinha, banheiro etc. Os itens técnicos estão lá, mas as pessoas não veem e não pensam neles a maior parte do tempo: instalação elétrica, instalação hidráulica, tubulação de gás, exaustores, entre outros.

Demandas Técnicas, uma realidade

Temos que encarar a verdade. Todo processo evolutivo deixa uma marca que precisa ser tratada. Nos humanos são os dentes de siso e o apêndice. Nos produtos são aqueles itens que têm que ser atualizados para evitar que o produto não desmorone. Normalmente eles se relacionam a:

• Arquitetura
• Defasagem Tecnológica
• Defeitos
• Design
• Documentação
• Infraestrutura
• Performance
• Qualidade
• Segurança

Essa não é uma lista exaustiva, mas no geral as demandas técnicas rodam nessas categorias. E qual o problema de deixarmos essas demandas acumularem?

Nesse caso, elas costumam atender pelo nome de…

Dívidas Técnicas

Todo passivo técnico que não é “pago” se acumula e se torna uma dívida. E o passivo técnico tem um comportamento de dívida. Se não for “paga”, em algum momento poderá se tornar impagável. É fácil perceber que chegamos nesse ponto quando o time fala que é mais fácil começar um produto do zero do que mexer no que temos hoje.

Mas, atenção, pois há uma confusão que as pessoas fazem ao chamar as dívidas técnicas de débito técnico. Essa confusão acontece pela tradução do termo Technical Debt do inglês para português. Debt é igual a Dívida. Vejamos a definição do dicionário Merriam-webster:

debt (noun)

algo devido; obrigação; um estado de obrigação de pagar ou reembolsar alguém ou algo em troca de algo recebido; um estado de dever. Logo, utilize a nomenclatura correta com toda a carga negativa que ela traz.

A seguir, eu dou três dicas que podem servir para identificar se a dívida está aumentando e o quanto está aumentando.

Dica 1) Meça o lead time do time

Há uma expectativa para que o lead time caia ao longo do tempo. São as mesmas pessoas, lidando com as mesmas tecnologias e resolvendo os mesmos problemas.

Logo, quanto mais tempo juntos, melhor eles ficam e maior a performance (menor lead time). Mas caso o desempenho esteja caindo (lead time aumentando), pode ser um indício de que a construção está ficando difícil. Investigue.

Dica 2) Quantifique os problemas comunicados pelo cliente

Outra expectativa que temos com times longevos trabalhando em um produto ou produtos similares é que a qualidade do produto esteja em constante evolução. No entanto, observe: caso os clientes estejam abrindo muitos chamados, reclamações ou pedindo correções, pode ser um sinal de que a dívida está grande. Verifique.

Dica 3) “Precisamos de uma sprint de correção” 

Como diria o saudoso Padre Quevedo: “Isso non ecziste (sic)”. Se o time precisa de sprints para corrigir defeitos é um sinal de que a situação está fincando bem crítica. Investigue imediatamente.

Faça boas perguntas para saber o quanto o time domina e se preocupa com algum assunto. 

Por exemplo: “Pessoal, se um hacker tentar fazer um ataque ao nosso produto, ele conseguiria entrar com facilidade ou nós temos mecanismos para bloqueá-lo?” Se a resposta for: “Sei lá!”, “Acho que sim”, “Isso é resolvido pelo pessoal do outro time”, não precisa investigar.

E preocupe-se! Alguns itens técnicos como segurança, design e documentação, não produzem um resultado tão direto quanto outros, como defeitos e defasagem tecnológica. Segurança, por exemplo, é um que dificilmente será percebido até ser tarde demais.

Nem toda demanda técnica é uma dívida

Tenha atenção também porque nem toda demanda técnica precisa ser uma dívida. Pode ser uma evolução de tecnologia, o aperfeiçoamento de uma técnica ou o experimento de um novo componente etc. Entretanto, cuidado! O que não é uma dívida técnica hoje poderá ser amanhã.

“Beleza Avelino. Já entendi que tenho que tratar esses itens técnicos, mas como?” Vou apresentar as soluções que encontrei, das menos eficientes para as que deram melhores resultados.

Um PO Técnico e um PO de Produto, cada um com o seu backlog

Esse deixa o time louco. Dois responsáveis, cada um puxando a corda para o seu lado e a corda são os outros membros do time. São duas pessoas com prioridades distintas e que mais cedo ou mais tarde entram em conflito ou largam o conflito para as outras pessoas do time resolverem.  Cada um acredita que “sua parte” é mais importante do que a outra e a guerra torna-se inevitável. Evite isso ao máximo!

Atenção: muitas das vezes o PO Técnico atende por outro nome, como Líder Técnico, Arquiteto de Solução, entre outros. O pessoal também gosta muito de colocar esse nome em inglês. Fica Chique. 😄

Um PO Técnico e um PO de Produto com um Backlog

É uma situação menos ruim do que a situação acima, mas ainda é um problema. Embora agora exista um único backlog, ainda temos o fator humano. Na prática eles ainda brigam por prioridade e em breve eles tentarão dividir o backlog. Como já diz o ditado popular: “Um cachorro com dois donos morre porque ou come demais ou passa fome”. Aqui pelo menos a briga acontece sobre um artefato, mas as discussões costumam ser mais brutais. Evite.

Um PO e em Backlog

Essa é a melhor decisão que encontrei até o momento. Um único Dono/Dona do Produto com um único backlog para esse produto. Você pode até argumentar que isso é bíblico. 

“Ninguém pode servir a dois senhores; pois odiará a um e amará o outro, ou se dedicará a um e desprezará o outro. “.

Mateus 6.24a

O PO pode encaixar demanda Técnica no Backlog? 

Alguns dirão que não, mas eu acredito que isso irá retirar um grande peso da vida dos desenvolvedores e do PO. Além disso, deixará as discussões mais maduras e transparentes. Muitas das vezes queremos esconder os itens técnicos debaixo de itens de valor. Isso é muito ruim porque ficamos em discussões intermináveis e esforço mutante. 

O PO fala: “Galera, a prioridade é entregarmos os itens A, B e C. Qual o esforço para eles?”. Os desenvolvedores respondem o esforço estimado A = Grande, B = Pequeno e C = Pequeno. O PO então fala: “Então vamos inverter para melhorar o RoI.  A ordem será B, C, A”. Os desenvolvedores então dizem: “Nesse caso B = Grande, C = Pequeno e A = Médio”. 

É provável que o primeiro item da lista tenha uma carga técnica escondida que é fundamental para criar qualquer um dos itens A, B e C. Por isso o esforço estimado é mutante. Não seria mais transparente retirar essa carga técnica e deixar claro para todos o que está acontecendo?

No caso, temos um item técnico T que precisamos fazer antes de qualquer um deles. Assim, temos os seguintes esforços: T = Grande, A = Pequeno, B = Pequeno e C = Pequeno. Isso facilita muito a vida do PO que sabe que sem T não haverá A, B e C e agora ele pode priorizar normalmente pelo item que tem o melhor RoI. 

O PO precisa então ser técnico? 

Não necessariamente. Os desenvolvedores devem chegar ao PO e comunicar a demanda interna que eles perceberam. Não apenas falar do problema, mas também das consequências caso aquela demanda não seja atendida. 

Formato de História

Se desejarem, é até possível descrever essa demanda técnica em formato de história. Por exemplo: Eu, enquanto desenvolvedor, desejo atualizar o serviço XPTO para melhorar a produtividade da construção do produto. Assim temos todos os elementos importantes da história: pessoa impactada, proposta de solução e motivador. 

Componentes da História

Você pode até criar uma métrica para avaliar se o item técnico produziu a mudança esperada. No caso, uma boa métrica seria: reduzir o lead time ou o tempo do clico de desenvolvimento.

Busque 100% de Transparência. Não chame esse item técnico de História de Usuário porque história de usuário deve ser entregue para o usuário (cliente ou consumidor). Compare os iguais com os iguais, mas não os desiguais com os desiguais.

Há algumas nomenclaturas que você pode utilizar. Se estamos avaliando algo novo com o objetivo de assimilá-lo no projeto, podemos chamar pelo nome dado pelo eXtreme Programming (XP): Spike. Se estamos corrigindo um erro, podemos chamá-lo de Correção de Erro. Deixe claro que aquele item não entrega valor para o cliente, pois a intenção dele é apenas habilitar o produto a continuar gerando bons resultados. 

Já vi pessoas tentando justificar itens técnicos com resultados de eficácia (financeira, satisfação do cliente etc.). Não “force a barra”. O que não tem esse tipo de justificativa, não precisa desse tipo de justificativa. Fica uma conversa de achismos e “valores” indiretos que não é crível.

Por exemplo: “Se não mudarmos a versão do Java vamos deixar de ganhar dinheiro”. A pergunta que se ouve depois é: “Quanto?” Aí começa a peleja, as gaguejadas e as pessoas ficando com cara de interrogação. Seja sempre sincero. Se o que ganhamos atualizando a versão do Java for performance de desenvolvimento, essa é a justificativa. Se for menos risco de segurança, essa também é a justificativa. Faz parte da saúde do produto aprimorar a excelência técnica dele.

Tente escrever os itens técnicos em um formato que o cliente consiga entender.

Um problema comum é que muitas vezes os times não percebem que os itens técnicos podem ser percebidos pelos clientes e podem de fato entregar valor para ele. Por exemplo. Digamos que pessoas responsáveis pela Administração de Dados percebam que algumas consultas ao banco de dados estão muito lentas. Eles podem escrever com uma linguagem técnica se colocando no lugar da pessoa impactada.

Por exemplo: Eu, enquanto Responsável pela Administração de Dados desejo aumentar a performance da consulta XPTO para que ela não consuma os recursos do meu servidor de banco de dados.

Compreensível, mas veja que lentidão de uma consulta, relatório ou funcionalidade é perceptível pelo cliente e impacta na satisfação dele com o uso do produto. Que tal escrever da seguinte forma: Eu, enquanto comprador, desejo receber respostas mais rápidas da consulta XPTO para que eu não desista de realizar a compra.

Atendemos todos os requisitos apresentados na Tabela 1 e podemos medir: Qual a taxa de abandono de carrinho depois de melhorarmos a performance da consulta?

Outro exemplo: Eu, enquanto responsável pela segurança do software, desejo avaliar meu código com o OWASP ZAP para verificar o quão seguro é o meu sistema. Que tal:  Eu, enquanto CEO, desejo que o sistema XYZ seja seguro o suficiente para que não comprometa a imagem da minha empresa.

Priorizando os itens

Concluímos então que no nosso backlog há um conjunto de itens que entregam valor para o cliente e um conjunto de itens técnicos que não entregam valor, mas a habilitam. Como priorizar coisas diferentes? Repito a dica: compare os iguais com os iguais, mas não os desiguais com os desiguais. Imagine que são coisas distintas. 

O time tem capacidade limitada. Não adianta tentar fazer tudo ao mesmo tempo, logo é necessário identificar qual a maior necessidade do momento e avaliar qual o percentual de esforço que o time deseja conceder para cada tipo de serviço. Por exemplo, em cada Sprint queremos que 70% dos itens sejam entrega de valor e 30% itens técnicos. Caso o time não utilize Sprints, dos 5 itens que priorizamos, 4 são itens de valor e 1 é item técnico.

Digamos que o time que tem o backlog apresentado na figura acima fez boas entregas. O cliente está satisfeito e o produto gera resultados. Todavia há dívidas que, se não forem pagas, prejudicarão a evolução do produto. É um caso em que o percentual de itens técnicos poderá ser superior ao percentual dos itens de valor. 

Agora, caso o time esteja no início do produto, poucas entregas ou cliente insatisfeito, então o percentual dos itens de valor deverá ser maior do que o dos itens técnicos. 

Voltando ao exemplo da figura anterior, digamos que o time acima consiga fazer 5 itens por sprints (vazão). Ele está bem no desenvolvimento e, portanto, definiu que 60% dos itens serão itens de valor e 40% itens técnicos. Logo, o backlog da próxima sprint ficará:

Como regra, dê preferência para que o percentual de itens de valor seja maior do que o dos itens técnicos. No frigir dos ovos, são os itens de valor que pagam as contas.

Se o seu time tem a vazão medida por pontos de história (story points) serve a mesma lógica. Qual o percentual de story points é dedicado a itens de valor e qual o percentual é dedicado a itens técnicos? Digamos que o time entregue 100 pontos por sprint. Utilizando os mesmos percentuais acima, teríamos 60 pontos dedicados para itens de valor e 40 pontos dedicados para itens técnicos.

E no Kanban?

Se o time utiliza Kanban, você pode utilizar o carrossel de slot de priorização. É o formato sugerido pelo David Anderson como Serviço Único e Múltiplas Classes de Serviço. Veja o exemplo nas imagens abaixo.

Nesse quadro, vemos que há três slots vazios que devem ser priorizados de acordo com o desenvolvimento do time. Como um bom Kanban, conforme os itens saem da coluna “Vamos fazer”, tanto os itens quanto os slots vão subindo na prioridade. 

A movimentação dos slots funciona como se fosse um carrossel. Já que os itens A e B (que eram ocupados pelos itens V10 e V11) acabaram de ficar vazios, eles vão para o final da fila de priorização. O item C será ocupado por V12. Se o time iniciar a construção do V12, o slot C irá para o fim da fila e o item D, que será ocupado obrigatoriamente por um item técnico, estará no topo.. 

É possível, e eu particularmente prefiro, ter uma raia específica para atender aos itens técnicos e outra para os itens de valor. Lembrando que, como em qualquer etapa do fluxo, os itens que estão nessas raias também são subordinados à limitação da capacidade do estágio.

Para compreender melhor, leia o artigo: O que é Kanban? Entenda como funciona esse método.

Nesse caso, utilizamos uma agregação de serviços, todos devem respeitar os limites impostos a cada estágio. Gosto mais desse modelo porque ele é mais fácil de entender, manusear e visualizar o que o time está fazendo do que a movimentação de slots.

Posso reduzir a entrega de itens de valor a zero?

Não recomendo, pois isso é muito, muito, muito ruim. Assim como o  PO deve fatiar os problemas dos clientes, os desenvolvedores também devem fatiar os problemas técnicos. Trocar uma camada técnica pode ser uma delícia para os desenvolvedores, mas pode se transformar em uma dor de cabeça enorme para o negócio.

Lembro uma vez que tínhamos que atender a um pedido simples: “Caso a pessoa que utiliza nossos serviços tenha um nome social, ele deverá ser exibido no lugar do nome civil”. A solução técnica para isso cabe em uma linha, pois é um comando bem simples de banco de dados:

NVL (nome_social, nome_civil) AS nome_pessoa. Nvl é um comando do banco de dados Oracle que, caso o valor retornado por um campo (nome social) não tenha sido informado, ele automaticamente retornará o valor do outro campo (nome civil).

Entretanto, esse time tinha uma defasagem grande no componente de Interface do Usuário que era Primefaces. Foi então que surgiu a ideia de, junto com a mudança do nome social, mudar a versão do Primefaces de 5 para 8. O comando simples apresentado no parágrafo anterior que levava minutos para ser disponibilizado e entregava um grande valor, levou 1 mês para ser entregue para os clientes por causa dessa “pequena mudança” do Primefaces.

Tudo pode e deve ser fatiado. Ao invés de um grande salto tecnológico, que tal pequenos saltos? Da versão 5 para 6, da 6 para a 6.1 até chegar na 8. Ao invés de mudar todas as consultas do software, que tal migrar apenas a mais importante? Por aí vai.

Conclusão

Gosto da Analogia que se não me engano é de Gojko Adzic. Existe uma parte do seu produto que deve jogar no campo ofensivo e tem como objetivo marcar gols (entregar valor), todavia há uma parte do seu produto que deve ser defensivo e ajudar o time a não tomar gols (itens técnicos). Um equilíbrio entre eles é muito importante para ganharmos o campeonato.

Espero ter ajudado. Você tem alguma experiência nesse assunto? Conte para nós nos comentários. Se quiser saber mais sobre isso, recomendo os artigos Dívida Técnica e Juros Compostos e Liquidando Dívidas Técnicas. 

Se quiser um treinamento que pode te ajudar com priorização de itens, recomendo CSPO e Métricas Ágeis.