Nota do autor (maio de 2026): Escrevi isto em dezembro de 2023, ao completar um ano em Viseu. É o resumo de um ano de aprendizagem em contexto industrial real. A lição mais importante que aprendi não foi técnica.

O Meu Primeiro Ano em Portugal: Como Construí um Sistema de Produção Industrial do Zero

Semana 1: a realidade da fábrica

Cheguei à fábrica do SYSteel Group em Viseu com o mesmo instinto que qualquer programador traz a um novo projeto: perceber o sistema, mapear os componentes, identificar os pontos de melhoria.

Mas antes de perceber o sistema, tive de perceber a fábrica.

O que vi na primeira semana foi uma engenharia de precisão extraordinária no corte de aço: máquinas de plasma a cortar com tolerâncias de milímetro, quinadoras a dar forma a estruturas metálicas com exatidão repetível, processos de granalhagem e tratamento superficial que exigem controlo técnico real.

E ao lado dessa precisão técnica: ordens de produção em papel. Notas manuscritas que viajavam do escritório para o taller. Excel com estados de encomendas atualizados à mão. Operadores que tinham de ir a pé ao escritório perguntar qual era a próxima prioridade.

A distância entre a precisão do metal e a gestão da informação era o problema que vim resolver.

Ouvir antes de construir

O erro mais dispendioso na transformação digital é construir antes de ouvir. Já o vi em projetos alheios e vivi-o em primeira mão nas minhas primeiras tentativas com o TALS — quando construía funcionalidades que ninguém na comunidade surda tinha pedido.

No SYSteel, decidi fazer o oposto.

Pus o capacete e os sapatos de segurança. Fiquei na nave de produção. Perguntei aos operadores das máquinas de plasma a mesma questão de formas diferentes: "O que é que te tira mais tempo no dia?", "Em que momento do trabalho te sentes mais bloqueado?", "Que informação precisas que agora não tens à mão?"

A resposta foi consistente em todos: "Não sei qual a peça a seguir nem onde está o resto da encomenda."

Não me diziam que o sistema era lento ou que a interface era complicada. Diziam-me que a informação de que precisavam para fazer bem o trabalho simplesmente não chegava onde eles estavam. O problema não era técnico — era de fluxo de informação.

Essa compreensão redefiniu completamente o design do SYSControl: não como uma ferramenta de controlo de gestão, mas como um assistente para o operador que está à frente da máquina. A diferença é subtil mas fundamental para a adoção.

As decisões técnicas e o porquê

Node.js para o backend. Familiar para mim, suficientemente performante para as necessidades do projeto, e com um ecossistema maduro de bibliotecas para o tipo de operações necessárias.

A decisão crítica foi o Socket.io para as atualizações em tempo real. Numa fábrica industrial, um atraso de cinco segundos no ecrã do operador não é um inconveniente — é uma operação de máquina a executar com informação desatualizada. Se o escritório muda a prioridade de uma encomenda, o ecrã da fábrica tem de refletir isso instantaneamente, não na próxima atualização de página.

Desenhei o SYSControl como um sistema nervoso digital para a fábrica: cada mudança de estado no escritório propaga-se instantaneamente a todos os pontos da fábrica que precisam saber.

SQLite para a base de dados na primeira versão, deliberadamente. PostgreSQL seria mais escalável, mas a prioridade era velocidade de implementação e simplicidade de manutenção num ambiente sem DBA. Construir a versão mais simples que resolve o problema é sempre melhor do que construir a versão mais elegante que chega tarde.

O primeiro protótipo e a primeira reação real

Instalei o primeiro tablet junto a uma máquina de plasma. A interface era limpa: o nome da peça atual, o estado da encomenda completa, o botão para marcar a peça como terminada.

O primeiro comentário do operador foi imediato e completamente inesperado: "Os botões são demasiado pequenos para os meus dedos com luvas."

Tinha passado semanas a desenhar a interface pensando em usabilidade padrão de software empresarial. Não tinha pensado que os utilizadores a iriam usar com luvas de trabalho de couro espesso, num ambiente com poeira metálica, com os dedos menos sensíveis pelo frio do inverno português.

Foi a lição de UX industrial mais direta que poderia ter recebido.

Redesenhei toda a interface com uma nova premissa: cada elemento táctil deve ser utilizável com luvas, os contrastes devem ser visíveis sob iluminação industrial mista (luz de naves + focos de máquinas), e não pode haver texto pequeno nem elementos que exijam precisão no toque.

Os problemas técnicos que não estão no Stack Overflow

