Wiki

Questa pagina è in sola lettura. Puoi visualizzare il sorgente, ma non puoi modificarlo. Contatta l'amministratore se pensi che ci sia un errore.
====== 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
      - sempre nel caso di file dati in pasto alla procedura è utile sapere se per caso il cliente non abbia apportato modifiche a mano sul file
      - 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, guidandolo o addirittura osservandolo con collegamento remoto (Teamviewer o simili) mentre esegue i vari passi fino al presentarsi dell'errore, o correggendolo 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.
        * il dipendente 1234567 dovrebbe essere estratto nell'unità organizzativa Filiale C, invece viene estratto in Filiale A
        * Nel flusso xyz i valori estratti per i conti 000001 e 000002 riportano questi valori ..., ma i valori dovrebbero essere questi altri ...
      - 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 nella maggior parte dei casi non conosciamo il contesto (della parte che riguarda zucchetti) e se certe cose vengono date per scontate, potrebbero facilmente sorgere incomprensioni.
  * La problematica va descritta nel ticket. Può essere utile fare copia/incolla della segnalazione originale, ma molto difficilmente questo sarà sufficiente, soprattutto per chi non ha dimestichezza con l'applicativo zucchetti e quando il problema sia particolarmente legato al mondo zucchetti, più che all'app Blutec.
  * Evitare di salvare il messaggio da Outlook e allegare il file msg, piuttosto è meglio fare copia e incolla e includere eventuali allegati.
  * 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 (azienda, periodo, eventuali altri filtri, eccetera).
  * 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>
Wiki

Strumenti Utente

Strumenti Sito

Strumenti Pagina
