Testing e revisioni di proprietà intellettuali: una guida soggettiva all’approccio

Avere la possibilità di revisionare un prodotto artistico o lavorativo per conto di terzi è doppiamente onore e onere, con molteplici ripercussioni

Può capitare, in virtù di un legame di amicizia, per stima reciproca o nell’ambito di un contesto lavorativo, di ritrovarsi a fare da revisore o tester per conto di terzi. L’atto consiste nel ricevere, in anteprima, un materiale di proprietà intellettuale altrui, e revisionarlo o testarlo in modo da garantirne una certa correttezza, oltre che una stabilità intrinseca tale da rendere il tutto idoneo alla pubblicazione finale. Può trattarsi di un programma informatico, di un libro, di un progetto, e può trattarsi di un’attività fatta a tempo perso oppure in un preciso contesto di lavoro, dove vi sono contratti e accordi siglati precedentemente volti a garantirne le modalità. E’ un modo molto vasto che però obbedisce a una serie di regole basilari, che qui affronteremo in parte.

La decisione, da parte di una persona o di un gruppo di persone, di scegliere proprio noi per revisionare il loro lavoro è di per sé un complimento, dato che implica un giudizio positivo sulla nostra persona e certifica una percezione di affidabilità. Analogamente, se siamo noi a dover scegliere un revisore o tester, il processo seguirebbe una direzione opposta ma senza variazioni nella sua impostazione di base. I concetti chiave di questi atti congiunti sono sempre gli stessi, e riguardano la ricerca, nella controparte, di affidabilità, precisione, puntualità, dedizione e correttezza comportamentale. Salvo in casi dove la scelta è forzata da dinamiche estranee al nostro controllo, nessuno penserebbe mai di affidare un incarico del genere a chi può sottrarre la proprietà intellettuale, manipolare il contenuto per aumentare il numero di errori e/o di fatto sabotarlo. La scelta dei revisori o tester è già, da sola, una componente non indifferente del lavoro svolto.

Prima di iniziare il lavoro, a meno che non sia l’ennesimo di una lunga serie di lavori analoghi, dove è per l’appunto possibile avere accesso alle modalità di svolgimento pregresse, è essenziale mettersi d’accordo sulla modalità di revisione. L’autore che fornisce il proprio materiale deve, a questo punto, dare precise indicazioni su come sarà articolato il lavoro, soprattutto se a essere coinvolte sono più persone, ciascuna delle quali si occupa delle stesse cose. L’autore, per esempio, può dare una certa autonomia ai revisori, permettendo a loro di operare sui singoli contenuti, correggerli e rimandarli in modo che vadano a sostituire le loro versioni pregresse; analogamente, l’autore può dare precisa disposizione di segnalare errori e possibili miglioramenti, mantenendo il controllo sulle modifiche effettuate, che rimangono un’esclusiva dell’autore stesso.

In questo campo, la differenza è data dalla natura del contenuto. Se smembrato in tante parti e di impostazione telematica, apposite piattaforme possono permettere ai singoli revisori di fare modifiche puntuali e visibili a tutti, sincronizzate in modo istantaneo e automatico al fine di evitare possibili copie in conflitto dei medesimi file, o di parti di essi. Anche a decisione presa è possibile autorizzare delle deroghe, ma bisogna prestare la massima attenzione al rischio di cancellazione accidentale di modifiche parallele, che di fatto hanno il potenziale di annullare ore e ore di lavoro.

Un insieme di parole che regolano i processi di revisione e testing. Fonte: einfochips.com

Fino a questo momento abbiamo approfondito alcune impostazioni tecniche, che pur essendo importanti, non sono il vero nocciolo della questione. Esistono fasi in cui a farla da padrone sono le componenti caratteriali, sia dell’autore che dei revisori o tester, ed è proprio qui che si gioca la partita più delicata. Partiamo col dire che, se il tutto avviene in un’ottica lavorativa, vi sono sovrastrutture volte a regolare i processi, e qualsiasi incomprensione può essere risolta in modo formale richiedendo l’intervento di uno o più superiori. In campi meno ufficiali, quali ad esempio la correzione, a titolo gratuito e in amicizia, di un programma o di un testo, è proprio in questa fase che possono emergere piccole diatribe legate più al carattere delle persone che non alla natura di quanto creato.

