Raggiungimento dell'accordo sulla risoluzione del problema
Uno dei modi più semplici per raggiungere un accordo sulla definizione del problema è di scriverne una descrizione e di
accertarsi che sia da tutti concordata.
Chiedere al gruppo: Qual'è il problema?
-
E' molto comune procedere avventatamente nella definizione della soluzione, anziché prendere del tempo nel
comprendere prima il problema. Scrivere una descrizione del problema e accertarsi che tutti siano d'accordo sulla
definizione.
Quindi chiedere nuovamente al gruppo: Qual'è il problema realmente?
-
Individuare le cause principali oppure il "problema dietro al problema". Il problema reale si nasconde spesso
dietro quello che si percepisce come un problema.
Non accettare il primo resoconto di un problema. Domandarsi sempre "perché?" Esaminare la natura del problema.
A volte il gruppo può essere concentrato su una soluzione concepita che rende difficile, da parte loro, formulare quale
sia effettivamente il problema sottostante. In questi casi, può essere positivo esaminare i benefici della soluzione e
quindi tentare di individuare i problemi che vengono risolti da quei benefici. E' possibile quindi verificare se quei
problemi sono problemi "reali" nell'organizzazione. Le tecniche più comuni utilizzate per trovare il problema dietro al
problema sono: tecnica di stimolazione creativa, Diagrammi di
Fishbone e Diagrammi di Pareto.
|
Identificazione dei portatori d'interesse
A seconda della competenza del dominio del team di sviluppo, l'identificazione dei portatori d'interesse può essere una
fase superficiale o meno. Spesso, ciò riguarda l'intervista dei responsabili delle decisioni, dei potenziali utenti e
di altre parti interessate. Le seguenti domande sono utili:
-
Chi sono gli utenti del sistema?
-
Chi è l'acquirente finanziario per il sistema?
-
Chi altro sarà implicato dagli output che il sistema produce?
-
Chi valuterà e approverà il sistema quando è consegnato e distribuito?
-
Esistono altri utenti interni o esterni del sistema le cui necessità devono essere indicate?
-
Chi eseguirà la manutenzione del nuovo sistema?
-
Vi è qualche altra persona?
-
D'accordo, vi è qualche altra persona?
Sviluppare i profili dei potenziali (o effettivi) utenti del sistema. Le informazioni iniziali sugli utenti
chiave e sulla relativa ambiente devono essere riportate nel documento Visione.
|
Definizione dei limiti del sistema
Il limite del sistema definisce il confine tra la soluzione e il mondo reale che circonda la soluzione. In altre
parole, il limite del sistema descrive l'involucro in cui il sistema di soluzione è contenuto. Le informazioni, nel
formato di input e output, sono trasferite dal sistema agli utenti presenti all'esterno del sistema e viceversa. Tutte
le iterazioni con il sistema avvengono mediante le interfacce tra il sistema e il mondo esterno.
In molti casi, i limiti del sistema sono evidenti. Ad esempio, i limiti di un singolo utente, il responsabile del
personale di riferimento che utilizza Microsoft Windows®, sono relativamente ben definiti. Esiste un solo utente ed
un'unica piattaforma. Le interfacce presenti tra l'utente e l'applicazione sono costituite dalle finestre di dialogo
dell'interfaccia utente che l'utente accede per immettere le informazioni nel sistema e tutti i report di output ed i
percorsi di comunicazione che il sistema utilizza per documentare o trasmettere le informazioni risultanti.
|
Identificazione dei vincoli da imporre al sistema
Occorre considerare una varietà di fonti di vincoli. Di seguito è riportato un elenco di potenziali fonti e domande da
chiedere:
-
Politico: Esistono delle problematiche politiche interne o esterne che possono incidere sulle potenziali soluzioni?
Interdipartimentale?
-
Economico: Quali vincoli finanziari o budgetari sono applicabili? Esistono dei costi sui beni venduti oppure delle
valutazioni sui prezzi del prodotto? Vi sono delle problematiche sulla concessione di licenze?
-
Ambientale: esistono dei vincoli ambientali o regolatori? Legali? Altri standard a cui si è vincolati?
-
Tecnico: La scelta delle tecnologie è limitata? Il lavoro da svolgere è vincolato dall'utilizzo di piattaforme o
tecnologie esistenti? Non è consentito l'uso di eventuali nuove tecnologie?
-
Fattibilità: La pianificazione è definita? E' limitato l'uso alle risorse esistenti? Si può utilizzare la
manodopera esterna? E' possibile ampliare le risorse? Temporanee? Permanenti?
-
Sistema: La soluzione deve essere realizzata sui sistemi esistenti in uso? E' necessario preservare la
compatibilità con le soluzioni esistenti? Quali sistemi operativi e ambienti occorre supportare?
|
Formulazione della specifica del problema
Insieme all'intero gruppo, lavorare sulle lavagne a cavalletto e riempire la seguente maschera per ogni problema che è
stato identificato:
Il problema del <descrivere il problema>
implica <i portatori d'interesse implicati dal problema>.
Il cui impatto è <quale sia l'impatto del problema>.
Una soluzione ottimale sarebbe <elencare alcuni vantaggi chiave di una soluzione ottimale>.
Lo scopo di questo modello è di distinguere le soluzioni/risposte dai problemi/domande.
Esempio:
Il problema di: l'intempestiva e inappropriata risoluzione delle problematiche dell'assistenza clienti
implica: i clienti, i rappresentanti dell'assistenza clienti ed i tecnici dell'assistenza.
Il cui impatto è: insoddisfazione del cliente, mancanza di qualità percepita, impiegati non soddisfatti e
perdita di ricavo.
Una soluzione ottimale sarebbe: fornire l'accesso in tempo reale ad un database per la risoluzione dei problemi
mediante i rappresentanti del supporto e facilitare la presenza dei tecnici, in modo tempestivo, soltanto nei luoghi
che necessitano effettivamente della loro assistenza.
|
Definizione delle funzioni del sistema
Sulla base dei benefici elencati nelle specifiche del problema, sviluppare un elenco di funzioni che si desiderano
avere sul sistema. Fornire una breve descrizione e assegnare gli attributi che aiutano a definire il loro stato
generale e priorità nel progetto.
|
Valutazione dei propri risultati
In questa fase occorre controllare la visione e accertarsi che il lavoro svolto sia nei tempi previsti, ma non
revisionarla in dettaglio. Considerare l'elenco di controllo per il documento di visione (Elenco di controllo: Visione).
|
|