Assistenza

In un precedente post abbiamo parlato dell’assistenza continuativa e della sua importanza. Tra i principali motivi per avere ad un piano di assistenza continuativa citiamo i costi di manutenzione che aumentano vertiginosamente nel caso in cui un’app non mantenuta debba essere aggiornata dopo anni. Le cause sono tra le più svariate: gli aggiornamenti dei sistemi operativi portano cambiamenti nelle funzioni, le dipendenze tra le librerie si modificano, vecchi sistemi vengono dismessi e seguono tanti altri problemi tecnici sui quali non vogliamo annoiarvi.

In questo articolo parliamo di un secondo tipo di assistenza: l’assistenza e la gestione nel processo di risoluzione di bug in una software house. 

Un bug (o baco, tradotto in italiano) è un comportamento inaspettato o scorretto di un’applicazione. Può trattarsi di un semplice testo sbagliato, fino ad arrivare ad un’inaspettata chiusura dell’app quando viene premuto un particolare bottone in un contesto ancor più particolare. I bug possono essere trovati da tutti gli utilizzatori del prodotto, che siano utenti finali o tester interni dell’azienda produttrice del software. Una volta trovati, i bug, necessitano di un fix (in gergo tecnico), cioè devono essere risolti. 

Oggi parleremo di come vengono gestiti i bug trovati in un prodotto all’interno di software house strutturate come DuckMa. 

Assistenza: le 2 tipologie

Come già accennato abbiamo discusso in un altro post l’assistenza continuativa, descrivibile anche come mantenimento di un software. Per non dilungare troppo questo articolo vi rimando direttamente alla fonte.

Il secondo tipo di assistenza, mira a risolvere i problemi trovati dal cliente e dagli utilizzatori dell’app, cioè fixare i bug. Per DuckMa l’assistenza comprende tutto il processo:

• la presa in carico di una segnalazione, 
• la stima della tempistica di risoluzione, 
• la richiesta di conferma (se la stima è superiore a 4h),
• la risoluzione del problema. 

Per semplificare meglio in un esempio, possiamo vedere cos’è un bug e cosa non è un bug:

• Il bottone “impostazioni” che fa chiudere l’app quando viene premuto è un bug;
• Un messaggio di una chat che non arriva può essere un bug;
• Un’immagine che viene tagliata male è un bug;
• La scritta “imostazioni” anziché “impostazioni” è un bug;
• La mancanza delle impostazioni, se non preventivata, non è un bug, ma una richiesta di aggiunta di funzionalità.

Quest’ultimo tipo di necessità viene trattato come richiesta di cambiamento, facendo uno studio funzionale e grafico prima dell’implementazione, secondo il metodo DuckMa.

30 giorni free

Produrre un software senza bug è impossibile. Per questo DuckMa garantisce 30 giorni di assistenza gratuita per tutti i clienti che decidono di seguire il metodo e creare il loro successo con noi!

Ovviamente tutti i software prodotti vengono già sottoposti ad una serie stringente di test per far emergere il maggior numero possibile di bug ancor prima che il cliente possa testare l’applicazione:

1. Durante il processo di sviluppo viene creato un documento di collaudo contenente centinaia di test che verranno effettuati prima della consegna del software.
2. Se durante lo svolgimento di questi test emergessero dei bug, vengono tempestivamente fixati dagli sviluppatori che stanno lavorando sul progetto.
3. Una volta eseguiti i fix, il prodotto viene sottoposto nuovamente a tutti i test, anche quelli che erano stati superati correttamente, per assicurarsi che non sia successo nulla al resto dell’app durante le correzioni. 
4. Il ciclo si ripete fino alla consegna del prodotto al cliente.

Potrebbe capitare che alcuni bug necessitino tempi di risoluzione che vanno oltre la data di consegna al cliente. In quel caso il cliente viene informato durante la consegna che siamo già al corrente del bug che troverà in quel particolare caso e che si sta già lavorando alla sistemazione.

Conclusi i 30 giorni di assistenza gratuita sono ovviamente disponibili per il cliente diversi piani tra cui scegliere per la gestione dei bug che emergono nel software:

• Pacchetto ore: viene stabilito un prezzo orario basato sul numero di ore annue acquistate per l’assistenza. Se le ore di assistenza non vengono sfruttate saranno disponibili l’anno seguente.
• Tariffa oraria: non viene acquistato alcun pacchetto, ma vengono fatturate le ore impiegate nella risoluzione dei problemi.

Vediamo ora come DuckMa lavora in un processo collaborativo continuo con i clienti per ricevere e risolvere tempestivamente le segnalazioni di bug.

ClickUp

Esistono vari strumenti per la gestione dei progetti, noi abbiamo scelto ClickUp. Il nostro team di esperti certificati ha studiato un modo efficace ed efficiente per la ricezione delle segnalazioni da parte del cliente e la presa in carico dei bug da fixare.

Da un punto di vista generale ClickUp è una piattaforma di gestione del lavoro basata su cloud che consente di organizzare, gestire e collaborare sui progetti. È una soluzione all-in-one che offre una serie di funzionalità, tra cui:

• Gestione dei progetti: una serie di strumenti per la gestione dei progetti, tra cui la pianificazione, la tracciabilità del tempo, la comunicazione e la collaborazione.
• Gestione delle attività: consente di creare e gestire attività, impostare scadenze e assegnare responsabilità.
• Gestione dei documenti: consente di archiviare e condividere documenti, nonché di collaborare su di essi.
• Gestione delle comunicazioni: offre una serie di strumenti per la comunicazione interna ed esterna, tra cui chat, videoconferenze e gestione dei commenti.

ClickUp è una soluzione flessibile e scalabile che può essere adattata alle esigenze specifiche di ogni azienda. Tra i maggiori vantaggi troviamo:

• Flessibilità: offre una serie di funzionalità che possono essere adattate alle esigenze specifiche di ogni azienda.
• Scalabilità: può essere adattato alle esigenze di crescita di un’azienda.
• Collaborazione: offre una serie di strumenti che facilitano la collaborazione tra i membri del team.
• Integrazioni: si integra con una serie di altre app e servizi, rendendolo facile da utilizzare con le soluzioni esistenti.

ClickUp lavora in modo gerarchico. All’interno del workspace di ClickUp ogni progetto ha uno spazio dedicato. All’interno sono presenti diverse cartelle di lavoro ed una in particolare dedicata all’assistenza per bug fixing. Nella cartella è presente una lista dedicata al cliente, all’interno della quale può inserire un’attività per ogni bug che trova e può vedere lo stato di tutti i bug che sono stati segnalati in precedenza. 

Stati

In ClickUp organizziamo i progetti dividendole in attività (o task) di minore entità per frammentare il lavoro e suddividerlo in modo più coerente. Ad ogni attività può essere assegnato uno stato. Lo stato ci permette di conoscere in quale fase di lavorazione si trova una particolare attività.

Ogni cartella ha degli stati dedicati, tra cui anche l’assistenza. La gestione degli stati nella cartella dell’assistenza al cliente per bug fixing è stata studiata per ottimizzare le tempistiche di risoluzione e per agevolare il monitoraggio delle segnalazioni. 

Al cliente viene fornita una lista contente un’attività di esempio contenente tutti i campi necessari per la comprensione del bug. Questa attività dovrà essere duplicata prima di essere compilata, in modo che il cliente abbia sempre un template di partenza per segnalare correttamente ogni bug che trova.

Una volta che la segnalazione è stata effettuata, l’attività sarà creata nello stato “OPEN”. In questo stato il Project Manager (PM) viene notificato di una richiesta per bug e sa che dovrà analizzarla.

Quando il PM apre l’attività per stimare la durata necessaria alla risoluzione pone come stato “ANALISI”, in modo che il cliente sappia in tempo reale che la sua segnalazione è in corso di analisi per la risoluzione. In questa fase sono possibili 4 strade:

• Se si tratta di un bug e la risoluzione richiede meno di 4 ore, il PM pone come stato “PRESA IN CARICO” con il significato che sono iniziati i lavori per risolvere il bug;
• Se non sono sufficienti le informazioni inserite nell’attività da parte del cliente o se sono necessarie più di 4 ore alla risoluzione verrà posto lo stato “INFORMAZIONI AGGIUNTIVE”. Successivamente nella sezione dei commenti dell’attività verranno richieste le informazioni necessarie o la conferma al cliente per procedere con la risoluzione superiore alle 4 ore;
• Se il bug non è replicabile, o non si tratta di un bug, l’attività viene posta in “RESPINTA” in quanto non si tratta di un bug da risolvere, oppure non è possibile riprodurre il problema su alcun dispositivo;
• Se non si tratta di un bug, ma di una richiesta di cambiamento, l’attività viene posta nello stato “CR”. Lo stato “CR” implica lo spostamento dell’attività in un’altra lista che contiene le evoluzioni future del software o le richieste di cambiamento che non erano state concordate e preventivate prima della fase di sviluppo.

Infine, possiamo trovare due stati conclusivi del bug. Il primo deriva dalla richiesta di informazioni aggiuntive, nel caso il bug richieda più di 4 ore per la risoluzione, in cui il cliente può decidere di attendere con la risoluzione e porre lo stato di “PENDING”. Questo segnala che si è a conoscenza del bug e delle tempistiche di risoluzione, ma si vuole aspettare a risolverlo.

Oppure, nel caso di risoluzione del bug ed esecuzione dei test con esito positivo verrà inserito lo stato “COMPLETE” per segnalare al cliente la corretta risoluzione del problema segnalato.