Nessuno conosce i vostri processi meglio dei vostri addetti alle operazioni, quelli che fanno davvero il lavoro. Il tempo necessario per completare una specifica tecnica 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 programmazione. 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 cambiassero, o almeno si definissero chiaramente, le proprie aspettative?
Portare l'IT nella Red Zone
Le piattaforme di sviluppo software Low-Code e No-Code hanno lo scopo di consentire a persone con poca o nessuna esperienza di programmazione, dotate di una solida conoscenza dei processi supportati e delle funzionalità richieste, di costruire da sole le applicazioni necessarie. La differenza tra low-code e no-code fornisce il prossimo approfondimento necessario:
- "No" significa che non è necessario un programmatore
- " Low" significa che la necessità di assistenza da parte del programmatore è bassa.
Date queste caratteristiche, è probabile che gli strumenti no-code vengano utilizzati per creare semplici azioni o automazioni che non accedono ad alcuna risorsa di dati aziendali. Ciò include routine di workflow 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 programmazione 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 lungo il campo, vicino o dentro la zona rossa (che è all'interno della linea delle 20 yard, per chi non segue il football). Da lì, lo sviluppatore sarà in grado di portare la palla fino alla zona di fondo e consegnare un'applicazione completamente formata e conforme.
Chi sa cosa si nasconde nel cuore dei manager del dipartimento?
Uno dei vantaggi legati all'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 irregolarità 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 dei citizen developer possono fornire.
Quanto meglio si formano i responsabili di reparto, tanto maggiore sarà il carico di lavoro per lo sviluppo.
Una dose di realtà nell'impostazione delle aspettative
C'è una certa tentazione di prendere la piattaforma low-code più vicina, consegnarla al vostro miglior collaboratore 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 developer 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 non presente o per crearne una insolita; altri sono sistemi di processo completi ed esaustivi.
Poiché il numero dei citizen developer aumenterà di tre o quattro volte nei prossimi anni, le organizzazioni dovranno definire ogni fase di questo continuum, deciderne l'aspetto e 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 procedura per risolverlo. Per affrontare problemi più grandi e complessi occorreranno formazione e certificazione, e l'entusiasmo di lavorare con uno sviluppatore per completare il progetto.
Benvenuti alla Fase Uno del viaggio del citizen developer!
Di Howard M. Cohen