O ambiente do SYSteel tem características que nenhum tutorial de desenvolvimento web contempla.

A rede WiFi industrial. As interferências eletromagnéticas das máquinas de corte plasma e as estruturas metálicas das naves degradam o sinal WiFi de forma imprevisível. Implementei lógica de reconexão automática e armazenamento local (offline-first) para que se um tablet perder a ligação, continue a funcionar com dados locais e sincronize quando a rede regressar. O operador nunca vê um ecrã em branco.

Hardware legado. Alguns computadores do escritório corriam versões antigas de Windows sem atualizações. O sistema teve de ser compatível desde o início com browsers desatualizados, sem assumir ES6 ou APIs modernas em todos os clientes.

O primeiro crash em produção. Chegou aos três meses, numa segunda-feira de manhã. Um edge case na lógica de sincronização que não tinha aparecido nos testes. Resolvi-o em quinze minutos, antes do turno da tarde começar, sem afetar operações críticas. Gerir esse incidente — diagnóstico rápido, fix sem pânico, comunicação transparente com a equipa de direção — foi tão importante como o código em si.

A adoção: o problema mais difícil

A resistência inicial dos operadores não foi indiferença — foi desconfiança ativa.

"Vieste para nos vigiar." "Isto é para o chefe saber exatamente quanto tempo demora cada peça." "Agora vão saber se nos sentamos cinco minutos."

Essas preocupações eram legítimas. A tecnologia de monitorização na indústria tem uma longa história de ser usada como instrumento de controlo laboral, não como ferramenta de ajuda. Se não enfrenta isso diretamente, a adoção nunca chega.

Mudei completamente o enquadramento. Em vez de apresentar o SYSControl como um sistema de gestão de produção, apresentei-o como: "Vim evitar que caminhes dez vezes por dia ao escritório perguntar o que fazer a seguir."

Esse enquadramento funcionou porque era verdade. A maior frustração que os operadores expressavam não era o trabalho em si — era a interrupção constante de ter de ir buscar informação que devia estar disponível onde eles estavam.

Quando viram que a app lhes poupava passos físicos e lhes dava autonomia para saber exatamente o que fazer a seguir sem perguntar, a atitude mudou. Os operadores que mais resistiam tornaram-se os mais ativos a reportar bugs e a sugerir melhorias. A transformação digital não se impõe — vende-se como uma melhoria da vida quotidiana no trabalho.

Os números ao fim do primeiro ano

Ao fechar o primeiro ano do SYSControl em produção, os resultados eram concretos:

• 90% de redução de papel na área de corte: as ordens de produção são geridas inteiramente no sistema
• Comunicação escritório-fábrica em tempo real: o que antes demorava horas (uma pessoa a caminhar ou a ligar) passou a ser instantâneo
• Redução estimada de 15% nos tempos mortos das máquinas, por ter a informação da peça seguinte pronta antes de terminar a atual
• Zero interrupções por falta de informação no turno da tarde, que antes dependia das notas do turno da manhã

Mas o número que mais me importava não era nenhum desses.

Era ver um operador veterano — alguém com 20 anos na fábrica que nunca tinha tocado num tablet — deslizar o dedo para marcar uma peça como terminada e sorrir porque "agora está tudo mais claro". Esse operador tornou-se o maior defensor do SYSControl dentro da nave.

Esse é o meu verdadeiro KPI.

O que aprendi que não está em nenhum curso de desenvolvimento web

Os cursos de desenvolvimento web ensinam JavaScript, frameworks, padrões de arquitetura, boas práticas de código. O que não ensinam:

O processo antes do código. 50% do tempo num projeto de transformação digital bem-sucedido é passado a perceber o processo que vais digitalizar. Se não percebes o processo humano e físico, o código apenas digitaliza o caos.

A política interna de uma empresa industrial. Quem tem realmente autoridade sobre o quê, que tensões existem entre departamentos, por que razão certas decisões são tomadas de certa forma mesmo quando parecem irracionais de fora. Perceber isso antes de propor mudanças evita implementações tecnicamente perfeitas que morrem por resistência organizacional.

Como vender uma mudança a quem preferia que tudo ficasse igual. A competência mais subestimada na transformação digital não é técnica — é a persuasão empática. Perceber o medo genuíno por trás da resistência e responder a esse medo específico, não ao medo genérico "da mudança".

Sou um programador que escreve JavaScript. Mas antes de escrever a primeira linha de código, sou um engenheiro de campo que põe o capacete e aprende o processo que vai digitalizar.

Essa ordem importa.