Metodologia

Il mondo della consulenza informatica non gode sempre di ottima reputazione. Le aziende spesso assistono a ritardi nella progettazione per poi scoprire che l'implementazione non rispecchia i requisiti di business.

I progetti di sviluppo in ambito aziendale nascono per supportare una o più aree di business ed implicano una conoscenza profonda della realtà aziendale. Demandare alla consulenza esterna la gestione di questi progetti comporta il rischio di ottenere soluzioni parzialmente valide con impatti non graditi e non previsti durante le fasi preliminari; effetti negativi che possono propagarsi in aree non direttamente coinvolte.

Un errore di analisi ricorrente consiste nel credere che il committente sia anche il destinatario della soluzione.

Gli utenti vengono spesso coinvolti sul progetto solo marginalmente, durante le fasi di test o di training.
Pensiamo invece che sia necessario coinvolgere i destinatari della soluzione fin dalle fasi di assessmet chiedendo loro di ricoprire un ruolo attivo fino alla chiusura del progetto.

lo sviluppo secondo more

Nel modello esiste una stretta correlazione tra commitment, development ed usability. I nostri progetti prevedono la stretta collaborazione di aree aziendali:

  • Executive Area - ovvero il soggetto committente nel cui interesse la soluzione viene sviluppata. Gestisce le risorse e definisce il perimetro di applicazione.
  • Development Area - il team di sviluppo che può essere interno oppure esterno all'azienda. Si occupa di sviluppare la soluzione secondo quanto dettato dall'esecutivo.
  • User Area - costituita dai destinatari della soluzione è chiamata a guidare lo sviluppo in base ai requisiti funzionali.

Volendo rappresentare graficamente le relazioni esistenti tra le aree potremmo utilizzare un triangolo:

Il rapporto tra le aree

Il giusto equilibrio tra le parti è rappersentato da un triangolo equilatero dove tutti i lati hanno la stessa lunghezza. Il prevalere degli interessi di una area volge a discapito delle altre:

Esempi

In more, per raggiungere gli obiettivi, adottaiamo una metodologia dinamica basata su modelli semplici. Grazie a questo approccio riusciamo a tenere sotto controllo i tempi ed i costi.

Quando si pensa ad un progetto di grandi dimensioni si tende a fare analisi molto approfondite con l'intenzione di prevedere tutti gli impatti che lo sviluppo avrà sui processi aziendali, senza lasciare nulla al caso. Il tentativo di avere una vision molto lunga consuma molte risorse e di fatto non è quasi mai precisa. Se i tempi di sviluppo sono lunghi e vi sono numerose funzionalità da implementare, gli obiettivi possono fallire perché nel frattempo i processi evolvono e le esigenze cambiano.

Un approccio alternativo consiste nel dividere l'implementazione in step partendo dalle funzionalità di base procedendo per obiettivi intermedi. In questo modo si ottengono più cicli di test, consolidamento ed analisi con una vision più vicina alla realtà . Ogni volta che uno step si conclude, si può valutare quali altre funzionalità implementare senza correre il rischio di trovarsi fuori rotta.

I quattro step del ciclo di sviluppo

Nel modello vengono identificati quattro step per lo sviluppo:

  • Vision - Anima della progettazione. Decidere lo scopo ultimo dell'applicativo o di una o più funzionalità .
  • Planning - Considerare tutti gli elementi in gioco, dall'utente agli strumenti per l'implementazione. Il grado di dettaglio dipende dall'oggetto della previsione (vision).
  • Development - Lo sviluppo del software deve rimanere nel perimetro dettato dalla pianificazione altrimenti si rischia di finire fuori strada (tempi lunghi o funzionalità parzialmente valide).
  • Consolidation - Gli utenti (beta tester) sono chiamati a verificare che l'implementazione risponda alle richieste dettate dalla previsione.

Gli step dello sviluppo

Alla fine di un ciclo si potrà decidere quali funzionalità implementare, quali tenere in secondo piano (nice to have) e quali rinviare ad implementazioni future. Da un altro punto di vista, lo sviluppo per step successivi consente al management di sospendere i lavori avendo comunque un prodotto pienamente funzionante nelle parti di primaria importanza.

I cicli