Cambiare lavoro (5 di n): il colloquio

Dopo aver affrontato la preparazione del curriculum vorrei spendere qualche parola sul colloquio. Il curriculum e la lettera di presentazione sono dei mezzi per arrivare al colloquio che a mio avviso costituisce “il grosso della partita”.

Non credo che ci siano particolare stratagemmi da seguire, di seguito elenco i punti fondamentali:

Essere sinceri sinceri, nel senso che mentire spudoratamente non paga, nemmeno se si viene assunti
Essere sinceri, ma non fessi, nel senso che gli stessi concetti possono essere espressi in maniera molto diversa, è importante cercare di capire cosa vuole sentire l’interlocutore e cercare se possibile di essere in sintonia con lei/lui
Essere umili, l’arroganza o la presunzione sono irritanti
Cercare di prepararsi un discorso o una serie di risposte

Qualche esempio concreto: state cercando di cambiare lavoro perchè avete un capo insopportabile e vi chiedono “perchè ha deciso di cambiare lavoro?”

Rispondere “perchè il mio capo non capisce niente” può corrispondere al vero (punto 1), ma non è detto in maniera corretta (quindi niente punto 2) , si può passare per arroganti o presuntuosi (anche perchè chi vi fa il colloquio potrebbe essere il vostro futuro capo e quindi si potrebbe identificare in quello che non capisce niente) quindi niente punto 3 e infine è una risposta istintiva e quindi niente punto 4.

Risultato 1 giusto-3 sbagliati

Si può fare di meglio.

Tra i tanti colloqui dell’anno scorso me ne ricordo uno di una persona che a parole era bravissimo sapeva cosa rispondere alle domande aziendali “classiche”, ma ahimè è caduto sulle domande tecniche dimostrandomi che “stava cercando di vendermi” molto fumo e poco arrosto. Credo che in un colloquio ci stia presentarsi in maniera positiva, “raccontando una storia” come direbbe Seth Godin, ma la storia deve poggiare su basi solide altrimenti si rischia di essere ricordati come dei venditori di fumo.

Credo che sia importante essere pronti per le domande classiche che sono

Perchè si cambia lavoro
Cosa si cerca nel nuovo lavoro
Quali sono le esperienze maturate fino ad adesso

In più per fare buona impressione oltre a rispondere alle domande potrebbe essere farne qualcuna per capire se si è in possesso di qualche elemento che potrebbe aiutare chi ci sta intervistando.

Esempio: se si viene dal mondo bancario e si sta facendo il colloquio con una azienda che lavora nell’ambiente della sanità chiedere se ci sono flussi amministrativi o procedure di pagamento per capire se ci sono aspetti per cui poter offrire un contributo in base ad esperienze passate potrebbe essere un elemento distintivo.

Chi ci intervista di solito ha dei problemi da risolvere e spera che il nuovo assunto sia in grado di aiutarlo, se si capiscono i problemi dell’interlocutore e si offrono delle competenze di solito queste non passano inosservate.

Riassumendo: sincerità senza ingenuità, preparazione, propositività.

I problemi lavorativi: qualche banalità

con questo post vorrei provare ad elencare qualche piccolissima riflessione sui problemi lavorativi

I problemi facili non sono problemi e probabilmente li ha già risolti qualcun altro
Se devi risolvere un problema che nessuna delle n persone prima di te è stato in grado di risolvere hai tra le mani un problema “difficile”. In realtà hai tra le mani un problema “difficile per gli altri”; non è detto che lo sia anche per te. Ricorda che vale anche il viceversa (ovvero difficile per te non significa difficile per gli altri).
Se risolvi problemi “difficili” i colleghi se ne accorgono e ti chiedono di risolverne altri
Vale anche il viceversa del punto 3, se non risolvi problemi i colleghi tenderanno a chiedere meno
Risolvere problemi difficili di solito ti fa sentire soddisfatto
Se risolvi i problemi (veri) del tuo capo è difficile che se ne dimenticherà
Se risolvi solo i tuoi problemi e non quelli degli altri non se ne accorge nessuno

Chiudo con tre domande:

Vogliamo risolvere dei problemi?

Se sì, quali?

In base a cosa veniamo valutati?

Cosa fare per cambiare le cose in azienda (1 di n)

Una considerazione concisa. Capita a tutti i non apprezzare alcuni aspetti dell’azienda per cui lavoriamo.

Se vogliamo che le cose vadano diversamente dobbiamo essere i primi a farlo.

Esempio concreto

Ci chiedono le cose all’ultimo secondo sempre.

Se vogliamo che le cose cambino dobbiamo essere noi a cominciare a chiedere le cose con anticipo e fare in modo che anche qualcun altro faccia come noi.

Se ci chiedono le cose all’ultimo e noi facciamo uguale come potranno cambiare le cose?

Spesso comportamenti simili sono generati dal fatto che fanno tutti così; ovvero due o tre persone hanno cominciato a fare così, nessuno ha detto niente e gli altri sono adeguati perchè ormai tutti chiedono le cose 10 secondi prima di quando serve (ed è anche più comodo per chi chiede).

E’ più facile seguire la corrente, ma se vuoi cambiare spesso è necessario nuotare in una direzione diversa.

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:

Ci sono livelli che non fanno alcun tipo filtro (verso il basso) e questo significa che potrebbero farsi parte, tanto vale essere stressati direttamente
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è:

Se una persona non ha voglia di lavorare troverà sempre il modo di evitare di farlo e ha sicuramente imparato a difendersi dallo stress
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 del programmatore: piccolo addendum

L’altro giorno stavo riflettendo sul fatto che lo stipendio non è correlato alla effettiva produttività di un programmatore, ovvero che a partità di errori risultanti chi produce codice a velocità doppia rispetto ad un altro non prende lo stipendio doppio, figurarsi cosa succede a chi produce codice a velocità n volte superiore.

Mi sono chiesto perchè?

Dopo qualche la secondo la risposta è stata: perchè sono un ingenuo.

Sono ingenuo perchè diversi manager che conosco riponderebbero: “lui/lei non dovrebbe prendere il doppio, sono gli altri che dovrebbero prendere la metà”.

Non hanno tutti i torti, infatti in nel mio ragionamento manca un sistema di riferimento vero.

Amen

Se si vuole guadagnare di più è necessario trovare altre strade.

P.S. Ma non sono così sicuro che guadagnare di più debba essere per forza il primo obiettivo, anzi in molti casi raggiunto un livello medio di retribuzione gli obbettivi dovrebbero essere altri.

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:

Ci arrivano in pochi in quanto molte persone optano nel frattempo per un’altra carriera (PM, etc)
Non tutte le aziende sono disposte a pagare un programmatore “puro” tale cifra
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.

L’open source e le sue possibili implicazioni il caso Spring

Adesso che le acque si sono calmate e che la vicenda è finita bene vorrei provare a fare qualche riflessione sull’argomento. Parto dai fatti. In ambiente Java lo Spring-framework si è affermato come uno standard importante per lo sviluppo. Spring è rilasciato con licenza Apache che è, insieme a quelle BSD, una delle più permissive, ovvero con il codice ed il jar relativo ci puoi fare quello che vuoi. Spring è sviluppato da una azienda Spring Source che dalle attività di supporto, consulenza e sviluppo closed trova il suo sostentamento.

