Ir para o conteúdo
Custos e DecisãoSoftware à MedidaInteligência ArtificialAutomação

Quanto Tempo Demora um Projeto de Software à Medida ou de IA

Prazos reais por tipo de projeto, o que acontece em cada fase, e as quatro coisas do lado do cliente que atrasam mais do que qualquer decisão técnica.

Pedro Santos
Pedro Santos
Arquiteto de Software Principal
6 min de leitura
Quanto Tempo Demora um Projeto de Software à Medida ou de IA
Neste artigo
  1. Resposta curta, por tipo de projeto
  2. O que acontece dentro do prazo
  3. O que atrasa, por ordem de frequência
  4. Porque é que prazos muito curtos são um sinal de aviso
  5. Como encurtar o prazo sem cortar qualidade
  6. O que fazemos no diagnóstico

A seguir ao preço, é a pergunta mais frequente, e a que costuma receber respostas mais vagas. Vamos responder com prazos concretos, dizer o que acontece dentro de cada fase, e ser explícitos sobre o que atrasa, que é quase sempre o que ninguém antecipa.

Antes disso, um esclarecimento que muda a leitura de tudo o que vem a seguir: "pronto" não é um momento único. Há a data em que o sistema entra em produção com utilizadores reais, e há a data em que o sistema estabiliza. São coisas diferentes, com semanas de distância entre elas, e a maior parte das desilusões com prazos nasce de as confundir.

Resposta curta, por tipo de projeto

Para âmbito fechado, definido antes de começar:

  • Agente de IA único, ligado a um sistema: 6 a 10 semanas até produção.
  • CRM ou ERP à medida, primeira versão utilizável: 8 a 12 semanas.
  • Portal B2B ou extranet para clientes e fornecedores: 8 a 14 semanas, conforme o número de perfis de utilizador.
  • Plataforma de IA interna com vários agentes de departamento: 4 a 6 meses, faseada, com o primeiro agente em produção muito antes disso.
  • Automação de um processo de retaguarda bem delimitado: 4 a 8 semanas.

Estes números pressupõem uma coisa que não é dada: que existe alguém do lado do cliente disponível para responder a perguntas e decidir. Voltamos a isso, porque é o fator com mais peso no calendário real.

O que acontece dentro do prazo

O calendário de um projeto de 10 semanas divide-se, na prática, em quatro blocos, e a proporção entre eles surpreende quem espera que seja quase tudo programação.

Semanas 1 a 2, definição. Percorrer o processo com quem o executa hoje, identificar as regras que existem mas nunca foram escritas, e fechar o que fica dentro e fora do âmbito. É a fase que mais determina o resultado final e a que mais frequentemente é cortada quando alguém quer um prazo mais curto. Cortá-la não poupa tempo, adia-o.

Semanas 2 a 7, construção e integração. Aqui está o desenvolvimento propriamente dito, mas também a parte imprevisível: ligar-se a sistemas que já existem. Se o ERP tem API documentada, é trabalho previsível. Se não tem, o esforço pode duplicar sem que nada mude no ecrã final, e é sobre isso que escrevemos no artigo sobre integrar IA no software que a empresa já usa.

Semanas 6 a 9, validação com uso real. Não é uma demonstração. É pôr o sistema à frente de quem vai trabalhar com ele todos os dias e recolher o que não funciona. Aparecem sempre casos que ninguém tinha mencionado na definição, porque são óbvios demais para quem os faz há anos.

Semanas 9 a 10, entrada em produção e acompanhamento. Migração de dados, formação, e o período em que a equipa está atenta ao que acontece quando o sistema encontra a realidade toda de uma vez.

Depois disto, conte com mais quatro a seis semanas de ajuste com utilização real. Não é sinal de problema, é como qualquer sistema de gestão se comporta: os primeiros dias de uso genuíno revelam mais do que qualquer sessão de testes.

O que atrasa, por ordem de frequência

Vale a pena ser direto, porque três destes quatro fatores estão do lado do cliente e são todos resolúveis com antecedência.

Acessos a sistemas de terceiros. É o campeão. Um ERP mantido por um fornecedor externo, um acesso a base de dados que precisa de aprovação, uma conta de serviço que demora três semanas a ser criada. Nenhum destes prazos depende da equipa que constrói, e todos podem ser desbloqueados antes de o projeto arrancar.

