Normalmente, quando chiedi alla tua agenzia di occuparti di qualcosa, ti risponderanno di aprire un “ticket”.
Durante la gestione del ticket ci saranno alcune fasi dove il tuo contributo sarà fondamentale per raggiungere la soluzione più appropriata nel minor tempo possibile.
In particolare, il Triage e la UAT, e subito dopo il Deploy.
Le fasi
Triage
Dopo aver aperto un ticket con la tua agenzia, il project manager eseguirà il cosiddetto “triage”.
In pratica, testerà il ticket per confermare che il problema:
- Non sia un errore dell’utente.
- Sia ripetibile sia in produzione che negli ambienti di staging e sviluppo (se non sai cosa sono, leggi questo articolo). Questo potrebbe significare dover ricreare negli ambienti di staging o sviluppo le stesse condizioni osservate in produzione.
- Sia descritto chiaramente e con i dettagli necessari.
- Sia un problema nuovo e non un errore già noto, magari in via di risoluzione.
Oltre a questo, il project manager suggerirà una priorità per il ticket. Ad esempio:
- Se è impossibile effettuare il checkout per tutti gli utenti, l’urgenza sarà massima.
- Se c’è un problema funzionale minore, come ad esempio il malfunzionamento del contatore dello stock, l’urgenza sarà media.
- Se c’è un problema puramente estetico, l’urgenza sarà bassa.
Un’altra distinzione fondamentale è tra:
- Bug, ossia errori che interrompono o compromettono funzionalità già esistenti.
- Richieste di nuove funzionalità, ovvero miglioramenti o implementazioni che non erano presenti prima.
Durante il triage, il project manager sarà in contatto con te per assicurarsi che tutto corrisponda alle tue aspettative. Se fornirai risposte celeri e accurate, faciliterai questa fase.
Un triage ben eseguito garantisce che le risorse vengano allocate ai problemi più urgenti e rilevanti.
In questa fase, potrebbe anche venir stimata la portata della richiesta. Il tuoi project manager, in collaborazione con lo sviluppatore, potrà darti una stima di massima del tempo richiesto per risolvere il problema.
Sviluppo
Una volta identificato il problema, e ricevuto il via livera per l’avvio dei lavori, il project manager passerà il ticket a uno sviluppatore.
Lo sviluppatore potrebbe avere delle domande alle quali, generalmente, il project manager che ti segue e conosce il progetto saprà rispondere. Ad esempio: dove si trovano le credenziali X, perché è stata scelta la soluzione Y, e così via.
I lavori verranno effettuati sul sito di sviluppo o di staging, mai direttamente sul sito in produzione.
In questa fase, la comunicazione avviene principalmente all’interno del team della tua agenzia. Tuttavia, è possibile che il tuo input venga richiesto per chiarimenti o conferme specifiche.
QA
Il Quality Assurance (QA), o controllo qualità, inizia quando lo sviluppatore conferma che il problema è stato risolto.
In questa fase, un tester (o il project manager) dell’agenzia verificherà la soluzione seguendo le indicazioni fornite nel ticket originale.
Un QA ben fatto prevede di testare il sito sia in modalità desktop che mobile, utilizzando diversi browser. Inoltre, include test creativi per verificare che la soluzione non possa essere “rotta”. Ovviamente, tutti i test devono rimanere nell’ambito del ticket originale.
Tuttavia, può capitare che durante questa fase vengano scoperti nuovi problemi non documentati. In tal caso ci sarà una discussione per stabilire se il problema sia stato causato dalla nuova soluzione o se esistesse già (è possibile verificarlo controllando il sito in produzione). Se il problema dovesse rivelarsi indipendente dal lavoro corrente, il tester aprirà un nuovo ticket e lo passerà al project manager per il triage.
In ogni caso, finché il tester non sarà soddisfatto dei risultati, rimanderà il ticket allo sviluppatore, spiegando i problemi riscontrati e richiedendo ulteriori interventi.
UAT
Quando il tester dell’agenzia è soddisfatto, il ticket viene passato nuovamente a te, il cliente dell’agenzia, per un ulteriore test: il User Acceptance Testing (UAT).
Durante questo test, dovrai confermare se, secondo te, la soluzione risolve il problema descritto nel ticket e se sei soddisfatto di procedere con l’ultima fase.
Questa fase è spesso sottovalutata, ma è cruciale: il cliente può osservare il sito con una prospettiva diversa rispetto a quella dell’agenzia, identificando eventuali casi particolari che la soluzione non copre e che potrebbero essere sfuggiti durante il QA.
Anche qui, il tuo contributo fa la differenza.
Deploy
Una volta che il lavoro in ambiente di sviluppo o staging è stato accettato, l’agenzia procederà a trasferire quel lavoro sul sito in produzione.
Questa operazione, chiamata Deploy, può richiedere da pochi minuti a diverse ore e potrebbe necessitare di mettere il sito in modalità manutenzione.
A seconda della soluzione implementata, dopo il deploy potrebbe essere necessario configurare impostazioni di moduli, inserire credenziali, o effettuare altre modifiche specifiche.
È molto utile che il cliente rimanga disponibile durante il deploy, per affrontare eventuali imprevisti o per completare configurazioni finali.
Una buona pratica è evitare di fare deploy (o modifiche significative) il venerdì. Questo perché, se si verificassero problemi dopo il deploy, potrebbero essere rilevati e affrontati solo il lunedì successivo.
Un’altra buona pratica è testare il sito in produzione dopo ogni deploy, per verificare che tutto funzioni correttamente e che non ci siano effetti collaterali imprevisti.
Data la facilità con cui potrai piazzare, cancellare, e risarcire ordini di prova, sarà utilissimo averti in prima linea per questo tipo di test.