4° capitolo del Manuale Tracce
Il Checker ha un ruolo fondamentale nella stesura di una traccia. Deve controllare e confermare che questa sia corretta e che raggiunga, rispettando tutte le regole, l’obiettivo dello scopo.
Spiegando in funzionamento di questo ruolo cogliamo l’occasione per simulare un processo di creazione di una traccia.
Il Checker riceve dall’Autore una traccia da controllare. La prima cosa che deve fare è creare una copia della traccia e lavorare su quella. La copia originale dovrà essere inserita in una sottocartella apposita (“old”), in seguito vedremo le modalità di archiviazione dei check.
Un primo controllo riguarda i contenuti della traccia, sia grammaticali che semantici, e dell’insieme di riferimenti/mail/allegati. Durante questo controllo è importante controllare anche la chiarezza del testo e la correttezza della scrittura e utilizzazione dei riferimenti.
Ci sono tre aspetti cruciali nel lavoro di checking: l’utilizzo della modalità revisione, dell’evidenziatore e dei commenti.
- Innanzitutto, tutte le attività di checking vanno svolte in modalità revisione. Questa si attiva tramite il seguente percorso: Revisione → Rilevamento Modifiche → Revisioni. Inserendo la modalità revisione qualsiasi modifica deve essere accettata attivamente da qualcuno per renderla effettiva. Così facendo nella creazione dei documenti di check si potrà controllare come erano state scritte le cose che il Checker ha deciso di modificare.
- L’evidenziatore deve essere utilizzato per sottolineare tutto ciò che è corretto nella traccia. Quando si modifica qualcosa non si sottolinea, così facendo l’autore saprà riconoscere più facilmente ciò che va modificato. Quando non si è convinti di un passaggio lo si può lasciare non evidenziato e usare un commento.
- I commenti servono a comunicare dubbi o informazioni aggiuntive con l’autore, tramite i commenti si crea un’interazione diretta Autore-Checker con l’obiettivo di comprendere o migliorare un determinato passaggio della traccia.
Una volta concluso il lavoro, il Checker potrà inviare all’autore la traccia checkata che sarà denominata ““NomeTraccia” – Check”
A questo punto l’autore prima di svolgere il lavoro di “Backchecking” inserirà il file con dicitura “Check” nell’apposita sottocartella e ne creerà una nuova copia sulla quale lavorerà (vedremo in seguito più nel dettaglio questa attività). Il Backchecking non è altro che l’attività di accettazione o rifiuto delle modifiche fatte. In caso, potrà creare nuove versioni dello svolgimento, integrando o eliminando porzioni di traccia.
È importante sottolineare che il checker non si pone come correttore indiscusso della traccia, ma è presente un dialogo tra autore e checker: le modifiche possono non essere accettate, e si discuterà riguardo i diversi pareri attraverso i commenti nel file (o di persona).
Se, ipoteticamente, l’autore dovesse accettare tutte le modifiche il processo terminerà e la traccia verrà salvata senza dicitura aggiuntiva. Il gergo per una traccia chiusa è “Check ok”.
In caso contrario continuerà lo scambio nel seguente ordine:
Backcheck inviato dall’autore à Check2 inviato dal Checker à Backcheck 2 inviato dall’autore e così via.
L’ultimo step è la chiusura della traccia. Questa si svolge eliminando tutte le evidenziazioni, accettando tutte le revisioni rimaste ed eliminando i commenti ancora aperti.
La traccia deve essere quanto più pulita possibile: commenti vecchi o superato riguardanti contenuto della traccia vanno eliminati e non si portano dietro nel “rimbalzo” autore – checker.
Se, anche a distanza di molto tempo, si decide di cambiare scopo alla traccia, si crea la Rev.B. La revisione B funziona esattamente come una traccia normale, con l’unica differenza che la revisione B può essere fatta da qualsiasi persona, e non necessariamente dall’autore originario, e che bisognerà integrare le modifiche nel file sempre in modalità revisione. Alla prima revisione si aggiungono le nuove argomentazioni, i nuovi riferimenti e tutto ciò che seve per raggiungere l’obiettivo presente nello scopo.
L’unica accortezza sarà quella di creare una cartella adibita a tutte le versioni della Revisione A in modo da evitare alcun tipo di confusione.
In figura riportiamo l’esempio di ciò che è solitamente presente nella cartella “old”, vi portiamo un esempio in cui ci sono stati molti scambi tra Autore e Checker:
Figura 1: Esempio check
Dopo il Backcheck 4 il ciclo di controllo nel nostro esempio si conclude, poiché si è arrivati a una versione soddisfacente della traccia. La cartella si presenterà come mostrato in Figura 2.
Mostriamo per completezza anche come si presenta una cartella nel caso siano presenti revisioni della traccia.
Nelle cartelle Rev.A e Rev.B saranno presenti viste analoghe alla Figura 2 in cui ogni cartella avrà all’interno la traccia finale e la cartella old.
Figura 3 – Vista cartella traccia
Nel perseguire gli obiettivi di:
- minimizzazione dell’effort del Risk Team nella prima formazione di tirocinanti/fornitori/collaboratori;
- massimizzazione dell’utilità associata al sito “Valore Rischio e Sistemi”
si è deciso di creare una versione alleggerita del Manuale Tracce già esistente.
L’obiettivo è di caricare l’intero manuale suddiviso in articoli e riscritto in maniera che sia fruibile comodamente e di non complicata comprensione.
Sono previsti 4 articoli che saranno dedicati ad una specifica parte di una traccia “standard”.
Questi articoli sono: