Procedure interne

• Segnalazioni interne di bug e richieste di funzionalità
• Come vengono gestite le richieste dei clienti su bug, feature request e altro
• Approvazione e rilascio features RA

Segnalazioni interne di bug e richieste di funzionalità

Il team Delivery è incaricato di gestire le segnalazioni di bug e richieste di funzionalità della piattaforma RiseAct e dei prodotti Donation Box e passare le informazioni al team R&D. 

In questo modo è possibile avere una visione armonica delle richieste di sviluppo che arrivano e anche dare tracciabilità attraverso workplace delle problematiche che vengono gestite da R&D. 

In caso durante una demo o una chiamata con un possibile cliente vengano identificate problematiche da parte del team di Business Development, Officina Buone Cause o altri team si può seguire questa procedura. 

Procedura: 

1) Aprire un ticket

Si può fare in tre modi: 
-  Accedere a helpdesk.metadonors.it con le proprie credenziali MTD 
-  Inviare una mail a supporto.riseact@metadonors.it 
-  Direttamente da Workplace 

 2) Specificare nell'oggetto del ticket il tipo di problematica 
- Il ticket entrerà nell'helpdesk e verrà preso in carico dal team Delivery/Customer Success

3) Informazioni importanti da inserire nel ticket per facilitarne la gestione e valutarne l'impatto: 

- Nome del cliente o prospect 
- Specificare se è un cliente esistente o un prospect 
- Descrivere in dettaglio il problema
- Descrivere l'errore o la funzionalità che si desidererebbe vedere implementata 
- Specificare se si ritiene utile la creazione di una pagina del manuale 
- Allegare video o screenshot 
- Spiegare se è una funzione che blocca l'uso della piattaforma o il processo di vendita
- Specificare se impatta più clienti i prospect
- Indicare se c'è una scadenza per risolvere la questione 

4) Cosa succede dopo

Bug vengono rilasciati tutti - senza passare da staging - e va testato già rilasciato. Quando è rilasciato lo assegna a chi ha aperto il bug che lo testa, se è ok lo comunica al cliente e se ok lo archivia/comunica se no lo rimanda indietro riassiassegnarlo a R&D.

Come vengono gestite le richieste dei clienti su bug, feature request e altro

Quello che segue è un template che si può utilizzare nel caso in cui i clienti di RiseAct chiedano chiarimenti sulla nostra roadmap e sul modo in cui gestiamo le richieste di assistenza o di innovazione della piattaforma. 

*****

Con RiseAct, ma in realtà con ogni servizio di software che sia un software as a service, è importante distinguere tre tipi di segnalazioni e richieste tecniche:

• i ‘bug’ o malfunzionamenti, per cui una funzione che dovrebbe esistere non funziona correttamente e causa un errore
• il design, per cui una funzione è stata pensata in un certo modo al lancio del prodotto o nella sua evoluzione o è dipendente da altre funzioni (o dall’integrazione con le tecnologie di altre piattaforme, come per esempio il caso di Mailchimp)
• le personalizzazioni, per cui a un cliente serve una funzione particolare non richiesta da altri clienti

Su ognuna di queste le modalità e tempistiche di intervento sono diverse e dipendono da tre fattori principali:

• il contratto del cliente e il piano di assistenza 
• la ricorrenza di una questione su un numero ampio di clienti,
• la possibilità di far lavorare il nostro team di sviluppatori sui tanti prodotti software che vende la nostra azienda,
• l’esistenza di un altro prodotto della suite Metadonors che assolve meglio a quelle funzioni.

Per quanto riguarda l’attuale processo di Riseact questo è il nostro modo:

- Bug:
Ogni settimana prioritizziamo la gestione dei bug e mettiamo in priorità alta quelli bloccanti. L’intervento sui bug dipende dall’entità del problema e dal tipo di assistenza che ha un cliente (Smart Vs Priority). Con il servizio di supporto ci diamo anche sempre l’obiettivo di proporre un workaround, cioè un modo per gestire la situazione nel frattempo usando altre funzioni, magari non ideali ma almeno utili a ottenere l’obiettivo

- Design
A seconda di quanti clienti ci chiedono una nuova funzione e a seconda del carico di lavoro definiamo trimestralmente la nostra Roadmap.
Quando diciamo che qualcosa ‘lo stiamo facendo’ o ‘lo faremo’ significa che nell’arco di settimane o mesi la funzione verrà integrata. Anche in questo caso dipende da vari fattori, incluso quanti clienti fanno una richiesta, o quanto lavoro è richiesto per fare le nuove funzioni.

RiseAct inoltre rilascia nuove funzioni continuamente che sono frutto di questo percorso. Stiamo sviluppando procedure per aggiornare il manuale a ogni aggiornamento o fornire informazioni aggiornate ai clienti. 

La possibilità che una richiesta di cambio di design entri in roadmap dipende anche da quanto il cliente investe nella nostra piattaforma oppure se quella funzione non si trova meglio in un altro prodotto (per esempio, se un cliente chiede su RiseAct tante funzioni che sono sviluppate meglio in Donodoo).

In nessun caso le tempistiche dipendono o sono influenzate dalle esigenze di un cliente singolo (a meno che questo cliente non reputi tale l’urgenza da valutare di investirci risorse per accelerare il rilascio/risoluzione, in questo caso siamo nella casistica seguente)

- Personalizzazione se un cliente ha un’esigenza particolare si fa un preventivo ad hoc e si concorda una tempistica di rilascio che in quel caso Metadonors è tenuto a rispettare (anche in questo caso però si deve fare i conti con tutto il carico di lavoro di Metadonors: ergo, anche se si decide di pagare è raramente possibile fare quel lavoro in pochi giorni o poche settimane)..

Approvazione e rilascio features RA

Creazione nuove colonne: “Staging” dove la nuova features è nell’area test e viene notificato sul canale e Virgi deve testare entro 7 giorni, se nessuno testa viene “Rilasciato” e di seguito Virginia si occupa di comunicarlo internamente e esternamente in community “Archiviato/Comunicato” → passa qui solo dopo che è stato comunicato.