Nota dell'autore (maggio 2026): Ho scritto questo nel dicembre 2023, al compimento di un anno a Viseu. È il riassunto di un anno di apprendimento in contesto industriale reale. La lezione più importante che ho imparato non è stata tecnica.

Il Mio Primo Anno in Portogallo: Come Ho Costruito un Sistema di Produzione Industriale da Zero

Prima settimana: la realtà dello stabilimento

Sono arrivato nello stabilimento di SYSteel Group a Viseu con lo stesso istinto di qualsiasi sviluppatore che arriva a un nuovo progetto: volere capire il sistema, mappare i componenti, identificare i punti di miglioramento.

Ma prima di capire il sistema, ho dovuto capire lo stabilimento.

Quello che ho visto nella prima settimana è stata un'ingegneria di precisione straordinaria nel taglio dell'acciaio: macchine al plasma che tagliano a millimetri di tolleranza, piegatrici che danno forma a strutture metalliche con precisione millimetrica, processi di sabbiattura e trattamento superficiale che richiedono controllo tecnico reale.

E insieme a quella precisione tecnica: ordini di produzione su carta. Note manoscritte che viaggiavano dall'ufficio al laboratorio. Excel con stati di ordini aggiornati a mano. Operai che dovevano camminare in ufficio per chiedere quale fosse la prossima priorità.

La distanza tra la precisione del metallo e la gestione dell'informazione era il problema che ero venuto a risolvere.

Ascoltare prima di costruire

L'errore più costoso nella trasformazione digitale è costruire prima di ascoltare. L'ho visto in progetti altrui e l'ho provato sulla mia pelle nei miei primi tentativi con TALS — quando costruivo funzionalità che nessuno nella comunità sorda aveva chiesto.

In SYSteel, ho deciso di fare il contrario.

Mi sono messo il casco e le scarpe di sicurezza. Mi sono fermato in laboratorio. Ho chiesto agli operai delle macchine al plasma la stessa domanda in formulazioni diverse: "Cosa è che più ti toglie tempo durante il giorno?", "In quale momento del lavoro ti senti più bloccato?", "Quale informazione ti serve che ora non hai facilmente?"

La risposta è stata consistente in tutti: "Non so quale pezzo viene dopo né dove è il resto dell'ordine."

Non mi dicevano che il sistema era lento, né che l'interfaccia era complicata. Mi dicevano che l'informazione che avevano bisogno per fare bene il loro lavoro semplicemente non arrivava dove loro erano. Il problema non era tecnico — era di flusso di informazione.

Quella comprensione ha ridefinito completamente il design di SYSControl: non come uno strumento di controllo gestionale, ma come un assistente per l'uomo che sta di fronte alla macchina. La differenza è sottile ma fondamentale per l'adozione.

Le decisioni tecniche e perché sono state prese così

Node.js è stata la scelta per il backend. Familiare per me, sufficientemente performante per le esigenze del progetto, e con un ecosistema maturo di librerie per il tipo di operazioni che servivano.

La decisione critica è stata Socket.io per gli aggiornamenti in tempo reale. In uno stabilimento industriale, un ritardo di cinque secondi nello schermo dell'operaio non è un disagio — è un'operazione di macchina che si esegue su informazioni non aggiornate. Se l'ufficio cambia la priorità di un ordine, lo schermo del laboratorio deve rifletterlo istantaneamente, non al prossimo refresh.

Ho disegnato SYSControl come un sistema nervoso digitale per la fabbrica: ogni cambio di stato in ufficio si propaga istantaneamente a tutti i punti dello stabilimento che hanno bisogno di saperlo.

SQLite per il database nella prima versione, deliberatamente. PostgreSQL sarebbe stato più scalabile, ma la priorità era velocità di deploy e semplicità di manutenzione in un ambiente dove non c'era un DBA. Costruire la versione più semplice che risolve il problema è sempre meglio che costruire la versione più elegante che arriva tardi.

Il primo prototipo e la prima reazione reale

Ho installato il primo tablet vicino a una macchina al plasma. Era un'interfaccia pulita: il nome del pezzo attuale, lo stato dell'ordine completo, il pulsante per marcare il pezzo come terminato.

Il primo commento dell'operaio è stato immediato e completamente inaspettato: "I pulsanti sono troppo piccoli per le mie dita con i guanti."

Avevo passato settimane a disegnare l'interfaccia pensando all'usabilità standard del software aziendale. Non avevo pensato che gli utenti l'avrebbero usata con guanti di lavoro in pelle spessa, in un ambiente con polvere metallica, con le dita meno sensibili per il freddo dell'inverno portoghese.

È stata la lezione di UX industriale più diretta che potessi aver ricevuto.

Ho riprogettato l'intera interfaccia con una premessa nuova: ogni elemento tattile deve essere operable con i guanti, i contrasti devono essere visibili sotto l'illuminazione mista (luce del capannone + fari delle macchine), e non può esserci testo piccolo né elementi che richiedono precisione nel tocco.

