Projeto de software sob medida: etapas do diagnóstico à produção

A proposta de sistema chegou, foi aprovada e agora o gerente de operações tem uma pergunta que ninguém respondeu na reunião: o que acontece a partir daqui? Quanto tempo da equipe dele o projeto vai consumir, quem precisa estar nas conversas, em que momento o pessoal de campo começa a usar e o que acontece com a planilha que roda a operação hoje. Quem nunca contratou desenvolvimento costuma descobrir essas respostas no meio do caminho, quando mudar custa mais.

Este artigo descreve as etapas de um projeto de software sob medida, do diagnóstico à produção, e o que a sua empresa entrega e decide em cada uma. No fim há um roteiro para acompanhar o projeto, que serve com qualquer fornecedor. Se você ainda está decidindo se vale construir ou comprar, comece pelo artigo sobre sistema sob medida ou software pronto.

O que é um projeto de software sob medida?

Um projeto de software sob medida é o trabalho de transformar um processo específico da sua empresa em um sistema que roda em produção, com as pessoas usando no dia a dia. Ele começa pelo entendimento do problema, passa pela construção em partes e continua depois da entrada em uso, porque a operação muda e o sistema acompanha.

A primeira etapa recebe nomes diferentes: levantamento, descoberta, diagnóstico. O manual de serviços digitais do governo britânico, uma das referências públicas mais detalhadas sobre o assunto, chama de discovery e resume o objetivo assim: antes de se comprometer a construir, é preciso entender o problema que precisa ser resolvido. O mesmo texto diz que não se deve começar a construir nessa fase, e que é comum chegar com uma solução pronta ("precisamos de um mapa interativo") quando o trabalho é transformá-la em problema ("como as pessoas acham o atendimento mais próximo?").

Nos nossos projetos, o diagnóstico começa com uma conversa com quem decide e com quem opera, e termina com escopo, prioridades e proposta. É assim que descrevemos o processo na página de sistemas web sob medida.

Por que tantos projetos de software travam antes da produção?

A maior parte dos projetos que travam pula o entendimento do problema ou adia demais o primeiro uso real. Quando o escopo nasce de uma lista de telas, o sistema reproduz o que alguém imaginou, e não o que a operação faz. Quando a entrega acontece toda no fim, os erros de entendimento aparecem todos juntos, perto do prazo.

Os princípios do Manifesto Ágil, escritos em 2001 por um grupo de desenvolvedores, tratam exatamente desses dois pontos. Um deles pede entregar software funcionando com frequência, de algumas semanas a alguns meses, com preferência pelo prazo mais curto. Outro diz que software funcionando é a principal medida de progresso. Um terceiro diz que as pessoas de negócio e os desenvolvedores devem trabalhar juntos diariamente durante o projeto.

Nas empresas de operação há um terceiro motivo, mais concreto: quem aprova o projeto raramente é quem usa o sistema. O diretor aprova, mas quem vai abrir o celular no cais, na portaria ou dentro de um tanque é outra pessoa. Se ela não participa, as exceções do dia a dia (o turno da noite, a terceirizada que chega sem documento, a área sem sinal) só aparecem quando o sistema já está pronto.

Quais são as etapas, do diagnóstico à produção?

As etapas são cinco: diagnóstico, escopo e proposta, primeira versão, implantação e evolução. A tabela mostra o que acontece em cada uma e o que cabe à empresa contratante.

Duas observações sobre a tabela. A primeira é que a coluna "o que a sua empresa entrega" nunca fica vazia. Um fornecedor consegue escrever código sozinho, mas não consegue saber sozinho como funciona a sua operação. A segunda é que a etapa de evolução não tem fim marcado. O sistema mais antigo que mantemos, a plataforma de operação de uma base de apoio portuário, começou pelos processos de segurança e foi ganhando módulos conforme a operação pedia. Hoje o banco de dados tem mais de 160 tabelas, e todos os módulos usam o mesmo cadastro de pessoas, empresas e locais.

Como acompanhar o projeto etapa por etapa?

O jeito mais simples de acompanhar é conferir, ao fim de cada etapa, se o que dependia da sua empresa foi entregue e decidido. O roteiro abaixo reúne esses pontos na ordem em que aparecem.

Use o roteiro como pauta das reuniões de acompanhamento. No diagnóstico, os itens mais esquecidos são as exceções e os sistemas vizinhos. Vale pedir a cada área que descreva o pior dia do mês, porque é nele que o processo mostra as regras que ninguém escreveu. Na primeira versão, o item que mais pesa é o responsável com tempo reservado. Sem ele, cada ciclo termina sem validação e os ajustes se acumulam para o fim.

O item sobre o que fica de fora também merece atenção. Uma proposta que só lista o que entra deixa espaço para cada lado imaginar uma coisa. Quando a exclusão está escrita ("integração com o ERP fica para a segunda fase"), a conversa sobre prioridade acontece no começo, com calma.

Como colocar a primeira versão em uso?

A primeira versão entra em uso por um processo e um grupo pequeno de usuários, com o caminho antigo ainda disponível por um período combinado.

