Como um desenvolvedor da Web estima o tempo de conclusão

É comum os desenvolvedores de software subestimarem o tempo necessário para criar um novo recurso. É uma das realidades do desenvolvimento de software.

Neste post, entrevistamos Caio Nogueira, CEO da UpSites, uma agência de criação de sites em São Paulo e conseguimos entender como um desenvolvedor normalmente estima um projeto para ajudar os comerciantes a entender o processo.

Desenvolvendo um botão de reordenar

Vamos supor que vou desenvolver um botão de reordenar para uma loja de comércio eletrônico. Esse botão permitirá que os clientes reordenem um produto com base em seus pedidos anteriores. O objetivo é incentivar pedidos repetidos usando os dados históricos de pedidos disponíveis.

Design novo botão. A primeira e mais visível tarefa é criar um novo botão na página do produto. Poderíamos começar com o botão existente de adicionar ao carrinho, mas precisaremos fazer algumas alterações nele.

  • Mova-o para fora do formulário HTML do add-to-cart e para o seu próprio formulário.
  • Estilize para que não seja tão visualmente distintivo como o botão existente “Adicionar ao carrinho”.

Clientes registrados apenas. Como esse botão se aplica apenas aos clientes que retornam, precisamos adicionar alguma lógica que os oculte de todos os outros.

A maioria dos sistemas de comércio eletrônico tem código para detectar se alguém está logado. Portanto, precisamos encontrar esse código e usá-lo com nosso botão de reordenar.

Clientes que compraram o produto. Também queremos mostrar o botão apenas para clientes que compraram este produto. Precisamos acessar seus pedidos e itens de linha.

Isso provavelmente exigirá algumas consultas ao banco de dados para obter todos os dados de que precisamos.

Também precisaremos verificar o desempenho dessas consultas, porque o tempo de carregamento das páginas do produto é crítico. Isso significa que podemos precisar adicionar tempo de desenvolvimento para otimização de desempenho.

Conecte o botão ao servidor. Agora que sabemos quem verá o botão, precisamos conectá-lo ao servidor para que ele realmente faça alguma coisa quando clicado.

Primeiro, precisamos envolver o botão em um formulário HTML. Também precisaremos incorporar o ID do produto em um campo oculto para que o servidor saiba a qual produto o cliente está olhando.

Também precisaremos de uma URL criada no servidor para este formulário – um endpoint. Dependendo do sistema de comércio eletrônico, isso pode ser fácil ou difícil. Em Ruby on Rails, por exemplo, precisamos adicionar uma rota para a URL e um controlador para manter a lógica do servidor.

Com o formulário, dados ocultos, URL e uma área para manter a lógica do servidor, conectamos o botão ao servidor. Mas ainda não faz nada.

Encontre produtos em pedidos anteriores. Com o desenvolvimento de front-end completo, agora podemos nos concentrar no backend e no objetivo real do botão.

Primeiro, usaremos o ID do produto enviado com o formulário e procuraremos esse produto nos pedidos do cliente. Para fazer isso, vamos acessar o banco de dados e encontrar o produto que precisamos. Como já fizemos uma versão semelhante disso – agrupando o ID do produto para que o servidor saiba qual produto o cliente está visualizando -, poderemos usar essas mesmas consultas, mas com alguns pequenos ajustes para encontrar o item de linha do produto em um pedido.

Quando tivermos o item de linha, podemos copiá-lo para o carrinho juntamente com quaisquer opções ou tamanhos solicitados pelo cliente.

Redirecionar usuário para o carrinho. Finalmente, agora que o produto foi adicionado ao carrinho, queremos redirecionar o cliente para a página do carrinho, para fazer o checkout.

Teste tudo. Durante todo o desenvolvimento, também precisaremos testar as funcionalidades à medida que avançamos – pelo menos alguns testes básicos para cada etapa.

Obtendo o código ao vivo. Como etapa final, todo esse código precisa entrar no servidor da web. Às vezes isso é fácil e leva apenas alguns minutos. Outras vezes, para projetos grandes, há semanas de agendamento, atrasos e tarefas adicionais imprevistas.

Muitos desenvolvedores perdem essa parte em suas estimativas. Eles chamam um recurso “concluído” mesmo quando não está no site real.

Mais complexo do que parece

O que pode ser surpreendente para os não desenvolvedores é a complexidade de implementar um botão de reordenar, um pequeno recurso.

É aparentemente simples, mas exigia design gráfico, lógica de front-end, formulários HTML, consultas de banco de dados e alterações de back-end.

É por isso que muitos recursos de software parecem demorar mais do que deveriam. Eles são como icebergs. A parte visível é pequena, mas há uma enorme quantidade de trabalho debaixo da superfície.

Um bom desenvolvedor passará por esse processo e fornecerá estimativas que incluem tudo. Um desenvolvedor medíocre ignorará as tarefas e poderá apenas estimar o tempo para simplesmente colocar o botão na página. O trabalho de funcionalidade real pode levar quatro vezes mais tempo.

E os passos que descrevi acima não cobrem tudo. Tendo rapidamente pensado sobre isso, percebo que há perguntas adicionais que precisarão ser respondidas antes que o desenvolvimento possa começar, o que poderia aumentar a estimativa.

  • E se houver vários pedidos com esse produto? Devemos usar o mais recente? Ou devemos ter um pop-up pedindo ao cliente para escolher um?
  • E se o cliente quiser reordenar, mas com uma opção ou variante diferente? Ele pode mudá-lo no carrinho ou ele terá que remover o que adicionamos e depois adicionar o novo? Isso economiza tempo com o botão normal de adicionar ao carrinho?
  • Seria mais sensato simplesmente dizer aos clientes o que eles pediram da última vez e deixar que eles escolhessem a opção desta vez – reordenar ou comprar novamente? (Isso é o que a Amazon faz.)
  • E se a primeira versão do design e layout do botão não parecer correta? O desenvolvedor deveria ter mudado?

Cada uma dessas questões revela uma suposição, uma área que pode ser uma potencial falta de comunicação ou algo que talvez precise ser discutido. Cada um pode afetar a estimativa.

Um processo difícil

Em suma, estimar o tempo de desenvolvimento é difícil. Muitos projetos parecem simples, mas são, na verdade, complicados.

Os comerciantes devem fazer muitas perguntas antes de lançar um novo projeto de desenvolvimento. Pergunte ao desenvolvedor para obter detalhes ou esclarecimentos sobre qualquer coisa que pareça vaga. Poderia estender o tempo para montar uma estimativa, mas a estimativa seria mais precisa e realista

Qual você preferiria ter: uma estimativa do projeto de 40 horas que realmente leva 40 horas, ou uma estimativa de 10 horas que leva 40? O primeiro que você pode planejar. O segundo estraga tudo.