Per ogni cosa c'è il suo momento

Trovo estremamente antipatico parlare di "gestione del tempo". E' qualcosa che istintivamente mi fa pensare all'alienazione dell'uomo ed a una cinica aridità interiore.

Mi viene subito in mente il proverbio africano: "Voi aveve l'orologio, noi abbiamo il tempo!" Ed è proprio così. Eppure il problema, nell'attività lavorativa di un CIO, così come in quella di chi copre ruoli di coordinamento, esiste ed è da affrontare seriamente.

In verità in tutti i corsi e seminari sull'argomento, la maggior parte delle considerazioni rientrano in una sfera che si potrebbe definire del "buon senso". Nonostante questo focalizzare alcune tecniche può essere utile.

Mauro Lupis'Blog esprime un concetto, in un suo post sull'argomento, che mi sembra possa rappresentare il miglior punto di partenza.

il tempo "è il regalo più bello che riceviamo all'alba di ogni nuovo giorno: 24 ore di vita! E questo bene, sempre più prezioso e sotto una continua e crescente pressione, va difeso, organizzato, pianificato."

Mi piace aggiungere un altro spunto che possa fare da pilastro al parlare sul tempo.

Per ogni cosa c'è il suo momento, il suo tempo per ogni faccenda sotto il cielo.
C'è un tempo per nascere e un tempo per morire,
un tempo per piantare e un tempo per sradicare le piante.
Un tempo per uccidere e un tempo per guarire,
un tempo per demolire e un tempo per costruire.
Un tempo per piangere e un tempo per ridere,
un tempo per gemere e un tempo per ballare.
Un tempo per gettare sassi e un tempo per raccoglierli,
un tempo per abbracciare e un tempo per astenersi dagli abbracci.
Un tempo per cercare e un tempo per perdere,
un tempo per serbare e un tempo per buttar via.
Un tempo per stracciare e un tempo per cucire,
un tempo per tacere e un tempo per parlare.
Un tempo per amare e un tempo per odiare,
un tempo per la guerra e un tempo per la pace.

(Ecclesiaste 3)

Focalizzando le attività lavorative e volendo semplificare al massimo si possono prender in considerazione due parametri:

Importanza e Urgenza.

Sembrano due paroline buttate lì, ma se uno ci riflette, si rende conto che le due cose non coincidono affatto.

Intanto la definizione di importante e urgenza va referenziata correttamente in base al contesto.

"Riparare una stampante è importante?" In assoluto viene da rispondere No. Cos'è una stampante ferma di fronte alla criticità di un Server malfunzionante? Ma se le stampe non emesse interrompono un servizio aziendale primario allora la prospettiva cambia.

Comunque aver definito due parametri ai quali si può rispondere Si, No, delimita le attività da svolgere un quattro categorie:

Importanti e Urgenti
Devono essere immediatamente eseguite

Non Importanti e Non Urgenti
Va beh, se non si fanno pazienza. Qualche volta sono però quelli che danno soddisfazione. Nell'arco di una giornata ci sono sempre dei momenti in cui il proprio ciclo di efficienza si abbassa, perchè non utilizzare quindici minuti dopo la pausa pranzo?
Quello che rimane fuore fa parte dell'eccesso di informazioni che ognuno di noi riceve e che è consigliabile filtrare.

Non importanti e Urgenti
Hai qualcuno a cui farle fare? E' giusto quello che serve per delegare il compito.

Importanti e Non urgenti
Attenzione, tutti gli studi dicono che si tende a trascurare questi impegni. C'è una sola soluzione: pianificare in agenda l'impegno. Pianificare significa stabilire data, ora e durata dell'attività. "lo faccio pomeriggio" non funziona.

Si dice spesso "non lasciamo che siano gli eventi o gli altri a gestire il nostro tempo". Giusto, volete un esempio? I messaggi email. Oggi banda larga e funzioni dei mail-server concorrono a mitragliare nuovi messaggi quasi a getto continuo. La tentazione di leggereli subito è forte. Resistere. Cosa fareste se ogni due minuti qualcuno bussasse alla vostra porta per chidervi qualcosa? Mettereste un bel cartello: "Non disturbare" e dareste un po' di regole per gli appuntamenti.
Un'altra vittima di un cattivo uso del tempo è l'aggiornamento professionale. Anche qui unica soluzione è pianificare. Generalmente io arrivo in ufficio un po' prima dei miei colleghi ed esco un po' dopo. In questi intervalli di tempo, liberi da interruzioni, cerco di far rientrare questa attività.


A proposito dell'uso del tempo, in una prospettiva che comprende anche il lavoro, ma non solo. Vedi il mio post sulla lentezza, qui.

Come personalizzare un colloquio

