case-study

Sinapsi: assessment, discovery e training per Logica Web

case-study

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.
Sinapsi 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.
Da un paio d’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.

Framework compass radar Logica Sinapsi

il 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.

Discovery con @creativecaos sulla proposta di valore e i bisogni dell’utente #ux #valuepropotitioncanvas #value #tantaroba pic.twitter.com/0uwgPEn6TM

— ramona vesprini (@ramonavesprini) October 4, 2018

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.

Il processo di sviluppo dell’Agenda

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à dove necessario, senza impatti negativi. In poco meno di due mesi abbiamo ricreato tutte le feature base della vecchia Agenda migliorando le performance e l’usabilità.

Cosa abbiamo imparato

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.

Team