Nessuno conosce i vostri processi meglio dei vostri addetti alle operazioni, quelli che fanno davvero il lavoro. Il tempo necessario per completare una specifica funzionale lo dimostra forse meglio di qualsiasi altra cosa. Se solo gli addetti alle operazioni potessero creare da soli le applicazioni. Hmmm....
L'ostacolo, ovviamente, è la necessità di una persona appositamente formata e con le competenze naturali necessarie per gestire la complessità della codifica. Ma c'è una forte carenza di queste persone, come dimostra il divario globale di competenze nel settore IT: quattro milioni di posti di lavoro non coperti.
Ma cosa succederebbe se si spostassero, o almeno si definissero chiaramente, le proprie aspettative?
Portare l'IT nella zona rossa
Le piattaforme di sviluppo software low-code e no-code sono progettate per permettere alle persone con poca o nessuna esperienza di programmazione, ma con una buona comprensione dei processi e delle funzionalità necessarie, di creare autonomamente le applicazioni richieste. La differenza tra low-code e no-code fornisce il prossimo approfondimento necessario:
- "No" significa che non è necessario un programmatore
- "Low" significa bassa necessità di assistenza da parte del programmatore.
Date queste caratteristiche, è probabile che gli strumenti no-code debbano essere utilizzati per creare semplici azioni o automazioni che non accedono ad alcuna risorsa di dati aziendali. Ciò include routine di flusso di lavoro per supportare una migliore collaborazione tra i reparti e automatizzare semplici attività, come l'invio di vari promemoria o la trasmissione di autorizzazioni.
Quando un citizen developer presenta un progetto creato con strumenti low-code, si deve prevedere che l'applicazione richiederà l'esame e la regolazione da parte di qualcuno con esperienza di codifica che abbia anche familiarità con la governance richiesta quando si accede alle risorse di dati aziendali.
Se questa aspettativa è condivisa e anticipata da tutti i membri dell'organizzazione, il citizen developer può muovere la palla fino all'area di rigore. Da lì, lo sviluppatore sarà in grado di fare goal e consegnare un'applicazione completamente formata e conforme.
Quale demone si nasconde nei cuori dei manager di dipartimento?
Uno dei vantaggi collaterali dell'adozione del low-code/no-code è che può contribuire a eliminare lo Shadow IT. Identificate i vostri rinnegati e offrite loro una formazione su una piattaforma low-code. Impegnatevi ad affiancarli a sviluppatori che possano garantire qualità e conformità, smussando al contempo le asperità dell'applicazione. Questo è ottimo per i responsabili di reparto; li aiuta a sentirsi ben supportati
È ottimo anche per gli sviluppatori, perché il loro carico di lavoro è stato ridotto da ciò che i manager dei dipartimenti degli Citizen Developers possono fornire.
Quanto meglio si formano i responsabili dei dipartimenti, maggiore sarà il carico di sviluppo che saranno in grado di alleggerire.
Una dose di realtà nella definizione delle aspettative
C'è una certa tentazione di prendere la piattaforma low-code più vicina, consegnarla al vostro miglior utente e dirgli di riprogettare l'intero ERP aziendale. Non è impossibile, ma non è realistico.
Sebbene lo sviluppo di soluzioni low-code/no-code sia iniziato negli anni '70, è solo di recente che il vero valore di questa pratica è stato riconosciuto e ha iniziato a diffondersi. Gartner prevede che entro il 2024 l'80% delle applicazioni sarà creato con strumenti low-code/no-code!
Ciò suggerisce che molte delle piattaforme low-code e no-code sono nelle prime versioni in attesa di ulteriori sviluppi. Allo stesso modo, gli utenti sono nelle prime fasi di utilizzo di questi strumenti e necessitano di maggiore esperienza e formazione prima di poter affrontare con successo sfide più complesse.
Quando si definiscono le aspettative per gli stakeholder e gli utenti, si parte da un vantaggio: probabilmente si riduce il carico di lavoro dei programmatori del personale. Non sottovalutate mai il tempo necessario a un nuovo utente che lavora con una nuova piattaforma per produrre un risultato valido. Siate onesti sui tempi. Man mano che si procede, questi tempi diventeranno sempre più brevi.
Ricordate agli stakeholder e agli utenti che il citizen developer che inizia il progetto ha una conoscenza approfondita dei processi e delle procedure coinvolte, il che dovrebbe migliorare significativamente l'allineamento tra le loro esigenze e il design della nuova applicazione.
Inoltre, i citizen developer farebbero bene a coinvolgere i loro colleghi nel processo. Far loro vivere un'esperienza più diretta con gli strumenti low-code/no-code darebbe loro la possibilità di sviluppare un maggiore apprezzamento per il lavoro, l'impegno e il tempo necessari per realizzare un'applicazione di qualità.
Quando si interfacciano con gli stakeholder, gli utenti e il proprio management, i Citizen Developers dovrebbero suddividere le loro stime di tempo in fasi. Magari iniziando con una fase di "identificazione del problema" che coinvolga l'intero reparto interessato. A questa potrebbe seguire una documentazione dettagliata dei processi e delle procedure coinvolte. Poi si potrebbe usare la piattaforma low-code per generare la maggior parte dell'applicazione. Infine, lo sviluppatore potrebbe rivedere l'applicazione risultante e apportare le eventuali modifiche necessarie. Stabilire un tempo previsto per ciascuna di queste fasi è più preciso che indicare semplicemente una stima dei tempi dall'inizio alla fine.
Regole diverse per strumenti diversi
Lo sviluppo di applicazioni utilizzando piattaforme low-code/no-code esiste in una sorta di continuum. Alcuni processi si riducono a semplici aggiunte al software esistente per fornire una funzione lasciata in disuso o per crearne una rara; altri sono sistemi di processo completi ed esaustivi.
Poiché il numero di Citizen Developers aumenterà di tre o quattro volte nei prossimi anni, le organizzazioni devono definire ogni fase di questo continuum, decidere come deve funzionale ed assegnare regole e procedure specifiche per ciascuna di esse. Idealmente, ogni dipendente che identifica un problema semplice dovrebbe essere messo in grado di creare una semplice routine per risolverlo. Affrontare problemi più grandi e complessi richiederà formazione e certificazione, e l'entusiasmo di lavorare con uno sviluppatore per completare il progetto.
Articolo scritto da: Howard M. Cohen