Vita da tecnici

Voglio condividere un caso da manuale a cui ho assistito in prima persona in questi giorni. (uso nomi di fantasia per evitare riferimenti espliciti)

L’azienda Fantasia vuole collaborare (oggi dire vendere sembra una brutta cosa) con l’azienda Sogno e dopo uno scambio di email/telefonate ecco l’incontro per fissare i punti cardine del rapporto. L’azienda Fantasia invia Pippo e Paperino che illustrano i prodotti.

I manager di Sogno sono molto contenti, Pippo e Pluto rispondono alle varie domande e alla fine Biancane afferma: “Ok, mi avete convinto, allora siamo tutti d’accordo, andiamo in produzione il 10 luglio”.

Paperino rimane decisamente perplesso, ammutolito per quel secondo che basta per far capire che casca dalle nuvole (e non atterra dolcemente). Biancaneve reagisce “Questo era un requisito emerso e comunicato fin dai primi contatti”. Pluto rimane in silenzio per il tempone cessario a far comparire un sorriso diabolico e dice “Confido nelle capacità della nostra azienda”.

Domanda: chi è il tecnico fra Paperino e Pluto?

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).

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

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.

E’ già da diverso tempo che ho in testa questo argomento. Spesso la progettazione e lo sviluppo vengono paragonate all’architettura, da cui vengono presi a prestito vari modelli. Un esempio su tutti è la qualifica software architect.

A mio parere assimilare il processo di realizzazione di un software al processo di realizzazione di un edificio è decisamente fuorviante e ci sono più divergenze che similitudini.

Consideriamo come viene fatto un edificio: si parte dal progetto che viene approvato (a volte accompagnato della presentazione di un plastico) e da lì si comincia a costruire. Una volta che si comincia alcune cose diventano immutabili, per esempio non è più possibile (se non con costi ed oneri esagerati) spostare la costruzione o cambiare forma alle fondamenta. E’ possibile cambiare i particolari, le collocazioni di alcuni muri, ma la natura dello stabile rimane quella del progetto. La costruzione viene fatta da una serie di figure completamente diverse e spesso molto specializzate, chi tira su i muri difficilmente monta gli infissi o fa l’impianto elettrico o quello idraulico o posa i pavimenti. L’architetto o l’ingegnere o il geometra vanno in cantiere per assicurarsi che il direttore lavori segua fedelmente il progetto, ma sicuramente “non vanno alla betoniera”. Un altro fattore importante è l’interscambiabilità, un muratore un giorno fa un pezzo di muro che il giorno dopo può essere finito da un collega, senza particolari passaggi di consegna.

In sostanza tutto procede secondo logiche preordinate e basate su standard accettati. (Se qualcuno pensa che nei cantieri edili ci sia il caos legga quello che segue).

Nell’informatica invece non accade nulla o quasi di tutto questo. Il committente spesso aprrova un progetto non conoscendo i dettagli di cosa verrà fuori e capisce cosa vuole solo quando vede funzionare un pezzo di software. Ne risulta che spesso è necessario un ciclo di prototipi e rilasci per tarare il tiro. Chi di noi andrebbe ogni giorno in un cantiere cantiere che ha commissionato dicendo “mi sposti la finestra più in qua” o “le piastrelle che ho scelto e che avete montato non mi piacciono più” o ancora “mi sposta la casa altri di 30cm dalla strada”? aggiungendo “tanto quanto vuoi che costi”?

Chi costruisce una casa sa benissimo che dopo che un pezzo è stato fatto c’è un costo ben preciso per buttare giù e rifare. Chi commissiona un software evidentemente no.

Un altro aspetto è la specializzazione che nell’informatica è molto meno sviluppata, proviamo a lasciare una classe o anche una funzione a metà ed assegnare ad un altro programmatore il compito di finirla; quanto tempo ci vuole per la presa in carico di quanto già fatto? Inoltre spesso unprogrammatore svolge diversi compiti (design dell’interfaccia grafica, modellazione/definizione di parti della base dati, etc)

Un altro indicatore che indica quanto la produzione del software sia diversa e più arretrata rispetto alle costruzioni edili è la presenza dei building block ovvero dei componenti riusabili. Nell’edilizia si usano, mattoni porte e finestre già fatte, nell’informatica molto meno. Cosa succederebbe se un giorno entraste nel cantiene dove stanno costruendo casa vostra e vedeste un muratore che con un camino acceso fabbrica dei mattoni? Immaginiamo il dialogo:

Noi: Buongiorno, cosa sta facendo?

