Come far sviluppare una web app aziendale

Una web app aziendale è un'applicazione che vive nel browser: si apre da un indirizzo, si aggiorna per tutti in una volta sola e non passa da un negozio di applicazioni. Si fa sviluppare descrivendo il processo che deve sostenere, non le schermate che vorresti, e rilasciandola per moduli partendo da quello che fa più male oggi. Le decisioni che pesano non sono tecniche: chi la userà, con quali permessi, e con quali sistemi già in casa deve parlare.

Se hai già deciso che ti serve uno strumento raggiungibile da qualunque postazione e ti chiedi come si passa dall'idea a un software che le persone usano davvero, qui trovi il percorso dal lato del committente, con le domande da fare al fornitore e i punti in cui i progetti slittano.

Quando conviene una web app (e quando no)

La web app è la scelta naturale in quattro situazioni. Quando le persone lavorano da postazioni diverse, in sede, da casa, dal portatile di un cliente, e non vuoi installare niente su ciascuna macchina. Quando le regole del processo cambiano spesso, perché nel browser una correzione arriva a tutti in poche ore. Quando devono entrare anche utenti esterni, clienti che consultano una pratica o fornitori che caricano un documento, ai quali puoi solo mandare un indirizzo. E quando lo strumento deve dialogare con sistemi già in rete, dal sito di vendita alla contabilità.

Non conviene quando l'uso è prevalentemente offline, per esempio ore di rilevazioni in un capannone senza copertura, quando servono funzioni profonde del telefono come la lettura continua di tag a contatto o il dialogo con terminali collegati, o quando la presenza in un negozio di applicazioni è un requisito commerciale.

Il confronto completo fra le due strade è nella guida su app nativa o web app: qui diamo per assunto che la scelta sia già caduta sul browser. Una precisazione utile: trasformare una web app in applicazione installabile è possibile, ma non è gratuito né automatico. Va messo a bilancio come un progetto a sé.

Cosa serve prima di iniziare

• Il processo da sostenere, scritto in termini di lavoro perso. Non "ci serve un portale", ma "ogni richiesta di intervento viene ribattuta in tre posti diversi". Mezza pagina che in azienda tutti riconoscono come vera.
• Una persona che decide. Una sola, con il potere di approvare un cambiamento senza tre riunioni e mezza giornata a settimana liberata davvero. È il fattore che sposta i tempi più di ogni scelta tecnica.
• L'elenco di chi la userà e da quali dispositivi. Ruolo, numero di persone, dispositivo prevalente: dodici addetti al banco con un tablet condiviso, quattro tecnici con il telefono personale, due in ufficio.
• I dati che esistono già e dove stanno. Fogli di calcolo, l'archivio del programma in uso, caselle di posta, cartelle condivise. Servono i file veri: quante righe sono, chi li aggiorna, quanti duplicati contengono.
• I sistemi con cui deve parlare, con il referente di ciascuno. Per ogni collegamento serve una persona da chiamare, non solo il nome del software: il ritardo tipico non è tecnico, è l'attesa di chi custodisce l'accesso.
• Un tetto di spesa e un orizzonte temporale, anche approssimativi: servono al fornitore per proporti un perimetro realistico, e a te per sapere oltre quale data il progetto perde valore.

Come si sviluppa, passo per passo

1. Mappa il processo reale, non quello dichiarato. Passa un'ora accanto a chi esegue il lavoro e chiedi cosa fa da quando arriva la richiesta a quando la pratica è chiusa, eccezioni comprese. Annota scorciatoie e file paralleli: sono il motivo per cui ti serve qualcosa su misura. Ottieni un elenco di attività vere, quasi sempre diverso dalle procedure ufficiali.
2. Decidi il perimetro del primo rilascio. Scegli l'attività che genera più lavoro manuale e scrivi anche cosa resta fuori: la contabilità non si tocca, la parte per i clienti si valuterà poi. Da qui il progetto diventa stimabile.
3. Definisci ruoli e permessi prima che qualcuno scriva codice. Elenca i profili e, per ciascuno, cosa può vedere, cosa può modificare e cosa non deve comparire. Ottieni una tabella di poche righe che evita la riscrittura più costosa, quella delle fondamenta.
4. Disegna le schermate dei due o tre compiti più frequenti. Non tutta l'applicazione: solo le operazioni che una persona ripete cinquanta volte al giorno, anche a mano su carta. Ottieni un accordo su come si lavora prima che costi settimane di sviluppo.
5. Concorda come si accede. Credenziali aziendali esistenti o utenze nuove, verifica in due passaggi, durata della sessione, e come entrano gli esterni: un invito a un indirizzo come fornitore@esempio.it, con permessi ridotti e scadenza. Ottieni una regola scritta su chi entra e per quanto tempo.
6. Pianifica le integrazioni con i sistemi esistenti. Per ogni collegamento stabilisci direzione dei dati, frequenza e soprattutto quale sistema comanda su quel dato: se l'anagrafica cliente vive in due posti, uno è la fonte e l'altro la copia. Ottieni la riga che evita due archivi che divergono senza che nessuno se ne accorga; il metodo è nella guida su come integrare software aziendali.
7. Prova con un gruppo ristretto di utenti reali. Tre o quattro persone, due settimane, su pratiche vere del mese scorso comprese quelle storte: il reso, lo sconto fuori listino, il cliente estero. Raccogli le differenze in un elenco unico, che deve accorciarsi ogni settimana.
8. Forma le persone e porta i dati. La formazione si fa sui casi di ciascun ruolo, non sul software in generale, e va in calendario prima della partenza. La migrazione si prova due volte a vuoto, contando le righe prima e dopo: è lì che emergono duplicati e vuoti.
9. Metti online e osserva errori e prestazioni nelle prime settimane. Chiedi un punto unico di raccolta degli errori e una revisione quotidiana delle segnalazioni per due o tre settimane. Metti in conto una decina di giorni a produttività ridotta: chi non li prevede li vive come un fallimento.

Le scelte tecniche spiegate a chi non è tecnico

Non devi scegliere le tecnologie, ma capire cosa ti stanno proponendo. Sei voci bastano, ognuna con una domanda da fare e un motivo per cui conta.

Se l'applicazione tratta dati personali, queste risposte servono anche a un secondo scopo. Le indicazioni di questa guida sono generali e riguardano l'organizzazione del progetto: i riferimenti ufficiali sono quelli del Garante per la protezione dei dati personali, e il tuo caso va verificato con il tuo consulente.

Errori comuni

Chiedere le schermate invece del processo. Si arriva con un elenco di pagine e campi, il fornitore le costruisce fedelmente, e all'uso si scopre che il lavoro vero passava da un'eccezione mai raccontata. Rimedio: consegna la descrizione del processo e delle eccezioni, e lascia che le schermate nascano da lì.

Rimandare ruoli e permessi alla fine. Sembra un dettaglio da sistemare prima del lancio, ed è invece la parte più intrecciata con l'impianto dei dati. Rimedio: una tabella di profili e visibilità, anche grezza, approvata prima della scrittura del codice.

Sottovalutare migrazione dei dati e formazione. Sono le due voci che mandano fuori calendario i progetti, non la programmazione. Rimedio: un responsabile della qualità dei dati dal primo giorno, almeno due prove di caricamento complete, e la formazione a calendario con nome e cognome dei partecipanti.

Quanto tempo serve e qual è il passo successivo

In ordini di grandezza: una o due settimane per mappare il processo e fissare il perimetro, un paio per confrontare le proposte, e un primo rilascio utilizzabile che si misura in mesi, non in settimane, con consegne intermedie ogni due o tre settimane. I moduli successivi seguono più ravvicinati, perché l'impianto esiste già. Le variabili che spostano il calendario restano due: quanto velocemente in azienda si decide e lo stato dei dati di partenza.

Il passo successivo, se hai già l'elenco delle attività che soffrono, è scrivere il perimetro del primo rilascio e trasformarlo in un documento di requisiti, da consegnare identico a due o tre fornitori. Le guide collegate qui sotto coprono il documento da preparare, le fasi e il rapporto con i sistemi in uso; se preferisci ragionare sul perimetro con chi lo fa di mestiere, la nostra attività di sviluppo software su misura parte da quella conversazione.