Come abbiamo iniziato a rilasciare le funzionalità due volte più velocemente (case study)

Quando le aziende si affidano alla tua app per il loro lavoro quotidiano, devi essere abbastanza agile da soddisfare rapidamente le loro esigenze. Se non lo fai, gli altri lo faranno sicuramente. Nel mondo spietato di SaaS, ritardare una funzionalità critica (o affrettare un pezzo di codice pieno di bug) significherà perdere clienti. Un solido flusso di lavoro agile può fare la differenza.

Siamo il team dietro Active Collab , un'app di gestione dei progetti con un set di funzionalità in continua crescita e una base di utenti considerevole. Ciò significa che anche il più piccolo cambiamento di funzionalità interesserà un gran numero di persone.

Ulteriori letture su SmashingMag:

• Come implementare nuove funzionalità senza danneggiare gli utenti fedeli
• L'elenco di controllo per il lancio del sito Web: 15 controlli essenziali prima della pubblicazione
• Un approccio incentrato sull'utente al web design per dispositivi mobili
• Come lanciare qualsiasi cosa
  

Pertanto, il processo di sviluppo deve funzionare senza intoppi e all'altezza di uno standard, con ritardi ridotti al minimo. Prima che qualsiasi cambiamento arrivi all'utente finale, passa attraverso cinque fasi cruciali: feedback, progettazione, sviluppo, garanzia della qualità e implementazione . In questo articolo, condividerò ciò che abbiamo imparato (a mie spese) su ciascuna delle fasi in oltre otto anni di attività.

Una sveglia

Prima di entrare nei dettagli, diamo un'occhiata a come è nato tutto questo. Dopo anni di aggiunta di funzionalità senza un'adeguata verifica, la nostra app soffriva di un aumento delle funzionalità. Abbiamo aggiunto così tante funzionalità nel corso degli anni che i nuovi utenti sono rimasti intimiditi dall'assoluta complessità dell'interfaccia utente (per non tornare mai più). Sapevamo che dovevamo ricostruire da zero, anche se ciò significava riscrivere ogni singola caratteristica da zero.

Poi sono arrivati ​​i ritardi. Le funzionalità per le nuove versioni erano costantemente in ritardo rispetto alla pianificazione. Ad esempio, uno sviluppatore junior avrebbe dovuto sviluppare un'integrazione con QuickBooks. Non abbiamo previsto con precisione la complessità, le competenze o le conoscenze necessarie. Inoltre, era l'unico assegnato a quel compito e nessuno poteva intervenire rapidamente per aiutarlo. Di conseguenza, quello che doveva essere un lavoro di due settimane ha finito per prenderne cinque. Quelle erano alcune bandiere rosse.

Era chiaramente giunto il momento di passare a un approccio più agile. Abbiamo preso ciò che ci piaceva da vari metodi agili (e non così agili), lo abbiamo combinato con l'esperienza e abbiamo creato la nostra versione, che da allora ha fornito ottimi risultati.

Diamo un'occhiata più da vicino alla strada che una funzionalità deve percorrere prima di essere offerta all'utente finale.

Dal suggerimento alla caratteristica

Nel nostro flusso di lavoro, una nuova funzionalità inizia a prendere forma molto prima di raggiungere il team di sviluppo e di solito nasce dal feedback degli utenti. Questa non è una coincidenza: rilasciavamo funzionalità che non servivano a nessuno, di solito solo perché un utente era particolarmente rumoroso o semplicemente pensavamo che sarebbe stato fantastico avere qualcosa. Invece di immaginare quali funzionalità potrebbero essere necessarie ai nostri utenti, ora prendiamo decisioni in base alla domanda effettiva.

Se ti piace la produzione snella, diresti che i nostri clienti "tirano" determinate funzionalità richiedendole più spesso di altre. I nostri team di supporto e vendita sono una parte importante del processo perché sono costantemente in contatto con utenti che condividono le loro esigenze e idee.

Sulla base del feedback, i nostri team aggiornano un modulo simile al seguente:

