Estimativa de projetos de software de uma maneira prática + planilha

O desenvolvimento de um sistema é um projeto cheio de detalhes, e estimar seu tamanho antes de realizar uma proposta ou iniciar seu desenvolvimento é essencial. Um erro ao entender a quantidade de trabalho necessário em um projeto ou sua duração pode significar o fracasso, causando stress e até perdas financeiras.

Qual o custo para desenvolver o aplicativo? Quantos dias ou meses são necessários de cada profissional no time? O quanto preciso saber de cada tarefa para chegar a uma estimativa realista?

Como estas são questões recorrente em consultorias que realizamos, escrevi este post com um apanhado do aprendemos ao longo dos últimos 20 anos desenvolvimento sistemas de todos os tipos.

Adicionalmente, vou te recomendar baixar nossa planilha de estimativa de projeto de software, para te ajudar a chegar aos números que tanto busca.

Ciclos de obtenção de informações

Normalmete tudo começa com uma reunião com o cliente para conhecer o projeto e a demanda. É importante saber que não será possível entender 100% do projeto e obter todas as informações em uma única reunião. Talvez nessa primeira reunião seja importante entender o escopo geral do projeto, os principais processos e interações, as expectativas com relação a interface, usabilidade e aplicabilidade da solução.

Tudo que for importante, anote de maneira simples. Se alguma dúvida maior surgir, anote para perguntar logo mais, mas não espere aprender tudo agora, foque no essencial. Uma ótima dica é usar o plugin Meet Transcript para o Chorme que irá registrar toda a conversa da reunião (se acontecer dentro do navegador, como no Google Meet ou Zoom pela web) e salvar em um documento no Google Drive. É raro eu não ter que voltar na transcrição da reunião buscar alguma informação, quando não lembro se algo foi falado de um jeito ou de outro.

Após a reunião é hora de começar uma planilha de estimativa, onde cada recurso falado na reunião deverá ser convertido em tarefas e então mensurados. Aqui, já deixo claro que é muito difícil estimar um projeto maior sem uma planilha, sem se debruçar sobre as tarefas, sem calcular.

Serão necessários alguns ciclos de obtenção de informações, visto que na estimativa o que se busca é clareza. Ao final teremos o “montante” aproximado que representa o projeto, seja em horas, dias, pessoas ou qualquer outro recurso.

Features, estórias e e tarefas

Uma feature é um recurso do sistema, é algo que nosso cliente quer em seu sistema. Um exemplo prático é a quando o cliente diz “O usuário deve autenticar no sistema”. Em metodologias ágeis você poderá ouvir isso como uma estória/história, que dirá como o usuário deverá chegar ao sistema, e seguir um fluxo para acessar.

Um recurso como este será divido em diversas tarefas menores, feitas por várias pessoas. É preciso criar o design para esta interface, é preciso um banco de dados para armazenamento e leitura dos dados, é preciso um backend que acesse estas informações, e por fim uma interface onde o usuário irá efetivamente digitar seus dados para poder acessar o sistema.

Cada uma destas tarefas menores precisarão ter um tempo em horas, para compor o tempo total desta feature.

Enquanto algo não ficar claro, envie perguntas por email ou  reuna-se novamente se for necessário, até que todas as partes desconhecidas estejam claras.

Uma vantagem em ter uma planilha com todos os detalhes, é poder anexar esta lista detalhada de tarefas ao contrato, para evitar mudanças de escopo ao longo do desenvolvimento.

Seguindo aqui no post, você verá como maximizar suas chances de sucesso.

Como achar o tempo da tarefa?

Quanto tempo seria necessário para implementar uma interface de login com email e senha, adequado ao responsivo, com as chamadas ao backend, tratamento de erros e feedback ao usuário?

Se você não sabe ainda essa resposta, existem mais desafios a serem vencidos. Vamos explorar aqui dois possíveis caminhos.

Recomendo sempre ter alguém técnico junto, se possível até o time de desenvolvimento, porque é bem complicado lá frente dizer “você irá implementar esta tarefa em 3 horas” e o desenvolvedor responder “só consigo fazer isso em 9 horas”.

Partindo da menor parcela implementável, e seguir multiplicando

Imagine medir o tempo que leva para ler uma página de um livro, para então, dado o numero de páginas, saber quanto tempo leva para ler o livro.

Uma maneira eficaz de pensar no tempo de uma tarefa, é imaginar uma tarefa bem pequena, da qual você consegue dizer com certeza “o esforço para implementar A é de uma hora”. A partir dai toda tarefa seria comparada com essa menor. “Implementar B levaria duas vezes mais esforço que A”, “C por sua vez é duas vezes maior que B”.

Nesta abordagem é ainda mais recomendado ter seu time de desenvolvimento pensando junto.

Medindo e registrando o tempo real