1. Escolha o processo que mais dói e que tem dono claro. Na base de apoio portuário, a plataforma começou pelos processos de segurança, como a permissão de trabalho, antes de chegar à manutenção e às horas extras.
2. Defina o grupo piloto: uma equipe, um turno ou uma unidade, com alguém que goste de testar e que tenha voz com os colegas.
3. Migre só os dados que o piloto precisa. Cadastros de pessoas, empresas e locais costumam vir primeiro, porque os próximos módulos vão reaproveitá-los.
4. Configure os perfis de acesso com quem conhece as funções. Cada perfil vê e altera só o que precisa.
5. Treine no processo real, com casos da semana, e não com dados de exemplo.
6. Acompanhe as primeiras semanas de perto e ajuste. Dúvidas repetidas de usuários costumam apontar uma tela que precisa mudar.
7. Combine a data em que o papel ou a planilha deixa de valer e cumpra. Dois caminhos abertos por tempo indefinido fazem a equipe voltar ao antigo.

No ERP de campo para limpeza industrial de tanques, o fluxo inteiro gira em torno de um número de referência único, que acompanha a limpeza da solicitação aos relatórios. Esse detalhe acabou com a confusão entre os códigos internos e o número que o cliente conhece, e é o tipo de coisa que só aparece quando quem opera participa do projeto.

E se o projeto depende de integração, de um sistema legado ou de área sem sinal?

Quando o projeto depende de outro sistema, a integração precisa ser verificada logo no diagnóstico, antes de entrar na proposta. É comum o sistema do outro lado expor menos do que se imaginava, e é ali que os prazos costumam escorregar. Na plataforma portuária, os painéis leem os dados do WMS direto do banco de dados SQL Server, sem substituir o WMS. Na central de comando para resposta a emergências ambientais, a jornada das equipes se integra à plataforma de gestão de projetos de campo do cliente.

Quando já existe um sistema antigo, a primeira pergunta é se ele ainda atende a operação. Se atende, modernizar por partes costuma ser o caminho mais seguro, com a operação usando o sistema o tempo todo. Se outra empresa começou o sistema, o projeto começa por uma avaliação do código e da infraestrutura. Tratamos disso em sustentação e modernização. No caso de transporte marítimo de passageiros, um sistema feito para um único operador está sendo redesenhado como plataforma para vários operadores, sem parar a operação que já usa a primeira versão.

Quando o trabalho acontece em embarcações, áreas industriais isoladas ou dentro de tanques, o uso sem sinal entra no escopo desde o início. O que precisa funcionar desconectado e como os dados sincronizam quando a conexão volta é uma decisão de desenho, tomada no diagnóstico. O artigo sobre PWA ou aplicativo nativo compara os dois caminhos para equipes de campo.

O que acontece depois que o sistema entra em produção?

Depois da produção, o sistema entra em sustentação: correções, atualizações de versão, monitoramento, backup e os ajustes que a operação pede. O manual britânico trata essa passagem na fase beta, que começa com um número limitado de usuários e recomenda manter o serviço antigo funcionando até o novo estar pronto para assumir. O texto também pede que a equipe tenha capacidade de continuar aprendendo e ajustando durante esse período, e que o suporte consiga atender usuários com dificuldades que ninguém previu.

Dois pontos merecem estar no contrato antes da virada. O primeiro é quem responde por falhas e por qual canal. O segundo é o acesso da sua empresa ao código, à infraestrutura e aos dados. Também é o momento de conferir a proteção de dados pessoais. A LGPD, no artigo 46, pede medidas de segurança técnicas e administrativas para proteger os dados pessoais, e o parágrafo 2º diz que elas devem ser observadas desde a fase de concepção do produto ou do serviço até a sua execução. Na prática, perfis de acesso, mascaramento de dados como CPF e registro de ações sensíveis entram no escopo desde o começo.

A evolução segue o ritmo da operação. Na central de emergências, as etapas e tarefas-modelo são configuradas por tipo de incidente, e a interface existe em português, inglês e espanhol porque equipes de idiomas diferentes usam o mesmo sistema. Esse tipo de requisito costuma aparecer depois que o sistema já está em uso, e o projeto precisa ter espaço para ele.

Quando um projeto sob medida não é o caminho?

Um projeto sob medida não é o caminho quando o processo ainda não está definido. Se cada equipe faz de um jeito e ninguém sabe dizer qual é o certo, o sistema só vai registrar a confusão. O primeiro trabalho, nesse caso, é desenhar o processo com quem opera. O próprio manual britânico diz que parar ao fim do diagnóstico não é fracasso quando a pesquisa mostra que esse é o melhor caminho.

Também não é o caminho quando o processo é igual ao de qualquer outra empresa, como folha de pagamento ou contabilidade. Para esses, um produto pronto resolve com menos custo e menos risco. E vale esperar quando a decisão depende de algo que o software não muda, como um contrato em renegociação ou uma norma em revisão.

Se o seu processo vive hoje em papel, planilha ou mensagens e você quer saber como ficaria um projeto para ele, a boosting.tech é uma empresa de software customizado que constrói e mantém sistemas a partir da operação que já existe. A conversa inicial não tem custo: combinamos dia e horário, entendemos o processo e o que precisa mudar, e depois enviamos uma proposta com escopo e prazo. Os detalhes estão em sistemas web sob medida.