Quanto custa transformar um processo do seu negócio numa aplicação web? Para obter um orçamento útil, comece por definir o trabalho que a aplicação terá de permitir concluir — e as dúvidas que ainda impedem alguém de o estimar.

A nossa recomendação é separar o investimento em decisões sucessivas: compreender o processo, testar a parte incerta e só depois autorizar a construção. O Service Manual britânico segue este princípio: investigar o problema antes de assumir o compromisso de desenvolver um serviço. É uma referência de método, não uma obrigação para empresas portuguesas. (gov.uk)

Não apresentamos aqui uma tabela de preços. As fontes consultadas sustentam critérios de planeamento, mas não uma média representativa do mercado português. Um intervalo em euros sem âmbito definido daria uma precisão que não temos.

Antes de pedir um preço, escolha um processo completo

Imagine uma empresa que aluga equipamento a outras empresas. Pretende uma aplicação, acessível pelo navegador, para gerir reservas, saída de material, devolução e eventuais danos. Este é um exemplo hipotético para preparar o orçamento.

«Gestão de alugueres» ainda é uma descrição demasiado aberta. Para pedir propostas, escreva antes um percurso concreto:

1. O operador recebe o pedido e consulta a disponibilidade.

2. Reserva o equipamento para determinadas datas.

3. Regista a entrega e o estado do material.

4. Na devolução, identifica faltas ou danos.

5. Um responsável decide se encerra o processo ou pede uma regularização.

Depois acrescente as exceções: uma devolução parcial, uma reserva cancelada, uma máquina que fica indisponível durante o aluguer seguinte.

Use este percurso numa reunião com o fornecedor. Peça-lhe que assinale o que compreendeu, o que está por decidir e o que precisa de testar. A investigação inicial deve precisamente esclarecer utilizadores, necessidades e limitações antes da construção. (gov.uk)

Vale a pena desenvolver tudo?

Antes de autorizar uma solução à medida, peça uma demonstração de software existente com o seu processo real, incluindo a exceção mais difícil. Esta é uma forma de avaliar uma compra recomendada nas orientações de contratação tecnológica do GOV.UK. (gov.uk)

Se conseguir resolver o essencial por configuração, considere essa alternativa. Se os produtos disponíveis não suportarem as regras centrais, não se integrarem nos sistemas necessários ou exigirem adaptações profundas, o desenvolvimento à medida merece avaliação. São critérios de escolha, não uma garantia de que construir ficará mais barato. (gov.uk)

Divida o orçamento por decisões, não por páginas

Propomos três autorizações de despesa. Cada uma deve terminar com informação suficiente para decidir se vale a pena pagar a seguinte.

1. Levantamento: comprar clareza

Peça uma proposta delimitada para estudar o processo. Defina como entregas o percurso dos utilizadores, as regras conhecidas, as exceções, os sistemas envolvidos e uma lista explícita de dúvidas.

Exija também uma recomendação: adaptar uma solução existente, desenvolver uma aplicação ou simplificar primeiro o processo interno.

A decisão no final desta etapa é se existe um problema suficientemente bem definido para justificar mais investimento. Não aceite que a entrega seja apenas uma apresentação comercial com o mesmo pedido inicial reescrito.

2. Prova técnica: testar o que pode inviabilizar o plano

No exemplo do aluguer, imagine que a aplicação precisa de consultar um programa antigo para conhecer o equipamento disponível. Antes de orçamentar essa ligação como garantida, peça uma prova com dados representativos.

A documentação técnica do GOV.UK recomenda protótipos para verificar interfaces com outros sistemas e esclarecer limitações. Um desenho de ecrãs pode ajudar a discutir utilização, mas não substitui esse teste técnico. (gov.uk)

Defina antecipadamente a pergunta: conseguimos consultar e atualizar a disponibilidade, com as permissões e os tempos de resposta necessários? Peça resultados, limitações encontradas e consequências para o orçamento.

3. Primeira versão: concluir uma operação real

Autorize uma primeira versão com um percurso completo. Para este exemplo, poderá abranger da reserva à devolução, deixando relatórios especiais para uma fase posterior.

Não retire do âmbito uma exceção indispensável só para baixar o preço. Se a empresa recebe devoluções parciais, indique como serão tratadas desde o início, mesmo que a solução inicial envolva uma intervenção manual controlada.

Peça ao fornecedor que associe cada entrega a uma demonstração verificável. «Módulo de devoluções concluído» diz pouco. «O operador consegue devolver parte do material e manter o restante aluguer em aberto» permite aceitar ou rejeitar a entrega.

O que exigir nas parcelas menos visíveis

Reserve uma conversa própria para as ligações a outros programas. A documentação da Microsoft recomenda analisar separadamente cada integração: os dados podem circular em sentidos diferentes e ter requisitos distintos, mesmo quando ligam os mesmos sistemas. (learn.microsoft.com)

Na proposta, peça que cada ligação identifique:

  • Que informação entra e sai, e com que frequência.
  • Quem fornece documentação, acessos e ambiente de testes.
  • Como serão tratados erros e dados incompletos.
  • Que custos de terceiros ficam fora do desenvolvimento.

Faça também da segurança uma entrega verificável. A OWASP disponibiliza o ASVS, um referencial de requisitos para desenvolvimento e verificação de segurança de aplicações web, incluindo utilização na contratação. Peça ao fornecedor que identifique os requisitos aplicáveis e os testes incluídos, em vez de escrever apenas «aplicação segura». (owasp.org)

Para o exemplo do aluguer, proponha um teste simples: um operador sem autorização não deve conseguir aprovar uma cobrança por danos, nem contornar essa limitação alterando o pedido enviado à aplicação.

Uma ficha para autorizar o investimento

Use esta ficha interna antes de adjudicar. É uma proposta de trabalho, não um modelo de preços de mercado.

| Decisão | O que pedir por escrito |

| --- | --- |

| Quanto pagar pelo levantamento? | Preço, entregas, exclusões e condição de conclusão |

| Há alguma dúvida técnica bloqueante? | Teste proposto, custo e resultado necessário para avançar |

| Quanto custa a primeira versão? | Âmbito aceite, esforço previsto, preço e pressupostos |

| Como são cobradas alterações? | Método de estimativa e aprovação antes da execução |

| Quanto custa operar? | Alojamento, serviços externos, manutenção e suporte separados |

| Como continuar com outro fornecedor? | Entrega de código, documentação, dados e acessos acordados |

Para comparar cenários, propomos um horizonte de 24 meses. Some levantamento, provas técnicas, construção, preparação dos dados, entrada em utilização e despesas de operação nesse período. Inclua também o tempo que a sua equipa terá de disponibilizar.

Não compare apenas o pagamento inicial: as orientações do GOV.UK recomendam avaliar o custo total de utilização e preservar a possibilidade de mudar de tecnologia ou fornecedor. (gov.uk)

Quanto deve aprovar agora?

Se ainda não sabe como funciona o processo, peça orçamento para o esclarecer. Se o processo está definido mas uma ligação técnica é incerta, autorize primeiro o teste. Se já existem regras, limites e critérios de aceitação, peça o preço da primeira versão operacional.

O próximo passo é reunir quem executa e quem aprova o processo. Escolham uma operação, descrevam as exceções e marquem o que ainda não sabem. Envie esse documento aos fornecedores e peça que distingam preço firme, estimativa condicionada e trabalho excluído.

Assim, a decisão deixa de ser «quanto custa a aplicação que imaginámos?» e passa a ser «quanto precisamos de investir para pôr este processo a funcionar, e o que falta confirmar antes de assumir esse compromisso?».