R&D con pragmatismo

R&D ?

Quando si parla di R&D (Research And Development) a me vengono in mente laboratori ben attrezzati in cui tecnici esperti svolgono il loro importante lavoro in un contesto sereno e senza vincoli cogenti di tempo e budget.
Ho il sospetto però tale visione spaventi molto i manager e contribuisca a rendere R&D un tabù.
Chissà, forse nell’immaginario collettivo questo acronimo richiama alla mente la sezione Q: quella che costruisce bizzarri congegni per James Bond.

L’idea mai espressa a parole, ma che emerge nei fatti, è che l’azienda non può permettersi di fare R&D.
Forse è l’effetto indotto da una cronica mancanza di lungimiranza che ci impedisce di riconoscere che in realtà l’innovazione è vitale.
Piuttosto dovremmo acquisire la consapevolezza che un’azienda non può permettersi di non fare R&D.

R&D: atto eroico

La difficoltà di riconoscere all’R&D l’importanza che ha, non significa che le aziende non innovino.
Le aziende innovano in modo poco organico e poco consapevole quindi poco efficiente.

Fare R&D in fondo significa dare fiducia a qualcuno e finanziarlo per raggiungere uno scopo, si tratta di agire con mentalità imprenditoriale e avere una certa attitudine al rischio.
Ciò a ben vedere avviene tutti i giorni in un’azienda.
Ogni progetto nel suo piccolo è una sfida imprenditoriale.
La differenza però è che il progetto è commissionato e finanziato dal cliente pertanto è per sua natura sensato.
Nel caso di R&D invece è necessario spiegare, argomentare, sostenere.
Esporsi per un’idea che solo potenzialmente avrà un ricavo nel futuro: ciò equivale ad un atto eroico da cui molti tendono a sottrarsi.
In certi ambienti stagnanti fare innovazione, corrisponde a creare delle increspature sulla superficie immobile dello status quo (o meglio “stagnus quo”) che si spandono in cerchi concentrici, disturbando i sonni tranquilli di chi vive subito sotto la superficie dell’acqua.   

In questo contesto si presentano situazioni paradossali.
Per esempio la richiesta alla “007” di un “orologio con laser incorporato” sarà considerata, perfettamente plausibile se viene dal cliente, invece sarà classificata come stramberia inutile e costosa, se proposta sotto forma di prototipo da un tecnico interno.
Non si ammazzano così anche le idee ?

Da R&D a R&A

In natura capita spesso che certi sistemi trovino da soli un equilibrio e credo ciò accada anche nelle aziende.
Se non ci sono ruoli precisi per la gestione di R&D cosa succede ?  Succede che coloro che sono impegnati operativamente nel core business dell’azienda nel loro lavoro quotidiano vivono i seguenti fenomeni:

  • individuano colli di bottiglia
  • intravedono possibili ottimizzazioni
  • raccolgono spunti dai clienti
  • rilevano carenza nell’usabilità di ciò che si produce
  • intuiscono ambiti di evoluzione del prodotto

Ciò succede perché, più si vola bassi, alla quota dell’utilizzatore finale e più si ha la possibilità di raccogliere dal campo feedback utili all’innovazione.
Il problema spesso è dare seguito a questi spunti trovando un budget che copra le attività di realizzazione.
A questo punto servono altri elementi:uno sponsor, la comunicazione efficace, del coraggio

L’assenza di una funzione aziendale che si occupa di R&D e che non sta a contatto con il campo è un bene perché spesso queste strutture si rivelano nel tempo dei mostri che si preoccupano di sopravvivere a se stessi piuttosto che produrre risultati.
Le buone idee in effetti sono ovunque all’interno di una organizzazione, pertanto è preferibile che arrivino da una platea più ampia possibile per poi essere canalizzate, censite e vagliate.

Per la mia esperienza raramente un’azienda può fare R&D, più realisticamente ciò che si può fare è Ricerca Applicata.

Nell’ambito di progetti finalizzati ad un cliente, è possibile individuare soluzioni che possano essere replicate in altri ambiti facendo economia di scala.

Un contesto favorevole 