Ter a informação histórica é sem dúvida a melhor maneira de todas, ter certeza de quanto tempo um dev médio do seu time leva para fazer aquilo. A forma que recomendo de fazer isso é utilizando um sistema de tracking de tempo, tal como Hubstaff, doTeam ou Clockify, onde o desenvolvedor deve dar play em cada issue, seguindo um padrão de título para facilitar depois encontrar os tempos facilmente tal como “Issue + Categoria + Titulo”, por exemplo:

#33 - Backend - Enviar email de boas vindas

Com algumas medições precisas, você passa a entender o tempo das coisas. O quanto antes você começar a medir o tempo trabalhado, mais cedo terá estimativas mais assertivas em próximos projetos. De quebra, irá perceber que alguns devs se enrolam muito mais para fazer algumas tarefas do que outros, mas isso é assunto pra outro post.

Precedências e dependências ocultas

Isso é o que o cliente disse, e é isso que ele espera:

Enviar email de boas vindas ao usuário

Essa é uma atividade relativamente simples, eu diria que envolve umas 3 horas de backend apenas. É enviar um email, pronto. 3 horas são suficientes com certeza, concorda? 

O que vou explorar neste tópico, é como um recurso inofensivo ⚠️ pode se tornar gigante e complexo, indo de 3 para 50 horas facilmente, ou seja, podendo demorar 15 vezes mais.

Quanto ao envio do email, será um email de texto simples ou terá um template HTML de base (que todos os emails poderiam ter)? Se precisar do HTML eu somaria 3 horas para o front criar um tema básico.

Peraí, para enviar um email é preciso já ter configurado no projeto uma biblioteca de envio de email. Será enviado um email “puro” ou irá usar algum serviço como AWS SES ou Sendgrid? Todos os envios de email dependerão desta atividade inicial. Se for um envio puro, para implementar e testar bem direitinho eu consideraria 6 horas, se for utilizando um serviço externo, cerca de 10 horas.

Observe agora os três tópicos a seguir, que são bem técnicos. Para cada um deste três níveis técnicos de percepção, essa atividade poderá ser aumentada em horas.

Indo fundo nos detalhes técnicos 

Se haverá um HTML, claro que terá a logo do sistema neste template. Onde a imagem estará? Porque será necessária a URL completa desta imagem, que arrisco dizer, estará em uma pasta de assets do backend. Ao enviar o email, o backend precisará saber essa URL, ou ao menos a URL base de todos os assets. 

Eu somaria mais 3 horas no backend.

Indo mais fundo, com mais detalhes técnicos 

Se vamos enviar um email para o usuário, é bom que ele possa ter uma opção “Não quero mais receber estes emails”, e realizar um unsuscribe. Isso implicaria em uma rota nova no backend para dar um update no usuário, desativando envio de emails, bem como atualizar o método de envio, para que nunca envie nada para um usuário que optou pela saída. 

Eu adicionaria  5 horas de backend para isso.

Tão fundo, que só com prática dá pra ir

Se o envio do email é algo crucial para seu projeto, alguns aspectos adicionais podem ser considerados.

O primeiro dele é saber se o email foi entregue. Entenda que existe uma diferença grande em enviar com sucesso, e chegar lá. Para que o sistema possa ter certeza de que o servidor de destino aceitou e recebeu o email, usando o SES ou outro serviço, eu consideraria mais umas 18 horas de implementação, porque será necessário implementar um webhook, que receberá depois de alguns segundos do envio a informação se que o email chegou ao servidor de destino.

Chegar no servidor não é a mesma coisa que aparecer na caixa de entrada. O servidor pode olhar pro email e julgar “é spam!”.

O segundo aspecto é conferir se o email tem potencial para chegar na caixa de entrada, usando alguma ferramenta ou serviço que receba o email enviado, e confira nele os indícios que o faria não chegar na caixa de entrada. Uma ferramenta que recomendo é o mail tester, que é gratuito e altamente eficaz. Porém, para testar o email e realizar os possíveis ajustes, que irão desde o conteúdo do texto, código HTML e até mesmo configuração de DNS do domínio, eu somaria entre 6 e 16 horas à tarefa.

Talvez perceber o risco em uma atividade, seja uma das partes mais difíceis de uma estimativa, porque exige prática na atividade em questão, talvez já ter feito algo parecido e saber de todas as armadilhas que podem existir.

Algumas tarefas escondem um grande risco, tais como integrar a um sistema de terceiros. Ao ver exemplos de integração pode parecer muito simples, olhando a documentação pode parecer simples, mas ao começar a desenvolver você percebe que a documentação não deixou claro que alguns headers deveriam ser enviados, que algum token expira a cada poucos minutos, que os dados reais são retornados de uma forma diferente, ou mesmo que o processo de experimentar a integração no ambiente de desenvolvimento é demorada.

Como cobrar pelo risco do projeto

