Chi dovrebbe gestire l'assistenza clienti all'interno di un team Agile?

Who should handle customer support within an Agile team?

"Assistenza clienti"? Seriamente, l'assistenza clienti viene gestita da un team di "Assistenza clienti". Ha bisogno di abilità completamente diverse rispetto alla programmazione, avendo uno sviluppatore che fa parte dello stesso campionato di lui come custode o contabile. Forse uno specifico sviluppatore potrebbe , ma in generale, è probabile che sia una pessima idea.

Responding to user bug reports & creating stories/issues for them

Questo è un lavoro di proprietari di prodotti. Ricevere feedback dagli stakeholder e metterli in forma per il pacchetto di lavoro per il team è il principale lavoro dei proprietari dei prodotti.

Responding to negative app store reviews

Come reagire? Come nel marketing? Come nelle relazioni comunitarie? Sono diversi lavori . E hanno bisogno di un set di abilità diverso rispetto a quello degli sviluppatori.

Troubleshooting user problems

Questo potrebbe essere o non essere il lavoro degli sviluppatori. La maggior parte delle aziende ha una squadra diversa per fare questo, ma almeno, tra tutti questi punti, questo è uno che uno sviluppatore dovrebbe essere qualificato a fare.

Responding to overall user feedback & feature requests

Parlare con le parti interessate è un lavoro di proprietari di prodotti.

Fixing urgent defects that were not known at the time of sprint planning

Dopo l'assegnazione delle priorità da parte del proprietario del prodotto, non appena l'attività / storia del difetto si trova nello sprint backlog, che è effettivamente un'attività di sviluppo.

TL; DR

L'assistenza clienti è un lavoro . Non è qualcosa che uno sviluppatore fa durante la pausa pranzo. Hai bisogno anche di un diverso set di abilità. Devi assumere qualcuno per quello allo stesso modo in cui assumerai un contabile. Non avresti mai uno sviluppatore fare le aziende libri un giorno alla settimana sia.

Gli sviluppatori commettono un errore evitando completamente qualsiasi supporto. C'è tempo e spazio per coinvolgere la squadra.

Molte aziende stanno imparando che il supporto clienti è ciò che è il loro business. Mi auguro che una società di software, in particolare quella che sta cercando di essere agile (supponendo che sia per questo che si utilizza Scrum), coinvolgerebbe i propri sviluppatori in supporto più di una società tradizionale. Questo è molto importante nella prima versione di un prodotto.

Qual è il punto di avere un team di sviluppo a tutto tondo se hai intenzione di mettere il supporto in qualche silo? Essendo più vicini agli utenti, le linee di comunicazione sono molto più efficienti. Di nuovo, questo è ciò di cui parla l'agile. Nel tempo, più problemi ricadranno nei problemi che possono essere risolti da un team di supporto (applicare una patch, mostrare all'utente una soluzione alternativa, apportare modifiche alle impostazioni, dare istruzioni su come utilizzare l'app, ecc.). È qui che si concentra su "Individui e interazioni su processi e strumenti" entra in gioco.

Mi rendo conto che molti sviluppatori lo odieranno assolutamente. Preferiscono essere codificati. Tuttavia, quando gli sviluppatori non capiscono come viene utilizzata la loro app, cadono vittima dei capricci e delle richieste dei gruppi di vendita e marketing. Non che gli addetti alle vendite conoscano i loro utenti, ma tendono a essere più bravi nel raccontare storie per esprimere il loro punto di vista.

Tutti i software hanno bug. La tua squadra dovrebbe fare una prima impressione di farli risolvere velocemente (questo è l'obiettivo vero?). Non avrai una seconda possibilità.

Che cos'è il documento definitivo, The Scrum Guide , per esempio?

• Responding to user bug reports & creating stories/issues for them
• Responding to negative app store reviews
• Troubleshooting user problems

Niente, ad eccezione del Product Owner che gestisce il Product Backlog come indicato di seguito. Questi possono, e probabilmente dovrebbero, essere gestiti da altri team che supportano il prodotto. Una volta identificato un problema impugnabile, lo Scrum Team può intervenire all'interno del framework Scrum come descritto di seguito.

• Responding to overall user feedback & feature requests
• Fixing urgent defects that were not known at the time of sprint planning

Per queste preoccupazioni ci sono indicazioni e aspettative.

During the Sprint Review, the Scrum Team and stakeholders collaborate about what was done in the Sprint. Based on that and any changes to the Product Backlog during the Sprint, attendees collaborate on the next things that could be done to optimize value.

Questo evento dovrebbe essere una fonte primaria di feedback e richieste aggiuntive.

The Product Backlog is an ordered list of everything that is known to be needed in the product. It is the single source of requirements for any changes to be made to the product. The Product Owner is responsible for the Product Backlog, including its content, availability, and ordering.

Una volta identificato un desiderio, il Product Owner o un delegato possono creare un Product Backlog Item (PBI) da perfezionare.

Se viene determinato che un bug è critico, può essere priorizzato ed eseguito in vari modi:

1. È posizionato nella parte superiore del Product Backlog da indirizzare nel prossimo Sprint. Questa opzione può essere scelta perché lo Sprint corrente è quasi completo, la quantità stimata di sforzo non può essere completata nello Sprint corrente, ecc.
2. Il team di sviluppo e il proprietario del prodotto negoziano per modificare l'attuale Sprint Backlog. Only the Development Team can change its Sprint Backlog during a Sprint. Questa opzione può essere scelta se il Team di sviluppo, il problema può essere risolto all'interno del time-box di Sprint, lo Sprint Goal non sarebbe in pericolo, ecc.
3. Il proprietario del prodotto annulla lo sprint in modo che il problema possa essere risolto. %codice%

Non c'è A gile ^(tm) ; c'è la filosofia agile .

Who should handle customer support within an Agile team?

In generale, un team di assistenza clienti o un individuo dovrebbe gestire l'assistenza clienti. Un adeguato supporto al cliente nel tradizionale senso della parola richiede un insieme distinto di competenze che molti sviluppatori di software non possiedono. Non è diverso da chi dovrebbe gestire il marketing o le finanze oi servizi di pulizie.

In breve, "Agile" non è un metodo per gestire un'impresa, è un metodo per lo sviluppo di software. Non puoi guardare agile per fornire risposte su come gestire la tua attività.

Tutto ciò che viene detto, nella più pura forma di agilità, è una domanda che solo la tua squadra può decidere. In generale, alcune delle cose che hai elencato appartengono al team di sviluppo (attività legate allo sviluppo del software reale) e altre al proprietario del prodotto (interazione con il cliente). Nessuna delle cose che hai menzionato dovrebbe appartenere al maestro di mischia.

Se il tuo team ha il compito di gestire ogni aspetto dello sviluppo del software dall'iniziazione alla consegna finale e al supporto, allora è responsabilità del tuo team capire come gestire le attività di consegna non software poiché la soluzione sarà esclusiva per la tua azienda e il tuo team.

Non sono d'accordo con le risposte che dicono che il team non è responsabile per il supporto. Se produci qualcosa come una squadra, dovresti esserne responsabile. Se ci sono bug segnalati, dovresti risolverlo. Puoi semplicemente includere bug nel backlog del team. Puoi ruotare i team che lavorano con supporto e sviluppo. In alternativa, un po 'di tempo durante lo sprint può essere riservato per il lavoro di supporto.

Nella mia organizzazione ci sono tre livelli di supporto. Il primo livello è l'organizzazione di consulenza che implementa presso il cliente. Il secondo livello sono i centri di supporto. Siamo al terzo livello in R & D. Se il bug è stato trovato nella nostra versione rilasciata, lo correggiamo.

Il tuo team di sviluppatori dovrebbe sviluppare software e non svolgere attività di supporto. In una piccola azienda, vuoi che le persone siano fluide, ma di solito è una buona idea mantenere la maggior parte dei ruoli abbastanza ben definiti. Se un dipendente specifico è un buon sviluppatore, ma è anche la persona del team con le competenze e l'attitudine più adatte a fare l'assistenza clienti, quel dipendente può indossare due cappelli. Ma solo perché uno sviluppatore indossa anche il cappello di supporto non significa che il resto del team di sviluppatori dovrebbe indossare il cappello di supporto. Se la persona assunta come proprietario del prodotto è anche uno sviluppatore esperto, allora gli permetta di indossare il cappello da sviluppatore; se il tuo supervisore è anche un contabile qualificato, lascia che indossino il cappello; se hai capito che devi riempire un cappello di supporto e la persona migliore per farlo nel team è uno sviluppatore, allora possono indossare sia lo sviluppatore che i cappelli di supporto.

Offri alle persone più cappelli, in base alle loro capacità e attitudini individuali, ma non estendere le responsabilità di un singolo cappello al punto in cui sarebbe impossibile assumere una singola persona che potrebbe effettivamente indossarlo.

Se sei un tipo agile, dovresti amare le richieste di supporto tanto quanto noi, perché sono una parte enorme del nostro feedback. Detto questo, è facile essere sopraffatti e rimanere indietro quando ancora non si dispone di un team di supporto per eliminare la pressione.