La Ricerca Applicata chiaramente è una sfida più complessa della R&D pura.
Sono richieste particolari doti di equilibrio per scegliere il giusto compromesso tra astrazione e pragmatismo.
Le soluzioni ideate infatti debbono essere applicabili nel contesto richiesto, ma risultare riutilizzabili in altri ambiti.
Per fare ciò, rispettando i vincoli progettuali è necessario avere ottimi progettisti.
Creare un contesto favorevole che presenti delle “anse” in termini di tempo/budget che consentano un approccio ai problemi di più largo respiro.
C’ è bisogno di persone competenti creative e sensibili per individuare aree sui cui applicare tale strategia.
E’ necessario creare momenti di confronto per fare emergere le necessità applicative e i problemi ricorrenti che la comunità di sviluppatori/funzionali incontra.
E’ importante divulgare l’esito dei questa attività in modo tale che la comunità ne sia informata affinché nel disegno delle nuove soluzioni i prodotti della ricerca applicata possano essere usati.
Promuovere la contaminazione tra aree aziendali.
Sostenere e promuovere la formazione continua.
Abbandonare la mentalità del fallimento e del colpevole per abbracciare l’empirismo fatto di piccoli esperimenti utili a scartare ipotesi errate.
Promuovere nei fatti e nella sostanza sentimenti di cooperazione e fiducia a tutti i livelli affinche’ le persone si espongano senza timore di fallire.

Non dovremmo avere bisogno di eroi

Durante il mio percorso lavorativo ho avuto il piacere di conoscere persone molto speciali che ricoprivano in azienda il ruolo dell’eroe.

Si tratta di persone brillanti, competenti e con un alto senso del dovere che, con la loro esperienza, anticipano i problemi, se ne fanno carico e li risolvono compiendo sforzi eccezionali. Per queste persone la parola “impossibile” non è mai stata scritta e fallire non è un’opzione contemplata. Lavorare con loro può essere difficile, ma anche entusiasmante. Ciò che a mio avviso rende veramente grandi queste persone è che portano il fardello sulle loro spalle e raggiungono la vetta con le proprie forze senza clamore. L’energia sprigionata da queste persone è percepibile nella passione che mettono nel fare il loro lavoro e ciò a mio avviso li rende dei leader naturali perchè sanno essere trascinanti.

Queste persone sono gemme preziose per le organizzazioni e per i team in cui operano.
Spesso però i valori che li caratterizzano: franchezza, trasparenza e coraggio confliggono con le logiche delle organizzazioni dove i manager sono impegnati a mantenere lo status quo e ai fatti antepongono le schermaglie politiche e verbali.
Ciò paradossalmente rende gli eroi al contempo utili, ma spinosi. A causa della loro abilita’ sul campo e della loro scarsa diplomazia, spesso queste persone sono relegate in ruoli intermedi in cui sono continuamente impegnati a spegnere incendi e sono esclusi dalle riunioni in cui vengono prese decisioni strategiche. Questa dinamica spesso priva l’organizzazione del prezioso punto di vista pragmatico di chi il business lo fa concretamente funzionare.

La presenza conclamata di eroi aziendali e la loro mancata valorizzazione ha ulteriori effetti collaterali indesiderati che spesso vengono ignorati.
Il punto è che se fare l’eroe è pericoloso faticoso, ma non offre alcun vantaggio materiale, si tratta di un modello non vincente che gli altri non seguiranno.
Chi non è un eroe e non ne subisce il fascino, non ha alcun buon motivo per emulare quel comportamento e farà il proprio dovere al minimo sindacale adottando la nota strategia “del fil de gas”. D’altro canto un eroe è tale a causa della sua natura e non per scelta, per cui se la natura degli individui è insopprimibile e il suo modo di essere non e’ premiante nel contesto in cui si trova, alla lunga si troverà costretto a fare l’eroe altrove.

In sintesi credo che un’organizzazione sana dovrebbe cercare di elevare tutti a livello di eroe, ma contemporaneamente dovrebbe strutturarsi per non averne bisogno mai, se non in casi veramente eccezionali.

Il principio di Peter

Il lavoro è un sistema per mantenere e possibilmente elevare il proprio benessere pertanto le persone, in modo del tutto naturale ambiscono ad una crescita economica.
Nel momento in cui i percorsi di crescita sono standardizzati, le persone, indipendentemente dalle proprie attitudini, cercheranno di percorrerli.

Nell’organizzazione colui che che sarà ritenuto adatto (non necessariamente meritevole) risalirà la scala gerarchica di gradino in gradino, ma si fermerà nel ruolo che gli è meno congeniale. Non essendo prevista una retrocessione, rimarrà bloccato in una situazione in cui esprime la propria massima incompetenza.

