I segreti per un software di successo - Step 1: inizia ad individuare i business drivers

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:

Step 1: Identificare i driver business driver: obiettivi e attori coinvolti

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:

• Perché avete bisogno di un nuovo software: qual è il problema che l'applicazione software deve risolvere?
• Quale processo la nuova soluzione deve assolvere e come la stessa attività viene svolta oggi?
• Chi userà l'applicazione? Quali sono i loro bisogni, aspettative e punti di contatto?
• Con quali sistemi interagirà il software (applicazioni aziendali legacy, archivi di dati, data warehouse, sistemi esterni, servizi cloud, ecc.)
• Cosa deve includere la soluzione - e cosa no?

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.

Step 2: Definire l’ambito di progetto: funzionale, non funzionale, contesto e requisiti tecnici

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:

• Cosa deve offrire il sistema ai propri utenti - quali sono le caratteristiche necessarie (funzionali)?
• Quali criteri devono essere soddisfatti?
• Qual è il Minimal Viable Product, l'insieme minimo di caratteristiche che è assolutamente necessario avere per creare un primo impatto?
• Quali sono i requisiti critici non funzionali, cioè come dovrebbe funzionare il sistema in termini di prestazioni, scalabilità, disponibilità, sicurezza, affidabilità, interoperabilità, manutenibilità, ecc. (non funzionali)?
• Qual è il contesto del progetto: il panorama delle applicazioni, i casi d'uso, eventuali benchmark ecc.

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.

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.

Step 4: Definire la roadmap

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.