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.
2 risposte finora ↓
Terenzio // Luglio 15, 2008 a 3:29 pm |
Vorrei aggiungere (anche se il blog è il tuo e non il mio) un mio punto di vista su quale può essere la chiave di volta per il successo di un progetto nei tempi prestabiliti (o quasi) e cosa può essere rifinito.
Il tecnico smanettone molte volte da un tempo basso anche perchè non ha tutti gli elementi su cui valutare il progetto.
Tipicamente a monte è stata fatta una analisi sommaria, tipicamente da un non tecnico che ha scritto un bel documento word di specifica dei requisiti e che per mancanza di tempo, aumento dei costi (il tempo è denaro dopotutto) o di competenza viene fatto passare come documento di analisi.
Un documento del genere non includerà mai tutte le casistiche limite e andarle a discutere tutte a priori a mio parere ha anche poco senso perchè:
- i tempi di analisi esploderebbero ed il commerciale non te li passerebbe mai
- non si può porre un limite alla fantasia all’utente che tipicamente non ha limiti ma al limite gli si potranno proporre dei metodi per lavorare che risolvano il suo “problema”
Camillo Precisini invece non sarà mai pago dell’analisi (sia che la faccia lui sia che venga fatta da un’analista) ponendo sempre dubbi (ragionevoli o meno) per cui il progetto avrà non solo una stima eccessiva di giornate e terminerà in ritardo ma il suo sviluppo partirà pure in ritardo.
Se poi aggiungiamo che per molti non tecnici la documentazione da loro prodotta è sempre sufficiente e non ne serve altra per procedere con lo sviluppo (analisi e progettazione vengono quasi sempre dimenticate e il testing percepito come incapacita del tecnico stesso di scrivere codice come si deve) la frittata non è fatta in arrivo ma già in partenza.
Per mediare i due estremi (e per esperienza diretta) è a mio parere sempre e comunque necessaria una fase di macro analisi fatta da un tecnico (sembra stupido specificarlo?) che parteciperà attivamente a tutto il progetto.
Questo si occuperà di individuare le macro aree da sviluppare e procederà alla micro analisi.
Collaborerà attivamente con il progettista e con gli sviluppatori se non è grado, per tempi e dimensioni del progetto ad essere parte integrante del team in queste fasi.
Dopo “la perdità di tempo iniziale” (perchè come già detto non scrivere codice vuol dire essere indietro agli occhi esterni) con ogni probabilità si riuscirà a:
- consegnare un semilavorato in grado di trattare il “caso buono” e cioè quello per cui i dati seguono il flusso ideale nell’applicativo.
- adattarsi fin da subito a soluzioni limite perchè non ci si vedrà costretti fin dal giorno zero (primo rilascio) ad accrocchiare soluzioni per tappare le falle
- realizzare qualcosa di abbastanza robusto da non andare in errore ogni 3 per 2.
- di instaurare un rapporto di fiducia con il committente che non si basa sul “siccome paghi faccio tutto quello che vuoi” ma piuttosto sul “siccome paghi vogliamo offrirti un servizio di qualità” (e le due cose di solito non coincidono).
Alla fine cosa si scopre?
Che per aumentare le speranze di riuscita di un progetto il Project Manager deve essere un tecnico (e con buone competenze) e che deve avere le mani in pasta nel progetto e non solo coordinare il team ed i rapporti con il cliente (che alla fine si riduce a fare il passacarte).
Ho scoperto l’acqua calda?
Secondo me si… purtoppo la realtà dimostra che non è così.
Scusa ancora la lunghezza (non è una risposta ma quasi un post…)
ciao Terenzio
giovannicuccu // Luglio 15, 2008 a 6:43 pm |
Concordo solo a grandi linee. Un vero PM è quello che non si limita fare da passacarte, ma mette la propria faccia e reputazione di fronte al cliente. Un PM come si deve sa gestire il cliente e se necessario, mediare le sue esigenze, magari diluendole in un arco di tempo più lungo. Un PM può essere anche non tecnico, anzi credo che debba essere in primis un esperto funzionale in grado di validare le rischieste del cliente ed il software del tecnico. Ma forse tu sei abituato a PM che dicono solo sì al cliente e sempre no al tecnico
. Io non lo chiamoPM, ma fa lo stesso……