Le migliori applicazioni emergono quando utenti aziendali e sviluppatori lavorano insieme. Ma non è un connubio facile, per nessuna delle due parti. Gli utenti aziendali faticano a sapere di quali funzionalità possono aver bisogno finché non le vedono. Gli sviluppatori, invece, faticano a creare la soluzione perfetta senza aver sperimentato il problema in prima persona.
Questi problemi risultano esacerbati dai tradizionali approcci di sviluppo high-code, in cui gli analisti di business si trovano a fungere da traduttori tra gli utenti di business e i team tecnologici. I due domini sono separati l'uno dall'altro, il che significa che le persone che hanno un problema sono separate da quelle più equipaggiate per risolverlo: gli sviluppatori. Gli sviluppatori che cercano di comprendere appieno il problema sono ostacolati da canali di comunicazione a bassa fedeltà (ad esempio le e-mail), traduzioni imperfette, latenza, eccessivo affidamento alla documentazione e, cosa più dannosa di tutte, nessun accesso agli utenti finali.
Fortunatamente, esistono due semplici modi per colmare il divario tra sviluppatori e utenti aziendali.
1. Definire il problema giusto, capendo a fondo i propri utenti.
I team IT non dovrebbero mai prendere per buoni i requisiti degli utenti aziendali. Al contrario, è bene promuovere una cultura di domande aperte: invece di “La conformità è un problema?”, meglio chiedersi “Cosa succede se la conformità non è rispettata?”
Bisogna incoraggiare gli sviluppatori a indagare più a fondo, a chiedere “Perché?” e scoprire soluzioni non lineari. Questo processo ha inizio durante l'avvio del progetto – spesso chiamato Sprint 0 – con sessioni collaborative che includono IT, sponsor aziendali e utenti finali. Si deve lavorare insieme per definire gli obiettivi, esplorare ciò che l'applicazione deve fare per raggiungere quegli obiettivi e tracciare un piano per consegnare un prodotto di valore. L'intento non è quello di definire ogni dettaglio del progetto, ma di pianificare abbastanza bene da iniziare con il piede giusto.
Parla con gli utenti aziendali di queste cinque aree chiave:
- Vision: Cosa vuoi ottenere con l'applicazione?
- Stakeholders: Quali utenti finali e altre parti interessate ne beneficeranno?
- Bisogni: Qual è il problema o il bisogno che l'applicazione deve affrontare? Quali sono i punti critici, le strozzature e i benefici auspicati?
- Applicazione: Quali sono le funzioni e le caratteristiche indispensabili? Perché sono "must-have"? C'è una catena causale che collega la funzione a un obiettivo aziendale misurabile?
- Obiettivi aziendali: Quali sono gli obiettivi aziendali misurabili, in ordine di priorità?
Ricorda anche di valutare lo stato attuale dei tuoi utenti. Poiché la tua nuova applicazione cambierà il loro modo di lavorare, dovrai capire cosa vogliono fare i tuoi interlocutori e cosa li sta ostacolando. Il modo migliore per farlo è quello di "supervisionare l'ambiente" con utenti reali, guardandoli lavorare nella loro vita quotidiana. Se questo non è possibile, chiedi agli utenti di descrivere i propri processi quotidiani, concentrandosi sul perché eseguono ogni attività e quali sono le più grandi difficoltà che incontrano.
2. Mantenere un feedback veloce, continuo e chiaro.
Con le pratiche di sviluppo tradizionali, i cicli di feedback sono come un traghetto che viaggia tra due rive. Da una parte ci sono gli utenti aziendali, dall'altra gli sviluppatori che costruiscono l'applicazione. Si traghettano le informazioni avanti e indietro lentamente, in un processo ad alta latenza che rischia molte distorsioni.
Invece di trasportare il feedback avanti e indietro, bisogna cercare soluzioni e processi che costruiscano un ponte tra sviluppatori e utenti aziendali. Le piattaforme low-code, per esempio, favoriscono la collaborazione e incoraggiano input chiari e frequenti, cosa che aiuta a testare le ipotesi in corso d'opera per trovare la soluzione giusta.
L'aumento della collaborazione e lo sviluppo iterativo aiutano anche a ottenere un buy-in precoce da parte delle parti interessate. Anziché uno sviluppo isolato che genera tutto il valore alla fine del progetto, gli utenti finali possono approvare e influenzare l'applicazione proprio mentre prende forma davanti ai loro occhi. I prototipi e le versioni in corso di sviluppo danno agli utenti qualcosa di concreto su cui esprimersi, accelerando il processo di design e assicurando che il team di sviluppo abbia una chiara comprensione di ciò che serve.
Insidie comuni nello sviluppo di applicazioni
Le migliori piattaforme low-code aiutano i team IT a ottimizzare la collaborazione con gli utenti finali, fornendo anche una migliore funzionalità con team di sviluppo più versatili e agili. Se però esegui progetti low-code con approcci high-code, non potrai mai sfruttare appieno tutto il potenziale del low-code.
Per scoprire tutto il potere del low-code, abbandona gli approcci di sviluppo obsoleti e datati a favore di pratiche agili essenziali. Scopri quali sono le quattro insidie più comuni dello sviluppo di applicazioni low-code e come combatterle nel nuovo eBook: 4 insidie dello sviluppo di applicazioni low-code.