Quando non avremo tutte le informazioni di cui abbiamo bisogno, contatteremo direttamente i clienti. Questo di solito viene fatto con sondaggi mirati su un campione accuratamente selezionato. Il punto è che ascoltiamo. Nessun feedback viene perso su di noi. È sempre riconosciuto e documentato.

Il passo successivo è l'analisi. Contiamo i punteggi ogni mese per vedere quale funzione ha ottenuto il maggior numero di voti. Inoltre, con una corretta categorizzazione, otteniamo una prospettiva più ampia su quali parti del nostro software devono funzionare. Ad esempio, se il calendario riceve molti reclami, prenderemo in considerazione la possibilità di rinnovare l'intera sezione, anziché introdurre la funzione che ha ottenuto il maggior numero di voti (come l'esportazione del calendario).

Tuttavia, anche quando i risultati sono in arrivo, la decisione di introdurre una funzionalità non è definitiva. Prima che entri nella nostra lista di cose da fare, eseguiamo sempre un accurato controllo di integrità:

• Quali vantaggi porterà questa funzione agli utenti?
• Si adatta alla nostra filosofia di prodotto?
• Aggiungerà complessità non necessaria?
• Si integra perfettamente con l'interfaccia e le funzionalità esistenti?
• Abbiamo le risorse per consegnarlo in tempi ragionevoli?

Quando una funzionalità supera la lista di controllo e i proprietari del prodotto la approvano, è il momento di passare al tavolo da disegno.

Progettare per l'utente

L'esperienza ci ha insegnato che aggiungere una nuova funzionalità non significa solo incollarla sopra l'interfaccia utente: devi fonderla con il design esistente, tenendo a mente l'utente. Se non lo fai, ti ritroverai presto con un'app così complessa che solo pochi coraggiosi riusciranno a superare i primi cinque minuti della prova (sì, ci siamo stati). Anche l'estetica è importante per una buona prima impressione, ma la nostra principale preoccupazione è la facilità d'uso . Una funzionalità deve essere aggiunta in un modo che risulti naturale per l'utente.

Manteniamo le cose in prospettiva chiedendoci, dove l'utente si aspetta che sia questa opzione?

Per gli utenti esistenti, è importante che il nuovo design segua i modelli con cui hanno familiarità e non interrompa il flusso di lavoro. Inoltre, ci sono standard e convenzioni del settore a cui siamo tutti (inconsciamente) abituati. Non aspettarti mai che i tuoi utenti cambino completamente le loro abitudini. È più probabile che cercheranno altrove se l'interfaccia non è intuitiva.

Prendi le scorciatoie da tastiera. Potresti creare il tuo set di scorciatoie e aspettarti che gli utenti le imparino (probabilmente non lo faranno). Oppure potresti aggiungere quelli che le persone già usano. Molti dei nostri utenti usano già Slack, ad esempio, quindi abbiamo aggiunto una scorciatoia con cui hanno già familiarità ( Command + K per i salti veloci funziona anche in Active Collab ).

Quando i flussi utente sono a posto, il nostro designer dell'esperienza utente simula il design in Sketch. Raramente utilizziamo HTML nelle prime fasi. Le visualizzazioni di Sketch ben congegnate ci offrono una flessibilità sufficiente da non dover fare alcun passo indietro quando iniziamo a programmare. Il design iniziale di solito finisce per corrispondere a circa l'80% del prodotto finale. Il resto viene aggiunto e regolato lungo il percorso.

Un altro passo importante del processo di progettazione è la copia. I nostri copywriter dedicano molta attenzione ad ogni singola parola. Abbiamo anche la nostra guida di stile, per sembrare il più accessibile ed essere il più facile da capire possibile. Ad esempio, dire "certificato di sicurezza" invece di "certificato SSL" trasmette in parole povere qualcosa con cui un utente medio potrebbe non avere familiarità.

Al termine, la funzionalità viene assegnata a un team di sviluppo. Il team è composto da un project manager, uno sviluppatore principale e una serie di sviluppatori back-end e front-end, a seconda del carico di lavoro. Il project manager si assicura che tutto funzioni senza intoppi e nei tempi previsti, mentre lo sviluppatore principale si occupa dell'aspetto tecnico delle cose. Inoltre coordinano e guidano gli sviluppatori junior.

È ora di dare il via alle cose

I nostri incontri d'inizio non sono noiosi incontri motivazionali. Sono opportunità per un team di sviluppo (composto da sviluppatori junior e senior) di incontrare il project manager e il product owner.

Invece di consentire monologhi vuoti, ci concentriamo sul mettere le parole di tutti in compiti attuabili. Durante la giornata si svolgono tre importanti incontri :

• Il Product Owner presenta al team la caratteristica data, le idee alla base, i progetti iniziali ei risultati attesi.
• Quindi, il team ha una propria riunione in cui discute il piano d'azione, i potenziali problemi e il programma dei test.
• All'incontro finale partecipano tutti i soggetti coinvolti e il piano prende la sua forma definitiva. Al termine di questo incontro, il team fornisce stime per le demo e una data di scadenza finale.

Tre incontri possono sembrare tanti per un giorno, ma è così che ci assicuriamo che i problemi vengano risolti presto. Riempire gli spazi vuoti in questa fase consente ai nostri sviluppatori di risparmiare un sacco di tempo, false partenze e backtracking. Gli incontri incoraggiano anche il lavoro di squadra e fanno sentire a tutti che i loro contributi sono ben accetti.

Dopo gli incontri, il team avrà tutte le informazioni necessarie:

1. Che cosa? Questo è l' ambito della funzionalità e include tutto ciò che deve essere eseguito, nonché potenziali blocchi e colli di bottiglia. Cerchiamo di anticipare quanti più scenari e casi limite possibili. Prevedere tutti loro non è facile; spesso vengono fuori mentre andiamo.
2. Come mai? Il proprietario del prodotto stima il valore commerciale di una funzione e spiega perché ne vale la pena. In questo modo, il team ottiene un quadro chiaro dei vantaggi per i clienti e del prodotto. La motivazione principale qui è che tutti dovrebbero capire perché il loro lavoro è importante e come contribuisce all'azienda nel suo insieme.
3. Come? Delineando i passaggi necessari per completare una funzione , ci assicuriamo che i nostri sviluppatori non perdano mai la bussola. Abbiamo anche stabilito aspettative realistiche aggiungendo un tag di complessità. Abbiamo scelto le taglie delle t-shirt: la S può essere risolta in poche ore, mentre la XXL richiede settimane o più per essere completata.
4. Chi? Il responsabile del team è responsabile del completamento di una funzionalità o di un'attività in tempo e dell'aggiornamento del proprietario del prodotto sullo stato di avanzamento. Gli altri membri del team sono assegnati al proprio insieme di attività secondarie, in modo che sia perfettamente chiaro chi è responsabile di cosa. Mantenerlo il più trasparente possibile ci aiuta a vedere se qualcuno sta lottando o causando ritardi.
5. Quando? Con tutto preso in considerazione, viene stimata una data di scadenza. Se un'attività è in ritardo, analizziamo i motivi e utilizziamo quell'esperienza la prossima volta. In questo modo, una scadenza mancata diventa un'opportunità di apprendimento e non una fonte di stress.

Il giorno del calcio d'inizio può diventare frenetico, ma è anche molto fruttuoso. Ognuno interviene con idee e commenti. Un'attività si trasforma da una lavagna vuota a un hub per commenti, modifiche e aggiornamenti. Entro la fine della giornata, il team di sviluppo ha un quadro chiaro del lavoro da svolgere e un terreno solido su cui costruire.

Esaminiamo questa lista di controllo prima di iniziare il lavoro:

• caratteristica spiegata,
• fasi per il completamento delineate,
• valore aziendale assegnato dal proprietario del prodotto,
• complessità assegnata dal team,
• funzionalità e dipendenze di bug identificate,
• criteri di prestazione individuati (se necessario),
• demo in programma,
• date di inizio e fine stabilite dal capogruppo.

Questo è il momento in cui un'attività si sposta nella colonna "In corso".

È tempo di codifica!

Il lavoro di squadra in mostra

I nostri sviluppatori non lavorano mai da soli: è sempre un lavoro di squadra ed è di gran lunga il modo più efficiente per rilasciare nuove funzionalità. Prima che i team venissero introdotti, uno sviluppatore (junior) sarebbe rimasto bloccato con un problema e avrebbe potuto girare in tondo per giorni (senza che nessuno se ne rendesse conto). Oppure, se non fossero il tipo da ranger solitario, distraerebbero costantemente colleghi e manager.

D'altra parte, con i team, mescoliamo persone con diversi set di abilità e livelli di esperienza. Ciò significa che a tutti viene assegnata una serie di compiti appropriati al loro livello. Inoltre, gli anziani hanno il vantaggio di imparare a gestire e allenare i compagni di squadra junior e gli junior possono chiedere aiuto. Poiché è un lavoro di squadra e tutti lavorano per lo stesso obiettivo, le domande non sono considerate distrazioni e il team può affrontare qualsiasi problema in modo molto più efficiente. Il team diventa un'entità auto-organizzante, suddividendo il lavoro in fasi (o sprint) e presentando il proprio lavoro durante le dimostrazioni.

Mostra e racconta

Secondo il programma, il team eseguirà una demo per il proprietario del prodotto. Lo scopo delle demo è mostrare le prestazioni di una funzionalità nel suo stato attuale e dove ha bisogno di più raffinatezza. È un controllo della realtà che non ammette scuse del tipo: "Servono solo alcuni ritocchi finali" (ritocchi che richiederebbero un altro mese). Inoltre, se le cose iniziano a prendere una piega sbagliata, i proprietari dei prodotti possono reagire rapidamente.

Incontri settimanali

Abbiamo iniziato con brevi riunioni quotidiane regolari a cui hanno partecipato tutti gli sviluppatori. Ogni sviluppatore descriverebbe brevemente su cosa stavano lavorando, i loro problemi, i loro blocchi e se avevano bisogno di aiuto. Divenne presto evidente che questi incontri dovevano essere più mirati e fornire risultati tangibili. Quindi, siamo passati a tenere riunioni con i singoli team circa una volta alla settimana. Questo è il modo in cui i proprietari del prodotto e il project manager sono tenuti al passo e tutti i potenziali problemi vengono affrontati sul posto.

Mettendolo alla prova

Il codice è stato scritto, le demo hanno avuto successo, tutto sembra andare a buon fine... finché non rilasci la funzione e vedi che l'app si arresta in modo anomalo. Ecco perché ogni caratteristica che realizziamo passa attraverso il controllo qualità (Q/A). Sempre. Il nostro tester esamina meticolosamente ogni possibile scenario, controllando tutte le opzioni ed eseguendo test in ambienti diversi. Una funzione raramente supera Q/A al primo tentativo.

Per aumentare la produttività, consentivamo agli sviluppatori di iniziare con nuove funzionalità durante questa fase, ma ciò si traduceva in molte funzionalità ritardate e semifinite. Quindi, ora il team di sviluppo si tiene occupato lavorando su piccole attività di manutenzione mentre le loro funzionalità vengono riviste. Se Q/A rileva un problema, gli sviluppatori lo risolvono immediatamente e inviano nuovamente. Il processo viene ripetuto finché la funzione non supera la Q/A e passa alla revisione del codice.

Questo è quando uno sviluppatore senior si assicura che il codice sia scritto secondo i nostri standard. Un ultimo passaggio prima del rilascio è scrivere la documentazione: non vuoi essere sommerso dalle e-mail di supporto dopo aver rilasciato una funzionalità che nessuno sa come utilizzare. I nostri copywriter aggiornano anche le note di rilascio e scrivono materiale di marketing, come annunci e-mail e post di blog.

Ecco la nostra definizione di "fatto":

• test automatici scritti,
• Q/A fatto e tutte le attività risultanti completate,
• revisione del codice eseguita e codice unito al master,
• note di rilascio aggiornate,
• funzionalità e dipendenze di bug identificate.

L'attività ha raggiunto la fase finale, denominata "Release Q".

Giorno di rilascio

Quando abbiamo scelto un giorno per le nuove uscite, abbiamo immediatamente deciso contro venerdì e lunedì. Il venerdì non va bene perché tutti i potenziali problemi non verrebbero risolti fino a lunedì; inoltre, il team di supporto era già piuttosto impegnato allora. Il lunedì non è il momento migliore perché qualsiasi aggiornamento importante richiede una preparazione, che dovrebbe essere eseguita nel fine settimana. È sempre bene lasciare un giorno per i ritocchi finali. Questo restringe le opzioni a tre giorni e siamo andati con martedì. Ecco perché:

• Abbiamo lunedì per rivedere la versione e aggiungere gli ultimi ritocchi prima della distribuzione.
• Se ci sono delle frasi non tradotte (la nostra web app è disponibile in sette lingue), abbiamo abbastanza tempo per finire la traduzione.
• Il team di marketing ha tutto il tempo per inviare newsletter e annunci tramite i social media.
• Siamo disponibili a fornire supporto per l'aggiornamento in modo rapido ed efficiente per il resto della settimana.
• Se una scadenza è scaduta per qualsiasi motivo, abbiamo ancora mercoledì o giovedì per completare i lavori.

Giornata di attività gratuita

Il giorno dopo un rilascio importante è un giorno libero per la squadra. Questo è quando imparano nuove abilità o fanno qualsiasi cosa relativa al lavoro che trovano interessante. Anche se tutti sono ansiosi di sapere quale funzione daremo il via il giorno successivo, il team non ne discute ancora. Invece, si rilasseranno e forse guarderanno una presentazione sulla storia di Erlang, o finiranno di leggere quell'articolo sul perché PSR-7 e il middleware sono importanti per lo sviluppo moderno di PHP, o avranno la loro discussione retrospettiva. È un giorno meritato per ricaricare la batteria e celebrare un lavoro ben fatto.

Giornata della caccia agli insetti

Oltre a sviluppare nuove importanti funzionalità, c'è sempre del lavoro da fare su quelle esistenti. Che si tratti di una correzione di bug, di un aggiornamento del design o di una piccola modifica della funzionalità, il team deve occuparsene in un tempo ragionevole.

Questo è il motivo per cui abbiamo giorni di caccia ai bug almeno una volta al mese. È quando tutti gli sviluppatori smettono di lavorare sui loro progetti principali e rivolgono la loro attenzione alla manutenzione. Questo sforzo mirato si è rivelato un grande successo. Quando tutti lavorano esclusivamente sui bug nello stesso giorno e sono disponibili ad aiutarsi a vicenda, il team risolve un numero enorme di problemi.

Qual'è il risultato?

Il rilascio di una grande funzionalità ora richiede in media circa tre settimane, dall'inizio allo sviluppo, test, revisione del codice, documentazione e rilascio finale. Una caratteristica di complessità equivalente ci impiegava 45 giorni. Dal nostro punto di vista, si tratta di un aumento della produttività del 100% . L'abbiamo realizzato con le stesse risorse e persone, l'unica differenza è un flusso di lavoro migliorato.

Quindi, se abbiamo un consiglio per te, è questo: coltivare una cultura aziendale che elimini la paura del cambiamento renderà il tuo team migliore in quello che fa. Che tu lo chiami Scrum, Kanban o Lean non importa, purché aiuti la tua azienda a crescere. Sperimentazione e innovazione sono al centro di ogni approccio agile. Non abbiate paura di testare diverse soluzioni, misurare i risultati e, sulla base dei risultati, modificare le pratiche esistenti. Seguiranno buoni risultati.