Come funziona il lavoro sul sistema FoodSoul: dall'idea al risultato

Apprezziamo la fiducia dei nostri partner e per questo vogliamo essere il più trasparenti possibile. In questo articolo vi raccontiamo come è organizzato il team, come le idee si trasformano in funzionalità, come stabiliamo le priorità e cosa succede dietro le quinte quando qualcosa va storto.

FoodSoul — un sistema vivo

FoodSoul non è solo un'applicazione. Dietro di essa c'è una grande infrastruttura: CRM, archiviazione e protezione dei dati, template di siti web e applicazioni mobili e migliaia di ristoranti partner, ognuno con le proprie esigenze e modalità operative.

Ascoltiamo costantemente: raccogliamo idee dai partner tramite il supporto tecnico, dal contatto diretto con i clienti e dai nostri analisti del reparto IT. Tutto questo viene accumulato in un backlog — una lista di attività in continuo aggiornamento, sulla base della quale viene formata la roadmap di sviluppo del prodotto.

Come è organizzato il team e la struttura del lavoro

Su FoodSoul lavorano diversi gruppi di specialisti, ognuno con la propria area di responsabilità e una propria logica di interazione con gli altri.

Supporto tecnico — la prima linea di contatto con i partner. Riceve le richieste, analizza la natura del problema e lo risolve direttamente oppure lo inoltra allo specialista competente per quella parte del sistema.

Specialisti di secondo livello — sono ingegneri che conoscono a fondo moduli specifici: integrazioni, applicazioni mobili, CRM, pagamenti. Sono loro a verificare se la richiesta riguarda una caratteristica del funzionamento o un vero errore.

Analisti raccolgono e strutturano i desideri dei partner, valutano quanto la modifica sia richiesta e come influenzerà gli altri clienti, prima che il compito passi allo sviluppo.

Sviluppatori e tester realizzano le attività e le verificano prima del rilascio — da piccole correzioni a grandi miglioramenti delle funzionalità.

Project manager mantengono il focus sulle priorità: monitorano il backlog, distribuiscono le attività tra i team e si assicurano che le cose importanti non vadano perse tra le attività correnti.

Il lavoro è organizzato in modo ciclico: il team rivede regolarmente il backlog, valuta le nuove richieste e desideri, pianifica le attività imminenti e monitora lo stato di quelle già in corso. Questo ritmo permette di non perdere di vista né i problemi urgenti né lo sviluppo a lungo termine del prodotto, mantenendo al contempo la prevedibilità: il partner può sempre sapere tramite il supporto tecnico a che punto si trova la sua richiesta.

Come stabiliamo le priorità

Quando si presenta un problema, agiamo secondo uno dei seguenti scenari.

Malfunzionamento di massa — un errore che nello stesso giorno o in poche ore colpisce più clienti contemporaneamente. Questa è la massima priorità: tester e sviluppatori intervengono immediatamente.

Bug critico per un singolo cliente — se l’errore influisce direttamente sul fatturato o sulla reputazione del partner, la priorità è altrettanto alta. Dedichiamo le risorse chiave e risolviamo il problema in tempi brevi.

Bug standard — una richiesta accolta dal supporto tecnico che non appare come una catastrofe. Viene presa in carico da uno specialista di secondo livello che conosce bene il sistema. Sono possibili due esiti: o si scopre che si tratta di una caratteristica del funzionamento non considerata, in tal caso viene spiegata la soluzione al cliente; oppure il problema esiste davvero, allora passa al project manager, viene registrato nel sistema delle attività con priorità e responsabile e viene realizzato secondo l’ordine di coda. Lo specialista del supporto tecnico monitora lo stato e informa il cliente quando il compito è completato.

Bug minore — un errore che non influisce sul funzionamento del sistema, ma richiede una correzione: un refuso, un elemento dell’interfaccia fuori posto, il colore sbagliato di un pulsante. Queste attività vengono prese in carico quando non ci sono richieste più prioritarie tra quelle sopra elencate.

Desideri — seguiamo attentamente ciò che chiedono i partner. Quando la stessa richiesta arriva da più clienti, la priorità aumenta e la sottoponiamo ad analisi. Ogni modifica riguarda subito tutti i partner, non solo chi l’ha richiesta, quindi prima della realizzazione raccogliamo feedback da diversi clienti, affinché il miglioramento per alcuni non crei disagi ad altri. Questo è un passaggio in più, ma è proprio ciò che rende la decisione finale più ponderata.

Perché si verificano i bug

Lo sviluppo di qualsiasi prodotto complesso è tale che gli errori sono una parte regolare del processo, non un’eccezione. Ecco da cosa deriva questa complessità.

Il sistema cresce. Più funzioni, integrazioni e scenari d’uso ci sono, più punti di interazione tra le diverse parti del sistema si creano. Il team testa gli scenari più tipici, ma coprire tutte le combinazioni in anticipo è fisicamente impossibile anche per il team più esperto.

Ogni partner utilizza il sistema a modo suo. Migliaia di locali significano migliaia di processi di lavoro unici. Il comportamento degli utenti nelle condizioni reali è sempre più ricco di quanto si possa prevedere negli scenari di test, e alcune deviazioni emergono solo sui dati reali.

Una modifica influisce su un’altra. Quando uno sviluppatore migliora un modulo, questo può influenzare una funzionalità correlata. Più grande è il sistema, più lunghe sono le catene di dipendenze tra le sue parti, e più attenzione serve per verificare ogni cambiamento.

L’ambiente cambia costantemente. Si aggiornano browser, sistemi operativi, servizi di terze parti con cui siamo integrati. Ciò che funzionava ieri può comportarsi diversamente dopo un aggiornamento da parte di una terza azienda, e monitoriamo questi cambiamenti per reagire rapidamente.

I requisiti si chiariscono in corso d’opera. A volte una funzione è realizzata esattamente come previsto, ma nell’uso reale si scopre che l’idea va migliorata. Così il prodotto diventa più preciso a ogni iterazione.

Consideriamo tutto ciò come una parte normale della crescita di un sistema complesso e lavoriamo costantemente per renderlo più stabile, veloce e comodo per ogni partner — grazie a test più approfonditi, una struttura di team chiara e un feedback costante dai clienti.

Se avete riscontrato un problema o volete condividere un’idea, scrivete al supporto tecnico di FoodSoul. Ogni richiesta arriva allo specialista giusto e non va persa. Siamo qui per voi!

Cordiali saluti,

Project Manager FoodSoul