Regras de negócio que nunca foram escritas. Descobre-se a meio que há três formas de calcular uma comissão, dependendo de quem se pergunta, e que ninguém tinha reparado nisso porque cada pessoa fazia da sua maneira. Isto não é falha de ninguém: é o normal em operações que cresceram sem sistema. Mas exige uma decisão, e a decisão exige alguém com autoridade para a tomar.

Ausência de um interlocutor com decisão. Um projeto que depende de comité para cada resposta perde uma a duas semanas por ciclo. Um projeto com uma pessoa que conhece o processo e pode decidir avança ao ritmo do desenvolvimento.

Alargamento de âmbito a meio. Aparece quase sempre com boas intenções: já que estamos aqui, aproveitava-se para incluir também. A forma saudável de lidar com isto é registar e deixar para a fase seguinte, com o seu próprio prazo e preço. Absorver no âmbito corrente é o que transforma dez semanas em cinco meses.

Porque é que prazos muito curtos são um sinal de aviso

Se uma proposta promete um sistema de gestão em produção em três semanas, há duas explicações possíveis e nenhuma é boa notícia.

Ou o âmbito é muito menor do que aquilo que se discutiu, e vai perceber isso quando pedir a primeira alteração. Ou o prazo conta apenas desenvolvimento e deixa de fora definição, integrações e validação. Essas fases não desaparecem por ficarem fora do calendário: reaparecem depois, sob a forma de atraso, e nessa altura já não há orçamento para elas.

O mesmo raciocínio aplica-se ao preço, aliás. É a mesma conversa vista de outro ângulo, e os intervalos estão no artigo sobre quanto custa implementar IA numa empresa em Portugal.

Como encurtar o prazo sem cortar qualidade

Há três decisões que encurtam prazos de forma real, e nenhuma delas é pedir à equipa que trabalhe mais depressa.

Reduzir o âmbito da primeira versão é a mais eficaz. Um sistema que faz bem metade do que se imaginou, em produção em oito semanas, gera aprendizagem que a versão completa não geraria em vinte. A segunda fase fica mais barata porque já se sabe o que interessa.

Preparar os acessos antes do arranque poupa semanas inteiras. Se o projeto vai tocar num sistema gerido por terceiros, essa conversa pode começar hoje, mesmo antes de haver contrato.

Nomear uma pessoa com decisão, e libertar-lhe tempo, é o que separa um projeto que anda de um projeto que espera.

O que fazemos no diagnóstico

Olhamos para o processo concreto, para os sistemas que já existem e para quem vai usar o resultado, e devolvemos um calendário com fases, datas e o que é preciso de cada lado em cada uma. Se o prazo que faz sentido não for compatível com o que precisa, dizemos antes de começar.

O diagnóstico é gratuito, não obriga a avançar e respondemos a pedidos de contacto em 48 horas úteis. Pode falar connosco ou ver como abordamos o desenvolvimento de software à medida.

Perguntas frequentes

Quanto tempo demora a construir um CRM ou ERP à medida?

Para um âmbito fechado e bem delimitado, 8 a 12 semanas entre o arranque e a primeira versão em produção com utilizadores reais. Sistemas que abrangem várias áreas da empresa ao mesmo tempo passam facilmente dos seis meses, e por isso recomendamos faseá-los.

E um agente de IA ligado aos nossos sistemas?

Tipicamente 6 a 10 semanas para um processo único em produção, incluindo integração, validação e acompanhamento. O prazo depende muito mais da forma de aceder aos dados do que da complexidade da IA em si.

Porque é que alguns fornecedores prometem prazos muito mais curtos?

Normalmente porque estão a contar apenas o tempo de desenvolvimento, deixando de fora a definição de regras, as integrações com sistemas de terceiros e a validação com utilizadores. Essas fases não desaparecem por não estarem no calendário: aparecem depois, como atraso.

O que é que atrasa mais um projeto de software?

Por ordem de frequência: esperar por acessos e credenciais de sistemas geridos por terceiros, decidir regras de negócio que nunca tinham sido escritas, e a ausência de uma pessoa do lado do cliente com autoridade para fechar decisões.

É possível ter alguma coisa a funcionar antes do prazo total?

Sim, e é assim que trabalhamos. Há sempre uma versão utilizável antes da versão completa, tipicamente a meio do calendário, para que a validação aconteça com uso real e não com uma apresentação.

Neumotik

Pronto para implementar na sua empresa?

Desenvolvemos software à medida que resolve exatamente os problemas descritos neste artigo. Diagnóstico gratuito e sem compromisso.