Ciao a tutti, mi trovo in una situazione un po’ strana e volevo condividere. Ho sempre lavorato come project manager tradizionale, ma ultimamente il mio team mi sta spingendo a provare a costruire piccole applicazioni interne da solo, senza coinvolgere gli sviluppatori per ogni modifica. Ho iniziato a sperimentare con alcuni strumenti visuali e devo dire che vedere qualcosa funzionare è gratificante, ma allo stesso tempo mi sento come se stessi barando o scavalcando delle competenze che non ho. Qualcuno si è mai sentito così quando ha iniziato ad approcciare lo sviluppo software con piattaforme low code? Mi chiedo se questa sensazione di “frode” passi con l’esperienza o se sia un segnale che sto sbagliando strada.
|
Cosa capire per usare il low-code senza sentirsi un impostore?
|
|
Capisco la sensazione di frode che nasce quando qualcosa funziona grazie al low code. È normale quando si viene dal PM tradizionale e si vede un piccolo pezzo di software nascere senza chiedere cambi agli sviluppatori. Forse la domanda è se questa possibilità cambia davvero chi siamo come professionisti o è solo una scorciatoia temporanea?
Dal punto di vista analitico la sensazione di frode spesso riflette un mismatch tra le aspettative e la realtà operativa. Il low code non elimina la progettazione, la gestione delle integrazioni o la governance. Potrebbe essere utile definire limiti, regole di test e una checklist di approvazioni per le modifiche.
Potresti stare scoprendo che con il low code non si elimina la responsabilità, si sta solo spostando la magnitudine del lavoro. Parte dell valore arriva dall'idea e dalla quantità di dati, non dal tasto magico. Non è una frode, è una ridefinizione di dove si concentra l'impegno.
Non vedo una frode in quello che fai, vedo invece una fase di transizione che mette alla prova limiti e budget. Se ti illudi che tutto si possa fare senza pensare all'architettura, prima o poi arriverà la verifica. Lo strumento non sostituisce la disciplina. low code.
Forse conviene riformulare il problema non è se sia lecito usare low code ma quali principi guidano la scelta tra prototipazione rapida e manutenzione a lungo termine. Quali criteri di successo e di controllo vuoi adottare per le modifiche?
C'è anche la dimensione del shadow IT che emerge con il low code, è un concetto che va governato per evitare duplicazioni o rischi di sicurezza, ma non è una condanna. A volte basta distinguere chi è proprietario della parte tecnologica e come si gestiscono le dipendenze. Hai già pensato a come tracciare le modifiche?
|
|
« Precedente | Successivo »
|

