Come fare per aumentare la produttività

Il miglioramento della produttività è un obiettivo che tanti  fra manger e dirigenti, ma anche persone a cui piace il loro lavoro affermano di voler perseguire. E’ il sogno di tutti riuscire a fare più cose nell’arco della giornata.

Al di là delle aspettative credo che tutti siano concordi nel ritenere che aumentare veramente la produttività è un’impresa molto difficile.

In questo post proverò a suggerire una semplice soluzione che consente di creare la basi per un aumento di produttività.

La prima regola, spesso trascurata, ma semplice, è che i maggiori aumenti di produttività si ottengono agendo sulla motivazione delle persone.

In poche parole le persone si devono sentire coinvolte ed invogliate ad essere produttive. Come fare?

Basta partire dall’efficienza nelle picole cose. Provo a fare alcuni esempi.

Pensate di lavorare in un ufficio in cui c’è un armadio con la cancelleria e potete rifornirvi quando ne avete bisogno; peccato che una volta no ed una volta sì manchino le penne, i quadernoni, gli evidenziatori, etc.

Chiedete “perchè?” e ottenete risposte del tipo “il fornitore è in ritardo” o “il fornitore ha esaurito l’articolo” o “non mi ero accorto/a che fossero finiti”

Dopo un po’ smettete di chiedere ed imparate a fare senza, tanto non si può fare niente per cambiare le cose oppure non avete tempo per cambiarle.

La stessa cosa vale quando state aspettando un ordine di un pc o un server, tutto sembra muoversi al rallentatore.

Per non parlare di quando le cose deve farle qualcuno dei vostri superiori a cui avete chiesto aiuto o un consiglio e questo “si fa di nebbia”.

Col tempo si finisce per perdere la fiducia e ogni volta aspettare rassegnati che accada l’evento superiore che sblocchi la situazione e quindi si perde l’entusiasmo e la fiducia.

Pensate invece ad una situazione in cui quando finisce un articolo di cancelleria qualcuno va alla cartoleria più vicina, compra quello che deve e la mattina dopo vi trovate quanto richiesto sulla scrivania, o al caso in cui avete ordinato un pc e il responsabile acquisti vi informa che c’è un ritardo e vi offre una macchina temporanea o vi fornisce una data precisa in cui questa sarà consegnata.

O, udite udite, pensate alla possibilità che il vosto capo vi chiami dicendo che ha risolto il problema che gli avevate posto o vi invita a pranzo (e paga lui) per cercare di risolvere insieme il problema segnalato.

Come sarebbe il vostro atteggiamento sul lavoro?

Io credo molto, molto  diverso, vi sentireste parte di un meccanismo che funziona e sareste naturalmente portati a farlo funzionare meglio in quanto tutti intorno a voi fanno lo stesso.

E tutto questo senza analizzare, pensare o mettere in piedi chissà quale sistema. In tante aziende passare dall’idea dell’inerzia a quella del movimento basterebbe per far respirare a tutti un’aria diversa.

Non è difficile, basta volerlo.

Fate una passaggiata nel corridoio o fra le stanze della vostra azienda e guardate le facce?

Sono allegre o sono tristi e/o rassegnate?

Basta fare due passi per capire da dove cominciare.

Serve davvero fare pressione sui programmatori?

Arriva la fine anno e al solito tutti vogliono tutto e subito. Una conseguenza spiacevole di questa situazione è che i grandi capi chiedono alle loro “prime linee” i risultati e spesso questi essendo meri coordinatori non fanno altro che girare la patata al livello successivo e coì via fino ad arrivare alle persone che producono le quali si trovano a dover far fronte ad un sacco di richieste. In pratica il capo del nostro capo mette sotto stress il nostro capo che mette sotto stress noi (a volte accade anche che il grande capo stressi tutti e tutti stressino voi). Se questo accade è un chiaro segnale che qualcosa non va  e per due motivi:

1. Ci sono livelli che non fanno alcun tipo filtro (verso il basso) e questo significa che potrebbero farsi parte, tanto vale essere stressati direttamente
2. Queste persone non hanno capito molto di come si possano coordinare delle altre persone (non RISORSE come la rma del computer, MA ESSERI PENSANTI) per ottenere dei risultati (il che rafforza la conclusione del punto precedente ovvero dovrebbero farsi da parte)

Il secondo punto è quello più importante e credo che abbia le sue radici nella visione dei rapporti con gli altri.

Immaginate di essere di fronte ad un problema importante che non potete risolvere direttamente, ma dovete per forza delegare ad un altra persona perchè non sapete risolverlo voi. Potrebbe essere qualsiasi cosa (un tubo rotto nel muro, un difetto nell’impianto elettrico, un software da realizzare). La persona incaricata non sembra procedere come da voi previsto e qualcun altro (il nostro capo, il coniuge, la suocera, etc) chiede come vanno le cose e quanto manca alla fine. Se non vi fidate della persona cominciate a chiedere, a dare consigli o a dire di fare in fretta o peggio ancora insinuate che non sa fare il proprio mestiere.

Mettetevi dall’altra parte e pensate di essere chiamati a fare un lavoro, di incontrare delle difficoltà e di avere qualcuno che “stressa”. Non è piacevole e sicuramente siete poco sereni per cui anche il lavoro che fate ne risente, per forza.

Che cosa potrebbe aiutare? Molto semplice: qualcuno che chiedesse “posso aiutare?” e/o che vi dimostrasse la sua fiducia. A parità di lavoro da svolgere il risultato sarebbe sicuramente migliore.

Perchè allora lo stile in voga è quello di mettere pressione? perchè il pensero di fondo è che i sottoposti se non controllati o “pressati” tendono a rilassarsi e rendere di meno. Credo questa assunzione anche vera non porti da nessuna parte perchè:

1. Se una persona non ha voglia di lavorare troverà sempre il modo di evitare di farlo e ha sicuramente imparato a difendersi dallo stress
2. Se una persona ha voglia di fare lavora meglio se motivata e se sente un clima di fiducia intorno a sè

Chi ha figli che vanno all’asilo (specialmente il nido) dovrebbe chiedersi come mai ci sono maestre che non urlano, sorridono sempre e si fanno obbedire “senza sforzo”. Penso che dovremmo prendere esempio da queste persone: in fondo la differenza fra adulti e bambini sta solo nel costo dei giocattoli che desiderano.

Lo stipendio dei programmatori

Oggi ho deciso di affrontare un tema “scottante” e di riflettere sulla qualità degli stipendi dei programmatori.

Ci sono una serie di fattori che rendono difficile stabilire una cifra valida per tutta Italia, come per esempio la domanda di personale qualificato; a Milano la vosta costa di più che in altre città e nello stesso tempo ci sono molte, molte aziende che hanno bisogno di personale. La conseguenza diretta è che lo stesso lavoro sarà meglio retribuito a Milano piuttosto che a Bologna.

Senza contare che la congiuntura economica (e quella attuale non è certo favorevole) può influire pesantemente sulle decisioni di investimento in personale.

Un’altro fattore che l’azienda valuta è la componente di “gestione” associata ad una posizione, si parte dall’autonomia individuale e si arriva fino alla gestione di un gruppo di lavoro; una persona che riceve specifiche da implementare e che “deve solo eseguire” verrà retribuita meno di una che coordina un gruppo di persone. Le aziende hanno bisogno di persone a cui affidare delle responsabilità, maggiore è la responsabilità, maggiore deve (e non dovrebbe) essere lo stipendio; indipendentemente da quello che si fa. La mia esperienza mostra che le aziende cercano il più possibile persone che a cui affidare in toto una serie di attività per ottenere indietro solo dei risultati, maggiori sono i risultati attesi, maggiore è lo stipendio.

