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.  

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;

La psicologia “semplice” del developer

Ho sempre ritenuto che nel nostro lavoro la componente psicologica sia molto importante, purtroppo ho registrato spesso una scarsa sensibilità verso questo tema.

Ma è veramente così difficile avere a che fare con i developer ?
E’ possibile disegnare il profilo psicologico di un developer ?

Recentemente, durante una di queste riflessioni, ritengo di aver colto una verità interessante.

Un developer professionale è molto simile ad un artigiano, i suoi manufatti sono diretta espressione della sua arte e del suo genio.

Inoltre:

  • trae piacere nel fare bene il suo lavoro e cerca l’eccellenza
  • ha bisogno di dare un senso al proprio lavoro e quindi cerca conferma che il suo manufatto sia utile
  • ha stima di chi fa il suo stesso lavoro e trae beneficio dal far parte di una comunità

Da ciò discente in modo chiaro che chiedere ad un developer di produrre “cacca” equivale a soffocare il sue ego ed infangare la sua arte, ingenerando un profondo senso di frustrazione. 

Di converso per alimentare e mantenere alta la motivazione dei developer è facile individuare una serie di azioni:

  1. manager competenti
  2. retribuzione commisurata al valore prodotto
  3. ambiente informale
  4. auto organizzazione
  5. disponibilità degli migliori strumenti
  6. agevolare l’accesso a informazioni e a formazione
  7. agevolare la partecipazione a community
  8. ridurre il debito tecnico
  9. rendere il lavoro sostenibile

Naturalmente ci sono dei lati oscuri che conviene tenere in debita considerazione:

  1. la ricerca dell’eccellenza è nemica della gestione del tempo
  2. l’ego spiccato può determinare sporadici deliri di onnipotenza

Sulla contrazione dell’universo

Le aziende sono organizzazioni che cambiano nel tempo.
La crescita di un’azienda è un fenomeno simile all’espansione dell’universo.
Quando il numero di persone cresce si cerca di contrastare l’entropia creando nuove funzioni livelli e ruoli aziendali che vanno ad accrescere la struttura gerarchica aziendale a forma piramidale.

La realtà e che non siamo affatto certi che l’espansione dell’universo sia continua. Allo stesso modo non possiamo dare per scontato che l’azienda cresca in modo indefinito.
Negli ultimi decenni abbiamo sperimentato un’altissima variabilità sui mercati e ci siamo dovuti ricordare che la crescita non è una costante.

Un’azienda allora per essere longeva dovrebbe assumere una struttura plastica che consenta di rimodellarla al bisogno e che riduca l’inerzia al cambiamento.
Da questa presa di coscienza di spesso nascono transizioni verso strutture organizzative più moderne a sviluppo orizzontale.

Se strutturare un’azienda in fase di espansione può essere relativamente facile, gestire una fase di contrazione ed appiattire la gerarchia è arduo.
I livelli, i ruoli e le funzioni creati nel tempo debbono essere revisionati in modo profondo e spesso doloroso.
Per le persone coinvolte in queste transizioni è come trovarsi nel compattatore dei rifiuti di Star Wars: è naturale opporsi in tutti i modi, cercando di sabotare la stessa sala comandi.

Per questo un processo del genere deve necessariamente partire dall’alto ma l’autorità non basta, serve anche autorevolezza.
La prima cosa da fare infatti è allineare tutti i livelli sui principi ed i valori.
Ciò può risultare estremamente difficile se negli anni precedenti i comportamenti e la linea di condotta hanno smentito nei fatti i principi ed i valori che si cerca di radicare: quello che serve è una buona dose di credibilità, ma ci vuole tempo.

Per questo motivo è più semplice creare da zero un’azienda che aderisca a certi principi e valori piuttosto che riconvertirne una esistente.

Come si può attraversare un fiume ?

Fiume
Fiume

Qualche tempo fa ho partecipato ad un bell’evento sul gaming.
Tra i vari giochi uno richiedeva di scrivere in 10 minuti un elenco di modi per attraversare un fiume.

Comincio a scrivendo le mie soluzioni:

  • con la barca
  • a nuoto
  • con un ponte
  • con una liana
  • con una pertica
  • con un tronco
  • ecc.

