Articles

O que deve estar em uma estimativa detalhada de uma empresa de desenvolvimento de aplicações web e mobile

Todos os clientes querem saber o preço do projeto o mais rápido possível. Embora exista uma forma rápida de determinar o preço com uma estimativa aproximada, ela não mata a sede. É aqui que entra em jogo uma estimativa detalhada.

A cada vez que começamos a colaborar com um novo cliente, nossa empresa de desenvolvimento de aplicativos web e móveis prepara dois documentos abrangentes que revelam todos os melhores detalhes relacionados aos custos do projeto do nosso cliente.

Talvez você já tenha lido sobre por que e como fazemos estimativas aproximadas (se não, você deve definitivamente fazer isso). E agora é hora de descobrir tudo o que você sempre quis saber sobre as estimativas detalhadas no MindK.

O que é uma estimativa detalhada?

Uma estimativa detalhada é um documento de carne que lhe fornece uma discriminação abrangente dos custos do seu projeto.

Divide todo o escopo do trabalho em partes elementares – características.

Cada recurso é estimado separadamente por nossas equipes multifuncionais.

O tempo que leva para terminar cada recurso se soma para formar um orçamento detalhado para seu aplicativo.

Estimativa detalhada vs. estimativa aproximada

Se você quiser que coloquemos uma etiqueta de preço em uma idéia básica que você acabou de compartilhar conosco, nós lhe enviaremos de bom grado uma estimativa aproximada. Pode dar-lhe apenas uma ideia geral sobre os custos do seu projecto.

Um orçamento detalhado é um documento muito mais matizado e extenso.

Em orçamentos aproximados, dividimos a sua aplicação em enormes blocos de funcionalidade chamados épicos.

Em estimativas detalhadas, damos um passo além e dividimos cada épico em funcionalidades.

Antes de podermos escrever a estimativa detalhada, temos que reunir e documentar todos os requisitos, esclarecer todas as questões abertas e escrever a especificação (no caso de um modelo de compromisso de preço fixo usado para o projeto).

Esta forma podemos encontrar todos os detalhes necessários de antemão e fornecer a estimativa mais precisa como resultado.

Não pode haver hipóteses nesta fase, apenas asserções.

Estima detalhada vs. estimativa precisa

Quando se lida com estimativas, Detalhado não significa Preciso.

Aqui está a razão.

As estimativas verdadeiramente precisas só são possíveis após a conclusão da fase de Descoberta, prototipando a solução, escrevendo a especificação e aprovando o escopo detalhado dos trabalhos.

Para os projectos de preço fixo, só elaboramos uma estimativa detalhada após a conclusão da fase de Descoberta. Normalmente faturamos esta fase como um projeto separado.

Para os projetos Agile/Scrum, usamos uma abordagem diferente.

De acordo com esta metodologia, o desenvolvimento do produto é um processo dinâmico e altamente flexível. Seu principal objetivo é produzir uma solução pronta para uso a cada 2 a 4 semanas e adaptar-se ao feedback dos usuários.

Fazer uma estimativa definitiva para todo o projeto não se adequa realmente a esta abordagem.

Na maioria dos casos, você não pode realmente prever a forma que sua aplicação vai levar meses e anos no caminho. É por isso que para projetos Agile preferimos usar o que chamamos de Guesstimate.

Permite-nos preparar estimativas aproximadas, porém extremamente detalhadas sem perder uma tonelada de tempo na fase de Discovery.

O que constitui uma estimativa detalhada?

Uma estimativa detalhada no MindK geralmente tem três seções: a estimativa em si, os custos relacionados ao software e a análise de risco.

A Estimativa

A secção dá-lhe uma repartição de custos por característica para o seu projecto.

Para os projectos de preço fixo, apenas escrevemos o custo preciso de cada característica, mas para os projectos Agile, apenas podemos fornecer uma estimativa.

Nesta secção, só incluímos as características que são 100% confirmadas pelos nossos clientes. Se em algum momento eles decidirem adicionar um recurso, nós o estimamos separadamente e atualizamos o documento.

Se um projeto é complexo (ou seja, você precisa de uma aplicação web, um aplicativo iOS /Android, um chatbot, etc.), cada um desses componentes é estimado separadamente.

Cada recurso é escrito na forma de uma história de usuário. Esta é uma forma simplista de renderizar uma parte da funcionalidade do ponto de vista do usuário.

Lê tipicamente: Como um <role>, eu quero <feature> para que <advantage> (ou seja, como dono de um blog, eu quero um formulário de assinatura, para que eu possa conseguir assinantes para receber atualizações no novo post do blog).

As histórias de usuários são curtas, concisas e flexíveis. Mas o mais importante, elas são extremamente fáceis de entender, mesmo que você seja um novato total no mundo do desenvolvimento de software.