Il soggetto che incappa in questo fenomeno si godrà i benefici della posizione raggiunta, ma soffrirà sentendosi inadeguato. A questo punto, quasi avesse vinto immeritatamente il primo premio alla lotteria, comincerà a temere per la propria poltrona. In fondo quanto tempo potrà passare prima che qualcuno si accorga della sua incompetenza ? Questo pensiero lo indurrà ad arroccarsi sulla propria posizione alzando gli scudi per difenderla. Mantenere lo status quo diventerà il suo unico obiettivo. Rifuggire le innovazione sembrerà un buona strategia. Circondarsi di persone servili aumenterà le probabilità di far durare il più a lungo possibile questo piccolo regno ottuso.

L’idea di indurre una persona a ricoprire un ruolo che non le si confà è dannosa per la persona e per l’organizzazione.
Chi si trova in questa situazione e non è disposto a venire a patti con se stesso, pur di sfuggire alla frustrazione potrebbe preferire cercare un’alternativa.

Per evitare tutto ciò, una possibile soluzione sarebbe sganciare la retribuzione dal ruolo, creando dei percorsi di crescita legati alla competenza e alla autorevolezza. Il problema è che la meritocrazia presuppone la capacità di valutare realmente il valore di una persona: un’impresa dannatamente complicata. Così nel mondo reale si preferisce ricorrere alla semplici code di carriera. Se una persona brillante ed ambiziosa entra a far parte di un gruppo consolidato, dovrà necessariamente attendere il suo turno per muovere un passo in avanti, anche se le sue qualità sono evidentemente sopra la media. Il rischio serio in questi casi è di perdere una persona molto capace per ridicole consuetudini. La realtà è che siamo in presenza di un sistema NON meritocratico, in cui è premiante l’anzianità di servizio.
Un sistema del genere tende a scoraggiare ed escludere dalle organizzazioni menti brillanti ed ambiziose che sarebbero preziose per affrontare le sfide che il mercato presenta.

Riferimento: https://it.wikipedia.org/wiki/Principio_di_Peter

Geometra del software

Foto di Juliane Thomaz da Pixabay

Qualche tempo fa un mio ex-collega burlone mi diede del “Geometra del software”.


In quel periodo ero impegnato a lavorare sull’architettura del sistema e non perdevo occasione per condividere con i colleghi la mia visione per avere dei feedback utili.
Spesso però le mie lunghe spiegazioni venivano catalogate come farneticazioni assurde: si capiva dall’espressione perplessa che si formava sul viso dell’interlocutore di turno.
Perciò, non di rado, mi sentivo come un predicatore errante. Vagavo senza una meta precisa, cercando di evangelizzare il prossimo, ma con scarso successo.

In quella occasione specifica, tutta la perplessità ingenerata nel mio collega, fu sintetizzata ed espressa con l’epiteto di “Geometra del software”.
Il suo era un modo bonario e divertente per ricondurre ad un livello più terra terra le mie ciancie sull’architettura di sistema.
Della serie: “Ferro, vola basso”.
Trovai la battuta brillante ed acuta e fu spunto per interessanti riflessioni.


La figura del geometra è positiva e concreta.
E’ meno etereo dell’Architetto, più vicino ai muratori alla calce ai mattoni, và sul cantiere.
Sarò romantico, ma mi piace pensare che all’occorrenza sia in grado anche di fare il cemento.

Circa un anno fa feci un colloquio e raccontai del mio ruolo nel delineare l’architettura di sistema. L’intervistatore, persona di estrazione tecnica, volle approfondire e disse: “Si ok, ma qui bisogna anche sporcarsi le mani…”
Capii di essere di fronte ad una persona pragmatica e di essere anche sulla stessa lunghezza d’onda. Risposi sorridendo compiaciuto di questa domanda, che le soluzioni architetturali che avevamo pensato e progettato le avevo realizzate in prima persona e le facevo funzionare tutti i santi giorni insieme ai miei colleghi.

Credo di aver letto su un libro di Taleb che gli antichi Romani collaudavano i nuovi ponti facendo posizionare sotto i progettisti e le loro famiglie.
Era un sistema cinico, ma efficace, per rendere il progettista pienamente consapevole dell’importanza del suo lavoro e direttamente responsabile del buon esito dell’opera.