La diretta conseguenza è che non importa se un programmatore è bravo a scrivere il codice in quanto non è su quel tipo di problemi che di solito ci si concentra. Il risultato, ovvero il codice funzionante è dato per scontato. La (triste) conseguenza è che, a meno di non riuscire ad introdurre in azienda una metrica sulla qualità del codice, lo stipendio del programmatore non potrà mai salire come quello di chi coordina le persone.

Considerando il mercato IT di Bologna oserei definire la cifra di 38.000 euro lordi l’anno come tetto massimo per chi svolge esclusivamente lavoro di programmazione. Non è una cifra malvagia, affatto, ma è necessario considerare che:

1. Ci arrivano in pochi in quanto molte persone optano nel frattempo per un’altra carriera (PM, etc)
2. Non tutte le aziende sono disposte a pagare un programmatore “puro” tale cifra
3. Per raggiungere tale cifra di solito servono più di 7 anni di esperienza nella posizione

Questo è un vero peccato in quanto posso spesso toccare con mano la realtà descritta da tanti libri che afferma che le differenze di rendimento fra le persone possono variare da una a dieci volte. Se lo stipendio di un programmatore senior ha un tetto (dovuto al fatto che non si misura la sua produttività) la conseguenza è che prima o poi questo imbocca una carriera diversa. Se si vuole evitarlo è necessario pensare a come valutare ed incentivare il lavoro del programmatore; agormento che mi riprometto di trattare in futuro.

Il curriculum del programmatore

In questi giorni mi sono trovato nel delicato ruolo di dover valutare una serie di curriculum di persone che hanno risposto ad un annuncio di lavoro pubblicato da Cup2000. Di seguito il testo integrale pubblicato sul sito:

Stiamo cercando un programmatore java laureato in materie scientifiche, con tre o più anni di esperienza in ambito J2EE. Il candidato dovrà aver maturato esperienza significativa nell’uso e nella configurazione dell’application server tomcat e nell’utilizzo di framework MVC. Verranno valutate positivamente precedenti esperienze nell’utilizzo di Spring, SpringMVC, iBatis, JUnit e TestNG. E’ gradita la conoscenza approfondita del database Oracle. Si richiede la capacita di lavorare in parziale autonomia seguendo obbiettivi precisi. Completano il profilo la capacita di lavorare in gruppo e la passione per lo sviluppo e la progettazione software.
Si offre un ambiente di lavoro stimolante in cui poter utilizzare i piu recenti standard tecnologici (Java 1.6, Spring 2.x, iBatis, Oracle 10).

Dalla lettura dei curriculum mi sono reso conto che il modo di scriverli tradizionale è decisamente poco utile allo scopo (mi sono reso conto che anche il mio è carente). I numeri del mio caso sono 16 curriculum per un posto; questo implica devo fare una selezione anche delle persone a cui fare il colloquio (considerato che un colloquio dura un’ora non ho materialmente due giornate lavorative da dedicare ai colloqui). Sulla base di cosa faccio la prima selezione? Su quello che ho: il curriculum.

Quindi quello che leggo mi deve convincere a chiamare la persona, quali sono i fattori che mi spingono a farlo?

La risposta e’ semplice: cerco di capire se il curriculum descrive una persona che rispecchia le richieste dell’annuncio. Se tutti i curriculum sono piatti il compito è difficile in quanto sono io che devo cercare le informazioni e se queste non sono chiare cercare di dedurre. Qual’è il modo migliore per attirare l’attenzione di chi legge? Condensare nelle prime 5/10 righe le informazioni essenziali che consentano una valutazione esatta delle capacità della persona. La traduzione pratica è molto semplice, una lettera di presentazione che spiega perchè la persona si ritiene adatta per quella posizione. Nei curriculum che ho letto non ce ne era una adaguata. La cosa che ho imparato è che quando si pubblica un annuncio di lavoro ci sono tante persone che rispondono, per cui la concorrenza è forte, è necessario potersi assicurare di superare la fase di scrematura del curriculum per poter arrivare ad un colloquio e per fare questo è necessario attirare l’attenzione di chi legge. il modo migliore per farlo è fargli leggere quello che si aspetta. Questo significa che ogni invio di curriculum richiede come minimo una lettera di presentazione personalizzata (chi legge dall’altra parte di solito riconosce al volo le frasi fatte o di circostanza quindi la lettera va tarata ogni volta), se questa contiene gli elementi cercati il curriculum serve solo come riscontro. Per ottenere il massimo è necessario adattare il curriculum alla posizione cercata evidenziando le parti di interesse per chi legge.

