Requisiti per apertura ticket per un app/software/utility Blutec

Verifiche Preliminari

Più sono complete le informazioni che puoi fornire già all'apertura del ticket, meno rimpalli ci saranno prima che possa effettivamente partire la lavorazione del ticket.

Dobbiamo poter riprodurre il problema, quindi bisogna sapere esattamente quali sono i passaggi che portano al verificarsi del problema. Per esempio bisogna:

sapere con quali parametri di lancio viene eseguita la procedura

se alla procedura vengono dati in pasto dei file da elaborare, è fondamentale averne una copia

Occasionalmente può capitare che quando noi eseguiamo gli stessi passi fatti dal cliente, il problema non si presenti. In questi casi potrebbe essere utile fare un prova col cliente, guidarlo o addirittura osservare con collegamento remoto (Teamviewer o simili) il cliente stesso che esegue i vari passi fino al presentarsi errore, o correggerlo se si nota che sta facendo un utilizzo improprio dell'app (e quindi il problema è nell'utilizzatore e non nel nostro software).

oppure può capitare che il problema riguarda l'utenza specifica usata per lanciare la procedura. In questo caso serve sapere quale sia l'utenza usata.

è necessario sapere che risultato bisogna ottenere

è importante sapere qual è il risultato che il cliente ottiene (presumibilmente errato) e quale risultato invece si aspetterebbe di ottenere. In ogni caso è molto importante fornire esempi concreti. Non solo quando l'anomalia riguarda pochi casi, per esempio una o due matricole, ma anche quando riguarda tutti i casi (è fondamentale avere esempi a campione) per esempio:

Per il tal dipendente dovrei vedere ferie sul giorno xy, ma non su quel giorno non vedo nessun giustificativo.

Non ci sono i tal dati nella tal maschera, ma invece dovrei trovarmi questo e quell'altro dato.

<cercare esempi sensati nei ticket>

Nel caso il problema sia che non viene prodotto alcun risultato, è utile capire cosa succede in fase di lancio, per esempio:

si blocca in stato di caricamento perpetuo

viene mostrato un messaggio di errore (se sì, che messaggio)

Una volta capito come poter riprodurre il problema è opportuno fare qualche verifica preliminare direttamente in applicativo Zucchetti, per provare ad escludere che si tratti di problemi sui dati, perchè di solito è molto più veloce individuarli da applicativo Zucchetti rispetto a cercare di rifare con query quello che già fa l'applicativo. Soprattutto in quella fase in cui ancora non si sa se il problema sia sulla query dell'app Blutec o sui dati contenuti nell'applicativo Zucchetti.

Potrebbe capitare che quello che sembra un problema della procedura Blutec magari è un problema che si presenta allo stesso modo anche sull'applicativo Zucchetti e magari il cliente non ha nemmeno provato a verificare se succede anche in Zucchetti.

Come precisazione riguardo al punto 3, si deve considerare che chi lavora sull'applicativo Zucchetti ha molta più dimestichezza con la natura dei dati, ne conosce il contesto e la logica di come vadano interpretati, a differenza dello sviluppatore che non mette mai mano all'applicativo Zucchetti e che quindi potrebbe non conoscere quasi per niente il contesto e interpreta quegli stessi dati come meri valori contenuti nelle tabelle del database, concentrandosi sulle relazioni tra i “contenitori” di quei dati invece che sulla logica di come vengono prodotti. La conseguenza di questo è che un'anomalia sui dati o un'anomala in una configurazione applicativa, può saltare all'occhio molto più facilmente all'esperto applicativo che non allo sviluppatore che fa verifiche tecniche sul software Blutec.

Nota bene

Qualora chi riceva la segnalazione non è in grado di fare le verifiche indicate sopra, aprire un ticket in sviluppo semplicemente per passare la problematica a qualcun altro non è aiuta a risolvere la segnalazione. Quando la segnalazione riguarda un'app Blutec che in qualche modo è legata al mondo zucchetti è indispensabile che chi apre la segnalazione verso sviluppo sia in grado di collaborare, per la parte Zucchetti, alla risoluzione del problema secondo le modalità indicate sopra. Quindi è fondamentale che prima di aprire il ticket, la gestione della segnalazione venga delegata a qualcuno che è in grado di fornire effettivo supporto allo sviluppo.