Ao utilizar um range de horas para refletir o risco, seu projeto não terá apenas um tamanho total, terá dois. Implica em dizer que o projeto ao todo será feito entre 815 e 970 horas, e é uma forma boa de refletir a realidade em desenvolvimento de software.

Se você se apoiar nas 815 horas e cobrar o projeto com base nelas, você está puxando o risco todo para você, se atrasar em qualquer aspecto, o prejuízo será seu. Se cobrar 970 horas, caso as atividades tenham “sorte” e não demorem tanto, você terá um lucro sobre o risco, o que é estranho também. O valor final poderá ficar muito alto.

Uma alternativa é chegar em um montante entre 815 e 970, a média talvez, não é científico, mas não fica só com você nem só com o cliente o risco.

Outra forma é cobrar o mínimo, mas deixar claro no contrato que as tarefas com risco serão medidas e cobradas individualmente caso ultrapassem o estimado.

O que não pode ser feito é ignorar o risco, pensar que todas as tarefas acontecerão suavemente, isso é ilusão.

Quando a estimativa dá errado

Normalmente não gostamos de falar das coisas quando dão erradas, mas como escuto muitas destas histórias, acho valoroso trazer pra você essa experiência, a fim de te ajudar e evita-las.

O cliente já disse o que queria, e se o tempo estourar e você sugerir entregar menos o cliente ficará irado. Ele não aceitará nada menos do que o combinado.

Dai surge a magnifica ideia de cobrar a mais pelas horas adicionais que seriam necessárias, e novamente, o cliente não vai pagar nada além do valor que estava no contrato, e poderá dizer que “o erro é seu”.

Erros em estimativa, sempre recaem sobre olhar o contrato, o que gera um desconforto tremendo. É a situação que ninguém quer ter que chegar. Por isso dedicar tempo e esforço em estimar é mais profissional e evita conflitos mais na frente.

Outros pontos de atenção ao estimar

Lembrar-se do bootstrap do projeto

Nos primeiros dias do projeto haverão um tanto de tarefas a serem feitas que não estão ligadas as features que serão desenvolvidas. Alguns exemplos:

• Discutir tecnologias, bibliotecas, e arquitetura do projeto
• Criar repositórios, pastas, dar permissões de acesso
• Criar design base para o projeto
• Criar base do projeto backend
• Criar base do projeto frontend
• Configurar ferramentas de qualidade de código
• Documentar padrões e setup do projeto para o time
• Criar CI/CD base para o projeto

Estas atividades apenas, costumam levar entre 100 e 200 horas conosco aqui.

Enviar, entregar, coletar feedback

Dependendo do tipo do projeto a publicação de uma versão para entrega pode tomar um certo tempo, variando das tecnologias que foram usadas, ambiente onde será executado e nível de maturidade em CI/CD do time. Leve em consideração este tempo.

Logo em seguida é preciso avisar ao cliente o que está sendo entregue, eventualmente prover um passo a passo para que ele possa experimentar todos os novos recursos, para então receber o feedback.

Em “estimativas alegres” a pessoa pensa que os dias acontecerão totalmente em sequencia, um atrás do outro, porém em alguns momentos é preciso parar tudo, esperar o cliente experimentar, validar, aprovar, antes de seguir. Recomendo ter um prazo máximo para essas etapas em contrato, senão o cliente pode relaxar e demorar dias ou semanas para dar o retorno 

Ao obter o feedback, pode ser preciso mais um tempo para ajustes bem como correção de bugs.

Saber o tempo que tarefas recorrentes levam para serem implementadas

O passo mais assertivo para ter uma estimativa mais correta, é medir o tempo que seu time tem levado nas tarefas, para poder consultar estes números e adotar horas reais para suas estimativas, como eu já havia dito.

Mas algumas tarefas essenciais devem ter seu tempo conhecido o quanto antes, aquelas coisas que todos os projetos terão, por exemplo:

• Um CRUD completo (listagem, inclusão, alteração e exclusão de registros), contando tanto o tempo de análise, modelagem do banco, backend, frontend, e testes
• Uma autenticação simples (email e senha)
• Uma autenticação utilizando redes sociais
• Um perfil de usuário, com foto, informações textuais e dados obtidos dinamicamente, com opção de alteração (incluindo upload de foto)
• Um dashboard cheio de dados e gráficos
• Obtenção de permissão para notificações, armazenamento do token, implementação do envio, recebimento, exibição e deep link para o destino final

Vai mais de acordo com o tipo de projeto que você desenvolve, mas tente observar estes blocos para entende-los.

Concluindo

Espero que este post tenha te ajudado a entender um pouco mais como fazer uma estimativa, levando em considerações detalhes que possam ter passado despercebidos, tornando seu resultado mais assertivo.

Não deixe de baixar nossa planilha de estimativa para entender melhor seus projetos, e entre em contato conosco caso precise de alguma ajuda extra. Será um prazer lhe atender.