Ecco, ancora oggi mi sporco le mani e se faccio una scelta o costruisco del software lo faccio con la piena consapevolezza che quanto deciso o realizzato dovrà funzionare nel tempo e che, se non funzionerà, io e i colleghi dovremo farlo funzionare in qualche modo.
Da ciò discende che quanto più, ciò che realizziamo è eccellente, tanto meno problemi e grattacapi ci darà nel tempo.

Questa filiera corta tra chi fa le scelte e fa le cose e chi se ne assume la responsabilità crea un circolo virtuoso che consente di minimizzare il debito tecnico o quanto meno di gestirlo in modo consapevole.

Per cui in definitiva sono orgoglioso di essere un “Geometra del software”.

La burocrazia che non ci serve

Esperienza sul campo e maggiore anzianità Vs Gerarchia 
La burocrazia quella stupida ed ottusa che affossa le proposte sensate che arrivano dal basso.
Quando avere condiviso un’esperienza sul campo rende le gerarchie inutili.
Autorevolezza Vs Autorità
Il coraggio delle proprie idee sapendo già che esprimerle non è la mossa più azzeccata.
La focalizzazione sulla mission .
I migliori strumenti per svolgere il proprio lavoro.
L’esperienza Vs le procedure standard.  

“Spatia Devinco Disiuncta Coniungo”

Questo è il motto in latino dell’Arma della Trasmissioni dell’Esercito Italiano in cui ho frequentato il 156° A.U.C.  .
Il senso della frase è chiaro: vinco lo spazio e unisco ciò che è separato.
Una bellissima frase che sintetizza la finalità dell’arma, ma che racchiude un significato più profondo.
Trovo infatti che questa frase esprima bene il concetto di team building come lo intendo io: quello sano, quello bello che ho potuto sperimentare in vari contesti lavorativi.
Le persone che catalizzano le energie migliori del team ed agiscono da collante fanno proprio questo: vincono le naturali distanze tra le persone e le avvicinano.
Uniscono i punti che le accomunano e creano quelle relazioni positive che sono alla base della collaborazione. 

Esseri umani: maneggiare con cura

Chi ricopre un ruolo di leadership si trova in certi momenti costretto a far “pressione” sui propri collaboratori, ma che effetti hanno tali sollecitazioni ?
Se immaginiamo una persona come una lamina d’acciaio e la pressione come una forza che agisce dall’alto verso il basso potremmo dire che una persona stressata è concava perché la pressione che sta subendo la sta deformando (fragile), se la persona è motivata potremmo considerarla piatta resiste alla pressione (resiliente), se è convessa sta reagendo alla pressione con una spinta (antifragile).
Ciascuno ha reazioni diverse alla pressione ed ha un proprio personale grado di flessione.
Compito dei leader dovrebbe essere identificare e misurare queste reazioni per evitare che venga raggiunto il punto di rottura.

Affrontare la giusta montagna

Catria

Ho letto numerosi libri in cui si sostiene che le sfide sportive più difficili possono essere vinte grazie alla forza di volontà.
La mente può influenzare il corpo e quindi se immagini di farlo lo puoi fare.
Mi piace pensare che la forza di volontà abbia questo potere, ma la mia esperienza diretta è che abbiamo dei limiti: fisici, caratteriali, psicologici con cui dobbiamo fare i conti.
Tentare di superare questi limiti per migliorare se stessi è doveroso e lodevole, ma non è sempre possibile.
Affrontare sfide più grandi di noi, denota coraggio ma in caso di fallimento può anche essere fonte di grande frustrazione.
Io amo la montagna, ma sul K2 non ci andrò mai: non è una sfida alla mia portata.