Un altra cosa che è importantissima è la “sincerità” del curriculum, ovvero è fondamentale scrivere solo cose “vere”. Ricordo ancora un colloquio avvenuto circa un anno fa con una persona che sembrava (dal curriculum) molto esperta in tantissimi campi e che invece alle prime domande tecniche ha ammesso una conoscenza solo scolastica. Tempo perso per me e per la persona che però si è preclusa la possiblità di un ripescamento in futuro. Quando l’annnuncio di lavoro è dettagliato (è citata anche la versione di Spring, di Java e di Oracle) significa che chi l’ha scritto conosce la materia e su quella si aspetta dei riscontri. Questo vale per tutte le parti del curriculum.

Un altro aspetto sono i requisiti, può anche essere accettabile non avere tutti i requisiti, ma è necessario capire su quali si può “glissare”. Esempio: tre o più anni di esperienza in ambito J2EE. Se uno ne ha due in java ed un uno in .net nella lettera di presentazione scrive che invia il curriculum in quanto considera un anno di esperienza in .net equivalente ad uno java (se ne ha tre solo in .net forse dovrebbe rispondere ad un altro annuncio o scriver euna lttere di presentazione veramente convincente).

Se non si possiedono i requisiti (es nessuna eperienza lavorativa rilevante) la cosa migliore è inviare un curriculum a parte, non per quella posizione di lavoro, indicando che non si possiedono i requisiti dell’annuncio, ma che si è interessati a lavorare per quell’azienda (scrivendo bene il perchè) e quindi si invia il proprio curriculum per una posizione diversa.

Concludo con due esempi di lettere di presentazione, la prima per l’annuncio in questione e la seconda per una posizione generica:

Buongiorno,

ho letto il vostro annuncio su XXXX per la posizione di programmatore Java senior e vi invio il mio curriculum in quanto credo di avere i requisiti adeguati. Sviluppo in Java J2EE da ormai Z anni e ho maturato una esperienza significativa (attraverso la conduzione dei progetti R,T,Y che trovate descritti nel curriculum)  nello sviluppo di applicazioni basate su framework MVC e Tomcat. Inoltre in diversi progetti ho utilizzato il database Oracle. Sono in grado, una volta stabili gli obbiettivi di progetto, di lavorare con la necessaria autonomia, garantendo sempre la visibilità dell’andamento del progetto assegnatomi.

Distinti saluti,

il secondo

Buongiorno,

ho letto il vostro annuncio su XXXX per la posizione di programmatore Java senior. Non possiedo i requisiti elencati nell’annuncio, ma le tecnologie elencate sono quelle che utilizzo attualmente e su cui sto maturando una solida esperienza. Mi piacerebbe fare parte della vostra Azienda in quanto l’annuncio evidenzia una “vocazione” tecnologica in linea con la mia. Vi invio il mio curriculum per una eventuale posizione di programmatore Junior che dovessere rendersi disponibile in futuro.

Distinti saluti,

Per quel che ne capisco io (ma sono un tecnico) solo delle aziende poco furbe butterebbero via dei curriculum che rispondono a delle lettere di presentazione così scritte. Aziende per le quali  un “programmatore dentro” non dovrebbe lavorare.

La fine anno e gli incentivi

