O Dilema da Estimativa

"E aí, quanto tempo leva pra fazer?"

Essa deve ser uma das perguntas que mais ouvi em toda a minha carreira. Começa sempre com uma pessoa interessada em montar um sistema do zero, ou modificar um sistema que já existe (sendo essa última motivação o que fez minha empresa prosperar nos primeiros anos). É engraçado como as pessoas que nos procuram esperam que nós, profissionais de desenvolvimento de software, tenhamos uma resposta na ponta da língua. Que, magicamente, pelo fato de lidarmos com isso todos os dias, fôssemos capazes de antever toda a estrutura de um sistema, a arquitetura, as telas, o banco de dados, a experiência do usuário e a performance, e num cálculo rápido, conseguíssemos viajar no tempo e ver a última linha do sistema sendo escrita, para logo após termos uma publicação de versão, perfeita e imaculada.

Essa pergunta tem uma irmã, que é "quanto custa para fazer?", que é ainda pior por uma série de motivos, mas darei dois de natureza bem prática. O primeiro tem a ver com o compromisso assumido entre o desenvolvedor e seu cliente. Atrasar uma entrega tem um ônus enorme ao desenvolvedor, que pode ver seu cliente simplesmente desistir do projeto e não pagar nada, ou ainda receber seus proventos muito depois do esperado, já que o projeto continuou por muitos dias além do que era previsto. O segundo existe em um mesmo problema da primeira pergunta, que é quando a estimativa está errada - normalmente, abaixo do que seria o tempo total real para o projeto - trazendo ônus para o time inteiro, e algumas vezes para a empresa inteira. O fenômeno é bem conhecido, e tem até um nome: Falácia do planejamento.

O resultado é clichê considerando o Brasil: desenvolvedores trabalhando várias horas a mais depois do horário normal, em finais de semana, feriados, algumas vezes chegando a inacreditáveis 16 horas por dia. Uma estimação errada pode tornar a vida de muitas pessoas bem miserável.

Na Design Líquido, seguimos o modelo de contrato fechado por pouco tempo, abandonando-o rapidamente, e usando ao invés apenas o modelo do taxímetro: o cliente paga pelo caminho que percorremos. Se o caminho não atingiu seu objetivo, a responsabilidade fica com o cliente. Algumas pessoas me perguntam se existem clientes que topam esse tipo de modelo, e a resposta é sim. Eu diria, todos eles.

"Mas como é isso, você entrega um projeto sem terminar e ainda cobra por ele?". Bom, não é tão simples assim. Já tivemos clientes em que o fim nunca chega. Funciona da seguinte forma: o cliente pede um sistema pequeno, com poucos requisitos e telas. Montávamos o sistema e entregávamos conforme combinado. A devolutiva do cliente era algo como "mas agora precisamos disso:", e vinham mais itens que não estavam acordados no início. Em outras palavras, o cliente queria mudar as regras do jogo no meio dele.

Software muda o tempo inteiro. Basta ver o que você tem instalado no seu telefone agora mesmo. Quantas vezes já não aconteceu de você abrir um aplicativo no dia seguinte, e um botão sumir, uma opção de menu aparecer em outro lugar, ou a aparência de uma tela ficar diferente? Com clientes, é a mesma coisa: eles mudam de ideia o tempo todo sobre o Software, mas querem manter o mesmo orçamento. No modelo de contrato fechado, isso é uma armadilha.

Por melhor que seja o desenvolvedor, ou engenheiro, ou arquiteto de software, prover uma estimativa acurada de uma aplicação feita do zero é impossível. As estimativas que vejo dar certo são dadas em cima de soluções que já existem, que o resultado é pegar uma massa comum de software, modificar alguns comportamentos e entregar. Nesse caso específico, o volume de modificações é bem conhecido, então o roteiro delas é executado sem grandes surpresas.

No entanto, boa parte da minha vida profissional foi lidando com clientes que queriam projetos do zero, que eu estimasse início, meio e fim, e o custo. E, para todos eles, minha resposta inicial é pragmática e bastante frustrante: "não tenho previsão".

É claro que eu não posso ficar sem dar previsão de coisa alguma. O que eu faço logo em seguida é dar uma previsão para algo menor e bem tangível. Uma tela, por exemplo. Um campo a mais. Uma validação. Uma mudança de comportamento. Esses são itens fáceis de ver o fim deles, sobretudo se já foram feitos antes em algum momento.

É aí que se baseiam os métodos de estimação mais complexos. Eles mudam completamente a cada 10 anos. Quando eu estava na faculdade, se falava em pontos de função, contagem de linhas, COCOMO e etc. Nunca vi qualquer um deles funcionar na prática. Os melhores líderes de projeto com quem já trabalhei usam alguns métodos de estimação baseados no Scrum e no Kanban, sendo alguns bem pitorescos, como um joguinho de poker com cartas de valores da sequência de Fibonacci, estimação por "tamanho da camiseta", ou mensurações arbitrárias com cálculo de velocidade do time. A maioria deles são irreais, mas funcionam bem como cabides de emprego (especialmente falando de quem gosta demais do Scrum).

Voltando às estimações que vi funcionar, posso definir uma sequência de passos que permite uma estimação até razoável:

1. Estimar cada tarefa do Backlog - a lista de itens pendentes do projeto - entre pequenas, médias, grandes e enormes. Para as enormes, quebrar a atividade em partes menores quando possível;
2. Distribuir as atividades para o time e medir a quantidade de tarefas entregues no período de duas semanas. Alguns líderes de projeto usam valores da sequência de Fibonacci para ter um valor final. Por exemplo, 1 para uma atividade simples, 2 para mediana, 3 para grande e 5 para enorme. Ao final das duas semanas, somam-se os valores das atividades, e o total é chamado de "velocidade do time";
3. Após dois meses, já é sabida a variação da velocidade do time, então, ao alocar atividades para duas semanas, o time sabe o quanto (não) consegue entregar, tendo a lista de atividades um valor total menor ou igual à velocidade média do time.
4. Por exemplo, se meu time teve 4 períodos de 2 semanas entregando 40, 42, 38 e 41 pontos, respectivamente, naturalmente vou adicionar um tanto de atividades para o próximo período cujo total de pontos esteja entre 38 e 42.
5. Por fim, agrupar as atividades por funcionalidade. O resultado é algo muito próximo de uma estimação confiável.

Devem aparecer atividades no período que já vi serem chamadas de Spikes: atividades de descoberta. É quando precisamos mergulhar no desconhecido e descobrir como uma determinada biblioteca ou API funcionam. A descoberta pode levar horas, dias ou até mesmo semanas, dependendo do nível de documentação e suporte a desenvolvedores.

Essas atividades são colocadas numa categoria chamada "Impedimentos", ou seja, uma atividade que bloqueia outras, e são as principais razões pelas quais qualquer estimativa falha. É muito difícil não ter Spikes em um projeto. A estratégia que melhor funciona é investir tempo no Spike o mais cedo possível, com o máximo de prioridade, para então ter o funcionamento daquela biblioteca ou API completamente entendido, e assim ter itens mais previsíveis no Backlog do projeto.

Voltando ao problema com os clientes

A estimativa dentro de um projeto com Scrum ou Kanban funciona, com certas limitações, mas não temos como fazer isso pra um projeto que nem sequer começou. E, de novo, no Brasil temos um problema adicional.

Clientes adoram ter a ideia do preço fechado, e quanto mais barato, melhor. Conversas iniciais comigo normalmente são banhos de água fria. Já aconteceu diversas vezes: um cliente vem com uma ideia e um wireframe - um modelo gráfico, algumas vezes já com as transições de uma tela para outra já funcionando -pronto, e querem ouvir que leva cinco vezes menos tempo para fazer do que estimo, e custa 10 vezes menos pra fazer do que o que estimo. Logo após, eles até acham alguém que faz pelo prazo e custo que eles imaginam ser adequado. O que normalmente acontece é um dos cenários abaixo:

• O projeto é implementado em alguma linguagem simples e aprender e barata em hospedagem, como PHP ou JavaScript. A parte gráfica inteira é implementada, já que existe um wireframe correspondente, mas o sistema não tem sequer metade das funcionalidades imaginadas. O sistema não escala, sofre com desempenho e não ganha tração, além de ter problemas triviais de segurança, como vulnerabilidades CSRF e XSS. O cliente desiste completamente do projeto;
• O projeto é implementado em duas camadas, sendo uma camada gráfica usando um framework JavaScript, podendo ser transpilado usando Node.js ou não, e uma API RESTful, sendo essa numa linguagem e frameworks apropriados para ganho em escala. Os conceitos iniciais são implementados corretamente em ambas as camadas, mas o cliente começa a pressionar o desenvolvedor para entregar num determinado prazo. Várias boas práticas são abandonadas, a finalização acaba com várias gambiarras e o projeto funciona pela metade. Insatisfeito, o cliente pede todos os fontes de volta e procura empresas como a minha para finalizar, desta vez disposto a bancar um orçamento maior. Com alguma configuração e uma hospedagem correta, o sistema até escala, mas o novo fornecedor de Software gasta um bom tempo corrigindo as gambiarras. Uma boa parte dos clientes não entende que o orçamento é gasto justamente para reescrever partes que não funcionam direito. Uma das estratégias que usamos é trazer novas funcionalidades, usando um tempo delas para corrigir o que não está bom e implementar alguma coisa que o cliente perceba valor. Uma boa parte desses clientes continua conosco, e outra parte decide ou abandonar o projeto, ou seguir com outro fornecedor mais barato, e o problema continua até que o cliente deixe o projeto do jeito que está, ou o abandone;
• O projeto é implementado por aquele que chamo de desenvolvedor-herói: um desenvolvedor que faz da sua missão de vida o projeto, gastando dias e noites nele até o projeto sair, não importando o custo pessoal que isso implica. Aos trancos e barrancos, o projeto sai, finaliza, até funciona em produção, mas depende 100% do desenvolvedor-herói. Em raríssimos casos o projeto continua só com ele. Em alguns casos, o cliente nos procura e pede para que ajudemos no projeto e a lidar com o desenvolvedor-herói, que nos vê como invasores e usurpadores. A relação é complicada e normalmente não amigável. Duas coisas podem acontecer: ficamos um tempo no projeto e finalizamos, corrigindo os maiores problemas que o desenvolvedor-herói não consegue resolver sozinho, ou o desenvolvedor-herói é dispensado e o projeto fica conosco.

