intranetlife

In breve Giacomo dice che i progetti interni vengono spesso, se non sempre, rilasciati confidando di "averci preso":
* innanzitutto a causa di fretta realizzativa accompagnata a pigrizia analitica
* in secondo luogo per uno spirito dirigista che non favorisce il coinvolgimento degli utenti
* in terzo luogo la parcellizzazione dei saperi nelle organizzazioni impedisce la collaborazione
* il risultato è che gli utenti lanciano "noi e il nostro progetto fuori dalla finestra"
* l'unica soluzione è ripartire dagli utenti.

Dicevo che sono d'accordo con Giacomo e aggiungo che la sua diagnosi si applica a tutti i progetti nei quali il software deve rispondere a reali esigenze operative delle persone: siti intranet, siti internet, applicazioni business.

In tutti questi la tentazione, e la presunzione, di progettare a tavolino è così forte da prendere spesso, anzi spessissimo, il dominio del progetto.
E così tutti i buoni propositi, tutte le "belle parole" scritte nelle presentazioni e recitate durante sessioni di formazione o nei seminari, vanno a farsi friggere.

Nel mio articolo, più che proporre una metodologia, mettevo in evidenza quattro punti:
1. scopo del progetto - deve essere chiaro e tradursi in obiettivi concreti per orientare il progetto nella giusta direzione
2. obiettivo del progetto - è sempre legato al "business" ed è la condizione per ottenere un ritorno positivo
3. aspettative degli utenti - cosa si aspettano di poter fare e quali benefici attendono dal progetto sono le condizioni per raggiungere l'obiettivo
4. feedback - ricercare e mantenere un coinvolgimento costante degli utenti nel progetto è la condizione per assicurare l'allineamento del progetto alle esigenze espresse e quindi all'obiettivo del progetto.

Concludevo scrivendo che sarebbe certamente più semplice progettare avendo in mente l'"utente standard", ma purtroppo (o per fortuna) il mondo e le aziende non sono fatti di utenti standard.

Le stesse considerazioni le ritrovo oggi ancora applicabili, nel bene e nel male.
Nel bene, perché sto sviluppando una metodologia progettuale che parte dalle esigenze raccolte presso gli utenti e le traduce in caratteristiche del servizio, del sito e dell'organizzazione secondo un percorso che lega le scelte realizzative all'esigenza da soddisfare.
Nel male, perché proprio la fretta realizzativa sta complicando non poco lo sviluppo di un altro progetto, mettendo costantemente il gruppo di progetto di fronte alle esigenze degli utenti che si manifestano confusamente e in prossimità del rilascio.

Concludo l'autoreferenzialità di questo post con la pubblicazione dell'articolo che ho citato.

Get your own - Open publication