Dopo aver letto l’ultimo articolo di Joel Spolsky sulle commissioni ovvero sugli incentivi a vendere ed in generale a raggiungere gli obbiettivi aziendali mi sono reso conto (oltre al fatto che Joel è quasi sempre tre passi avanti) che questo meccanismo è perverso e che andrebbe rivisto o quantomeno controllato. Cosa ci azzecca la fine anno? e’ tempo di budget, quel periodo in cui si concretizza la scadenza annuale e in cui si può parlare di medio evo ovvero di un tempo di regressione. Il messaggio è: se non si fa il budget sono problemi, per cui si rilassano tantissimi vincoli e si cerca in tanti modi di raggiungere l’obiettivo economico. Peccato che la maggior parte delle persone cominci a vedere solo l’obbiettivo economico e se ne freghi delle conseguenze arrecate ai colleghi. In una azienda di software chi sono i più bombardati?

La risposta è facile: quelli che producono il software, ovvero i tecnici.

A loro viene chiesto di fare in tre o quattro mesi quello che hanno fatto in otto (come se prima ci fossimo grattati i cabasisi) e comincia la fiera dell’improduttività causata dal fatto che i PM&C devono fare le famose riunioni di allineamento, ovvero incontri volti a produrre un piano di azione e delle scadenze (sempre per i tecnici).

Perchè scrivo questo? perchè penso che si possa evitare o almeno limitare il clima veramente difficile da gestire.

Soluzione numero 1: dividere l’anno in due e quello che si manca a fine giugno è recuperabile solo in minima parte a dicembre.

Soluzione numero 2: legare gli obbiettivi non solo al budget economico, ma anche ad una valutazione  da parte della struttura produttiva che soffre di queste condizioni.

Sono convinto che questi due punti possano da soli far evolvere la situazione verso il meglio; conosco le possibili obiezioni specialmente riguardo al primo punto: è impossibile sono i clienti/committenti che non ci consentono di spezzare l’anno in due.

Posso non crederci? Posso ipotizzare che i clienti si comportano così perchè noi li abbiamo abituati/assecondati a fare così?

Posso ritenere che se un PM o chi per lui si presenta con una cosa da fare all’ultimo minuto e sa che riceverà per quello un guidizio che influisce negativamente sul suo premio di produzione pianifica meglio l’attività?

Se i tecnici non possono dire che una cosa è impossibile perchè possono dirlo gli altri?

Concludo con una delle osservazioni riportate nell’articolo che ho citato; quando si stabiliscono delle commissioni o degli incentivi bisogna sempre tenere presente che le persone faranno tutto il possibile e alla fine troveranno degli stratagemmi per riuscirci; strategemmi è diverso da soluzioni.

I tecnici e i Project Manager

Il rapporto fra tecnici e PM (ovvero i project manager) è quello che solitamente crea più grattacapi. Le cause sono molteplici, ma due sono quelle più frequenti

1. I soldi
2. il tempo

Se queste due si è discusso a lungo per cui oggi voglio affrontare un altra causa, più rara, ma ben più insidiosa: il PM ex o finto tecnico. E’ un mix quasi micidiale che richiede molta calma e fermezza per essere gestito.

Lo scenario è di solito è il seguente:

Arriva il PM con il progetto completo di importo, giornate uomo e scadenze (le stime le ha fatte lui, ha imparato a farle quando era tecnico). Ecco il “pacco regalo”, tutto già fissato, c’è solo da lavorare. Con una sola piccola clausola, che il PM guarda, analizza e critica. E arrivano domande di questo tipo:

Ma questa funzione vuoi proprio farla così?
Ma sei sicuro di scegliere questa architettura?

Per poi passare in un crescendo quasi inarrestabile alle frasi del tipo

L’ho già fatto 10 anni fa nella metà dei giorni e dei soldi.

A questo punto la risposta è scontata: allora perchè non hai proposto la tua soluzione?

L’approccio da seguire, se si vuole evitare di arrivare ad una frizione inutile a tutti è quella di stabilire dei confini basati sulle responsabilità: se il progetto è in difficoltà per ragioni tecniche chi è il responsabile?