Um caso mais raro de cliente, mas que muito interessa para este que vos escreve, é o cliente que vem com um sistema péssimo e pede para reimplementá-lo em uma tecnologia mais moderna. Passado o orçamento e o prazo, o cliente simplesmente aprova tudo. Havendo atrasos, comunicamos o quanto antes, explicando as dificuldades e o que precisa ser feito. Entregamos o projeto, o cliente pede mais coisas, e assim continuamos. Estes são os atuais (e melhores) clientes da Design Líquido.

No entanto, clientes assim são bem difíceis de achar. A maioria dos potenciais clientes são esses que querem sistemas baratíssimos e impossíveis de serem implementados num determinado prazo. Numa conversa com uma colega, cheguei a este dilema que dá título a este texto. Como posso reter um cliente que quer pagar pouco e criar um sistema num prazo quase impossível de ser feito?

Inicialmente, pensei no seguinte:

1. Ter uma fundação comum a todos os projetos. Isso eu comecei em 2018 e finalizei este ano, depois de abandonar a Stack da Microsoft. Hoje a Design Líquido tem uma nova Stack, mais adequada aos tempos atuais, e compreende APIs RESTful, sistemas Web PWA e aplicativos nativos para celular;
2. Investir em mão de obra júnior. Isso eu comecei em 2021, com um programa de aprendizes. O que faço é selecionar alguns talentos e os subsidio para que estudem focados, sem colocar na frente outros problemas, como não ter um emprego e ter contas a pagar. Em resumo, ajudo a evitar o Scarcity Mindset. Os melhores aprendizes são convidados para projetos na Design Líquido;
3. Foco em automatização. Isso também comecei em 2018, escolhendo uma estrutura de nuvem que nos ajude de verdade, e não que crie problemas (especialmente no meu cartão de crédito). Teoricamente falando, hoje estamos prontos para receber qualquer cliente com qualquer sistema já existente, por mais problemático que seja. Em padrões de projeto, fazemos intenso uso da técnica de Scaffolding quando possível;
4. Vitrine própria de produtos. Isso partiu de um dilema antigo meu. Por uma década escrevi o sistema dos outros, mas nunca escrevi os meus. Isso começou a mudar no final de 2020, quando comecei a investir em projetos internos. Isso atrai novos clientes por ter casos de sucesso de fácil demonstração. Evita também o problema de ter um projeto abandonado por um cliente, o que diminui a vitrine.

Isso não resolve todos os problemas, mas resolve alguns. Os problemas que ainda não resolvi:

1. Mudar o discurso. Pragmatismo me faz perder muitos clientes. Quando falo da realidade do custo e dos prazos, potenciais clientes agradecem o tempo, vão ao mercado, acham alguém mais barato, que começa o sistema não entrega e o sistema naufraga. Todos perdem. No entanto, isso é um meio de negócio pra um tipo de empresa que chamo de Agência Digital: são especializados em entregar um site ou sistema visualmente atrativo, com baixo custo de desenvolvimento e baixa qualidade sistêmica. Os projetos são curtos e baratos, e normalmente eles dispõem de um pipeline interno, que começa no comercial, passa para a equipe de Design, depois para o desenvolvimento e finalmente a entrega. Não tem problema o sistema não funcionar bem, porque a missão está cumprida. Essas agências normalmente absorvem clientes em volume e o tempo dispensado a cada cliente é bem curto;
2. Voltar a desenvolver sistemas pequenos. São as origens da Design Líquido, os sistemas anões. Para isso, o que preciso fazer é montar uma esteira de processos melhor do que a das Agências Digitais;
3. Como prospectar clientes. Por muito tempo, a Design Líquido trabalhou com indicações, ou alcance orgânico de redes sociais. Numa eventual expansão, não está claro para nós quais clientes queremos prospectar, mas é algo que precisa ser definido.

Voltando ao Dilema da Estimativa

Mas, então, como resolver o Dilema da Estimativa, finalmente?

Não quero ter que mentir para clientes, que o projeto deles pode ser feito num tempo curtíssimo e num preço pequeno. Invariavelmente vou perder oportunidades. Quando projetos começam assim, já são fracassos automáticos.

Basicamente são duas estratégias:

• Continuar com o taxímetro: funciona bem para nós, e os clientes que aceitam o modelo se habituam bem a ele;
• Simplificar a entrega, melhorar os processos internos e reter o cliente: esta é a estratégia que estou trabalhando. Trazer as receitas de sucesso de outros projetos, descomplicar a arquitetura e ter uma equipe pronta para esses projetos pequenos, de prazo curto e custo baixo. É um desafio enorme, que deve ser alvo de futuros textos.

Eu não tenho uma certeza de que isso irá funcionar, mas é um bom começo. Futuramente voltarei a este assunto.