Finisce il tempo ed il coach chiede ad un partecipante di leggere una soluzione.
La persona si alza e declama fiero: “Sulle spalle di un altro..”
Lì per lì rimango di stucco poi comincio a riflettere.

Parto da me. Probabilmente per me e per i miei colleghi del gruppo tutti di estrazione ingegneristica è stato naturale cercare mezzi di locomozione per attraversare il fiume, ciò ha determinato automaticamente l’esclusione di una persona come mezzo di locomozione.

Mi metto nei panni dell’altro. Forse la persona è un manager. I manager per definizione gestiscono risorse tra cui esseri umani. I manager non sono uomini del fare. I manager da un certo punto di vista “usano” le persone per lavorare quindi tutto sommato, la risposta non dovrebbe stupire.

E’ stupefacente come un gioco di tale semplicità possa far emergere in modo così chiaro una tale differenza d’impostazione nella mentalità di una persona.

Il background ed il contesto influenzano il nostro modo di pensare e di affrontare i problemi, limitando di fatto l’area in cui cerchiamo le soluzioni.

Cosa rimane dell’Agile?

Qualche settimana fa ho partecipato al corso MASS Metodologie Agile di Sviluppo Software. Gli argomenti trattati:

  • Agile Manifesto
  • Scrum
  • Lean Software Development
  • XP

Ho avuto modo di approfondire temi a me cari e di fare esercitazioni di gruppo. Ho acquisito consapevolezza della relazione che esiste tra : Valori, Principi e Pratiche. E’ stato piacevole sentire citare il manifesto in una sede istituzionale da un docente aziendale; non più farneticazioni di qualche individuo controcorrente. Ho visto le facce dei miei colleghi prendere coscienza che esiste un modo diverso di intendere il nostro lavoro. Facce stupite di persone che scoprono un nuovo mondo in cui il buonsenso e’ dominante. Persone che a questo punto cominciano ad interrogarsi e farsi domande: e questo e’ già un grande risultato. Ma le transizionia Agile debbono partire dall’alto quindi non ci sono le condizioni. Allora prima che lo stupore scemi e si trasformi in frustrazione dobbiamo portare a casa i VALORI ed i PRINCIPI e qualche PRATICA (unit test) . Confrontarsi tutti i giorni con questi elementi ci renderà migliori e portatori di un messaggio forse controcorrente ma positivo e di buonsenso.

 

Lo spirito del formatore

Vengo da una famiglia di docenti: professori, maestri, mio nonno paterno fu preside, quindi l’attivita formativa fa parte del mio background culturale.
Tra il 200o ed il 2005 ho avuto la fortuna di svolgere io stesso l’attività di docente per numerosi corsi di formazione in ambito informatico: HTML, OOP, C, C++, Database Relazionali ecc con feedback sempre piuttosto positivi.
Qualche settimana fa mi è capitato di aiutare un collega preoccupato di non conoscere C#.
Per me nulla è impossibile quindi vedere un programmatore “scantato” di fronte ad un problema superabile non è accettabile.
Così per dimostrargli che passare da un linguaggio ad un altro meno è difficile di quanto sembri, l’ho aiutato 1o minuti a scrivere “Hello World” usando un ambiente di sviluppo per C# online.
Per lui è stato come scendere una pista nera senza sapere nulla degli sci: avventato e pericoloso ma divertente.
Il suo commento finale “Azz ma allora funziona, bè non sembra così complicato” mi ha dato grandissima soddisfazione.
E’ stato molto bello provare di nuovo, dopo tanto tempo, il piacere di insegnare qualcosa di nuovo ad una persona.
Ricordo perfettamente le settimane full-immersion dei corsi C e C++ a Milano in cui si alternava la mattinata di teoria al pomeriggio di laboratorio.
Per quanto i concetti del mattino sembravo essere stati trasmessi correttamente alla classe almeno a giudicare dalle espressioni del viso, nel pomeriggio, costruendo in prima persona dei piccoli programmi, accadeva spesso che il viso di qualcuno si illuminasse per poi esclamare: “A ecco come funziona! Adesso ho capito!”, segno tangibile che il concetto oltre ad essere stato ricevuto ed accettato per “fede” era stato verificato empiricamente e quindi fatto proprio, in modo maieutico.