Muratore: Buongiorno, sto facendo i mattoni per costruire la casa

Noi: Perchè?

Muratore: Sa, quelli che sono in commercio non mipiacciono tanto, poi hanno quegli spigoli così ruvidi, me li faccio io così faccio prima e sono come mi servono.

Il risultato sarebbe: fuori dal cantiere a calci nel sedere.

Nell’informatica molto pochi si scandalizzano se qualcuno nel 2008 si fa un package di logging in java o in .net eppure la fine dovrebbe essere quella del mutatore sopra citato.

Un’altra differenza sostanziale è che chi comincia a programmare fa una carriera in cui pian piano diventa coordinatore e poi project manager o commerciale; quanti muratori-architetetti o elettricisti-ingegneri conosciamo?

Si conclude qui questa riflessione sul processo di costruzione software e sulle sue differenze rispetto al processo di costruzione edile. Tutti i fattori elencati fanno parte della fase costruzione, manca ancora la fase “manutenzione e post vendita”, ma credo che già si intuisca come parlare di software architect sia una cosa che non ha fondamento reale. Nei prossimi articoli proverò ad illustrare altre differenze e delle metafore più appropriate.

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.

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.

Spesso, parlando con le persone con cui lavoro emerge un argomento ricorrente, i tecnici, quelli che realizzano quanto altri hanno pensato, svolgono tale mansione per poco tempo (dove per poco intendo da due a quattro anni). Dopodichè solitamente vengono promossi ad un ruolo “più alto”, ovvero di coordinamento di altre persone e/o di analisi-progettazione “pura” (ovvero quella dove si programma in word ed outlook). Per verificare se è vero basta porsi le seguenti domande: quanto commerciali conosco con esperienza decennale? quanto dirigenti conosco con esperienza decennale? quanto capi progetto conosco con esperienza decennale? quanto tecnici conosco con esperienza decennale?

La risposta all’ultima domanda di solito è il minimo dei numero prodotti dalle risposte alle domande precedenti.

Questo perchè il ruolo di tecnico, almeno in Italia, è una fase di transito, non un punto di arrivo. Non mi sembra una strategia vincente per un serie di motivi che proverò ad elencare.

Quello più immediato è che tale percorso si applica di solito a persone che sono al primo lavoro o con poca esperienza e che necessitano di formazione per poter svolgere il loro ruolo. Solitamente il primo anno serve per imparare come si fanno le cose, quindi ne rimagono due o tre per accrescere la propria produttività. Giunti alla fine di tale percorso solitamente la persona è in grado di svolgere la propria mansione in maniera efficiente e produttiva per l’azienda cosa succede?

Deve cominciare ad occuparsi di altro, spesso mettendo nel dimenticatoio le cose che ha imparato, senza poterle trasmettere a qualcun altro.

Non voglio assolutamente negare che ci possa evoluzione nei ruoli tecnici, ma quella che vedo in giro non mi sembra molto conveniente per le persone che aspirano a rimanere a contatto con la “produzione vera” del software. L’evoluzione deve essere graduale e mantenere uno stretto contatto con le attività svolte in precedenza. Provo a spiegarmi meglio; quando si sviluppa un software ci sono una serie di moduli/classi/pattern che sono altamente ripetitivi e che è corretto affidare a persone con poca o media esperienza in quanto “la strada è già stata tracciata”. La persona tecnica impara a sviluppare tale soluzioni, si chiede se e come possono essere migliorate ed impara a svolgere il proprio lavoro. Una volta fatto questo è corretto cominciare a risolvere altri problemi di maggiore complessità o cominciare a pensare come riutilizzare le soluzioni adottate in contesti diversi. Seguendo un percorso di questo tipola persona cresce tecnicamente e continua a sviluppare software sempre migliore in quanto fa tesoro delle esperienze precedenti. Con la crescita del bagaglio di conoscenze si arriva ad un punto in cui di fronte ad un nuovo sviluppo la persona identifica chiaramente i problemi e le relative soluzioni ed è in grado di produrre lo scheletro dell’applicazione (infrastuttura o moduli core, etc, etc) sia in termini diprogettazione che in termini di codice e lasciare le parti ripetitive a chi deve imparare. In questo modo il tecnico rimane tale, incrementa la sua produttività e concorre a formare anche altre persone, migliorando la produttività aziendale.

A me sembra logico e coerente, ma poichè spesso non è così dei motivi ci saranno; provo a fare delle ipotesi.

