Workforce Management
L'app tablet offline-first della piattaforma di workforce management di Unareti (gruppo A2A), usata ogni giorno dalle squadre sul campo al servizio di 3,5M+ utenze. Il mio progetto principale per sei anni.
In 30 secondi
Per sei anni sono stato lo sviluppatore Android dell'app da campo di uno dei più grandi progetti Salesforce Field Service in Italia: la piattaforma di workforce management di Unareti (gruppo A2A), al servizio di 3,5M+ utenze di elettricità, gas e acqua. Offline-first per necessità, abbastanza dinamica da gestire un catalogo di tipologie di ordini di lavoro in continua crescita, abbastanza affidabile per il pronto intervento. Nel percorso ho guidato un team fino a 4 persone e gestito il rapporto col cliente.
Contesto e problema
Unareti distribuisce elettricità, gas e acqua su 20.000+ km di reti in 200+ comuni, tra cui Milano e Brescia. La sua piattaforma di workforce management coordina un centinaio di schedulatori e centinaia di squadre sul campo, dal work order alla rendicontazione, in una logica multi-commodity e multi-società con un catalogo di tipologie di ordini di lavoro enorme e in continua crescita.
Le squadre lavorano dove la rete non arriva: cantine, seminterrati, sottoscala con i contatori. E una connessione debole è peggio dell'assenza di connessione, perché il sistema operativo si crede online e lascia partire chiamate che restano a metà. Alcuni dei dati raccolti sul posto, come le letture prese di persona sui contatori a casa del cliente, non si possono raccogliere due volte: se una lettura si perde, non si torna indietro.
La stessa app serviva anche il pronto intervento di Unareti, vincolato allo SLA di 1 ora fissato dall'Authority. Durante le ondate di calore estive a Milano l'esito di un intervento poteva dipendere dall'app, che tra le altre cose pilotava i comandi inviati ai contatori tramite una sonda Bluetooth. Un malfunzionamento qui non è una recensione negativa: è la faccia pubblica dell'azienda davanti a un cliente rimasto senza corrente.
Il mio ruolo
Sono stato sul progetto per tutta la mia permanenza in PIC (2015-2021), con l'app Android come focus principale. Col tempo sono arrivato a guidare un team fino a 4 persone (un altro sviluppatore Android più 2-3 tecnici di supporto), facendo da mentore ai profili junior, e ho gestito il rapporto col cliente: requisiti, stime, analisi tecniche, escalation. A contorno ho sviluppato anche parti del backend Salesforce con cui l'app dialogava (Apex, Process Builder, Flow) e lavorato con le integrazioni TIBCO e MuleSoft.
Decisioni tecniche
Offline-first progettato per la rete peggiore, non per quella media
Ogni funzionalità lavora su dati locali, sempre: la rete è un'ottimizzazione, mai un requisito. Il caso difficile non è il segnale assente ma quello scarso, quando il sistema si crede online e le chiamate partono e si bloccano a metà. Ogni chiamata remota era trattata come qualcosa che può fallire in ogni punto e riprendere in sicurezza più tardi, e la sincronizzazione era ottimizzata per essere rapida ed economica per squadre sempre in movimento.
Uno store locale a cui non è permesso perdere una lettura
Qualsiasi cosa inserisca l'operatore viene prima persistita in locale, sopravvive a crash e riavvii ed entra in una coda di sincronizzazione che non considera concluso nulla finché il server non ha confermato. Perdere una lettura era l'unico errore senza rimedio, quindi la durabilità ha vinto ogni compromesso contro velocità e comodità.
Conciliare il lavoro offline con un backend vivo
L'app si sincronizzava con Salesforce Field Service, dove le automazioni continuavano a modificare lo stesso dataset mentre il tablet era offline: una squadra poteva passare ore a modificare dati nel frattempo cambiati sul server. La sincronizzazione aveva regole di conflitto esplicite: cosa si fonde in automatico, quale lato vince, cosa deve tornare a una persona.
Un catalogo enorme di tipologie, zero schermate hard-coded
Nessun team può disegnare a mano una schermata per ogni tipologia di ordine di lavoro di un operatore multi-commodity. Le tipologie erano definite lato server come insiemi di campi variabili; l'app scaricava le definizioni e le interpretava a runtime, componendo input, informazioni e calcoli automatici per ogni tipologia. Una nuova tipologia poteva arrivare sul campo senza toccare l'app.
Un'interfaccia per chi preferiva la carta
Gli utenti erano tecnici esperti, molti vicini alla pensione, scettici all'idea di scambiare il flusso su carta con un tablet. La UI è stata progettata attorno alle loro abitudini e al loro vocabolario e rifinita di continuo con il feedback diretto delle squadre. L'adozione è stata trattata come una feature, con le sue iterazioni.
Debug senza bug report
Alle squadre non si poteva chiedere di replicare un bug o fornire dettagli tecnici. Così abbiamo costruito un sistema diagnostico dentro l'app: log su file locali, inviati a fine giornata al nostro server, dove script di analisi li setacciavano in massa a caccia di pattern ricorrenti e firme note. I problemi emergevano presto, senza dipendere dalle segnalazioni degli utenti.
Dentro i limiti di una piattaforma cloud
Salesforce, in quanto cloud multi-tenant, impone limiti stringenti su chiamate ed elaborazione. Frequenza di sincronizzazione, dimensione dei payload e batching sono stati progettati fin dall'inizio attorno a quei limiti, mantenendo l'app veloce senza mai sbattere contro i tetti della piattaforma.
Risultati
- fino a -40% tempi di intervento a livello di piattaforma
- 20.000+ km di reti servite
- 3,5M+ utenze servite
- 6 mesi dal kickoff alla prima release in produzione
- Una delle più grandi implementazioni Salesforce Field Service in Italia: centinaia di squadre sul campo ogni giorno, un centinaio di schedulatori sul back-end e l'adozione conquistata in una popolazione di utenti partita scettica. I risultati di piattaforma sono del team intero; l'app da campo era la mia parte.
Cosa ho imparato
Quando i dati non si possono raccogliere due volte, la durabilità batte tutto: storage e sincronizzazione si progettano prima attorno al guasto peggiore, e solo dopo si pensa alla velocità. E la rete peggiore non è quella assente: è quella che funziona a metà.
Il software riesce quando le persone lo usano davvero. Ascoltare utenti scettici e iterare sul loro feedback ha fatto per il progetto più di qualsiasi singola scelta tecnica, e trattare l'adozione come parte del prodotto è un'abitudine che mi è rimasta.