Devo riconoscere che selezionare il personale da assumere nel reparto ICT è, per me, una delle parti meno gratificanti del mio lavoro.
Il primo ostacolo è preparare una adeguata inserzione. Si vorrebbe infatti avere un numero di risposte non troppo alto nè troppo basso. Ammetto candidamente che in una occasione ho avuto zero risposte. Se la figura che avevo (obbligato) tratteggiato fosse esistita, col cavolo che sarebbe venuta a lavorare per una medio piccola azienda genovese!
Altre volte hanno risposto in centinaia compresi sedicenti poeti e pittori che volevano inventarsi sistemisti.

Poi la scrematura in base ai CV ricevuti, con il timore di scartare il genio nascosto.
A seguire l'agenda degli appuntamenti e infine la gestione del colloquio vero e proprio.

Per ovviare alla sempre possibile fregatura di una cattiva valutazione delle capacità professionali e comportamentali delle persone che si stanno intervistando, ho, nel tempo, messo a punto alcune semplici regole che ultimamente mi sono state molto utili e mi hanno permesso di fare selezione anche con candidati dall'altra parte dell'oceano Altantico, via Skype.

Primo passo normalizzare le informazioni.
Al canditato, dopo averlo messo a suo agio, chiedo di riepilogare il CV sottoforma di uno schema precompilato che mi permetterà dei confronti semplificati.
Chiedo inoltre di autovalutarsi su ogni item della conoscenza.
Per puro esempio:
Conoscenza della teoria delle reti (niente/qualcosa/buona/eccellente)
Capacità di configurare il database SQL (niente/qualcosa/buona/eccellente)
...

Non basta, perchè il metro, l'unità di misura, è soggettiva. Ci sono persone prudenti che definiscono di sapere qualcosa mentre sono decisamente competenti e altre che la sparano più alta che possono.
A questo punto entra in ballo il test. Mi faccio aiutare dal responsabile dei sistemi o dello sviluppo software, a seconda della figura da selezionare e su ogni argomento rilevante al profilo si sottopone il candidato a domande (già stabilite, ma poi qualcosa si personalizza al volo) che mirano a verificare quanto pesare la sua "unità di misura". La cosa sembra funzionare.

Io mi rifiuto di fare la sommatoria pesata totale, perchè la valutazione finale deve considerare anche aspetti soft non qualificabili, ma ridurre la lista a quei due, tre nomi da sottoporre al rush finale è fatta. A quel punto uno qualunque dei tre mi dà una sufficiente sicurezza di competenza.

Come decidere le priorità

I documenti tecnici che fanno riferimento al "livello di priorità" di un intervento (manutentivo o di sviluppo) sono numerosi.
Lo scopo è evidente: occorre spalmare in un ordine temporale le attività da eseguire e assegnarle alle risorse disponibili.

Il problema sul quale rifletto è chi stabilisce la priorità e quale criterio è preferibile adottare.

Tipicamente nei vari SLA (Service Level Agreement) che i fornitori dichiarano nel contratto si specificano tre livelli (qualche volta cinque).

Spesso la definizione di priorità fa riferimento al sistema (es.: Livello 1= blocco totale sistema).
E' una definizione comoda ma ambigua, perchè non rispecchia le reali priorità del business.
Si giudica cioè con la mentalità di un tecnico. In quest'ottica, una stampante che non funziona è per definizione un problema minore!.
D'altronde, provare per chiedere, lasciar decidere all'utente finale cosa è prioritario e cosa no è inconcludente e troppo soggettivo.
Anche qui un'esperienza personale. Qualche anno fa utilizzavo un software per spedire telex e fax che chiedeva all'utente la priorità di inoltro. Lascio indovinare: il 90% dei messaggi erano dichiarati urgenti e quindi il meccanismo, di fatto, azzerava il canale preferenziale e la trasmissine ritornava ad essere quella cronologica.

Forse la soluzione sta nell'esposizione chiara di un criterio applicabile (1):

Livello 1 = "Non posso fare qualcosa di importante (processi del business)
Livello 2 = "Risolvere il più presto possibile, comunque posso procedere in qualche modo"
Livello 3 = "Posso continuare a sopravvivere..."

Nota (1): tratto da ITIL Small scale Implementation.

Comunque non è detto che sia sufficiente perchè pur focalizzando il problema sui processi e non sulla gravità o complessità tecnica, rimane un margine elevato di soggettività.

Un altro sistema può essere definire un doppio livello , uno indicato dall'utilizzatore (nella forma sopra suggerita) e un'altro assegnato dal personale tecnico che valuta l'impatto sul sistema (sicurezza, disponibilità, continuità, performance ecc).
La moltiplicazione dei due indici porta a ben nove differenti livelli di priorità.