La prima che mi viene in mente è che il ruolo tecnico viene visto dal mangement come un ruolo “basso”, meccanico in cui le persone sono facilmente sostituibili. Una diretta conseguenza sono stipendi bassi e una naturale tendenza delle persone a cercare ruoli pù remunerativi. Una seconda ragione consiste nel fatto che per aspirare a posizioni “alte” spesso (per chi non ha conoscenze o parenti altolocati) è necessario partire dal basso per cui il ruolo tecnico (che in questo caso viene assimilato da chi lo svolge a di basso profilo) viene visto come la gavetta per arrivare altrove. L’ultima ragione che mi viene in mente è che chi decide non sa assolutamente nulla o quasi di come avviene veramente la progettazione del software e dei diversi livelli di produttività legati all’esperienza delle persone per cui applica schemi letti sui libri (nel 99% scritte da persone che non ne sanno come lui/lei) .

Spesso mi è venuto il dubbio di essere mezo matto e di non capire assolutamente nulla di quete problematiche per cui ho provato a cercare delle prove che confutassero la mia tesi. La conferma che non sragiono mi è venuta da Google. E’ sufficiente leggere come effettuano le assunzioni di personale tecnico per trovare una assonanza con le mie idee. Google cerca persone con esperienza, in grado di *dimostrare* cosa sanno *fare*. Una delle loro assunzioni di qualche anno fa è Joshua Block uno dei maggiori progettisti/implementatori delle librerie Java (in particolare java.util). Invito i curiosi ad aprire il sorgente di java.util.ArrayList.java e di vedere chi sono gli autori: due persone con decenni di esperienza.

Il secondo motivo per cui non credo nella parabola del tecnico è quella che la strategia della temporaneità porta distorsioni nell’organigramma aziendale. Se dopo pochi anni l’azienda ci invita a fare i capo progetto/commerciali/etc, etc dopo una decina di anni ci si ritrova con tanti “coordinatori” e pochi “produttori” con una struttura aziendale che assomiglia ad una palla da football americano (in quanto il management di solito rimane composto da poche persone) . Una barca dove le persone che tengono il timone sono numericamente simili a quelle che remano. Le soluzioni ad un simile problema sono varie: si incentiva un ricambio dei ruoli intermedi sostituendoli con persone senza esperienza o si “costringono” le persone “nella parte larga della palla” a fare tecnici. Le conseguenze della prima soluzione sono perdita di conoscenze, quella della seconda insoddisfazione dei dipendenti che aspiravano (finalmente) ad un ruolo “meno tecnico”.

A mio parere la soluzione vera consiste nel selezionare in fase di colloquio persone con aspirazione tecniche per ruoli tecnici, (cosa che non tutte le aziende sanno fare) e farle crescere (anche con nello stipendio!!) secondo il loro profilo; il risultato sarebbero dipendenti/collaboratori più motivati e maggiore produttività aziendale.

Se lo fa Google una buona ragione ci sarà.

Prima di iniziare a parlare di java, oracle, css, etc e di esperienze comuni a figure tecniche è opportuno definire cosa intendo per tecnico.

E’ una persona che a seconda del ruolo che svolge (progettazione sviluppo software, sistemista, dba, web designer, etc) sa mettere le mani sulla tastiera per creare un programma, uno script che risolva un problema o che aiuti l’utente finale a fare meglio qualcosa.

Il tecnico si distingue dallo smanettone proprio grazie alla capacità di sapere incanalare le sue capacità verso qualcosa di utile e produttivo.

La vera sfortuna è che il tecnico non è come un diamante, non dura per sempre, il ruolo tecnico va mantenuto con la pratica. Se abbiamo smesso di programmare/progettare dieci anni fa (e magari lo abbiamo fatto solo per un anno o due e pure malvolentieri) non possiamo più dirci tecnici.

Non esiste una medaglia con la scritta tecnico che una volta appesa al petto ci rimane gratis et amore dei.

Il problema vero è farlo capire a chi non è tecnico (come manager o commerciali).

Un esempio da manuale?

Un cliente ha un problema particolare, mai visto prima, una persona tecnica lo risolve solo perchè è stata prescelta tramite estrazione di un bussolotto che conteneva il suo numero di matricola et violà!! ecco l’esperto della materia XXXX anche se la persona se l’è cavata con accrocchi di ogni tipo e per il rotto della cuffia. Da quel momento in poi la sua vita aziendale è segnata; ha vinto la medaglia di tecnico, ad ogni problema simile il suo telefono squillerà.

La vita da tecnici in questo senso è veramente dura, ma nessun problema di solito, almeno in Italia, dura veramente poco.

Ma questo è l’argomento del prossimo post.