Questa consapevolezza però non mi impedisce di continuare ad amare la montagna e frequentare i nostri cari Appennini.
Si dice che tentare non nuoce ma non credo sia esatto, tentare imprese più grandi di noi può nuocere alla propria autostima.
Se vi incamminate per una meta che non è alla vostra portata lungo la strada dovete stare attenti ai segnali che il vostro corpo vi manda o rischiate di perdervi nell’impresa.
Walter Bonatti, in una delle sue ultime interviste, disse che la sfida degli scalatori non è tanto arrivare in vetta quanto tornare a casa sani e salvi, ciò naturalmente implica anche decidere di rinunciare alla scalata se necessario.
Nell’ultima ciaspolata che feci qualche anno fa, ultimo di un gruppo di 4 persone, a 3/4 del percorso, già molto affaticato, in un tratto molto ripido, mi dovetti fermare e cominciai a sbadigliare.
Rimasi colpito da questo strano segnale che il corpo mi lanciava e che sembrava fuori luogo, ma il senso ero chiaro: mi stavo spegnendo.
Il cervello diceva di proseguire, ma il corpo reclamava.
Decisi perciò di fermarmi e mi appoggiai con la schiena sulla neve. Trascorsi circa 5 minuti ad ammirare il panorama che mi si apriva davanti e approfittai per riprendere fiato.
Il sudore sulla pelle si raffreddò velocemente e non potendo rimanere lì fermo, dovetti scegliere cosa fare. Prima che il freddo si facesse sentire, mi rialzai e lentamente raggiunsi il resto del gruppo sulla cima del Catria.
Qualche anno dopo senza alcun tipi di preavviso ebbi qualche problemino con il cuore.
Non potei fare a meno di pensare che in quel frangente sulla montagna forse la mente aveva chiesto troppo al corpo e quella breve pausa era stata quantomai preziosa. Chissà ?
Insomma in quel caso la tigna mi portò fino in cima, ma avrei anche potuto scegliere di tornare indietro.
Naturalmente quando si affronta una sfida è importante mettercela tutta, ma se si tocca un proprio limite è importante ricordarsi che si può tornare indietro o cambiare strada.
Quando si sceglie una montagna da scalare è importante scegliere la montagna giusta.

L’utile costruttore

PL\SQL è un linguaggio procedurale ma è possibile adottare uno stile di scrittura orientato alla programmazione ad oggetti.

In un package PL\SQL è frequente dover definire un modello dati in memoria a supporto degli algoritmi di elaborazione.
Per far ciò, io personalmente preferisco utilizzare TYPE RECORD definiti all’interno del package stesso invece di TYPE OBJECT, perché ciò rende il package auto consistente.

Dato un TYPE RECORD è possibile definire uno o più RECORD di questo tipo di dato. L’inizializzazione di queste variabili può essere effettuati in punti diversi del codice nei modi più diversi, ma non si ha alcuna garanzia che il record venga inizializzato sempre in modo completo e corretto.
Questo rischio aumenta quando è necessario estendere il TYPE RECORD aggiungendo un attributo per esempio.
Il rischio è che, le procedure che utilizzano tali RECORD, risentano della inizializzazione incoerente di questi e che ciò produca errori a run-time.

Il concetto di costruttore è una soluzione efficace a questo problema: quando si usa una struttura dati, prima di usarla, è necessario avere garanzia che essa sia stata correttamente inizializzata.

Nel nostro caso l’idea è di considerare un TYPE RECORD l’equivalente di una CLASS e definire una FUNCTION che svolga il ruolo di costruttore.
Il costruttore accetta in ingresso tutta una serie di parametri che consentono di inizializzare il RECORD e restituisce il RECORD stesso.
La regola non scritta, si parla appunto di stile di programmazione, è che prima di usare RECORD di questo tipo si invoca sempre il suo costruttore.

SUBTYPE tItemId IS VARCHAR2(50);
SUBTYPE tCurrency IS NUMBER;

TYPE tItem IS RECORD(
   id     tItemId
  ,descr  VARCHAR2(255)
  ,price  tCurrency
  ,qty    NUMBER
  ,total  tCurrency
);
FUNCTION itemNew RETURN tItem IS
  this tItem :=NULL;
BEGIN
  this.qty   := 0;
  this.total := 0;
  RETURN this;
END;

FUNCTION itemNew(
   id IN tItemId
  ,descr IN VARCHAR2
  ,price  tCurrency
  ,qty    NUMBER
) RETURN tItem IS
  this tItem :=itemNew();
BEGIN
  this.id := id;
  this.descr := descr;
  this.price := price;
  this.qty := qty;
  RETURN this;
END;
DECLARE
  item tItem := itemNew();
BEGIN
  item := itemNew(id=>'ID123',descr=>'HAMMER',price=>1.3,qty=>2);
END;

Questo approccio può sembrare costoso a prima vista ma in realtà è semplice e facilmente ripetibile.

Il suo utilizzo rende il codice facilmente comprensibile.
Inoltre nel caso in cui si debba estendere il il TYPE RECORD, alterando il costruttore, avremo garanzia che l’intervento venga effettuato in modo coerente in tutti i punti del codice in cui il costruttore è invocato.

Il consiglio è di predisporre sempre un costruttore base non accetta alcun parametro e che inizializza tutti gli attributi ad un valore di default: nel gergo dei programmatori C un costruttore VOID.

