O antídoto para atraso em projetos

Trabalhando com desenvolvimento de produtos há mais de dez anos eu já perdi as contas de quantas vezes atrasei entregas. Se tornou algo tão comum pra todo mundo que isso nem é mais assunto nas reuniões de retrospectiva. Quando o assunto vem à tona normalmente o melhor comentário que sai é: “A gente precisa estimar melhor.”

Se você tem alguma vivência com Ágil então provavelmente está pensando: “É só cortar escopo.” Esse argumento é válido, mas o problema é que ele é um pouco vago. Cortar escopo pode ter significados diferentes para diferentes pessoas. É importante defini-lo claramente por ser um conceito com muita influência em nossa capacidade de entrega. E o que está por trás de reduzir escopo é o conceito de dívida.

Dívida não é ruim?

Dívida não é necessariamente uma coisa ruim. A maioria das empresas adquirem dívidas por acreditarem que serão capazes de multiplicar aquele dinheiro mais vezes do que os juros que vão se acumular. Se usada da maneira correta, dívida é algo bom. Quando falamos de reduzir escopo, em muitos casos estamos falando de contrair uma dívida na expectativa de ter retornos maiores que os juros que seremos obrigados a pagar.

Dívida em design e produto

Imagine que um time tenha se comprometido a fazer uma tela seguindo um certo design. Agora imagine que ao longo do caminho o design se mostrou difícil de ser implementado e o prazo está próximo. Nesse caso existem duas alternativas: A primeira é prosseguir mesmo sendo difícil, e arcar com o risco de não entregar a tela no prazo acordado. A segunda é reduzir escopo simplificando o design, isto é, simplificando a tela para reduzir o risco de não entregá-la a tempo.

No segundo caso o time teria decidido contrair uma dívida de experiência de usuário, uma vez que o design inicial supostamente era o mais adequado. O fato da tela ser entregue aos usuários dentro do prazo pode ser o suficiente para justificar a dívida. Dependendo dos resultados obtidos o time pode decidir por dedicar um tempo para adequar a tela ao design proposto inicialmente, ou o time pode simplesmente ignorá-lo porque decidiu trabalhar em outra tela que supostamente traz mais valor do que a adequação ao leiaute traria.

Repare que a decisão gira em torno de assumir uma dívida para garantir uma entrega, ou não assumir uma dívida mas não garantir uma entrega. O mesmo é válido para escopo de produto. Pode ser melhor entregar somente algumas funcionalidades e já gerar valor pro usuário com elas do que se manter trabalhando num escopo maior de funcionalidades enquanto segura a entrega de valor.

Dívida em Tecnologia

Um outro cenário normalmente pouco explorado é a contração de dívidas em tecnologia. Levamos muito a sério algumas filosofias e práticas que nem sempre são aplicáveis a todos os contextos. Na comunidade de tecnologia é muito difundida a necessidade de aplicações terem testes automatizados, ou ainda código limpo. Não que esses atributos não sejam importantes, mas certamente podem ser um ponto de alavancagem onde existe a possibilidade de cogitar contrairmos uma dívida.

Uma vez trabalhei em uma empresa que tinha lançado um novo produto há poucos meses. Toda a extração de dados dos novos clientes eram feitos por um sistema desenvolvido por uma empresa parceira. Um dia esse sistema parou de funcionar, e quando entramos em contato com essa empresa os desenvolvedores falaram que não dariam mais manutenção, e que poderiam nos passar o código fonte. Sem esse sistema não seríamos capazes de fazer novas vendas, uma vez que não conseguiríamos colocar mais clientes para dentro. Eu tinha basicamente duas alternativas. A primeira era pegar o código fonte desse sistema, ler e entender tudo que estava lá, encontrar o bug e fazer o deploy no nosso ambiente. Na melhor das hipóteses isso levaria alguns dias. A outra opção era eu escrever um script que resolveria da forma mais simples possível essa extração de dados. Segui pela segunda opção. Não me apoiei em TDD ou sequer escrevi qualquer tipo de teste. Não declarei classes ou usei qualquer conceito de orientação a objetos. Escrevi um bom e velho código procedural num Jupyter Notebook, e em poucas horas consegui criar um entrega mínima viável. Assim não perdemos nem um dia de vendas.

É evidente que nesse cenário tínhamos uma dívida enorme. Mas com o passar do tempo transformamos esse script em uma aplicação com código decente, testes automatizados e dentro do nosso pipeline de deploys.

Via de regra quanto mais experimental for o código, mais dívida técnica pode ser assumida. Por isso é comum muitas startups crescerem com um código tão ruim. Quase tudo que uma startup faz é experimental. Com o passar do tempo os juros dessas dívidas passam a se tornar parte relevante do processo, e precisam ser atacados para evitar que um produto vá a falência (no limite quando não é possível mais evoluí-lo).

Outras formas de dívida

Hoje em dia é muito comum eu tomar uma decisão de assumir pequenas dívidas para acelerar uma entrega, para pagá-la logo em seguida. Supondo que a funcionalidade leve cinco dias para ser desenvolvida (sem contrair dívida), prefiro entregar em quatro dias (com dívida) e depois pagá-la no quinto dia. O tempo total continua sendo de cinco dias, mas o usuário recebeu valor mais cedo.

Em outros casos a dívida aparece no formato de risco, ou seja, ela não necessariamente cobra juros, mas eventualmente podemos ter algum problema onde seremos obrigados a pagar a dívida urgentemente. Desde que o risco não seja muito grande, esse também pode ser um bom ponto de alavancagem para garantir uma data de entrega.

Nem sempre nós somos capazes de tomar decisões unilateralmente, então é importante praticarmos nosso poder de persuasão para conseguir reduzir escopo junta a outras pessoas. E nas ocasiões onde podemos decidir por conta própria, também é importante ter coragem.

Conclusão

Assumir dívidas é uma das formas mais eficazes de garantir entregas. Acumular muitas dívidas pode tornar os juros impagáveis. Reduza escopo intencionalmente. Assuma dívidas conscientemente.