Lo si scriva nero su biano ed in cc a chi di dovere e la partita è chiusa. Si concorda un piano di scadenze e si lavora su quello.

Le cause di questi attriti non sono tecniche, sono caratteriali. I tecnici solitamente sono tali perchè amano avere il controllo delle cose che fanno, ovvero avere la sensazione (ed in vb6 si andavo veramente poco più in là) che quello che si produce sia assolutamente deterministico. Che cosa controlla un PM?

L’operato di altre persone (oltre ai soldi s’intende).

Non c’è niente di meno deterministico (e se poi si usa ancora vb6…..)

Come reagisce il PM? Cercando di imporre la sua autorità, con la speranza di un maggiore controllo.

Peccato che le persone riconoscono l’autorità (in senso lato, ovvero si creino dei riferimenti di cui fidarsi) e quelle imposte senza fondamenta creano un sentimento completamente diverso.

Che fare (se il PM non ci arriva da solo)?

L’unica speranza di lavorare sereni è quello di concordare costi e scadenze sensati e cercare di proporre soluzioni alle situazioni critiche, ovvero di cominciare a dare delle certezze.  Se il PM capisce di avere un  maggiore controllo e capisce anche che comportandosi in un certo modo può continuare ad averlo probabilmente cambierà atteggiamento.

Basterebbe capire che in progetto in cui ci sono n tecnici ed un pm che farà per forza di cose la maggior parte del lavoro? Per raggiungere lo scopo chi è che deve essere produttivo al 100%?

I tecnici, per cui o li si motiva o non si raggiunge l’obbiettivo.

Se non lo capisce (o non lo si vuole capire)….pazienza, peggio per lui; probabilmente rinuncerà ad una parte del suo premio di produzione (che di solito è più alto di quello di un tecnico).

Un libro da non perdere

Oggi ho cominciato la lettura di un nuovo libro e (finalmente) ho avuto la conferma che non sono un pazzo visionario, almeno per quanto riguarda il modo di gestire i tecnici di una azienda IT. Essa afferma che molti manager SBAGLIANDO trattano i tecnici come pezzi di una catena di montaggio, quando un pezzo si rompe basta ordinarne uno uguale. Finalmente dopo 10 anni di lavoro leggo un libro che mette nero su bianco quello che ho sempre pensato, ovvero che il motto

“nessuno è insostituibile”

sia solo una mezza verità; in quanto è vero che l’azienda di una certa dimensione va avanti anche se una persona meritevole se ne va, ma è anche vero (e in questo moento non sto pensando a me stesso) che la “botta” spesso si sente (e nel 1999-2000 di botte ne ho sentite parecchie).

Il libro continua mostrando come i manager spesso agiscano in maniera semplicemente illogica perchè

“Le non soluzioni facili hanno molto più appeal delle soluzioni impegnative”

Molto bello anche il capitolo che spiega come sia sbagliato dare scadenze impossibili o mettere continuamente sotto pressione i tecnici.

Il tutto fa il paio con un paio di situazioni reali (una vissuta in pirma persona ed una no) che confermano ancora di più che non sono io il matto, ma chi crede che lo sviluppo software sia uguale al mondo della produzione industriale (e gestisce le persone come tali).

Mi chiedo come mai ci ho messo tanto a scovare questo libro.

Per chi fosse interessato sto parlando di “Peopleware” di Tom DeMarco – Timothy Lister

La carriera del tecnico

Questo post riprende uno precedente in cui parlavo della parabola del tecnico ed in cui emergeva come, almeno in Italia, non ci sia spazio reale per i tecnici di lunga e comprovata esperienza (o almeno i posti ci sono, ma sono l’eccezione e non la regola). Durante questi mesi ho avuto l’occasione di selezionare diverse persone che si candidavano per posizioni tecniche. Con mia grande sorpresa, la netta maggioranza indicava la posizione di tecnico come temporanea, ovvero come balzello da pagare per diventare cosa?