Indicazioni pratiche per scrivere il ticket

Un ticket ideale include le seguenti informazioni:

Oggetto del ticket scritto nel seguente formato:

Impianto/Cliente - Prodotto - Descrizione sintetica del Problema

Esempi:

Sinergia - Utility Appello completo - Non estrae ferie per alcuni dipendenti

Fed TN - Report contabilità fittizia - Stampa vuota

SCM - Utility monitor assenze - Errore in fase di estrazione

Fed ER - Giustificativi da corsi - Impossibile cancellare giustificativi inseriti

Blutec - BData - Errore in copia attività

Messaggio: descrizione del problema, includendo eventuali dettagli aggiuntivi ottenuti dalle prove fatte sull'app Blutec e dalle verifiche sui dati fatte su Zucchetti, con eventuale copia/incolla della segnalazione originale (un po' superflua se la descrizione spiega bene il problema)

Nel descrivere il problema tieni presente che in sviluppo non conosciamo il contesto e se certe cose vengono date per scontate, potrebbero facilmente sorgere incomprensioni.

Evitare di salvare il messaggio da Outlook e allegare il file msg. La segnalazione va descritta/trascritta nel ticket.

Se la segnalazione è stata fatta tramite bludesk, per aprire il ticket usare la funzione di creazione ticket figlio.

Inserire il nome preciso del prodotto/app/utility/procedura/software Blutec. Se il cliente la chiama in modo diverso comunque la richiesta deve arrivare col nome effettivo (per esempio il nome della voce di menu presente nelle utility. A voler andare di fino, potrebbe essere più pratico avere uno screenshot con punto di menu usato per l'apertura dell'app.).

Parametri di lancio utilizzati per riprodurre il problema.

Utente cliente che lancia la procedura.

Uno o più esempi verificabili di dati estratti incorrettamente e indicazione di come invece tali dati avrebbero dovuto essere estratti.

Una volta aperto il ticket, eventuali informazioni aggiuntive scoperte da sé o ricevute in seguito dal cliente vanno fornite sempre attraverso lo strumento del ticket, non via Teams o email. Questo per evitare di frammentare le informazioni in tanti posti diversi.

In un ticket deve essere contenuta una singola segnalazione. Se viene segnalato dal cliente un ulteriore nuovo problema diverso dal quello originale, va aperto un ticket separato, dedicato al nuovo problema, anche se la tematica fosse la stessa.

Nell'esporre la problematica ed eventuale suggerimento su come poterla risolvere è importante cercare di contestualizzare l'esigenza e l'obiettivo che si vuole raggiungere, in modo che possiamo capire la regola generale e risolvere il problema alla radice, evitando il rischio di sistemare il problema solo per uno o più casi particolari (con cablature o regole semi-cablate).

Feedback É importante ricevere riscontri alle risposte che forniamo, soprattutto quando la problematica segnalata è stata risolta. Bisogna che ad un certo punto venga dato un feedback per chiudere i ticket, a volte accade che alcuni ticket vengano chiusi arbitrariamente da noi perchè semplicemente perchè sono passati mesi dall'ultima comunicazione e a quel punto diamo per scontato che non avendo più avuto risposte, la problematica debba essere stata risolta.

Note:

L'indicazione del nome impianto/cliente serve perchè non è scontato che indicando l'azienda noi sappiamo su che impianto si trovi.

Prodotti

Utility <nome>

Report <nome>

Procedura Pianificata <nome>

Zucchetti <nome applicativo>

<Altro Software Blutec>

Richiesta di integrazione e/o implementazione nuova funzionalità

Cercare di far passare che quando devono chiedere di implementare una certa questione di paghe, di risorse, presenze o quel che è, devono mettersi nei panni di qualcuno che non ne sa niente di quelle tematiche, quindi necessitiamo di spiegazioni ELI5. Tema da espandere e approfondire meglio.