Conosci il tuo “cliente" non è solo un principio chiave del marketing e delle vendite, ma è altrettanto importante per lo sviluppo del software. Nonostante l'approccio iterativo e agile adottato nei progetti software di oggi, non sempre viene affrontata la fase di user research in cui vengono identificate le reali necessità degli utilizzatori del prodotto finito. È fondamentale gettare le basi di un'applicazione software prima di dare il via al progetto. Da qui la fase di Foundation di Cegeka: una serie di workshop che si avvalgono della metodologia del Design Thinking per capire in profondità sia l’organizzazione del cliente che le esigenze degli utenti (user needs).
Dalla richiesta alla proposta, in 4 step:
Può sembrare banale, ma il primo passo per un progetto di qualunque tipo è quello di identificare i driver di business di alto livello. Perché si pensa di affrontare il progetto, quali sono gli obiettivi e quali le priorità?
Alcuni progetti non hanno successo proprio perché non tengono in considerazione le esigenze degli utenti: non si conosce come lavorano o quali sono le difficoltà che incontrano. Il più delle volte le specifiche vengono fornite da persone che non saranno gli utilizzatori finali ma che “pensano” di avere una visione completa ed approfondita delle attività quotidiane degli utenti. Altre volte, non si tengono in opportuna considerazione i differenti ruoli e le conseguenti necessità degli utenti finali, per cui si costruiscono applicazioni basate su requisiti parziali, che risultano inefficaci e costringono gli utenti a sviluppare pratiche “fuori sistema”.
Proprio per questi motivi per Cegeka diventa sempre più importante l’utilizzo di strumenti come le personas e i customer journey.
Nella prima fase di Foundation, si identificano le diverse categorie di utenti: le personas.
Successivamente vengono mappati i percorsi (journey) che gli utenti seguono quando interagiscono con il software esistente, e l’insieme delle loro attività al fine di tradurle in una nuova soluzione che garantisca la migliore esperienza utente.
Le domande più frequenti che in questa fase permettono di dare il via alla discussione sono:
Alla conclusione di questa fase saranno chiare l’organizzazione del cliente e le necessità del progetto. Questo permetterà a Cegeka di supportare il cliente in tutte le scelte da compiere durante il progetto, diventando partner dell’iniziativa e non limitandosi a restare un semplice fornitore.
Le informazioni raccolte nello step precedente saranno elaborate e trasformate nella descrizione delle caratteristiche richieste al software: i requisiti funzionali. Accanto a questi vengono definiti anche i requisiti non funzionali, ossia gli attributi “di qualità” della soluzione come la scalabilità e le prestazioni desiderate. Sulla base di queste analisi viene individuata l'architettura e lo stack tecnologico più appropriato.
Esempi di domande che ci si pone in questa fase sono:
Tutte le caratteristiche identificate in questo step sono elencate nella "features map".
Ogni funzionalità (feature) è elencata, dettagliata, prioritizzata e raggruppata in componenti relativi “contenitori”; contestualmente vengono definiti i requisiti non funzionali ed i diagrammi di contesto.
Questi documenti serviranno come linee guida e punti di riferimento per lo sviluppo: dal primo giorno fino alla conclusione del progetto software.
Scrivere i requisiti non funzionali è un'attività essenziale, ma viene spesso dimenticata quando si prepara un progetto software. I clienti possono dare per scontate caratteristiche come le prestazioni e la sicurezza, assumendo che siano inerenti ad ogni applicazione. Hanno ragione, naturalmente, ma solo fino ad un certo punto. Fattori come le necessità del progetto, le restrizioni di budget, la politica aziendale, i regolamenti e molto altro ancora, influenzano la scelta di investire (o meno) in un qualsiasi requisito non funzionale. Non è un compito facile. Eccedere nel tentativo di soddisfare il maggior numero di requisiti non funzionali potrebbe rendere la soluzione troppo costosa e irrealizzabile. Sottovalutarli o ignorarli potrebbe compromette drasticamente la qualità della soluzione. Saranno quindi necessari dei compromessi. In Cegeka abbiamo l'esperienza necessaria per aiutare i nostri clienti a fare le scelte giuste.
Step 3: Stabilire il prezzo
Il budget definitivo di progetto viene creato solo quando tutti i requisiti di cui sopra sono stati identificati. Con i nostri professionisti suddividiamo le attività progettuali in sotto-attività che vengono quotate con un numero di giorni uomo associato. Vengono poi valutate le necessità di governance, di Unit Test (i test svolti dal gruppo di progetto) e test di integrazione, preparazione degli ambienti, rilasci, supporto post rilascio nonché la contingenza per coprire eventuali imprevisti che potrebbero verificarsi durante lo sviluppo.
Alla fine della fase di Foundation, redigiamo una roadmap concreta del progetto che specifica la timeline, i rilasci, la composizione del gruppo di sviluppo, la necessità del coinvolgimento di altri profili come esperti di sicurezza, UX/UI, esperti dell’ambito, ecc.
La fase di Foundation richiede un lavoro di squadra e, idealmente, segna l'inizio di una partnership di successo e a lungo termine. Per comprendere appieno i vostri bisogni e desideri, un team interdisciplinare di Cegeka - composto da un project manager, esperti di dominio, sviluppatori, ecc. - ascolta e parla con il vostro business così come con il personale IT. Naturalmente, manteniamo questo dialogo durante tutto il progetto per garantire che il software risultante superi le vostre aspettative.
La fase di Foundation richiede un lavoro di squadra e, idealmente, segna l'inizio di una partnership di successo e a lungo termine.