Capo progetto o analista (per fortuna nessuno ha detto manager o dirigente )

Quando ho chiesto perchè ho ottenuto risposte simili che in sostanza convergevano su un aspetto: il desiderio di coordinare (che tradotto nella mia testa significa parlare molto, scrivere poco e sapere ancora meno).

Tali aspettative si sposano con l’opinione di un dirigente che conosco che ha più volte affermato (cito quasi testualmente):

“Se una persona ad una certa età è ancora un tecnico allora è un coglione”

La certa età è stimata intorno ai 40.

Quello che mi verrebbe da dire a queste persone e che dico pubblicamente è :

Se vole fare i project manager o gli analisti fatelo, ma senza “inquinare” le posizioni tecniche dove probabilmente farete solo dei danni in quanto farete un lavoro che non vi appassiona e non adatto a voi. Non sto escludendo una carriera di coordinamento per i tecnici; quando si accumula un buon bagaglio di esperienze è giusto condividerle e far evitare alle persone con meno esperienza i propri errori ed è anche corretto non spendere il proprio tempo in attività senza valore aggiunto.

Se volete fare i manager o dirigenti studiate come tali, pagate un bel MBA, conoscente gente conta e poi trovatevi un lavoro ben pagato, non c’è bisogno di fare la gavetta da tecnico, anzi è controproducente.

Arriva fine anno: obiettivo bilancio

Probabilmente l’ultimo trimestre è il più duro per i tecnici (ma anche per i commerciali) in quanto il tempo per centrare gli obiettivi è sempre meno e di solito la meta è distante.

Di solito si verifica la seguente situazione: i commerciali o i capi progetto per fare il budget dicono di sì a tutto o quasi ed arrivano sulla scrivania progetti impossibili. L’impossibilità principale è data dal fatto che i tempi a disposizione per tali progetti sono ridicoli. La domanda classica è perchè il progetto arriva a settembre o ottobre o più tardi invece di marzo, aprile o maggio?

Domanda inutile, tanto tutta l’azienda che conta, dal top management fino ai commerciali (che solitamente sul budget hanno premi di produzione non trascurabili) hanno in testa un unico target, centrare gli obiettivi economici.

Cosa fare? Accettare la cosa come un dato di fatto, che si ripeterà ogni anno. E’ una componente strutturale di tante aziende per cui si tratta di stringere i denti ed aiutare l’azienda a raggiungere gli obiettivi (anche se spesso il raggiungimento degli obiettivi economici non si riflette sullo stipendio del tecnico la cui mansione è assimilata alla manodopera facilmente sostituibile). Quello che a cui si deve stare molto attenti sono le possibili “fregature” (solo per il tecnico s’intende). Non mi sono mai trovato in situazioni simili, ma ho ben presente i racconti e le lamentele di tante persone che ho conosciuto e che ci sono passate; solo grazie alle loro sono uscito indenne da tali disavventure. Uno scenario classico è il seguente.

Un PM/commerciale ha un progetto in ritardo e da tale progetto deriva una parte non trascurabile (per sempio sopra il 5%) del budget aziendale, per cui ci sarà la massima volontà a centrare l’obiettivo. E’ nell’interesse di tutti, l’azienda che aumenta il fatturato, la persona prende il premio. Se ci sono cause insormontabili per cui l’obiettivo non può essere veramente centrato scatta la corsa “all’accordo”. Essa consiste nel dire, caro cliente,partner, etc, etc il tale progetto e’ in ritardo per questi motivi, va bene se mi certifichi che questa parte del progetto attualmente in sviluppo è finita ed io te la consegno fra X mesi? Dove esiste un rapporto di fiducia ci si viene sempre incontro, per cui in tanti casi la risposta è sì. Così i conti tornano, nel senso che l’azienda raggiunge gli obiettivi di bilancio, il lavoro e’ spostato di qualche mese ed il cliente ha un “credito” da giocarsi la momento buono.