Fino a un mese fa venivano rilasciati i jar delle versioni con un ciclo di vita classico, rilascio delle major release (es 2.5) a cui seguivano le versioni con bug fix (2.5.1, 2.5.2, etc). Ed ecco che arriva l’annuncio, Spring Source cambia politica e dice che i sorgenti saranno rilasciati sempre cona la stessa licenza e sempre con su subversion, ma ci saranno solo i jar delle major release e delle minor release che verranno rilasciate entro tre mesi dalla data di rilscio delle mino release. Dopo i tre mesi ognuno fa da se’ se vuole i jar in quanto sul subversion pubblico non ci sono ne tag ne branch quindi nessuna informazione per creare delle minor release comuni. Se si vogliono i jar delle minor release successive si deve sottoscrivere un contratto di supporto.

Credo che si tratti di un caso da manuale. Il sorgente rimane disponibile a tutti, puoi compilarlo, ma in realtà la libertà è solo apparente. Se dopo i tre mesi trovo un bug cosa faccio? Consulto la lista dei bug e se questo è stato corretto scarico i sorgenti e li compilo. Benissimo a questo punto che versione sto usando? boh. Come faccio a chiede supporto sui forum della comunità se in pochi ho nessuno usa la mia versione? E’ facile intuire che se si vogliono creare delle applicazioni da metter ein produzione su cui garantire un supporto non si può procedere “liberi e belli” a meno di avere delle persone dedicate ai problemi Spring. Per cui ritengo che tale policy costringa di fatto a comprare il supporto da Spring Source. E’ il classico caso in cui del sorgente te ne fai veramente poco, quello che conta è che hai un prodotto di qualità, gratis e con un supporto da parte della comunità. E’ questo che dal punto di vista dell’utilizzatore conta, la libreria ed il supporto (per il management conta molto anche il fatto che è gratis); il sorgente spesso è uno specchietto per le allodole; un’altra cosa che conta è che la licenza consenta di vendere l’applicazione a sorgente chiuso (cosa che per esempio la licenza GPL non ammette).

Per fortuna le proteste della comunità hanno indotto Spring Source ad un cambio di rotta che ha portato al rilascio dei jar delle minor release fino alla versione RC della successiva major relase. Il problema si è notevolmente ridimensionato, a patto di essere sempre sulla cresta dell’onda ovvero di adottare l’ultima versione. Chi non se lo può permettere paga e tutto sommato è giusto così.

Vorrei concludere con una riflessione sui prodotti open source; l’analisi di una serie di casi mostra come storicamente tutti i prodotti che hanno dietro di sè una azienda che ne controlla lo sviluppo seguono un ciclo in cui la versione free (nel senso di free beer) subisce delle limitazioni del tempo; basti guardare Spring, MySQL, extJS e se ricordo bene anche le librerie QT. Il motivo è quasi sempre il profitto. Nel caso di prodotti open che sono sviluppati dalla comunità (Tomcat o Postgresql per esempio) questo non può succedere in quanto c’è una comunità di individui che spesso ricava profitto da altre fonti o in maniera indiretta. Lo svantaggio è che non ci sono persone dedicate allo sviluppo quindi le release possono essere diluite (anche se OpenBSD dimostra esattamente il contrario).

La scelta di un prodotto open source deve essere quindi effettuata facendo anche valutazioni di questo tipo in quanto i cambiamenti in corsa sono spesso sgradevoli e costringono ad un esborso economico improvviso oltre che ad una perdita di fiducia nel prodotto che si sta usando.

I tipi di tecnico IT e la qualità del software

Esistono diverse categorie di tecnici IT, ma vorrei soffermarmi su due categorie.

La prima è quella che quando chiedi una stima ti fornisce un numero di giornate sempre piuttosto basso (sono la fortuna dei commerciali e dei PM) e che alla fine entro la data stabilita qualcosa riesce a darti. il problema è quasi sempre il cosa. Spesso il software realizzato mostra una serie di bug evidenti che rivela che il grosso del lavoro è stato fatto, ma manca ancora la fase di rifinitura (ovvero quella di test serio). Cosa significa la maggior parte del lavoro? Significa che il codice all’80% circa c’è già tutto, non sono gestite le finezze ed i casi “estremi” (ovvero tutte quelle condizioni di input normali per l’utente, ma ignote allo sviluppatore).

