Como funciona o desenvolvimento de um sistema, do levantamento à manutenção

O desenvolvimento de um sistema sob medida passa por etapas que se repetem em quase todo projeto bem conduzido: conversa inicial e diagnóstico, levantamento do processo real, escopo da primeira versão, protótipo de telas, desenvolvimento em ciclos curtos, teste com dado real, treinamento, migração dos dados, ida para produção e, depois, suporte e evolução. O nome de cada etapa muda de fornecedor para fornecedor; a ordem e o que cada uma resolve, não.

Este guia descreve cada etapa do ponto de vista de quem contrata: o que acontece, o que a sua empresa precisa fazer ou decidir e o que costuma dar errado. Serve para quem vai começar um projeto e quer saber quanto vai ser exigido da própria equipe, e para quem já está num projeto e quer entender em que ponto ele está.

As etapas do desenvolvimento de software numa tabela

Algumas etapas andam em paralelo (a migração costuma ser preparada enquanto o desenvolvimento acontece), mas pular uma delas não faz o trabalho desaparecer: ele volta, mais caro, numa etapa seguinte.

Conversa inicial, diagnóstico e levantamento do processo real

Conversa inicial e diagnóstico

O que acontece. Você conta o problema, e o fornecedor tenta entender se ele pede mesmo um sistema sob medida. Às vezes a resposta é um software pronto, uma integração entre ferramentas que a empresa já tem ou uma automação pequena.

O que a empresa decide. Quem é o dono do projeto: a pessoa que conhece o processo e decide quando duas áreas discordam.

O que costuma dar errado. Chegar com a solução em vez do problema. "Quero um aplicativo" diz menos do que "os técnicos perdem a ordem de serviço e o faturamento atrasa". A solução pedida nem sempre é a que resolve.

Levantamento do processo real

O que acontece. Alguém acompanha o processo do começo ao fim: um pedido, uma ordem de serviço, um cadastro. Abre as planilhas de verdade, vê os documentos que circulam, anota quais sistemas continuam e como os dados passam de um para o outro, e conversa com quem executa, não só com quem gerencia. Quando há ERP ou CRM envolvido, o texto sobre integração de ERP, CRM e planilhas mostra o que precisa ser mapeado.

O que a empresa faz. Libera tempo de quem faz o trabalho e mostra o processo como ele é, não como está no manual.

O que costuma dar errado. Descrever só o caminho normal. As exceções (o cliente que paga em duas vezes, o pedido devolvido pela metade, o item sem código) são onde o sistema ganha ou perde a confiança da equipe. Exceção esquecida no levantamento vira retrabalho no desenvolvimento.

Escopo, priorização e protótipo de telas

Escopo e priorização: o que entra na primeira versão

O que acontece. Com o processo descrito, define-se a primeira versão: o trecho que mais custa hoje, completo o bastante para ser usado por pessoas reais. O resto vira uma lista priorizada para as versões seguintes. Esse escopo é a base do orçamento e do prazo, como mostra o texto sobre quanto custa desenvolver um sistema.

O que a empresa decide. O que fica de fora agora. É a decisão mais difícil do projeto e a que mais economiza.

O que costuma dar errado. Querer tudo na primeira versão. Sistema que tenta nascer completo demora, consome o orçamento e chega com regras que já mudaram.

Protótipo de telas

O que acontece. Antes de qualquer código, as telas principais são desenhadas e ligadas umas às outras, de modo que dá para clicar e seguir o caminho de um pedido do começo ao fim. Mudar um protótipo custa muito menos do que mudar um sistema construído.

O que a empresa faz. Revisa com quem vai usar, não só com a diretoria. O técnico de campo e a atendente enxergam problemas que o gestor não vê.

O que costuma dar errado. Aprovar o protótipo pela aparência e não pelo fluxo. Cor e logotipo mudam em minutos; um campo que falta no meio do processo pode mudar a estrutura do banco de dados.

Desenvolvimento em ciclos curtos com entregas visíveis

O que acontece. O sistema é construído em ciclos curtos, de uma a algumas semanas. No fim de cada ciclo existe uma versão funcionando no ambiente de teste, e não um relatório de andamento. As prioridades do ciclo seguinte são revistas com o que se aprendeu no anterior.

Esse desenvolvimento acontece num ambiente isolado: nada do que está sendo construído encosta na planilha ou no sistema que a operação usa até o dia da troca. É a primeira regra do nosso método, e é o que permite errar e corrigir sem que o cliente final perceba.

O que a empresa faz. Responde às dúvidas rápido e prioriza no começo de cada ciclo. Pergunta que fica uma semana sem resposta trava a equipe ou vira suposição, e suposição errada vira retrabalho.

O que costuma dar errado. Pedidos que chegam por fora, por mensagem direto ao desenvolvedor, sem passar pelo dono do projeto. E o oposto: ciclos que terminam sem nada para ver, só com a promessa de que na próxima fase vai aparecer.

