AlfonsoStuardi.com

Mi sono fatto, tempo fa, una promessa: non accettare responsabilità se non supportate da un adeguato livello di autorità.

Uno degli errori che più frequentemente mi è capitato di incontrare sul campo, infatti, è la cosiddetta “delega zoppa”. Consiste in sostanza nell’attribuire ad un collaboratore, da parte del management, determinate responsabilità senza che a queste, però, corrisponda una delega di autorità sufficiente alla loro gestione.

Condizione che si traduce nella mancanza di quegli strumenti necessari, a volte, per riuscire ad ottenere davvero dei risultati.

E’ il caso, soprattutto, di quei progetti trasversali alla struttura funzionale dell’azienda, nei quali sono impiegate, part-time, risorse afferenti a diverse aree, ognuna delle quali ha un diretto responsabile. Responsabile, magari, con un grado di commitment nel progetto molto basso.

Se il project manager non ha in mano strumenti reali per coinvolgere le risorse e dettare i tempi, qualunque tipo di pianificazione diventa immediatamente utopistica, con scarsa soddisfazione di tutti (management in primis) e, soprattutto, scarsissimi risultati.

Una delle perenni sfide nello sviluppo di sistemi a supporto del business è quella di fare in modo che gli sviluppatori implementino effettivamente quelli che sono i requisiti funzionali realmente necessari ai key users del processo.

La definizione dei requisiti di business è spesso compito esclusivo degli utenti finali, i quali la realizzano secondo il proprio formalismo e la propria prospettiva, in una modalità che può essere più o meno accurata, completa e chiara.

Gli sviluppatori, d’altro canto, non hanno la stessa prospettiva e la stessa conoscenza profonda del processo di business: non sempre, quindi, riescono a comprendere appieno i requisiti a loro inoltrati.

La soluzione, spesso adottata dal sottoscritto, è quella di riunire assieme i 2 gruppi (key users e sviluppatori) in sessioni di lavoro nelle quali  i requisiti funzionali potranno essere opportunamente tradotti in un modello. In queste sessioni è importante la presenza di un facilitatore, in grado da fungere da interfaccia tra il modello dei processi di business ed il modello tecnico, ed, eventualmente, un progettista esperto in grado di definire i modelli di base sui quali verranno incentrate le seguenti attività di design, sviluppo e test (spesso i due ruoli sono ricoperti da una sola figura).

E’ la comunicazione, in sostanza, la chiave per il successo di un progetto di sviluppo software. Accade molto più spesso di quanto si possa pensare che, banalmente, un progetto fallisca totalmente o sfori costi/tempi perchè nessuno si è preso il tempo necessario per riunire i diversi players in una stessa stanza, assicurandosi che tutti siano sulla stessa lunghezza d’onda.