Peccato che per l’utilizzatore questo significhi che il prodotto è al 40/50% non all’80, con le conseguenti lamentele del PM, del commerciale, del cliente.

Questo tipo di persona, se ha passione per il suo lavoro e non è uno che tira via (basta guardare come è scritto il codice per riconoscere il tipo), è di quelli a cui piace cambiare progetto e imparare sempre, a volte a ritmi decisamente elevati. Il motivo per cui non esegue i test è che ha già assorbito le basi della tecnologia e quindi ha già la testa che pensa al prossimo progetto, i test non aggiungono nulla o quasi al suo percorso tecnico.

Il secondo tipo di tecnico IT è quello che si potrebbe definire “Camillo Precisini” (il nome è preso da una favola per bambini che parla di un cane estramente meticoloso e preciso, fino all’esagerazione). Per lui il software non è mai finito e dopo la prima fase di realizzazione ne segue una, tendenzialmente infinita, di test, test, test. Difficilmente queste persone ti danno una data di fine (se te la danno) compatibile con le scadenze del progetto. La fine di solito la mette il PM che intima di rilasciare il prodotto, pena la crocifissione nella mensa aziendale. Il prodotto finito è decisamente più stabile e l’utente è più soddisfatto.

Quela dei due profili dovrebbe essere privilegiato(a parità di eleganza del codice e dell’architettura software)?

La risposta sembrerebbe essere il secondo.

Vorrei riflettere più a fondo.

Il tecnico smanettone consegna generalmente in tempo ed il suo semilavorato necessita di qualche giorno (ovviamente dipende dalla dimensione del sofware) per essere definito accettabile da cliente. E’ il classico caso in cui il PM che conosce i suoi polli aggiunge un tot di giorni di margine e raggiunge l’obiettivo. Il tecnico preciso consegna quasi sempre in ritardo e comunque vorrebbe avere più tempo, vorrebbe avere più specifiche, etc,etc. Il software che consegna anche se più stabile, va comunque rivisto, in quanto la produzione software segue un percorso ciclico in cui ad ogni consegna si rivedono alcuni presupposti precedenti.

La cosa che va capita è che il software è buono solo se chi lo usa lo ritiene tale; inoltre essendo un prodotto umano è per definizione soggetto ad errori. Che senso ha consegnare un software tre mesi dopo e avere lo stesso gli utenti che lamentano (anche se meno rispetto a quello che sarebbe avvenuto tre mesi prima)?

In questo caso l’utente ti dice: me lo hai consegnato tardi e ci sono pure degli errori (per lui evidenti).

Gli errori ci saranno sempre, tanto vale consegnare in tempo e poi correggere gli errori.

I programmatori migliori di solito vorrebbero produrre un software che loro giudicano decente; la cosa che va capita è che:

Spesso il grado di qualità del software è percepito molto diversamente dall’utente
Non è detto che si debba arrivare alla qualità ottenuta al primo rilascio

La qualità del software, intesa sia dal punto di vista del codice che delle funzionalità utente, si ottiene solo dopo una fase di rodaggio in produzione quando si capisce cosa questo deve fare anche dal punto di vista dei dettagli operativi. Questo significa che è ottenibile sono dopo n iterazioni sviluppatore-utente.

In questo scenario il primo profilo spende meno tempo ed energia e nel lungo periodo, a parità di qualità, riesce ad essere più produttivo. Senza contare che nel mondo reale è tutto urgente ed il tempo non basta mai, per cui avere delle persone che investono tempo in cose che si potrebbero rivelare inutili o che potrebbero essere essere fatte fra n mesi può essere un elemento di freno oggettivo. Questo non vuol dire che non ci sia posto per i precisini, ma che questi dovrebbero cercare di bilanciare gli smanettoni (direi che un precisino e due smanettoni è una buona proporzione) per ottenere un compromesso accettabile.