E’ essenziale che un revisore o tester mantenga una linea all’altezza della situazione e rispettosa nei confronti dell’autore dell’opera o del progetto. La filosofia è la seguente: “sto revisionando un lavoro altrui, e benché passi dalle mie mani, non è mio”. Questo principio si riflette sulle natura delle correzioni e delle proposte; esistono, purtroppo, esempi di accozzaglie di correzioni oggettive e proposte soggettive di miglioramento, presentate unitamente e dunque elevate allo stesso livello e con le stesse pretese. Non è così che funziona: l’errore, che può essere una sbavatura di testo in un progetto documentale, o un bug in un programma informatico, va riportato prontamente se mina la stabilità del prodotto finale, perché è un ostacolo oggettivo al funzionamento. Qui si ha di fatto l’obbligo di segnalare all’autore cosa c’è che non va, in modo che avvenga una correzione. Diverso paio di maniche quando il revisore vuole presentare un suggerimento, o ha un’osservazione – magari anche pertinente – sull’impostazione generale del progetto: in un ambito democratico si ha tutto il diritto di proporre un cambiamento, ma va separato dall’errore oggettivo ed è essenziale che si consideri l’idea che l’autore possa rifiutarlo proprio in virtù della soggettività che l’ha portato in auge. A un primo rifiuto si può rispondere, pacatamente, con un’ulteriore argomentazione del perché di un determinato suggerimento, giustificandolo e dando prove della sua fondatezza, ma è essenziale non insistere. Al secondo rifiuto, il caso è da considerarsi chiuso ed è meglio evitare di portarlo avanti per il semplice gusto di fare ostracismo al progetto. Il revisore è, per l’appunto, un revisore, ma non un coautore: arriva il momento in cui non è più il caso di varcare il confine e pretendere l’impossibile. Lasciamo il Rubicone lì dov’è, perché questa non è una guerra di conquista o una rivoluzione. Un revisore maturo lavora e porta a termine in modo dignitoso un progetto anche se quest’ultimo non è di suo gradimento: è, in poche parole, asettico rispetto al fattore della preferenza personale, e si concentra sulle correzioni di natura oggettiva.

Altro concetto fondamentale riguarda il modo in cui le revisioni vengono presentate all’autore. Indicare un errore è un atto che bisogna concretizzare col dovuto rispetto, tenendo bene a mente il bene superiore e comune che è quello della revisione del progetto; nell’indicare l’errore o bug di sistema, serve un modo di porsi formale e pacato, talvolta con qualche riferimento personale aggiuntivo sul come è stato riscontrato, al fine di rompere il ghiaccio (e.g., “avevo appena finito di cenare e, riprendendo, la revisione del testo, ho notato una è non accentata proprio qui…”). Evitare, se non espressamente richiesto, di far pesare o comunque mettere eccessiva enfasi sul numero di errori riscontrati, durante il processo di revisione, con frasi decisamente fuori luogo (e.g., “questo è addirittura il trentesimo bug di sistema legato a quella funzione, ti rendi conto?”). Come ultima cosa, ma solo perché appare per ultima in questa mini-rassegna e non perché risulta effettivamente essere meno importante, è imperativo cercare di evitare di fare fronte comune tra più revisori su determinate problematiche di natura non oggettiva, con frasi un po’ al limite della concezione di squadra sana e produttiva (e.g., “ma sei di coccio? Siamo in quattro a dirti che in quel modo il progetto non va”). A prima vista sembrano tutte cose scontate perché, in fondo, non si tratta di altro rispetto al consueto mantenimento di una certa netiquette, eppure gli inconvenienti di questa natura sono molto più comuni di quanto si creda.

Premuto questo tasto dolente, è il momento di toccarne un altro: la riservatezza dei contenuti condivisi, che ricordiamo essere ancora non idonei alla pubblicazione definitiva. Non deve esserci un contratto di lavoro a ricordarci che, se un progetto ci è stato fornito in anteprima, dobbiamo mantenere estremo riserbo sul suo contenuto. Alcuni contesti prevedono forti penali in caso di fuga di notizie, perché l’entità del materiale lo prevede e ingenti danni economici sono possibili, ma proviamo a essere corretti anche nei confronti del “piccolo” contenuto, quello fornitoci in amicizia o comunque in un contesto informale. Non andiamo a riferire a terzi gli errori fatti dall’autore, se siamo revisori, e non riferiamo in mondovisione dell’inefficienza e del comportamento dei nostri revisori, se siamo autori. Insomma, anche qui è sufficiente applicare un po’ di giusta riservatezza, così come di fatto avviene in molti campi della nostra vita privata.

Un cortese invito a fare della sana revisione, in un contesto produttivo e civile. Fonte: bssc.edu.au.

Questa digressione soggettiva sulla tematica delle revisioni e del testing finisce con un ultimo, grande tasto dolente: la tempistica di consegna delle correzioni. In questo caso la problematica ha una doppia sfaccettatura, in quanto potrebbe essere il frutto di un problema accessorio, che è semplice e diretto: sottostimare l’entità del lavoro di revisione e dunque ritardare la consegna per sopravvenute incompatibilità di tempo con impegni di natura personale. Questo aspetto nascosto e potenzialmente pericoloso, dato che rischia di ritardare il completamento generale di lavori che hanno richiesto settimane, mesi o anni per essere completati, rende il tutto più triste dato che il ritardo più avvertito dall’autore non è quello delle varie vicissitudini della fase principale e produttiva, ma quello che si sperimenta proprio alla fine, quando si è agli sgoccioli e si sta per consegnare (o pubblicare) il tutto. Per rendere l’idea, immaginate di fare un’intera scalinata, tra l’altro con una certa fatica, e di realizzare che proprio l’ultimo scalino risulta più difficile da superare perché la vostra scarpa è rimasta bloccata all’altezza di uno scalino precedente, dove qualcuno ha messo della colla. E’ sicuramente più fastidioso e deludente rispetto al trovare quella stessa colla su uno dei primissimi scalini. Ecco, il senso è proprio questo, e riguarda la percezione psicologica del ritardo dell’ultimo momento, più scoraggiante del ritardo che si sperimenta in itinere.

Certo, è opportuno riconoscere in ogni revisore o tester anche la persona che c’è dietro: un imprevisto nella vita, positivo o negativo che sia, può sempre portare dei ritardi ed è corretto sopperire a essi con un sostituto o con maggiore forza lavoro. E’ un po’ meno accettabile, tuttavia, quando il ritardo è frutto dell’improvvisazione, dato che essere un revisore non significa soltanto “leggere” qualcosa e dare un’impressione generale, ma significa analizzare rigo per rigo, codice per codice e particolare per particolare di un lavoro altrui, ossia fare un’opera minuziosa e lenta che deve rendere il prodotto finale quasi perfetto e a prova d’errore. Se siete autori in cerca di revisione, guardatevi bene, pertanto, da revisori improvvisati e inaffidabili, e se siete revisori, cercate ambienti positivi in cui si può operare serenamente.

Francesco D’Amico

Informazioni su lightbluemobius

The Lightblue Ribbon coordinator and founder.
Questa voce è stata pubblicata in (TLR) Francesco D'Amico, Business ed Economia, Cultura, Arte e Letteratura e contrassegnata con , , , . Contrassegna il permalink.

Rispondi

Inserisci i tuoi dati qui sotto o clicca su un'icona per effettuare l'accesso:

Logo di WordPress.com

Stai commentando usando il tuo account WordPress.com. Chiudi sessione /  Modifica )

Google photo

Stai commentando usando il tuo account Google. Chiudi sessione /  Modifica )

Foto Twitter

Stai commentando usando il tuo account Twitter. Chiudi sessione /  Modifica )

Foto di Facebook

Stai commentando usando il tuo account Facebook. Chiudi sessione /  Modifica )

Connessione a %s...

Questo sito utilizza Akismet per ridurre lo spam. Scopri come vengono elaborati i dati derivati dai commenti.