Un'installazione per un evento in una settimana
Sette giorni sono possibili, a certe condizioni
Capita: l'evento è fra una settimana, l'idea è arrivata tardi, oppure un fornitore è saltato. In quelle situazioni abbiamo consegnato installazioni funzionanti in una sola settimana. Non è la modalità normale di lavoro ed è giusto dire perché: una settimana non si ottiene lavorando più in fretta, si ottiene rinunciando a delle cose. Sapere quali, prima di cominciare, è tutta la differenza fra una consegna e un disastro.
Le condizioni senza le quali non si parte
Una persona che decide, disponibile ogni giorno. In sette giorni non c'è spazio per un giro di approvazioni. Serve qualcuno raggiungibile che possa dire sì o no nell'arco di un'ora, e che abbia l'autorità per farlo.
Un'idea sola. Non un'esperienza articolata in fasi: un'interazione, chiara. Ogni ramificazione aggiunta in questa finestra temporale costa il doppio di quanto costerebbe normalmente, perché non c'è tempo per assorbire un imprevisto.
I contenuti già esistenti. Testi, immagini, logo, font: se vanno prodotti, quello è un progetto parallelo con i suoi tempi. Nella maggior parte delle consegne rapide che sono andate male, il ritardo era sui contenuti, non sul software.
Accesso al luogo prima del giorno dell'evento. Anche solo un sopralluogo con una prova di rete. Senza, si sta scommettendo sull'ambiente più imprevedibile del progetto.
Vincoli tecnici noti subito. Chi fornisce gli schermi, che risoluzione hanno, c'è corrente dove serve, che rete c'è, chi è il referente tecnico del luogo. Sono domande da fare il primo giorno, non il quinto.
Se una di queste condizioni manca, la risposta onesta non è "ci proviamo": è ridurre l'ambizione dell'installazione finché torna dentro i vincoli, o spostare l'obiettivo a un formato più semplice che si sa di poter garantire.
Come si distribuiscono i giorni
Giorno 1 — si decide e si chiude. Una sola riunione, in cui si definisce cosa fa l'installazione, cosa succede quando qualcosa non va, e cosa esplicitamente non farà. Da lì in avanti quel perimetro non si tocca: è la regola che rende possibile tutto il resto.
Giorni 2-4 — si costruisce il flusso principale. Solo il percorso completo, dall'inizio alla fine. Niente varianti, niente pannelli di gestione. Alla fine del quarto giorno deve esistere qualcosa che si apre e funziona, anche se brutto.
Giorno 5 — prova sul posto. È il giorno che non si salta mai, nemmeno quando si è in ritardo — soprattutto quando si è in ritardo. Rete vera, luce vera, schermi veri, e almeno cinque persone che non hanno mai visto il progetto che provano a usarlo. Quello che emerge qui è quasi sempre diverso da quello che ci si aspettava.
Giorno 6 — si sistema quello che la prova ha rotto. E si costruisce il comportamento degradato: cosa si vede se la rete manca, se un servizio esterno non risponde, se qualcuno interagisce in modo imprevisto. È il lavoro meno visibile e quello che più spesso salva la giornata.
Giorno 7 — installazione e presidio. Montaggio con margine, una prova completa prima dell'apertura, e una persona reperibile con accesso remoto per tutta la durata dell'evento.
Cosa si taglia, dichiarandolo
In una settimana non entrano il pannello di amministrazione, la personalizzazione fine della grafica, le varianti dell'esperienza, il supporto a ogni possibile dispositivo, e le integrazioni con sistemi terzi che richiedono credenziali da richiedere a qualcun altro — perché quei tempi non dipendono da noi.
Il punto non è tagliare di nascosto: è mettere per iscritto cosa non c'è, così che nessuno lo scopra la sera prima. Un elenco condiviso di ciò che è fuori perimetro è lo strumento più utile di tutto il progetto.
Cosa invece non si taglia mai
C'è una tentazione ricorrente quando il tempo stringe: rinunciare alla prova sul posto, oppure alla gestione degli errori, per guadagnare mezza giornata sulle funzionalità. È lo scambio peggiore che si possa fare in un progetto con una data fissa.
Il motivo è semplice: una funzionalità in meno la nota solo chi sapeva che era prevista. Un'installazione bloccata la notano tutti, contemporaneamente, nel momento di massima visibilità. Il danno non è proporzionato al tempo risparmiato.
Non si taglia neanche il tempo di montaggio. Il margine fra l'installazione e l'apertura al pubblico è quello che assorbe l'imprevisto fisico — la presa che non c'è, lo schermo che arriva con un attacco diverso, l'ascensore occupato. Chi programma il montaggio all'ultimo momento utile sta scommettendo che nessuna di queste cose accada, e di solito almeno una accade.
I rischi veri, in ordine
Per esperienza, le cose che fanno saltare una consegna rapida sono, in ordine di frequenza: i contenuti che arrivano tardi; la rete del luogo diversa da come era stata descritta; l'hardware fornito da terzi che arriva il giorno stesso; una decisione riaperta a metà settimana; e un servizio esterno più lento del previsto sotto carico.
Quattro su cinque non sono problemi di software, e questo dice qualcosa di utile: in una consegna a sette giorni il lavoro di coordinamento pesa quanto quello tecnico. Vale la pena che qualcuno se ne occupi esplicitamente.
Quando conviene davvero
Un'installazione veloce non è una versione scadente. È un progetto con un perimetro onesto e stretto, e in molti casi è esattamente ciò che serve: qualcosa di semplice che funziona benissimo davanti a mille persone vale più di qualcosa di ambizioso che funziona a metà.
Se poi l'esperienza va bene, la versione successiva ha una base reale su cui costruire — con dati veri su come il pubblico ha interagito, che è il materiale migliore per decidere cosa aggiungere.
Una settimana non si guadagna correndo di più. Si guadagna decidendo prima, e avendo il coraggio di scrivere nero su bianco cosa non ci sarà.