I problemi tecnici che non sono su Stack Overflow

L'ambiente di SYSteel ha caratteristiche che nessun tutorial di sviluppo web contempla.

La rete WiFi industriale. Le interferenze elettromagnetiche delle macchine al plasma e le strutture metalliche del capannone degradano il segnale WiFi in modo imprevedibile. Ho implementato logica di riconnessione automatica e archiviazione locale (offline-first) affinché se il tablet perde connessione, continua a funzionare con i dati locali e sincronizza quando la rete ritorna. L'operaio non vede mai una schermata bianca.

Hardware legacy. Alcuni computer di ufficio eseguivano versioni antiche di Windows non aggiornate. Il sistema ha dovuto essere compatibile da subito con browser non aggiornati, senza assumere ES6 né API moderne su tutti i client.

Il primo crash in produzione. È arrivato al terzo mese, un lunedì mattina. Un edge case nella logica di sincronizzazione che non era apparso nei test. L'ho risolto in quindici minuti, prima che iniziasse il turno di sera, senza che influisse sulle operazioni critiche. La gestione di quell'incidente — diagnosi veloce, fix senza panico, comunicazione trasparente con il team di direzione — è stata tanto importante quanto il codice stesso.

L'adozione: il problema più difficile

La resistenza iniziale degli operai non è stata indifferenza — è stata sfiducia attiva.

"Vieni a sorvegliarci." "Questo è perché il capo sappia esattamente quanto ci impiega ogni pezzo." "Adesso sapranno se ci prendiamo cinque minuti di riposo."

Quelle preoccupazioni erano legittime. La tecnologia di monitoraggio nell'industria ha una storia lunga di essere usata come strumento di controllo del lavoro, non come aiuto. Se non affronti questo di fronte, l'adozione non arriva.

Ho cambiato completamente l'approccio. Invece di presentare SYSControl come un sistema di gestione della produzione, l'ho presentato come: "Vengo a fare sì che non debba camminare dieci volte al giorno in ufficio a chiedere cosa fare."

Quel framing ha funzionato perché era vero. Il disagio più grande che gli operai esprimevano non era il lavoro stesso — era l'interruzione costante di dover cercare informazioni che dovrebbero essere disponibili dove stavano.

Quando hanno visto che l'app gli risparmiava passi fisici e gli dava autonomia per sapere esattamente cosa dovevano fare senza chiedere, l'atteggiamento è cambiato. Gli operai che più resistevano sono diventati i più attivi nel segnalare bug e suggerire miglioramenti. La trasformazione digitale non si impone — si vende come un miglioramento della vita quotidiana.

I numeri all'anno 1

Alla chiusura del primo anno di SYSControl in produzione, i risultati erano concreti:

• 90% di riduzione della carta nell'area di taglio: gli ordini di produzione sono completamente gestiti nel sistema
• Comunicazione ufficio-laboratorio in tempo reale: quello che prima tardava ore (una persona che camminava o chiamava) è passato a essere istantaneo
• Riduzione stimata del 15% dei tempi morti delle macchine, per avere l'informazione del pezzo successivo pronto prima di terminare quello attuale
• Zero interruzioni per mancanza di informazione nel turno di sera, che prima dipendeva da note del turno di mattina

Ma il numero che più mi importava non era nessuno di quelli.

Era vedere un operaio veterano — qualcuno che aveva 20 anni nello stabilimento e non aveva mai toccato un tablet — scorrere il dito per marcare un pezzo come terminato e sorridere perché "adesso tutto è più chiaro". Quell'operaio è diventato il maggiore difensore di SYSControl all'interno del laboratorio.

Questo è il mio vero KPI.

Quello che ho imparato che non è in nessun corso di sviluppo web

I corsi di sviluppo web insegnano JavaScript, framework, pattern di architettura, buone pratiche di codice. Quello che non insegnano:

Il processo prima del codice. Il 50% del tempo di un progetto di trasformazione digitale riuscito si passa a capire il processo che stai per digitalizzare. Se non capisci il processo umano e fisico, il codice solo digitalizzerà il caos.

La politica interna di un'azienda industriale. Chi ha realmente l'autorità su cosa, quali tensioni esistono tra dipartimenti, perché certe decisioni si prendono in un certo modo anche se sembrano irrazionali da fuori. Capire questo prima di proporre cambiamenti evita implementazioni tecnicamente perfette che muoiono per resistenza organizzativa.

Come vendere un cambio a chi preferirebbe che tutto rimanesse uguale. L'abilità più sottovalutata nella trasformazione digitale non è tecnica — è la persuasione empatica. Capire la paura genuina dietro la resistenza e rispondere a quella paura specifica, non alla paura generica "del cambio".

Sono uno sviluppatore che scrive JavaScript. Ma prima di scrivere la prima riga di codice, sono un ingegnere di campo che si mette il casco e impara il processo che stai per digitalizzare.

Quell'ordine importa.