The Qonto Way: una specifica per dominarli tutti

May 09 2023
Man mano che il nostro prodotto diventava più complesso, diventava sempre più difficile avere un quadro completo di come tutto funzionasse insieme. E, per mantenere il nostro ritmo di crescita, dovevamo trovare un modo per mantenere una fonte di verità aggiornata per tutte le nostre specifiche funzionali.

Man mano che il nostro prodotto diventava più complesso, diventava sempre più difficile avere un quadro completo di come tutto funzionasse insieme. E, per mantenere il nostro ritmo di crescita, dovevamo trovare un modo per mantenere una fonte di verità aggiornata per tutte le nostre specifiche funzionali. Questo articolo spiega come abbiamo gestito in precedenza le specifiche, i problemi che abbiamo riscontrato con tale approccio e come ne abbiamo ideato uno completamente nuovo.

Cosa c'era di sbagliato in "specifiche per funzionalità"

Il nostro approccio tradizionale alle specifiche era quello di avere una pagina dedicata per ogni nuova specifica, in cui i Product Manager avrebbero compilato un elenco di comportamenti previsti per schermi nuovi ed esistenti. Questo approccio ha funzionato bene finché il prodotto non è diventato più complesso, soprattutto quando le nuove funzionalità hanno sostituito parti degli schermi esistenti.

Di conseguenza, è stato difficile capire esattamente come funzionava uno schermo e quali potrebbero essere le potenziali ripercussioni altrove nell'app durante l'aggiornamento di un elemento specifico. La base di codice divenne l'unica fonte attendibile di verità e i Product Manager dovettero affidarsi agli ingegneri per spiegare ripetutamente come si comportavano gli schermi. Ciò ha interrotto l'attenzione degli ingegneri, costringendoli a fornire risposte rapide e approssimative che hanno portato a rielaborazioni, sprechi, tempi di consegna più lunghi e frustrazione.

Costruzione del prototipo

Per risolvere questo problema, avevamo bisogno di sviluppare un prototipo di una fonte di verità per specifiche e progetti. Ogni schermata dovrebbe avere una fonte unica di verità. Pertanto, qualsiasi aggiornamento effettuato su uno schermo dovrebbe riflettersi in quell'unica fonte di verità, invece che in qualsiasi altra pagina dedicata. I nostri progetti erano su Figma, quindi li abbiamo tenuti lì. Scrivere le specifiche accanto agli screenshot in Notion era in realtà più lavoro che scrivere direttamente le specifiche in Figma. Gli sviluppatori hanno potuto vedere immediatamente i progetti ad alta fedeltà con le loro specifiche nello stesso file Figma, con le specifiche esistenti proprio accanto alla modifica proposta

Per garantire che le nostre specifiche fossero complete, abbiamo identificato quattro aree chiave che i nostri approcci precedenti non avevano incluso nel nostro nuovo prototipo. Innanzitutto, avevamo bisogno di visibilità su tutti gli elementi di uno schermo, indipendentemente dalle condizioni. In secondo luogo, avevamo bisogno di sapere come si comporta qualsiasi elemento senza dover ricorrere a chiedere agli ingegneri di retroingegnerizzare la base di codice. In terzo luogo, avevamo bisogno di sapere se un elemento è condiviso su più schermi per evitare che una modifica su uno schermo apporti aggiornamenti indesiderati su altri schermi. E infine, avevamo bisogno di un'immagine chiara dei flussi di schermo con tutte le condizioni per navigare da uno schermo all'altro.

Migliorare e ridimensionare il prototipo

Per coinvolgere tutti i nostri designer, dovevamo elaborare uno standard chiaro che rispondesse alle loro esigenze specifiche su una piattaforma che riconoscevano e utilizzavano regolarmente. Ora abbiamo uno spazio di lavoro "Specifiche visive" in Figma con cartelle ordinate per tema e non per squadra. Ogni schermo appartiene a tutti, non solo a una squadra. Se un team responsabile di un ambito specifico apporta una modifica che avrà un impatto su un'altra parte dell'app, può aggiornare le schermate giuste nel posto giusto e tutti vedranno automaticamente la modifica. In questo modo, il nostro attuale approccio alle specifiche è più completo di prima. Ogni cartella del tema ha una pagina per ogni storia utente.

Il contenuto di una user story mostra la progressione orizzontale del viaggio dell'utente. Verticalmente, abbiamo tutte le possibili varianti di ogni schermata dei tasti (stato di errore, stato di caricamento, stato vuoto...). Le schede specifiche sono i criteri di accettazione completamente esaustivi per ogni elemento in cui viene spiegato ogni possibile comportamento dell'elemento. Le schermate principali conterranno la maggior parte delle specifiche e le varianti mostreranno solo le loro specifiche specifiche.