Peccato che a volte quando si afferma che un lavoro è finito (anche se non è vero), anche il relativo capitolo di spesa viene chiuso. Che conseguenze ci sono?

Per il commerciale nessuna, ha centrato l’obiettivo. Per il tecnico qualche “problemino” c’è, infatti dove carica le giornate l’anno dopo se il capitolo si spesa è chiuso?

Spesso su un nuovo progetto o nella fase successiva del progetto. Pessima soluzione. Per tanti motivi.

Quello più importante è che si falsano i rapporti costi/ricavi delle attività e di conseguenza i manager prendono delle decisioni su dei dati sbagliati.

Esiste una via d’uscita? Secondo me sì. La prima cosa da fare è accordarsi in maniera chiara e precisa sull’allocazione futura dei costi dei progetti “chiusi virtualmente”. La seconda cosa è far in modo che in azienda vengano quantificate in maniera esplicita gli spostamenti di fine anno. Per un tecnico è doveroso darsi da fare per raggiungere gli obiettivi aziendali, ma faticare tanto per poi trovarsi brutte sorprese in futuro, no.

L’hardware del tecnico

Una delle cose più trascurate è la postazione di lavoro. Spesso vedo persone che devono lavorare con PC non adeguati al compito che devono svolgere. Credo che sia un caso in cui con poco di più in termini di spesa si riesca ad ottenere un rendimento decisamente maggiore. Riporto un esempio personale, fino a due mesi fa lavoravo con un pc che richiedeva circa 35 secondi per avviare il tomcat usato per lo sviluppo (sullo stesso PC oltre all’antivirus era attivo Oracle 10g ed Eclipse, più un Firefox con i plugin firebug e webdeveloper). Quando sviluppo applicazioni web riavvio tomcat almeno 20 volte al giorno (ovvero dalle 2 alle 3 volte l’ora). Questo significa 20*35=700 secondi di attesa circa pari a 11 minuti abbondanti. Dopo qualche mese ho chiesto un pc più performante, adesso tomcat parte in 4 secondi. Questo significa 20*30=600 secondi risparmiati, 10 minuti esatti al giorno. Sono 200 minuti al mese, pari a quasi 7 ore. Non sviluppo tutti i giorni 8 ore al giorno, ma credo che di poter dire che ogni due mesi risparmio 8 ore. Considerato che il costo aziendale di uno sviluppatore con esperienza viene valutato sui 250/300 euro al giorno l’azienda in tre mesi rientra dall’investimento.

Per chi programma avere un pc adeguato è importante non solo dal punto di vista della redditività, ma anche come segnale che l’azienda invia al dipendente/collaboratore. Come vi sentireste se appena arrivati vi dessero un pc vecchio e lento? Come vi sentireste invece se vi dessero un pc nuovo potente e con un bel monitor LCD?

Questo non vuol essere un invito ad “esagerare”, comprando pc che rimangono inattivi per il 90% del tempo, ma un suggerimento a valutare le reali esigenze della persona con delle prove sul campo che misurino le attese durante il normale lavoro (da cui si potrebbe dedurre che i pc ronzini li dovrebbero dare al management, persone che solitamente leggono documenti e usano la posta elettronica).

Il Pc dal quale sto scrivendo questo articolo (il mio personale) ha una cpu Athlon64X2 3800+, 4Gb di ram 2 hd da 250GB e un monitor LCD da 22′ wide. Esagerato?

Forse, ma quando ho dovuto preparare un corso su Oracle Data Guard ed avevo due vmware Linux Centos 64bit ognuna con un Database 10g in archive log non mi sono pentito di avere tutto questo “ferro” a disposizione.

Quanto costa un pc con una configurazione simile? Ho davati un volantino pubblicitario di un negozio di una nota catena informatica che vende una configurazione molto simile (il monitor è lo stesso un HP w2207) a 999 euro iva inclusa.

Per chi lavora e porta a casa i soldi con l’informatica non sono soldi spesi male.