Sinapsi è un’azienda IT specializzata in software per aziende edili, in particolare per quelle che mettono a disposizione addetti specializzati al supporto di urgenze, come riparazioni di mezzi pesanti e manutenzioni degli stessi.
Nasce nel 2000 come costola di Imola Gru – specializzata nella riparazione e manutenzione delle gru – con lo specifico proposito di migliorare la gestione dell’azienda attraverso il software. Per Imola Gru Sinapsi crea Logica, un software gestionale che poi ha acquisito vita propria e oggi è venduto a molte altre aziende.
Negli ultimi anni è in corso un processo di trasformazione digitale molto importante. Logica si sta trasformando da applicazione desktop ad un software web chiamato Logica Web: è stato riscritto completamente from scratch, passando da un’applicazione Visual Basic ad un backend basato su J2EE ed un frontend AngularJS.
L’assessment dell’applicazione
La nostra collaborazione con Sinapsi è iniziata con un assessment sullo stato di salute della loro applicazione AngularJS. Una intera giornata con il loro team, analizzando le parti più critiche. Per poter prendere decisioni tecnologiche mirate a bisogni reali, abbiamo disegnato il nostro assessment in modo da rendere evidente qual è il valore che il progetto porta all’azienda, e come il processo di sviluppo del software si lega al business dell’azienda stessa.
Oltre a proporre soluzioni e consigli prettamente tecnici, ci siamo concentrati sul tirare fuori dei principi attorno ai quali far ruotare le loro scelte tecnologiche. Per farlo abbiamo utilizzato il gioco delle leve e abbiamo stilato insieme Framework Compass Radar.
Il Framework Compass Radar ha fatto evincere che la manutenibilità è un fattore critico che deve guidare le scelte tecnologiche del team, dato il forte impatto che questo nuovo software web ha per l’azienda. Come conseguenza abbiamo deciso di abbracciare un approccio “difensivo” rispetto ad AngularJS, utilizzare cioè solo le parti davvero utili al progetto, riscrivendosi in casa invece quelle su cui il team ha deciso di mantenere il massimo controllo.
Il training on the job
Dopo il nostro assessment, abbiamo proposto al team di Sinapsi un pacchetto di giornate di training on the job. Durante queste giornate abbiamo aiutato il cliente nel suo processo di refactoring, operando su due fronti, uno relativo al codice JavaScript e l’altra relativo all’organizzazione del CSS.
Lato CSS abbiamo introdotto un’organizzazione del codice secondo le specifiche BEM e un pre processore SCSS con uso organico delle variabili. Abbiamo riscritto gran parte dei componenti UI e documentato il loro uso in design pattern. Abbiamo razionalizzato le dipendenze e automatizzato tutto in task automatici.
Per quanto riguarda JavaScript abbiamo continuato il nostro lavoro “di difesa” da Angular, eliminando il framework dalle parti più importanti dell’applicazione. Ma cosa ancora più importante abbiamo aiutato il team del cliente a prendere confidenza con alcune buone pratiche come il Test Driven Development ed il testing End-to-end. In questo modo lo abbiamo reso autonomo negli sviluppi futuri.
La ricerca sugli utenti e la discovery dell’Agenda
Dopo una fase di sviluppo autonomo dell’applicazione, Sinapsi si è rivolta a noi per una parte particolarmente delicata dell’applicazione – l’Agenda – che permette di pianificare il tempo degli addetti. Questa area rappresenta il cuore della proposizione di valore del software: presente anche nel software desktop, una serie di gesture rendevano semplici la gestione del tempo e subito evidenti le criticità e le azioni da intraprendere. Per approcciare al meglio lo sviluppo di questa parte, abbiamo deciso di fare:
Una ricerca sugli utenti per capire meglio l’uso che essi fanno del software ed eventuali mancanze. Questo ci ha permesso di individuare tre distinti tipi di utenti, le attività che essi svolgono e relativi pain e gain:
- il pianificatore che gestisce il tempo degli addetti specializzati e ne organizza le giornate, ed è anche colui che fa l’utilizzo più massivo dell’agenda;
- il commerciale che si occupa di vendere attività che poi dovranno essere pianificate, utilizza l’agenda per passare il lavoro al pianificatore tramite una serie di stati degli interventi;
- l’addetto caposquadra che, dal cantiere, deve sapere dove portare la sua unità quotidianamente in base al pianificato.
Una giornata insieme per allinearci sugli obiettivi e pensare nuovi scenari per migliorare il prodotto esistente. Abbiamo delineato chiaramente gli obiettivi di business che avrebbero guidato i successivi sviluppi e confermato la tipologia di utenti e aziende a cui si rivolgono. Abbiamo ri-utilizzato il gioco delle leve per delineare i principi attorno ai quali far ruotare lo sviluppo dell’agenda.
Per rimodellare i servizi dell’Agenda abbiamo utilizzato il value proposition canvas: ci ha permesso di presentare a tutto il team i risultati della ricerca sugli utenti, in particolare pain e gain percepiti da ogni tipologia di utenti. Attorno ad essi abbiamo rimodellato le feature dell’Agenda riconsiderandone la priorità, rimuovendole o aggiungendone di nuove quando un pain non era mappato. Per lasciare libero sfogo alla creatività sulle nuove feature abbiamo utilizzato la tecnica del crazy eight in modo da poter creare e selezionare le idee migliori per far fronte a desideri non corrisposti dalle feature attuali.
Dopo questa giornata di discovery, insieme al Product Owner abbiamo riportato il value proposition canvas in una kanban traducendo il lavoro fatto in user story.
Quello che ci siamo portati a casa noi, grazie alle metodologie agili, è aver sperimentato che alcune fasi della giornata di discovery possono essere attuate in maniera preventiva e da remoto.
Questi alcuni dei vantaggi portati dalla giornata:
- ha permesso di coinvolgere persone che non è necessario siano presenti nell’intera fase di discovery o non disponibili per altri impegni;
- ha dato un ampio respiro alle attività (come il test con gli utenti o la customer journey) che non sono strettamente oggetto di discovery ma più del design sprint;
- nell’esplorazione abbiamo ottenuto molti dati (provenienti dalle attività precedenti) che possono divenire informazioni importanti di cui tener conto durante le discussioni;
- ci ha aiutato ad avere una visione più ampia, soprattutto lato cliente, dello scenario che si stava esplorando;
- ha confermato, rafforzato o smentito assunzioni e pregiudizi da parte dei membri del team.
Ancora una volta, il principio “gli obiettivi sono stabili mentre contesti, bisogni e strumenti cambiano nel tempo” si è dimostrato più che attuale e vincente.
Il processo di evoluzione dell’Agenda e dell’area Messaggi
La discovery dell’area Agenda, insieme a quella fatta successivamente per l’area Messaggi, ha fatto emergere da parte di Sinapsi due esigenze:
- completare l’applicativo con queste due funzionalità fondamentali;
- far fare all’applicativo un sensibile step in avanti dal punto di vista della qualità, intesa come migliore esperienza d’uso.
Grazie al team cross-funzionale e alle diverse figure e competenze professionali coinvolte nel progetto, in poco meno di due mesi abbiamo ricreato tutte le feature base della vecchia agenda migliorandola ulteriormente a livello di performance e usabilità.
Stessa cosa per quanto riguarda l’area di messaggistica interna che è stata completamente riprogettata per includere componenti social (reaction, emoji, …) e completata da un sistema di gestione documentale interno, integrato con l’applicativo.
Siamo poi riusciti sia a introdurre funzionalità sia ad aumentare la qualità dell’intera applicazione grazie ad un nuovo design system.
Come abbiamo raggiunto questo risultato? Siamo partiti con un interface inventory, evidenziando i differenti approcci applicati nel corso del tempo, sia a livello di user interface che a livello di esperienza utente.
Poi abbiamo prodotto il nuovo design system, passando per la condivisione dello scopo del prodotto, con tutto il team al completo, e la stesura dei design principle. Queste attività ci hanno permesso di separare i pattern giusti da quelli non adatti e di riprogettare correttamente questi ultimi, uniformando inoltre lo stile dell’applicazione all’identità del brand.
Il design system ha avuto anche ricadute positive sullo sviluppo, semplificando le scelte progettuali, favorendo il riutilizzo del codice e diminuendo così i costi. Ha inoltre abilitato la comunicazione interna al team grazie a un linguaggio condiviso.
Infine, le metodologie agili e il nostro contratto “soddisfatti o rimborsati” ci hanno permesso di consegnare valore settimanalmente rispetto agli obiettivi di business individuati nella fase iniziale, e di rimettere in discussione le priorità e esigenze dove necessario, senza impatti negativi.
Un nuovo modello di business per Logica web
Parallelamente alle implementazioni, Sinapsi sta esplorando nuovi modelli di business ed evoluzioni della proposizione di valore di Logica web. Per iniziare a disegnare la nuova visione di insieme abbiamo fatto una prima sessione di value proposition design, per definire i nuovi segmenti di clientela, l’offerta a loro dedicata e il modello di vendita del servizio. Una sessione piena di desiderata e obiettivi da esplorare e verificare sul campo.
Per questo abbiamo successivamente identificato le assumption da validare, in modo da poter poi identificare degli esperimenti per ottenere informazioni sulla bontà della direzione da seguire.
La nuova proposizione di valore comporterà anche un nuovo flusso e modalità di utilizzo del software, anche questo sarà tutto da testare con gli utenti: il primo passo fatto in questa direzione è stato un event storming da remoto con tutto il team per delineare il flusso del futuro applicativo.
Abbiamo iniziato il nostro percorso con Flowing circa tre anni fa. Eravamo alla ricerca di formazione per la parte frontend e abbiamo trovato un team in grado di seguirci su ogni aspetto dello sviluppo del nostro applicativo. La collaborazione è maturata e si è solidificata nell’arco del tempo fino a coprire o toccare quasi ogni aspetto della nostra area di sviluppo (frontend, backend, design e definizione di business model). Una cosa che ho particolarmente apprezzato è il team che mi è stato messo a disposizione. Sia le persone stesse, la loro competenza e la loro disponibilità, sia il fatto che lo stesso team sia rimasto praticamente lo stesso durante l’arco di tutta la collaborazione assicurando così stabilità e continuità a tutto il progetto.
Stefano Zanotti, CTO