A estimativa detalhada inclui a repartição de custos para cada tipo de trabalho:

  • Análise de negócios;
  • Design;
  • Markup (HTML);
  • Desenvolvimento;
  • Assurance da qualidade;
  • Gestão de projectos (PM).

O custo de PM normalmente representa cerca de 25% do resultado final. A percentagem exacta depende de muitos factores:

  • Quanto mais complexo for um projecto, mais comunicação e gestão requer.
  • Quanto maior for a equipa mais desafiante se torna a sua gestão, o que resulta nas horas PM adicionais.
  • O número de integrações de terceiros também pode influenciar os custos de gestão. Além de ser mais um recurso para implementar (e gerenciar), APIs de terceiros muitas vezes requerem que nossos PMs entrem em contato com os provedores de serviços.

Por exemplo, a comunicação com grandes empresas (grandes bancos, grandes corporações, etc.) como provedores de API pode ser uma verdadeira dor no pescoço. O alto nível de burocracia e as rígidas estruturas hierárquicas podem transformar uma tarefa tão simples em uma tarefa excruciante.

Em uma subseção separada, listamos todas as características padrão.

Nossa experiência com o desenvolvimento móvel e web nos diz que certas características e tarefas estão presentes em todas as aplicações. Eles podem, por exemplo, incluir a configuração de servidores e ambiente de desenvolvimento, gerenciamento de projetos, lançamento do Google Play (para aplicativos Android) e assim por diante.

O custo de soluções de terceiros

Quando se trata do desenvolvimento de software, reinventar a roda é um esforço caro e muitas vezes inútil. Felizmente, cada tarefa padrão ou problema frequente no mundo de TI tem pelo menos uma solução pronta. Às vezes eles são gratuitos, mas na maioria dos casos você tem que pagar por eles.

Se para concluir um projeto precisarmos comprar algum software, serviço ou biblioteca de terceiros, nós estimamos seu custo e incluímos o valor no documento.

Se o seu projeto, por exemplo, suportar mensagens SMS, então teremos que pagar por um gateway SMS.

Se o design do seu site é baseado em um template específico pronto que você quer usar, então vamos adicionar o seu custo ao orçamento.

Or se os nossos clientes querem que os ajudemos com o alojamento, sugerimos-lhes as melhores opções (como Amazon Web Services, DigitalOcean, ou outros serviços comprovados). Assim, os custos associados com a hospedagem e manutenção do servidor aparecerão nesta seção.

Análise de risco

Todos os projetos comportam alguns riscos inerentes. O trabalho do Project Manager é identificá-los e desenvolver as estratégias para lidar com eles.

Embora as melhores práticas de gerenciamento de riscos, alguns dos riscos se materializam e impactam os custos de um projeto. Nós avaliamos cada risco potencial e os incluímos na estimativa detalhada.

Você só tem que pagar a quantia especificada se um determinado risco se transformar em um problema real. Caso contrário, você fica com o dinheiro.

Estas estimativas nos servirão como um seguro contra uma grande variedade de perigos que ameaçam o desenvolvimento do seu projeto.

Aqui estão os exemplos de categorias de risco que ocorrem no desenvolvimento do produto:

  • Qualidade/Técnica/Performance (i.e. uso de tecnologia nova ou excepcionalmente complexa, modificação de tecnologia, metas de saída impossíveis);
  • Gestão de projetos (i.e. alocação de fundos e tempo defeituosos, planejamento de projeto insuficiente);
  • Organizacional (i.e. falta de consistência entre os objetivos de custo, tempo e escopo, pouca priorização, apoio irregular);
  • Externo (ou seja, mudanças na legislação, problemas com fornecedores e subcontratados, clima);

Após a identificação dos riscos, o PM os prioriza e realiza uma análise de risco.

O objetivo é descobrir a probabilidade de cada risco em particular (ou seja, as probabilidades de sua materialização) e impacto (as conseqüências de sua materialização).

Um exemplo?

Como já mencionei, os provedores de API podem ser lentos em responder. Eles podem atrasar o envio da documentação necessária ou oferecer suporte de subparte. Este é um risco real sobre o qual devemos avisá-lo com antecedência. Então nós o colocamos na seção de riscos e ao mesmo tempo desenvolvemos uma estratégia efetiva de gerenciamento de riscos para minimizar a probabilidade da ameaça e seu impacto.

Wrapping Up

Agora você sabe o que esperar da estimativa detalhada no MindK. O documento lhe dará uma resposta exaustiva à questão do preço do seu projeto e também o ajudará na elaboração do orçamento. Finalmente, ele irá fornecer uma imagem clara do que você vai pagar.

Há mais alguma coisa que eu possa lhe dizer sobre os orçamentos detalhados no MindK? Basta nos deixar uma linha e eu darei uma resposta detalhada!

e-book agile development

  • 19
    Partilhas
  • 19