Crediamo fortemente nell'unione delle forze. Dopo tutto, si può imparare molto da e con gli altri. Inoltre, prospettive diverse sullo stesso argomento aiutano enormemente a prendere una decisione equilibrata.
Lo sviluppo e il supporto sono essenziali per fornire le migliori soluzioni ai clienti.
In Easy LMS, lo sviluppo e il supporto sono essenziali per fornire le migliori soluzioni ai clienti. Lavoravano già insieme, ma erano team separati.
Fino a giugno 2021, ecco come lavoravano insieme in poche parole - semplificato e senza sfumature ?. Il supporto era responsabile di servire i nostri clienti al meglio. Dedicavano molto tempo a elencarli e ad aiutarli a raggiungere i loro obiettivi di allenamento. Parte di questo compito consisteva nel rispondere alle loro domande in chat o nella demo e nel registrare i loro bug e le loro richieste di funzionalità. Legare il tutto e partire! Poi è arrivato il proprietario del prodotto. Sulla base delle informazioni registrate dai consulenti e della sua visione del prodotto, decideva quale funzionalità costruire e proponeva la sua soluzione al team di sviluppo. Gli sviluppatori hanno realizzato la soluzione - raramente con l'aiuto e la comprensione dell'assistenza - e l'hanno lanciata! Infine, i consulenti hanno aggiornato tutti i contenuti correlati. Fatto!
Sfruttare maggiormente i punti di forza del team
Come potete leggere, potevamo sfruttare meglio i punti di forza dei team. Per questo abbiamo deciso di portare la collaborazione a un livello superiore. È nato un nuovo team: un team di problem solving che comprende membri dello sviluppo e dell'assistenza. Inoltre, nel team sono coinvolti un UX designer e un Product Owner.
Intervista al team Jabba
Al momento abbiamo due squadre per la risoluzione dei problemi: la squadra Jabba (il nome è composto da tutte le iniziali dei membri della squadra) e SummerKnowly (dal nome della nostra mascotte). Anna e Joey sono membri del team Jabba. Insieme al gufo della comunicazione Caroline, parlano dei dettagli della collaborazione aggiornata.
Caroline: Da giugno 2021 abbiamo i team di problem solving. Anna, puoi spiegarci come i team elaborano le domande dei clienti oggi?
Anna: "L'assistenza continua a trattare le domande dei clienti; siamo il primo punto di contatto. Rispondiamo e li aiutiamo. Se un cliente segnala un bug, cerchiamo di riprodurlo con l'aiuto dello sviluppo e, se ci riusciamo, lo registriamo come bug e ne indichiamo l'urgenza e l'impatto.
Per le richieste di funzionalità è lo stesso che per i bug, a parte la fase di riproduzione. Inviamo una richiesta di funzionalità con il maggior numero di dettagli possibile a Productboard, uno strumento per gestire tutte le nostre richieste di funzionalità. Il nostro Product Owner Jeroen e l'UX Designer & Researcher Dyann le elaborano e valutano attentamente le richieste di funzionalità rispetto agli obiettivi della nostra azienda. Il risultato è un elenco di nuove funzionalità da costruire".
Caroline: Ok, sembra un po' come il vecchio processo; inoltre, c'è più comunicazione e interazione. Quando entra in gioco lo sviluppo?
Apportiamo prospettive diverse
: "Proprio in questo momento. Al posto del proprietario del prodotto, i team sono responsabili di cosa lavorare e della soluzione scelta. Dal nostro team di problem solving, Anna e io siamo responsabili di scegliere su cosa lavorare successivamente come team. Qui apportiamo prospettive diverse. Anna sa di cosa ha bisogno un cliente, mentre io ho un buon senso della complessità di una richiesta".
"Diamo priorità ai bug rispetto alle potenziali nuove funzionalità e decidiamo su cosa lavorare in base all'urgenza temporale. Quando abbiamo scelto, scriviamo la situazione attuale del problema e il risultato di tale situazione, in modo che il resto del team sappia perché è urgente risolvere il problema. Poi il resto del team viene a discutere la soluzione e a scriverla. Dyann, il nostro UX Designer & Researcher, si unisce spesso alla conversazione per garantire che la soluzione scelta sia facile da usare e da capire. La discussione è preziosa grazie ai molteplici punti di vista che portiamo con noi. Tutti hanno voce in capitolo. Dopodiché, inviamo la nostra proposta al proprietario del prodotto per l'approvazione".
Caroline: Ottiene sempre un'approvazione immediata?
: "La maggior parte delle volte. Se non viene approvata, Jeroen avrà delle domande a cui cercheremo di rispondere in una telefonata o nel documento della proposta. C'è un po' di scrittura avanti e indietro prima di ottenere il via libera. Una volta approvato, scriviamo le storie dell'utente (in rosso: una breve spiegazione scritta di ciò che un utente vuole e si aspetta) e dividiamo i compiti tra il team.
Caroline: Anche il supporto è coinvolto nella scrittura delle storie utente? Prima lo faceva solo lo sviluppo.
Anna: "Dipende se si tratta di una funzionalità o di un bug. Ci uniamo sempre per le nuove funzionalità, mentre per i bug non è sempre necessario. Scrivere storie utente è relativamente nuovo per noi. Quindi, stiamo lavorando per migliorare".
"Quello che facciamo è anche iniziare immediatamente a scrivere i contenuti correlati per la nuova funzione. I contenuti correlati sono le etichette per l'interfaccia dell'amministratore o dei partecipanti o gli articoli di aiuto. Inoltre, dobbiamo decidere quali comunicazioni devono essere fatte con i clienti, come messaggi all'interno del prodotto, messaggi diretti ai clienti, ecc. Questo lo facciamo insieme alla creazione della funzione".
Caroline: Quindi, il cambiamento principale è che il supporto e lo sviluppo scelgono un problema e creano la soluzione insieme. Entrambi avete una maggiore influenza sul risultato finale. Come vive questo nuovo processo di lavoro?
Anna: "È stato sicuramente un cambiamento abituarsi al nuovo stile di lavoro in termini di programmazione e di lavoro a stretto contatto con nuove persone. Ma è stato anche un vantaggio. Mi piace lavorare a più stretto contatto con gli sviluppatori perché hanno prospettive diverse su cosa costruire e perché. Ora prendiamo decisioni più equilibrate. Inoltre, il fatto di vedere l'uno dall'altro come lavoriamo aiuta. In passato, ci adattavamo ai problemi. Facevamo più lavoro manuale e questo diventava la norma. Gli sviluppatori notano facilmente se il lavoro manuale può essere automatizzato o semplificato. È nella loro natura pensare in questo modo. Il loro aiuto ci ha già fatto risparmiare una grande quantità di tempo".
Ora abbiamo una visione molto più approfondita di ciò che sta effettivamente accadendo
Joey: "Ora abbiamo una visione molto più approfondita di ciò che accade realmente. Come i clienti utilizzano il nostro LMS, cosa è importante per loro e le motivazioni che li spingono a farlo. Ci sembra di essere più in contatto con le esigenze dei clienti. In passato, un problema ci veniva consegnato dopo aver attraversato diversi livelli aziendali. Noi eravamo alla fine del processo, quindi molte informazioni essenziali sono andate perse lungo il percorso e molte domande non sono state poste. Conosciamo molto meglio il sistema dal punto di vista tecnico e affrontiamo i problemi in modo diverso. La collaborazione con il supporto fin dall'inizio ci permette di porre le domande necessarie per costruire una soluzione efficace e sostenibile. Possiamo dire che il gap informativo è stato colmato".
Caroline: Stiamo anche facendo interviste ai clienti per capire meglio le loro esigenze. Immagino che questo sia molto utile per il team di risoluzione dei problemi.
Joey: "Sì, è così! Perché ciò che i clienti vogliono non è sempre ciò di cui hanno bisogno. Ciò che pensano sia sbagliato non è sempre l'elemento di fondo che deve essere risolto. Questo è molto difficile da vedere per un esterno. Quindi, i colloqui con i clienti sono uno strumento prezioso per rivelare i problemi sottostanti. Ci danno anche un contesto!".
C'è molta condivisione di conoscenze
Caroline: Ok, torniamo alla collaborazione tra sviluppo e assistenza. In che modo vi completate a vicenda?
Anna: "C'è molta condivisione di conoscenze. Oltre ai consulenti che portano il punto di vista del cliente, entrambi sappiamo cose diverse sull'LMS. Di conseguenza, a volte noi sappiamo come funziona lo strumento e loro no, e viceversa. Quindi, ad esempio, per noi qualcosa è assolutamente ovvio (rosso. supporto), mentre gli sviluppatori non pensavano che funzionasse in quel modo o che la gente usasse una funzione in quel modo. Allo stesso modo, potremmo passare venti minuti a replicare un bug, mentre se invio un messaggio in merito a uno sviluppatore, questi conosce immediatamente la soluzione. Quindi, c'è un po' di tutto questo da entrambe le parti e ora possiamo condividerlo".
Caroline: C'è anche un aspetto negativo nel lavorare in questo modo?
Joey: "No, riunire sviluppo e assistenza è stato un buon passo. In generale, c'è sempre un aspetto negativo nel cambiare il proprio metodo di lavoro. Bisogna abituarsi e questo potrebbe portare a qualche frustrazione. Richiede molto tempo. Ma questi sono solo ostacoli da superare. Non è una rottura. Non vogliamo tornare indietro".
Caroline: Puoi spiegarci meglio. Qual è stata la sfida più grande?
Joey: "La sfida maggiore è stata capire come utilizzare i punti di forza degli altri nel modo giusto, senza perdere tempo. All'inizio, capitava spesso che alle riunioni ci fossero troppe persone che non potevano contribuire alla discussione. Quindi, si trattava di una perdita di tempo. Ma è successo anche il contrario. Ci sono state le cosiddette riunioni sbagliate. Le persone avrebbero potuto contribuire ma non c'erano. Alla fine ci siamo riusciti comunicando le nostre esperienze e applicando il metodo dei tentativi e degli errori".
Caroline: Anna, che cosa hai imparato dagli sviluppatori del tuo team?
Ho imparato a strutturare meglio il mio lavoro quotidiano con meno interruzioni.
Anna: "È difficile da dire. Scherzo. Innanzitutto, su un piano più filosofico, il lavoro degli sviluppatori è molto più strutturato del lavoro di supporto. Ho imparato a strutturare meglio il mio lavoro quotidiano con meno interruzioni. Gli sviluppatori sono molto rigidi nei confronti del loro tempo, il che è logico perché hanno bisogno di tempo ininterrotto per svolgere il loro lavoro: vedere questo mi aiuta a portare questo aspetto nella mia giornata lavorativa. Così ho imparato a rispettare meglio il mio tempo e i miei limiti. Inoltre, su una base più pratica, gli sviluppatori mi forniscono molti consigli per la risoluzione dei problemi per aiutare i clienti".
Caroline: E in cambio, Joey, cosa hai imparato dai consulenti di supporto del tuo team?
Joey: "Penso che sia l'opposto dell'ultima cosa che ha appena detto Anna. Abbiamo sempre avuto molte idee su come risolvere le cose; tutto ciò che potevamo fare era affidarci alle nostre conoscenze. Ma non usiamo il sistema come lo usano i clienti. Quindi, interagendo con l'assistenza, abbiamo imparato molto su come i clienti utilizzano effettivamente il sistema e su quali soluzioni sarebbero adatte a loro. Prima si trattava solo di tirare a indovinare e di fare del nostro meglio. Coinvolgiamo maggiormente la prospettiva degli utenti finali in ciò che facciamo. Possiamo immaginare meglio la loro situazione".
Caroline: Ritiene che ora stiamo costruendo soluzioni migliori per i nostri clienti?
Joey: "Sì, decisamente! Un buon esempio è il nostro sistema di pagamento completamente nuovo".
Caroline: Come azienda, miglioriamo e cambiamo continuamente. Ma dopo otto mesi vi sentite a vostro agio con il nuovo processo di lavoro?
Anna: "Per me, all'inizio, non ero sicura di poter contribuire. Ho davvero bisogno di stare qui? Qual è il mio valore? Qual è il motivo per cui sono qui? Almeno in quella parte, ora sono molto più fiducioso. Ho capito che ho un valore e un posto in squadra".
