O contexto
Uma PME cuja atividade assenta em intervenções em casa dos clientes: técnicos na estrada, planeamentos que mudam, folhas de intervenção para preencher no local e levar de volta ao escritório.
Antes do projeto, tudo isto assentava em folhas de cálculo, impressões e telefonemas. Funciona — até certo volume.
O desafio
A armadilha, neste tipo de software, é conceber para quem compra em vez de para quem usa.
O gestor quer visibilidade: onde estão as equipas, o que foi feito, o que falta faturar. O técnico, esse, está de pé, numa casa das máquinas mal iluminada, com uma só mão livre e às vezes sem rede. Se a ferramenta lhe der mais trabalho do que o papel que substituiu, não será usada — e um software de negócio que o terreno contorna não produz nenhum dado fiável.
E era preciso conviver com o existente. A empresa já gere a sua atividade com um sistema de gestão: os seus clientes, os seus contratos, os seus técnicos e as suas folhas vivem lá há anos. Substituí-lo não era pedido, nem razoável, nem financiável. O novo software tinha portanto de se instalar ao lado, trabalhar sobre os mesmos dados, e nunca pôr em causa o que já funciona.
O que fizemos
- Uma API ligada à base do sistema de gestão existente. Os clientes, os contratos, os técnicos e as folhas continuam a ser propriedade do sistema histórico: lemo-los sem nunca alterar a sua estrutura. O que pertence em exclusivo ao novo software — férias, notificações, documentos internos — vive nas suas próprias tabelas, ao lado das outras.
- Uma regra estrita sobre a base partilhada: nenhuma evolução automática do esquema. Qualquer alteração passa por um script escrito, revisto e executado à mão. Numa base que não é nossa, o automatismo não é um conforto, é um risco.
- Uma aplicação móvel para os técnicos, com uma introdução de dados pensada para o terreno: percurso curto, campos reduzidos ao necessário, nada que pressuponha um teclado confortável.
- Um registo que sobrevive à falta de rede. O planeamento, as folhas e as leituras ficam guardados no telemóvel: o técnico preenche a folha numa cave, manda assiná-la no local, e a sincronização recupera quando a rede volta.
- Uma ferramenta de escritório, organizada em torno de um planeamento em calendário, para quem afeta as intervenções e acompanha o que falta faturar.
- Um desenvolvimento iterativo, entregue em pequenos incrementos em vez de uma migração única. Um software de negócio não se especifica corretamente à primeira: são os primeiros usos reais que revelam o que falta e o que nunca servirá.
O resultado
O software está em desenvolvimento contínuo desde 2024 e continua em evolução ativa — o que, numa ferramenta de negócio, é o melhor sinal possível: só se continua a investir naquilo que é usado. O sistema de gestão histórico, por seu lado, não mexeu.
Este projeto ilustra duas convicções. A primeira: num software de terreno, o critério de sucesso não é a riqueza funcional, é a taxa de adoção. Uma funcionalidade que ninguém preenche não vale nada, seja qual for a qualidade do seu código.
A segunda: quase nunca é preciso substituir o sistema histórico de uma empresa. Basta, na maioria das vezes, acrescentar-lhe o que lhe falta, onde os seus utilizadores precisam — o que custa uma fração do preço de uma substituição e não põe a atividade em causa.
Cliente abrangido por um acordo de confidencialidade