Ora, ogni volta che sviluppiamo una nuova funzionalità, creiamo un nuovo ramo in Figma e aggiungiamo le nuove carte specifiche in un colore distinto accanto ai nuovi elementi. Una volta terminata la funzione, queste carte specifiche verranno trasformate nel loro stato "live" e il ramo sarà unito a quello principale. Ciò mantiene tutto pulito, aggiornato e pronto per l'avvio di una nuova funzionalità nelle migliori condizioni possibili.

Esecuzione della migrazione completa

Aggiornare le modalità di lavoro in un reparto tecnico e prodotto può essere impegnativo. Ed è qui che è entrata in gioco Qonto Way: il miglioramento continuo è al centro della nostra cultura. Proviamo nuovi metodi con un sottoinsieme del team e, se si rivelano utili, li implementiamo in tutto il team. In caso contrario, li scartiamo. Quando si è trattato di rinnovare il nostro approccio alle specifiche, abbiamo iniziato a livello del mio team e ho assunto la piena responsabilità dell'iniziativa con il supporto dei membri del team Product/Design/Tech che sono direttamente coinvolti nel suo utilizzo. Idealmente, vuoi eseguire il reverse engineering di schermate e specifiche sufficienti per coprire la prossima funzionalità su cui alla fine lavorerai (ho decodificato l'intero ambito del mio team in modo che siamo pronti per qualunque nuova funzionalità si presenti sulla nostra strada).

Assicurati di dimostrare la tua esperienza (positiva!) di questa nuova funzionalità e non esitare a promuoverne pesantemente i vantaggi ad altri per ottenere il consenso dei dirigenti tecnici e di prodotto.

Una volta avviata la fase, dovevamo aggiornare il modo in cui lavoravamo su larga scala. Abbiamo scritto una serie di standard riveduti, ciascuno orientato a un team diverso: tecnologia, prodotto e design, con una proprietà chiaramente delineata per ogni stack.

Una volta raggiunto questo passaggio, puoi creare le tue nuove funzionalità nelle specifiche visive, consolidando la conoscenza funzionalità dopo funzionalità. Tuttavia, ottieni tutti i vantaggi di lavorare in questo modo solo dopo aver mappato ogni comportamento. A seconda della situazione, ci sono due modi per avviare la mappatura su vasta scala (ogni team può decidere di adottare un approccio o un altro):

  • Congela la produzione per alcuni giorni su ciascun team funzionale e chiedi al tuo team tecnico e ai progettisti di retroingegnerizzare l'intero ambito esistente. Questo metodo ha diversi vantaggi: il team interessato ottiene una conoscenza completa del dominio, inclusi i nuovi iscritti, e tu ottieni il 100% di chiarezza su come funziona tutto, niente più punti ciechi.
  • Retroingegnerizza solo le parti che prevedi di aggiornare poco prima di creare una nuova funzionalità. Ciò garantisce che non ti manchi nulla e puoi iniziare a costruire i nuovi elementi in cima a questa nuova fonte di verità. Lo svantaggio di questo approccio è che non avrai mai una mappa completa del quadro.

Il nostro nuovo processo di specifiche ha rivoluzionato il modo in cui lavoriamo, dicendo addio al codebase "cave diving". Creando un'unica fonte di verità per specifiche e progetti, abbiamo creato uno spazio di lavoro facile da usare, accessibile a tutti i membri del team e che fornisce informazioni accurate e aggiornate su tutti i nostri schermi e storie utente. Abbiamo risparmiato tempo, ridotto le rielaborazioni, accelerato l'onboarding dei nuovi arrivati ​​e fornito un quadro più completo di come tutto funziona insieme.

Qonto è una soluzione finanziaria pensata per PMI e liberi professionisti fondata nel 2016 da Steve Anavi e Alexandre Prot. Dal nostro lancio nel luglio 2017, Qonto ha semplificato il finanziamento aziendale per oltre 350.000 aziende.

Gli imprenditori risparmiano tempo grazie alla configurazione semplificata dell'account di Qonto, a un'esperienza utente quotidiana intuitiva con cronologia delle transazioni illimitata, esportazioni contabili e una pratica funzione di gestione delle spese.

Mantengono il controllo pur essendo in grado di dare ai propri team maggiore autonomia tramite notifiche in tempo reale e un sistema di gestione dei diritti degli utenti.

Beneficiano di una migliore visibilità del flusso di cassa tramite dashboard intelligenti, codifica automatica delle transazioni e strumenti di monitoraggio del flusso di cassa.

Godono anche di un'assistenza clienti stellare a un prezzo equo e trasparente.

Interessato ad entrare a far parte di un'azienda stimolante e rivoluzionaria? Consulta le nostre offerte di lavoro !