10.0 Cascata e gestione ciclica del progetto (Parte 3) – Ciclo di vita del progetto e risultati

Durante tutto il ciclo di vita del progetto, gli utenti dovrebbero essere in grado di testare tutti i risultati intermedi. #

I clienti sono invitati a definire nel modo più preciso possibile le proprie esigenze durante le fasi di definizione e progettazione. Questo è impegnativo per due motivi. Per cominciare, i consumatori hanno una comprensione limitata del potenziale e delle impossibilità della tecnologia dell’informazione. Non hanno idea di cosa sia o dovrebbe essere fattibile, né sanno cosa dovrebbero o non dovrebbero desiderare. In secondo luogo, i consumatori spesso non hanno una conoscenza approfondita dei propri processi aziendali.

Numerose iniziative IT includono l’informatizzazione degli attuali processi aziendali di un’organizzazione. Anche se i consumatori hanno lavorato con i processi per un lungo periodo di tempo, spesso non hanno la capacità di progettare i propri processi aziendali. Possono funzionare bene a modo loro, ma non possono specificare quale sia quel modo. La definizione esatta del processo è necessaria prima di sviluppare software che guiderà l’informatizzazione. La complessità dei clienti aumenta a causa della necessità di spiegare le procedure correnti.

Criteri determinanti #

Spesso l’elenco dei criteri prodotto durante la fase di definizione è incompleto. I programmatori creano software in conformità con questo elenco parziale durante la fase di implementazione. Quando i consumatori incontrano le versioni beta del nuovo software, diventano evidenti esigenze extra. “Sembra carino, ma potresti forse aggiustarlo in modo che non debba inserire costantemente la mia password?” I programmatori spesso lamentano che i clienti non sono sicuri di ciò che vogliono. I clienti affermano che, in quanto esperti, gli sviluppatori di software avrebbero dovuto identificare ciò che i clienti desiderano nelle prime fasi del processo.

È stato creato un design funzionale completo per un progetto software che includeva l’elaborazione automatizzata di applicazioni per un servizio basato sul web. Sono state raccolte numerose esigenze dei clienti. Dopo aver aggiunto alcuni progetti di schermate e disegni di flusso, i programmatori potevano iniziare.

Gestione di clienti e vincoli #

Forse a causa dei severi vincoli di tempo del progetto o forse a causa dell’organizzazione piuttosto caotica del cliente, i progettisti avevano dimenticato di comprendere una componente fondamentale: l’amministrazione manuale. Il programma ha elaborato le domande. Poiché le applicazioni dovevano essere elaborate automaticamente, i programmatori hanno ritenuto che non sarebbe stata necessaria alcuna amministrazione umana. Anche questo criterio è stato omesso dalla progettazione funzionale.

Quando il programma è stato fornito per il test, il cliente ha scoperto che molte app presentavano eccezioni. Queste domande non possono essere elaborate automaticamente e devono essere gestite manualmente. Tuttavia, il programma funzionava in modo completamente automatico.

Il gestione del progetto a cascata richiede la verifica dell’effettivo esito del progetto al termine della fase di attuazione. Questo è un ritardo fase di sviluppo . Tra la fase di definizione, la fase di progettazione e la fase di attuazione possono passare mesi o anche più di un anno. Se si riscontrano difetti di progettazione in una fase avanzata del progetto, può essere costoso, se non impossibile, modificare il programma senza iniziare completamente un nuovo progetto. Dato che è praticamente impossibile definire tutti i criteri in anticipo, è auspicabile un approccio operativo che consenta di testare i risultati (intermedi).

Analisi dei requisiti #

Confrontando una serie di potenziali società di software, un cliente ha chiesto informazioni sulle possibilità. Una parte era titubante e ha messo in dubbio la fattibilità di molte delle richieste del cliente. La parte opposta era rappresentata da un agente di vendita aggressivo.

Quando un cliente ha chiesto informazioni sulla fattibilità di una richiesta specifica, l’addetto alle vendite ha chiamato i suoi programmatori. ‘Possiamo creare una funzione che esegua X?’ Il programmatore, che pensava principalmente in termini tecnici, diceva che tutto era teoricamente concepibile. Né il programmatore né il venditore erano preoccupati per gestione del progetto fattibilità (ad es. tempo, denaro, complessità e rischio).

L’eccitazione del rappresentante di vendita ha superato il contegno sobrio dell’altra parte. Il cliente ha selezionato l’offerta aggressiva del rappresentante di vendita. Il progetto appena acquisito è stato poi affidato a un project manager ea un team di programmatori.

Dopo un po’ di tempo è apparso chiaro che il progetto non era all’altezza delle aspettative del cliente. Ciò era in parte dovuto al fatto che le procedure erano molto più complesse per il cliente di quanto non sembrassero inizialmente. Durante un acceso scambio tra le due parti, il cliente ha affermato che il venditore «ha dichiarato che la funzionalità X non sarebbe stata un problema.