FanMsn è l'app con cui si scrive direttamente alle proprie celebrity preferite: messaggi diretti a creator e personaggi noti, dall'app o dal browser. Una cosa va detta subito, perché rende questo caso studio diverso dagli altri: non è un prodotto mio. È di RJC Soft, dove lavoro come Team Leader. Ho coordinato il frontend, guidato lo sviluppo dell'app e seguito il percorso fino agli store.
Il problema
Un gestionale sa più o meno quante persone lo apriranno lunedì mattina. Un'app in cui si scrive a un personaggio noto no: basta che quel personaggio la nomini e la sera arriva gente che la mattina non c'era. Non puoi dimensionare tutto per il caso peggiore, ma nemmeno permetterti che la serata buona sia quella in cui l'app non si apre.
Quando due persone si scrivono dentro un prodotto, di quello che ci passa risponde il prodotto. Segnalare, bloccare, intervenire: sono cose che devono esserci prima del lancio, non da aggiungere quando il problema si è già presentato. Su un'app aperta a chiunque è la condizione per stare sugli store, non un di più.
Apple e Google guardano con più attenzione le app in cui gli utenti si scrivono tra loro e in cui c'è di mezzo una persona pubblica. Una versione respinta non è solo qualche giorno perso: è una data di lancio che salta, mentre una squadra intera ha già fatto il suo lavoro e aspetta.
Il mio ruolo
In una squadra il cosa lo decide chi possiede il prodotto. Il mio compito era che quello che veniva deciso arrivasse davvero online: scritto una volta sola, allo stesso modo da tutti, e per una strada già percorsa.
1
Con più persone sullo stesso frontend le scelte si moltiplicano: come si gestisce lo stato, come si parla con il server, quando un pezzo di interfaccia diventa un componente riutilizzabile. Decisioni così le abbiamo prese una volta e messe nero su bianco, così ogni schermata nuova parte già orientata invece di riaprire la stessa discussione.
2
Nomi, struttura delle cartelle, formattazione, cosa passa in revisione e cosa no. Non è burocrazia: è la differenza tra un file che chiunque può aprire e correggere e un file che può toccare solo chi l'ha scritto. In una squadra, la seconda cosa non è competenza, è un rischio.
3
La pubblicazione non è l'ultima casella da spuntare. Quello che gli store chiedono si mette in conto dall'inizio: come si costruisce la versione da consegnare, cosa serve nella scheda, chi risponde quando arriva una richiesta di chiarimenti. Arrivarci preparati vuol dire consegnare quando serve, non quando capita.
Architettura→ Standard→ Revisione del codice→ Build→ Pubblicazione
Sotto il cofano
Tenere separati due prodotti sarebbe stato il doppio del lavoro e il doppio dei modi di sbagliare. FanMsn si usa dall'app o dal browser, ma sotto è la stessa cosa.
Chi installa l'app e chi apre il sito vedono lo stesso prodotto perché sotto c'è lo stesso codice. Una correzione si fa una volta e vale su tutti e due i fronti: nessuno deve ricordarsi di riportarla di là, e nessuno scopre a distanza di settimane che una delle due versioni era rimasta indietro.
App · Web · Base condivisa
Ogni modifica passa da qualcun altro prima di entrare. Serve a intercettare gli errori, ma soprattutto a far girare la conoscenza: dopo qualche settimana non esiste più la parte di codice di una persona sola, e chi va in ferie non porta via con sé un pezzo di prodotto.
Convenzioni · Revisione
Numero di versione, contenuto della release, build che si rifà uguale a se stessa: chi consegna non deve tenere a mente dodici passaggi. Se una versione va storta si torna alla precedente senza discussioni, l'unica sicurezza che conta quando l'app è già nelle mani delle persone.
Versioni · Build
Scheda, screenshot, descrizione, note per chi revisiona: sono materiale di lavoro, non pratiche da sbrigare all'ultimo. La pubblicazione sugli store me ne occupo anche sui progetti miei, ed è lo stesso mestiere che racconto nella pagina sulle app mobile per iOS e Android.
App Store · Google Play
Dove siamo
FanMsn è online dal 2024 e ci si arriva da tre porte: App Store, Google Play e browser. È il fatto che conta di più, perché un'app che resta pubblicata è un'app che continua a passare dalla review a ogni versione nuova, che regge gli aggiornamenti dei sistemi operativi e che intanto cambia mentre la gente la sta usando.
Il cambiamento che posso raccontare con onestà non è una metrica di prodotto: quella non è mia e non me la intesto. È il modo di lavorare. Le scelte di architettura non si rifanno a ogni schermata, perché sono scritte e valgono per tutti. Le stesse cose non si scrivono due volte in due punti diversi, perché app e web condividono la base. E la pubblicazione ha smesso di essere il momento in cui si scopre cosa manca.
Scelte scritte/ Codice leggibile a tutti/ Una base per app e web/ Consegne ripetibili
Questo progetto dimostra una cosa che gli altri miei casi studio non possono dimostrare: so lavorare dentro un prodotto che non è mio, come ho fatto per cinque anni da front‑end developer su LuisaViaRoma. Il passo in più, qui, è stato rispondere anche del lavoro degli altri: una scelta tecnica sbagliata è sbagliata per tutta la squadra, e la squadra ci lavora sopra per mesi. La stessa strada verso gli store, fatta invece da solo, la trovi nel caso studio di Single Fin Pet Centric Beach.
Cosa vuol dire per te
Non sempre serve un paio di mani in più. A volte serve qualcuno che decida come si scrive il codice e poi lo faccia rispettare, e che tenga il progetto in una direzione sola mentre le persone cambiano. Posso entrare così, senza scrivere io ogni riga: coordinamento del frontend, scelte di architettura, standard condivisi e revisione.
Coordinamento · Architettura · Revisione
La review di Apple e Google è un mestiere a parte, e su un'app consumer è il punto in cui i progetti si fermano. Me ne occupo dall'interno: account sviluppatore, schede, screenshot e le risposte quando arriva una richiesta di chiarimenti. Sapere in anticipo cosa verrà guardato è la differenza tra una data di lancio e una data di lancio spostata.
App Store · Google Play · Web