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.
