Il ruolo di committente

Nei progetti di sviluppo software il ruolo di committente è essenziale.
È il ruolo che di solito esprime la richiesta da cui avrà origine il progetto, legata a precisi obiettivi di business. Decide i principali requisiti che guideranno lo sviluppo, e che dovranno essere coerenti con quegli obiettivi. Alla conclusione del progetto, è il committente che accetta il prodotto finale.

Anche durante il progetto è il committente che deve prendere le decisioni più rilevanti. Spetta infatti a lui (o lei) decidere quali funzionalità e quali caratteristiche rientrano nei confini del progetto, e quali no. E quali sono i limiti di costo sostenibili ed i vincoli temporali da rispettare.

Quando poi una delle tre variabili principali di progetto (cose da fare, tempi e costi) cambia in corso d’opera, per effetto di eventi non previsti all’inizio, diventa necessario valutare gli impatti del cambiamento. La decisione su cosa sia opportuno variare come conseguenza diventa cruciale, ed è nuovamente di competenza del committente.

Se ad esempio emerge durante il progetto la necessità di realizzare una funzionalità inizialmente non prevista, bisogna valutare se sia possibile aumentare i fondi necessari per svilupparla, se dilazionare i tempi di rilascio, se aggiungere la nuova funzione eliminando o rimandando altre funzioni previste inizialmente, ma meno urgenti.

Decisione che spetta di diritto al committente, perché riguarda considerazioni legate agli obiettivi di business che solo lui può valutare in modo completo, e che rientrano nelle sue responsabilità.

Analogamente spettano al committente le decisioni da prendere quando si verificano casi di ritardo nei tempi di sviluppo: conviene spostare in avanti la data di rilascio del prodotto o mantenere la data prevista inizialmente, riducendo le funzionalità del prodotto precedentemente concordate?

Dal momento che il committente è il ruolo che prende le decisioni più critiche per il progetto (compresa, se e quando è il caso, quella di interromperlo), si tratta di un ruolo indispensabile, e deve essere chiaro a tutti chi lo riveste per tutta la durata del progetto stesso.

Uno dei fattori di rischio più pericolosi in un progetto di sviluppo software è la situazione in cui non è chiaro chi abbia il ruolo di committente, o in cui la persona ufficialmente designata a svolgere tale ruolo non abbia la capacità, la volontà o l’autorità sufficienti a prendere le decisioni quando diventa necessario farlo.

Il problema, in casi simili, è che il committente è un ruolo difficilmente sostituibile. In situazioni progettuali in cui altri ruoli sono svolti in modo poco efficace, si può far fronte con degli interventi correttivi in corso d’opera, come affiancamenti o sostituzioni; è invece improbabile che si possa invece intervenire con correzioni quando ad essere debole è il committente.

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *