Progettazione della soluzione
Dopo aver separato le funzionalità necessarie da quelle utili, è possibile iniziare a progettare la soluzione.
Considerare uno scenario in cui si è parlato con il responsabile marketing del cliente. Si è appreso tutto ciò di cui il responsabile ha bisogno nel nuovo sistema e si è progettato l'intero sistema in base alle sue esigenze. A seguito della dimostrazione del nuovo sistema, gli altri addetti al marketing si dichiarano insoddisfatti dell'intero sistema perché non li aiuta nel loro lavoro. Il motivo per cui questo sistema non può funzionare è perché si basa sulle esigenze di un unico utente.
Se si parla con un solo utente invece che con tutti o con la maggior parte di essi, si rischia di non ottenere un quadro completo. Progettare un sistema per gli utenti significa coinvolgerli nell'intero processo. Non è possibile progettare una soluzione in base a una sola riunione, crearla in base ai propri progetti e poi distribuirla a tutti gli utenti. Ad esempio, se si sta progettando una soluzione finanziaria ma gli utenti non sono contabili, sarà necessario trovare un modo per progettare una soluzione che tutte le persone possano capire e usare.
L'approccio migliore sarebbe quello di determinare prima le categorie ovvie di utenti e poi parlare con alcuni di ciascun gruppo. Ad esempio, alcuni utenti potrebbero gestire le nuove richieste, mentre altri le modifiche. Ciascuna categoria di utenti potrebbe avere esigenze diverse e usare metodi diversi per svolgere il proprio lavoro e tutto ciò andrà considerato nella progettazione. Successivamente, è necessario prendere in considerazione le persone che usano la soluzione legacy da molti anni rispetto ai neoassunti che non hanno acquisito la stessa esperienza né metodi di uso più rapidi. Ogni utente può offrire informazioni approfondite che saranno utili alla progettazione della nuova soluzione.
Ogni app Dynamics 365 prevede processi aziendali che esegue in un determinato modo. È possibile personalizzare ogni app per soddisfare molti requisiti aziendali diversi. Tuttavia, in alcune occasioni l'approccio attualmente usato da un utente per eseguire un'attività potrebbe non essere ottimale quando applicato a Dynamics 365. Per personalizzare Dynamics 365 affinché funzioni nel modo in cui l'utente ha lavorato con il proprio sistema legacy, potrebbe essere necessario eseguire estese attività di personalizzazione e di sviluppo ad hoc. Sebbene l'ideale sia ridurre al minimo le modifiche al modo in cui un utente svolge le proprie attività, a volte il cambiamento è necessario.
Si immagini, ad esempio, di avere apportato alcune modifiche al modo in cui un utente svolge il proprio lavoro e che ciò abbia determinato una riduzione al minimo dello sviluppo personalizzato necessario. Questo approccio sarebbe comunemente preferibile rispetto a quello di progettare in base al modo in cui un utente ha completato il lavoro in precedenza. Questo esempio mostra quanto sia importante esaminare un problema dal punto di vista di un utente e dal punto di vista dell'azienda e del creatore o sviluppatore di app.
La progettazione dovrebbe massimizzare il vantaggio da tutti e tre i punti di vista:
Punto di vista dell'utente: l'utente desidera una soluzione intuitiva e più simile possibile al modo in cui ha svolto il suo lavoro finora.
Punto di vista dell'azienda: l'azienda desidera produttività più elevata e maggiore fidelizzazione dei clienti.
Punto di vista del creatore di app: il creatore di app desidera una soluzione implementabile con la quantità minima possibile di codice personalizzato.
Considerando ogni punto di vista nella progettazione della funzionalità, si potrebbe scoprire che il progetto si è orientato verso la soluzione più vantaggiosa.
Molti consulenti sanno che, nella creazione di nuove soluzioni, dovranno valutare i progetti con gli utenti. Riesaminare i progetti della soluzione ancora una volta è più economico che doverla realizzare nuovamente. Assicurarsi di esaminare la soluzione insieme agli utenti più volte. Iniziare creando un progetto di base, fondandolo su quanto riportato dagli utenti. Quindi, esaminare questo progetto di base insieme agli utenti e aggiornarlo secondo il feedback ricevuto. È possibile ripetere questo ciclo in modo continuo fino a ottenere un progetto del quale tutti siano soddisfatti.
È inoltre necessario considerare la quantità di risorse necessarie per implementare il progetto. Stimare tutte le attività e determinare cosa è possibile implementare in base al budget e al tempo del cliente. Questo approccio viene spesso definito il triangolo di gestione del progetto. Non è mai possibile modificare un lato senza influire sugli altri due. Se l'ambito è più ampio, così devono essere anche gli altri due lati.
Quando si progetta un sistema, è necessario essere consapevoli del budget, del tempo e delle risorse disponibili in modo da poter definire un ambito appropriato. Questi tre elementi non possono funzionare l'uno senza l'altro ed è necessario considerarli insieme. Se si dispone di 25 risorse a lavoro su un progetto, è possibile ampliare l'ambito se si dispone anche di un budget significativo. Non è possibile avere un ambito ampio se il budget e le risorse disponibili non sono sufficienti per eseguire quel progetto. Se c'è bisogno di un nuovo sistema entro la fine dell'anno, è necessario modificare l'ambito e/o il budget di quel progetto. Anche quando si progetta un sistema specifico per utenti specifici è necessario tenere conto di questo fattore. Se una funzionalità è fondamentale per gli utenti, è necessario assegnarle la priorità. Progettare per gli utenti non significa ignorare budget, tempo o risorse. Significa creare il miglior sistema possibile in base alle esigenze dell'utente nei limiti dati da budget, tempo e risorse.
Per facilitare la comprensione del progetto della soluzione agli utenti, è possibile creare utenti tipo immaginari, che presentino le seguenti caratteristiche:
Deve trattarsi di utenti tipici.
Non devono essere utenti reali ma risultanti da una combinazione fittizia di utenti delle diverse sezioni.
Deve trattarsi di persone immaginarie in cui gli utenti reali possano immedesimarsi.
Devono essere correlati a una storia in un modo comprensibile agli utenti reali.
Un altro modo per assicurarsi che gli utenti comprendano il contenuto del progetto è usare uno scenario. Uno scenario usa l'utente tipo creato per raccontare una storia che descrive le varie funzionalità. Ad esempio, la storia di una normale giornata del Contabile potrebbe includere le seguenti informazioni:
Tutte le attività che il contabile svolge nell'ambito delle sue mansioni
Una descrizione di tali attività
I sistemi che il contabile usa
Uno scenario può includere anche l'ipotesi migliore o l'ipotesi peggiore. La progettazione dovrà gestire tutte le diverse possibilità.
Infine, la progettazione può includere i casi d'uso. Un caso d'uso è la storia del modo in cui una persona che esegue un processo specifico raggiunge un obiettivo. Nel caso del contabile, il caso d'uso può riguardare il modo in cui inviare gli stipendi a tutti i dipendenti. I casi d'uso aiutano a decidere e spiegare quali processi importanti devono essere presenti in una soluzione, oltre a decidere cosa è necessario fare. I casi d'uso non devono solo considerare lo scenario ideale, il cosiddetto percorso senza ostacoli. Al contrario, assicurarsi di creare casi d'uso per il percorso senza ostacoli e per percorsi alternativi in caso si verifichino problemi. È importante prepararsi agli errori così come alle situazioni in cui tutto funziona come previsto.
Quando si inizia a stilare il progetto, occorre tenere presenti diverse considerazioni. È necessario scrivere il documento in modo che sia comprensibile agli utenti. Non serve complicare il progetto o usare un gergo complesso che gli utenti potrebbero non capire. Scrivere il documento di progettazione nello stesso modo in cui si creerà la soluzione: pensando agli utenti. Gli utenti dovrebbero essere in grado di leggere il documento e trovarvi tutto ciò di cui si è discusso in precedenza, senza nessuna sorpresa. È fondamentale che gli utenti comprendano il documento di progettazione in modo che possano fornire adeguato feedback al riguardo.