Naturalmente sfruttando l’OVERLOADING è possibile definire una famiglia di costruttori che espongono parametri diversi in base alle varie esigenze applicative.

Un cronografo piccolo piccolo

A volta capita che una procedura PL\SQL sia lenta.
In questi casi per individuare le porzioni di codice lento è utile misurarne il tempo di esecuzione.
Per far ciò ho realizzato un package che implementa un cronografo.

CREATE OR REPLACE PACKAGE CRONO IS
   TYPE tTimer IS RECORD(
      s TIMESTAMP
     ,e TIMESTAMP
   );
 FUNCTION  new     RETURN tTimer;
   PROCEDURE stop    (this IN OUT NOCOPY tTimer);
   PROCEDURE reset   (this IN OUT NOCOPY tTimer);
   FUNCTION  time    (this IN OUT NOCOPY tTimer) RETURN VARCHAR2;
   FUNCTION  hour    (this IN OUT NOCOPY tTimer) RETURN NUMBER;
   FUNCTION  minute  (this IN OUT NOCOPY tTimer) RETURN NUMBER;
   FUNCTION  second  (this IN OUT NOCOPY tTimer) RETURN NUMBER;
 END;
CREATE OR REPLACE PACKAGE BODY CRONO IS
  
  FUNCTION  new RETURN tTimer IS
    this tTimer := NULL;
  BEGIN
    this.s := SYSTIMESTAMP;
    this.e := NULL;
    RETURN this;
  END;
  
  PROCEDURE starting(this IN OUT NOCOPY tTimer)IS
  BEGIN
    this.s := SYSTIMESTAMP;
  END;
  
  PROCEDURE stop (this IN OUT NOCOPY tTimer) IS 
  BEGIN
    this.e := SYSTIMESTAMP;
  END;
  
  PROCEDURE reset (this IN OUT NOCOPY tTimer) IS
  BEGIN
    this.s := SYSTIMESTAMP;
    this.e := NULL;
  END;

  FUNCTION  time (this IN OUT NOCOPY tTimer) RETURN VARCHAR2 IS
    ret VARCHAR2(32767):=NULL;
  BEGIN
    ret := this.e - this.s;
    
    ret := ret || ' ' || 'h:' || (extract(hour from this.e - this.s));
    ret := ret || ' ' || 'm:' || (extract(minute from this.e - this.s));
    ret := ret || ' ' || 's:' || (extract(second from this.e - this.s));
    
    RETURN ret;
  END;

  FUNCTION  hour (this IN OUT NOCOPY tTimer) RETURN NUMBER IS
    h NUMBER :=NULL;
  BEGIN
    h := (extract(hour from this.e - this.s));
    RETURN h;
  END;

  FUNCTION  minute (this IN OUT NOCOPY tTimer) RETURN NUMBER IS
    m NUMBER :=NULL;
  BEGIN
    m := (extract(minute from this.e - this.s));
    RETURN m;
  END;

  FUNCTION  second (this IN OUT NOCOPY tTimer) RETURN NUMBER IS
    s NUMBER :=NULL;
  BEGIN
    s := (extract(second from this.e - this.s));
    RETURN s;
  END; 
END;

Il suo utilizzo è molto semplice.
A seguire un esempio:

DECLARE
  t1 CRONO.tTimer; --Variabile di tipo cronometro

  --Codice che consuma tempo
  PROCEDURE NOP(cycle IN NUMBER)IS
  BEGIN
    FOR i in 1..cycle LOOP
      DECLARE
       c NUMBER := 0;
      BEGIN
        select 1 into c from dual;
      END;
    END LOOP;
  END;

BEGIN
  --Il cronometro t1 viene creato ed avviato
  t1 := CRONO.new();
  
  NOP(cycle=>1000);
   
  --Il cronometro t1 viene fermato
  CRONO.stop(t1);

  --Si stampa il tempo misurato dal cronometro t1
  DBMS_OUTPUT.PUT_LINE('Tempo trascorso A:' || CRONO.time(t1));

  --Si resetta il cronometro t1
  CRONO.reset(t1); 
  
  NOP(cycle=>500);
 
  --Il cronometro t1 viene fermato
  CRONO.stop(t1);
   
  --Si stampa il tempo misurato dal cronometro t1
  DBMS_OUTPUT.PUT_LINE('Tempo trascorso B:' || CRONO.time(t1));
 
END;