Este perfil WoLF (funciona no último "fogo"/problema, Funciona no último incêndio) é gerado, seja por motivações próprias da pessoa que são pouco focadas ou por um direcionamento das equipes em direções díspares. De qualquer forma, eles sempre produzem trabalho adicional resolvendo problemas que não são atendidos ao longo do caminho até que mais cedo ou mais tarde eles devem ser enfrentados com o conseqüente custo econômico e perda de oportunidades, entre outros.
Se com o desenvolvimento de software você quisesse criar um filme como os da máfia, o argumento poderia ser o seguinte:
…Julia, a dona da "Casa para o Cuidado dos Bambinos Abandonados" quer salvá-la da execução hipotecária, e ocorre a ela implementar rapidamente o novo aplicativo de jogo "Abandoned-Child Finder" a tempo para a temporada de férias. Sua esperança é que a receita de assinatura e publicidade salve o dia do orfanato. Infelizmente, para que seu aplicativo seja lançado com sucesso no prazo, ele trapaceia um pouco assumindo a responsabilidade por uma dívida de definição técnica resultante de um elemento de empilhamento de incentivos para jogadores de nível épico. Tudo parece perfeito, a casa para as crianças parece segura, seus inquilinos estão mais uma vez ensaiando para o concurso anual de Natal… definição. Como a equipe de Julia já está no caminho certo para entregar os novos recursos necessários para levantar capital de risco, eles ignoram o relatório de Carmen... até Luis, o cobrador de dívidas técnico, o Scrum entre Scrums, com um post-it® vermelho brilhante... pregado na ponta de um taco de beisebol. Escusado será dizer que o resto do filme implica que Julia passou seus dias descobrindo e depois resolvendo todas as implicações de não ter corrigido esses erros de definição em primeiro lugar, desviando a receita do aplicativo necessária para evitar que as crianças fossem despejadas. para o frio na véspera de Natal.
Sim, é evidente, um clichê muito usado, mas muito familiar aos profissionais de desenvolvimento de produtos. É claro que Julia está cumprindo os deveres do WoLF. Se um ou mais perfis forem adicionados a este perfil PUFFIN (Planeja iniciativas intermináveis de fábrica de recursos) o caos e o conflito já é o de um filme apocalíptico.
Como você chega a essa situação
Como nossa heroína Julia, também deixamos de lado o dívidas técnicas com a promessa de que pagaremos mais tarde, quando houver mais tempo.
O problema é que nunca há tempo suficiente por várias razões. Alguns exemplos reais podem ser os seguintes (sem nomes ou detalhes facilmente identificáveis, é claro):
- O VP de Vendas Incríveis prometeu ao cliente Big Fish o recurso "XYZ" em uma data fixa que provavelmente foi oferecida com consulta mínima da equipe responsável pela entrega dos produtos.
- O parceiro de risco ansioso que deseja sair quer garantir que um determinado domínio ou vertical seja coberto antes do próximo IPO.
- O programador entediado que cria seu currículo precisa de experiência prática na criação de relatórios de BI orientados por API entregues usando Angular, aproveitando a mais recente tecnologia de aprendizado de máquina em um cluster Apache Spark.
- O Product Owner com fome de promoção que quer impressionar o chefe com ótimos recursos de front-end nos quatro meses que antecedem sua avaliação de desempenho.
Todos eles soam como candidatos à priorização não orientada por dados, que virá com um preço potencialmente alto a pagar e um enorme custo de oportunidade.
Então, por que racionalizamos assim? Talvez porque trabalhar com dívida técnica seja divertido, durante a primeira semana. Depois disso, torna-se um jogo sinistro de subornar e extorquir companheiros de equipe, além de enganar algum outro membro da equipe desavisado para fazer o trabalho sujo.
Como evitar chegar a esses cenários
Para aqueles (poucos) que ainda não experimentaram a 'alegria' de uma visita de um simpático cobrador técnico, vale a pena ter em mente estes 7 princípios a serem observados durante o processo.
Apoie, investigue e priorize estes princípios ou situações:
- Se um engenheiro está lutando com dívidas técnicas para terminar um trabalho.
- Se você criar um recurso com uma dívida óbvia de experiência do usuário (UX).
- Se a pesquisa for necessária porque os dados não existiam.
- O trabalho não está contribuindo para o valor do cliente, quando foi planejado para acontecer.
- Uma história foi publicada e depois foi preciso jogar para justificar o que foi dito.
- Falha ao validar o impacto.
- Você pega a ideia, mas ainda está criando mais tarefas, refazendo-as, cortando funções, aumentando a carga operacional,... a cada passo fica menos impressionante.
A ousadia e a sinceridade são essenciais na tomada de medidas para que a equipe, a gestão, os stakeholders, os patrocinadores e, se possível, os clientes estejam cientes de que futuras versões do produto ou serviço incluirão as dívidas contraídas. Pelo menos é necessário estabelecer uma correta gestão das expectativas explicando os "infelizes acidentes" que podem ocorrer se as responsabilidades adquiridas não forem pagas.
Se você decidir simplesmente pagar os juros ou pagar integralmente, lembre-se de que, assim como um agiota, o preço de sua acumulação técnica provavelmente aumentará de custo durante o período de tempo em que permanecer instável.
Referências
- Acelerar: A Ciência do Software Lean e DevOps: Construindo e Dimensionando Organizações de Tecnologia de Alto Desempenho' — Nicole Forsgren & Jez Humble
- 'Manual do DevOps: Como criar agilidade, confiabilidade e segurança de classe mundial em organizações de tecnologia'— Gene Kim, et.al.