Ambiente de teste, validação com dado real e treinamento

Validação com dado real

O que acontece. Cada versão é validada no ambiente de teste com os dados reais da empresa: a planilha de verdade importada, com as linhas tortas, os campos em branco e o cliente cadastrado duas vezes. O exemplo bonito da demonstração esconde justamente os problemas que vão aparecer no primeiro dia de uso.

Quando a cópia de teste contém dado pessoal, ela merece o mesmo cuidado da produção: acesso restrito a quem está no projeto e nada além do necessário. A LGPD, no artigo 46, pede medidas de segurança desde a fase de concepção do produto, e o ambiente de teste faz parte dessa fase.

O que a empresa decide. Quem testa. Basta uma pessoa que conheça a rotina e tenha algumas horas por semana, mas precisa ser alguém que faz o trabalho no dia a dia.

O que costuma dar errado. Testar só o caminho normal, ou testar com cinco registros quando a operação tem cinco mil. Lentidão, duplicidade e regra que falha no caso raro só aparecem com o volume e as exceções da operação real.

Treinamento

O que acontece. A equipe aprende a usar o sistema antes da troca, de preferência no próprio ambiente de teste, com casos tirados do dia a dia. Um guia de uso curto fica como referência.

O que a empresa decide. Quando liberar a equipe e quem será a referência interna, a pessoa a quem os colegas perguntam primeiro.

O que costuma dar errado. Treinar todo mundo de uma vez, numa apresentação, semanas antes da implantação. Quando o sistema entra em uso, ninguém lembra mais.

Migração de dados e ida para produção com caminho de volta

Migração de dados

O que acontece. Os dados da planilha ou do sistema antigo são limpos, padronizados e importados. Duplicidades são resolvidas, formatos são unificados e os totais são conferidos antes e depois da carga: número de clientes, saldo em aberto, pedidos do mês.

O que a empresa decide. Que histórico vem junto (tudo, os últimos anos ou só o que está em aberto) e quem confere os números.

O que costuma dar errado. Deixar a migração para a última semana. Ela costuma ser ensaiada mais de uma vez no ambiente de teste antes da carga definitiva.

Ida para produção

O que acontece. O sistema passa a ser o lugar oficial do processo. Há uma data combinada, um backup completo antes da troca e alguém acompanhando de perto a primeira semana. Em alguns processos vale manter planilha e sistema em paralelo por poucos dias, conferindo os números; em outros, o paralelo só dobra a digitação.

O que a empresa decide. A data, longe do fechamento do mês e da semana de mais movimento, e por quanto tempo a planilha antiga fica disponível só para consulta.

O que costuma dar errado. Subir sem caminho de volta. Se a versão nova se comporta mal com a operação rodando, a equipe precisa voltar à anterior de forma planejada, e não improvisar enquanto os pedidos se acumulam. Antes da troca, confira se o backup restaura de verdade; o texto sobre backup e teste de restauração mostra como. Nas nossas entregas, a versão anterior fica guardada, o retorno do banco de dados é escrito antes da atualização e a reversão se faz em um comando.

Suporte, manutenção e evolução depois da entrega

O que acontece. Sistema em uso nunca fica pronto. Há correção do que aparece com o uso, atualização de segurança das bibliotecas, ajuste por mudança de regra fiscal ou comercial e funções novas pedidas por quem usa. Cada versão nova passa pelo mesmo ambiente de teste antes de chegar à equipe. O monitoramento do sistema avisa quando algo sai do ar antes de o cliente reclamar.

O que a empresa decide. Por onde os pedidos de mudança entram (um canal só, priorizado pelo dono do projeto), o que conta como urgente e qual modelo de contrato cobre a manutenção.

O que costuma dar errado. Tratar a entrega como o fim do projeto e deixar o sistema um ano sem atualização. As correções de segurança acumuladas viram uma atualização grande e arriscada. Outro erro frequente é o código e a documentação ficarem só com o fornecedor; o texto sobre como escolher uma software house lista o que exigir em contrato para isso não acontecer.

Como se preparar para o primeiro projeto de sistema

Antes da primeira conversa com qualquer fornecedor, separe:

• uma descrição do processo em uma página, com quem faz cada etapa;
• as planilhas e os documentos que circulam hoje, mesmo desorganizados;
• a lista dos sistemas que continuam e de quem tem acesso administrativo a cada um;
• o nome do dono do projeto e de quem vai testar as versões;
• o trecho do processo que mais custa hoje, candidato à primeira versão.

Com esse material, a conversa inicial já começa como diagnóstico, e as etapas seguintes andam mais rápido. É por ele que começamos no desenvolvimento de sistemas sob medida da Locomotiva Tech, e quando o diagnóstico mostra que uma integração ou um software pronto resolve o problema, a proposta segue esse caminho em vez de um sistema novo.