Un’app può sembrare perfetta in demo. Schermate pulite, animazioni fluide, tutto funziona davanti al cliente nella sala riunioni. Poi va in produzione, e un operatore in magazzino la apre con un telefono vecchio, una connessione intermittente e dati che non coincidono con quelli del portale web che usa un’ora dopo.
Una demo dimostra che un’app funziona. La produzione dimostra che è stata progettata bene.
Il vero test inizia quando l’app esce dalla sala riunioni
Un’app aziendale vive in condizioni che una demo non mostra mai: rete instabile, dispositivi datati, dati che devono restare coerenti con altri sistemi usati dagli stessi utenti nello stesso momento. Un’app aziendale non deve funzionare bene quando tutto va bene. Deve continuare a funzionare quando niente va come previsto.
Un’app aziendale non vive da sola
Il problema, in questi casi, non è quasi mai l’interfaccia. È l’architettura che la sostiene. Un’app aziendale non è necessariamente un prodotto autonomo: spesso è un’interfaccia attraverso cui l’utente accede a un sistema più grande, che comprende ERP, CRM, portali e API già esistenti. Quando viene sviluppata come oggetto isolato, scollegato da quei sistemi, funziona bene finché resta un prototipo. Diventa un problema quando gli utenti iniziano a usarla ogni giorno insieme ad altri strumenti, aspettandosi che i dati tornino identici ovunque li guardino.
Quando due sistemi mostrano due verità diverse
Un caso reale, nel settore farmaceutico: un’app mostrava dati in conflitto con il portale web usato dalla stessa rete di distribuzione. Le due piattaforme interrogavano fonti differenti e applicavano logiche diverse di aggiornamento, un disallineamento strutturale che si traduceva in confusione operativa quotidiana per chi doveva fidarsi di quei numeri per lavorare. La soluzione non è stata correggere i sintomi caso per caso, ma eliminare la duplicazione della logica e portare entrambe le piattaforme verso lo stesso layer API, rendendolo l’unica fonte applicativa dei dati condivisi.
I problemi che una demo non può mostrare
Le difficoltà che emergono in produzione si distinguono su tre livelli diversi.
Problemi di utilizzo: dispositivi, performance, rete, compatibilità — quelli che riguardano l’esperienza concreta di chi usa l’app ogni giorno.
Problemi di sistema: sincronizzazione dati, integrazione, autenticazione, governance — quelli che toccano l’architettura, e che un test su simulatore, da solo, non può intercettare.
Problemi di continuità: documentazione, responsabilità, manutenibilità, dipendenza dal fornitore — quelli legati al ciclo di vita, che si manifestano mesi o anni dopo il rilascio.
La qualità si progetta prima del go-live
La tecnologia non dovrebbe essere il punto di partenza. È una conseguenza dei requisiti. La scelta tra nativo, cross-platform o PWA dipende da necessità hardware, utilizzo offline, performance, distribuzione, frequenza degli aggiornamenti — non da una preferenza tecnica a priori.
Lo stesso vale per la privacy. “GDPR by design” significa poco se resta uno slogan: nella pratica vuol dire minimizzazione dei dati, segregazione degli accessi, retention definita, cifratura.
Dove finiscono, temporaneamente, i dati aziendali sul dispositivo quando la connessione manca?
È una domanda che deve essere posta prima di scrivere la prima riga di codice, non quando l’app è già in produzione.
Un’app deve essere mantenibile anche da chi non l’ha sviluppata
Un progetto premium deve essere trasferibile, non solo funzionante.
Significa test su dispositivi fisici reali prima di ogni rilascio, non solo simulatori. Significa documentazione tecnica completa consegnata a go-live, così che il team del cliente, o un futuro fornitore, possa prendere in mano il progetto senza dipendere da chi lo ha scritto. Nessuna dipendenza da una sola persona, nessuna conoscenza che resta chiusa fuori dalla documentazione.
Un’app aziendale si misura nel tempo
Oggi gestiamo oltre 15 app aziendali già in produzione. Non consideriamo il go-live come la fine dello sviluppo, ma come il momento in cui il progetto deve dimostrare di essere pronto per il mondo reale. Le nostre app vengono approvate dagli store al primo invio, come risultato di un processo che porta i controlli su requisiti, sicurezza, comportamento e conformità prima della submission, non dopo un rifiuto.
Un’app aziendale non si giudica quando viene presentata. Si giudica quando entra nei processi dell’azienda e continua a funzionare mesi e anni dopo. È lì che si vede la differenza tra un prodotto consegnato e un sistema progettato per durare.
Prima di progettare la schermata, progettate il sistema in cui dovrà vivere. È da lì che comincia un’app aziendale progettata per durare.
