Questo articolo l'hanno scritto loro. Cinque tirocinanti, due mesi, zero esperienza, un prodotto vero. Noi l'abbiamo riletto solo per la chiarezza: non abbiamo tolto niente, la nostra parte è in fondo, dopo la loro.
Il 15 giugno pensavamo che organizzare un progetto significasse assegnare attività, rispettare delle scadenze e portare a termine il proprio lavoro. Abbiamo completato numerosi project work in classe grazie alle conoscenze tecniche imparate ma non ci era mai stata insegnata una metodologia da seguire. Durante questi progetti in classe ognuno prendeva una parte (chi il design, chi il codice, chi l'esposizione), se la vedeva da solo con qualche feedback del gruppo e alla fine delle 2 settimane di progetto si univa il tutto sperando che fosse coerente.
Qui, durante i 2 mesi di tirocinio, abbiamo applicato una metodologia che non avevamo mai usato: Scrum.
Il valore della comunicazione in un gruppo non si impara con un semplice corso o con un meeting. Certo, possono essere utili per darti una base, ma la vera conoscenza arriva da ore passate a lavorare per poi non avere risultati concreti. Questo ci è successo varie volte durante i nostri due mesi di lavoro:
Il 22 luglio Roberto e Alessandro hanno scritto la documentazione di una feature due volte senza saperlo. Risultato? Due documenti diversi, derivati da due idee diverse, tempo sprecato: un'ora a testa. Potrebbe non sembrare tanto, ma se si sommano questi piccoli errori alla fine di una sessione di lavoro il risultato cambia: una feature in più poteva essere integrata, un mockup in più poteva essere disegnato.
Non ci è voluto tanto prima di sbattere la testa la prima volta su un errore che sarebbe potuto essere evitato seguendo un metodo. Poi è successo di nuovo. Ma ad ogni errore comprendevamo un tassello in più, fondamentale per la nostra formazione di lavoratori.
Fino ad ora abbiamo parlato di comunicazione tra i membri del team, ma per quanto riguarda il cliente cosa abbiamo imparato?
Il progetto ha un vero cliente e relazionarsi con lui è stato fondamentale. Durante i vari project work in classe, data la loro breve scadenza o la mancanza di un cliente reale, non si è potuto instaurare un rapporto di fiducia con lui e questo ha portato alla mancanza di un feedback costante, cosa fondamentale che invece è accaduta durante il lavoro:
Il mattino del 2 luglio siamo andati per la prima volta nella sede del cliente per mostrare quello che avevamo costruito nel primo mese di lavoro. Nelle settimane precedenti abbiamo fatto varie presentazioni del prodotto, ma solo tra colleghi in azienda con l'obiettivo di farci fare esperienza con l'ambiente. Abbiamo presentato la prima versione del nostro prodotto e abbiamo accolto tutti i dubbi, proposte e idee del nostro cliente. Ha riscosso molto successo una feature del prodotto in cui si dava la possibilità di notificare gli aiuti ricevuti dai propri colleghi, cosa che in quel momento per noi risultava marginale rispetto alle altre funzioni. Questa esperienza ci ha insegnato che una feature che potrebbe non avere molto valore rispetto ad altre in realtà potrebbe nascondere delle potenzialità che senza il cliente non avresti mai notato. Da quello spunto abbiamo fatto un brainstorming per capire come migliorare quella funzione, insieme alle molte altre che hanno riscosso successo.
Per riassumere la nostra esperienza: all'inizio il concetto di Scrum per noi tirocinanti sembrava solo una serie di parole e concetti da imparare, con un'applicazione che "può portare risultati ma non è così impattante", invece si è rivelato fondamentale non solo per il prodotto finale ma anche per noi come squadra che doveva ancora imparare ad esserlo.
Eppure prima di tutto questo credevamo di lavorare bene, pensavamo: "Il lavoro lo abbiamo portato a casa", ma con quale organizzazione? Bisogna sempre mettersi in dubbio, non bisogna mai innamorarsi della propria idea, bisogna confrontarsi tra team e persone esterne. Questa è la formula che porta ad un lavoro ben fatto e non ad un mappazzone.
A giugno non avrei mai immaginato di avere le capacità di creare un prodotto ed in effetti non ce le avevo, ero semplicemente un ragazzo a cui piacevano i videogiochi e che puntava a crearne uno.
"Dove sono i mockup?" Il 17 luglio durante la presentazione settimanale mi è stata fatta questa domanda, ed io ho risposto che non avendo in mente i limiti tecnici del software non li avevamo preparati. Panico. «Senza un progetto completo non si va da nessuna parte», ci hanno detto. Fino a quel momento eravamo andati avanti senza un vero metodo di lavoro sul prodotto. Guardavo lo schermo e nel plugin da noi creato mancava effettivamente uno studio del design.
Sbagliando ci siamo fidati delle nostre teste e delle nostre idee non scritte per lavorare e lasciavamo fare il resto all'intelligenza artificiale che sì, può facilitare e accelerare il lavoro, ma senza un'idea scritta e ben dettagliata prende troppe licenze poetiche per compiere il suo lavoro.
Da lì Michele ci ha insegnato la procedura corretta da applicare (analisi, documentazione, design, implementazione e test). Ne sono rimasto un po' sorpreso, non capivo quali grandi differenze avrebbe apportato il cambio di metodologia se il prodotto era funzionante. Ho deciso di seguire il consiglio e la confusione che prima ritenevo normalità è sparita.
Abbiamo cominciato a fare reverse engineering di quello che era stato già creato per scrivere una documentazione più dettagliata, mentre i documenti dei nuovi componenti hanno seguito un template standard. Da quella documentazione abbiamo creato le prime bozze delle schermate e dopo quello abbiamo trasferito tutto nel codice.
La creazione di nuove schermate dall'analisi ai test impiegava mezza giornata in meno dopo il cambio del metodo. Questo mi ha fatto capire non solo che avere un progetto chiaro dall'inizio semplificava l'aggiornamento del prodotto ma anche che l'essere aperti al cambiamento può essere complicato all'inizio ma può portare risultati che non immaginavi.
Il plugin creato sicuramente non è un videogioco ma riprende molti concetti che provengono da quel mondo ed il processo per farlo è paragonabile ad un rage game che dopo tanta rabbia e frustrazione per finire un livello porta tanta soddisfazione.
Ero una neo diplomata, arrivavo da un contesto in cui ero l'unica ragazza in una classe di maschi all'istituto tecnico. Sapevo già programmare in più linguaggi. Mi aspettavo solo di approfondirli col tirocinio. Temevo che io e il mio team non ce l'avremmo fatta a realizzare un vero plugin.
Era il 16 giugno 2026, me lo ricordo come se fosse ieri: era la prima volta in vita mia che programmavo nell'ambiente Forge (Piattaforma di sviluppo Atlassian). Scrissi il mio codice su Visual Studio Code e provai a installarlo per vedere se fossi riuscita a implementare la section message, un gadget che ha come compito il notificare un messaggio desiderato, con cui volevo fare delle prove sui vari stati che il work item attraversava nel nostro plugin. Tentai in diversi modi di vedere se il mio lavoro avesse portato dei risultati, ma niente: passai due ore a chiedere a Claude dove poter vedere la mia implementazione. Ero abbastanza frustrata dalla situazione e avevo finito le idee su come risolverla.
Quando ormai stavo perdendo le speranze e la pazienza, chiesi a Gemini, che mi spiegò che stavo cercando il mio plugin nel punto sbagliato e che nell'issue di Jira non si sarebbe inserito magicamente, ma che l'inserimento manuale era un mio compito. Una volta capito come si faceva, inserii il mio plugin manualmente, rendendomi così conto che stava lì da ormai due ore e che l'errore era solo mio, perché non sapevo dove cercarlo. Da lì in poi tutto divenne più facile e anche un po' più automatico: iniziai a conoscere le varie sezioni dove inserire quello che programmavo, e tutto divenne più comodo e utilizzabile.
Da questo tirocinio mi porto a casa una cosa: saper chiedere aiuto quando si è in difficoltà. Se avessi chiesto a un membro del mio team di darmi una mano quando mi ero bloccata, la risoluzione sarebbe stata più veloce e avrebbe creato più spirito di squadra. Invece, come spesso succede, mi sono lasciata bloccare dalla paura di risultare meno esperta, perdendo così due ore che avrei potuto spendere meglio.
Due ore per capire una cosa che una domanda al mio team avrebbe risolto in due minuti.
All'inizio del mio tirocinio ero sicura delle mie competenze tecniche, ma per quanto riguardava la comunicazione la situazione era ben diversa. Ero convinta che un progetto valido parlasse da sé, che il suo valore intrinseco fosse evidente a tutti e che il mio compito fosse semplicemente illustrarne le funzionalità.
Non avevo ancora compreso quanto fosse determinante il modo in cui un'idea viene presentata, capace di fare la differenza tra una presentazione che ispira fiducia e una che genera incertezza.
È stato il 29 luglio, mentre preparavamo la presentazione finale, che ho avuto l'illuminazione: spiegare un progetto andava ben oltre la semplice descrizione delle sue caratteristiche. Rivedendo il lavoro con il team, mi sono resa conto della mia tendenza a elencare semplicemente le fasi svolte, seguendo il mio filo logico senza considerare se il pubblico riuscisse davvero a starmi dietro. Ogni osservazione metteva in luce aspetti che avevo trascurato: concetti ormai diventati naturali per me, dopo settimane di immersione nel progetto, non erano affatto scontati per chi vi si avvicinava per la prima volta alla nostra idea. È stato allora che ho capito: conoscere un argomento e saperlo comunicare efficacemente sono due competenze completamente distinte.
Lavorando insieme al gruppo e confrontandomi con chi aveva più esperienza, ho iniziato a osservare un modo diverso di presentare le idee. Non bastava elencare ciò che avevamo costruito: bisognava creare un filo logico, accompagnare chi ascoltava passo dopo passo e mettere in evidenza il problema che il progetto risolveva prima ancora di descriverne le funzionalità. Poco alla volta ho capito che una buona presentazione non consiste nel dire tutto quello che si sa, ma nel dire ciò che serve, nel momento giusto e nel modo più chiaro possibile.
La lezione più grande che porto con me non riguarda uno strumento o una tecnologia. Riguarda il valore della comunicazione. Oggi so che un buon progetto non viene apprezzato solo perché è fatto bene, ma anche perché qualcuno è in grado di raccontarlo nel modo giusto. È una competenza che continuerò a sviluppare in qualunque ambiente lavorerò, perché ogni idea, anche la migliore, ha bisogno di essere compresa prima di poter essere condivisa.
Se devo essere onesto, a Giugno il tirocinio me lo ero già immaginato tutto: sveglia, quattro call, un attestato e dritti alle vacanze. Quello che non avevo messo in conto era dover imparare a fidarmi di altre quattro persone che, il 3 giugno, conoscevo solo di nome.
Quel giorno, primo vero, orario 9-18 con pausa pranzo come fossimo già dipendenti, ero chiuso in camera con la bacheca di Jira aperta e la webcam di Teams spenta insieme a quella di tutti gli altri, la regola non scritta era: o l'accendevamo tutti, o nessuno. Ero curioso più che spaventato, ma non avevo la minima idea di cosa guardare su quello schermo. Aspettavo che qualcuno scrivesse in chat per primo, sperando non fossi io quello che doveva ammettere di non capire niente. Nessuno scriveva. Ho capito dopo che stavamo aspettando tutti la stessa cosa, io compreso.
Il 2 e 3 luglio siamo scesi a Maranello per presentare WorkPlay, ed è lì che ho capito davvero cosa stavamo costruendo: fino a quel momento era un progetto tra noi cinque e uno schermo condiviso, in quella stanza è diventato qualcosa che doveva reggere davanti a persone che non ci conoscevano e non ci dovevano niente. Due settimane dopo, il 17 luglio, la presentazione non è andata benissimo, e il lunedì successivo Michele ha rimesso mano al plugin di persona, non me la sono presa, anzi guardarlo sistemare in poche ore quello che a noi era costato settimane mi ha fatto ridere più che altro, ed è stato comunque utile vedere come si fa.
La cosa che mi porto via non è tanto tecnica: è che in cinque, chiusi ciascuno nella propria camera dalle nove alle sei, siamo comunque riusciti a litigare, scherzare e prenderci in giro tutta l'estate come se fossimo nella stessa stanza. Alla festa per i cinque anni di essereAgile me ne sono accorto meglio: eravamo davvero una squadra, non solo cinque persone che si dividevano lo stesso ticket.
Il 3 giugno pensavo che il problema sarebbe stato imparare Jira. Il problema vero era smettere di pensare che dovessi cavarmela sempre da solo, e ridere un po' di più mentre imparavo.
A inizio giugno ero un semplice programmatore, concentrato solo sullo scrivere codice perché era l'unica cosa che sapevo fare davvero. Mi aspettavo che questo tirocinio sarebbe stato come gli altri: chiuso in una stanza, da solo o al massimo con qualche compagno, a scrivere righe di codice tutto il giorno. Temevo che alla fine sarei rimasto a mani vuote, o comunque con un'esperienza che avrei potuto fare tranquillamente per conto mio, senza bisogno di un team.
Se dovessi descrivere una scena, sceglierei il 3 Giugno ovvero il primo giorno. Ero seduto davanti al mio schermo e pensavo "E adesso da dove cominciamo?", non avevo la minima idea di cosa fare. Non sapevo che cosa dovevo fare o cosa si aspettassero da noi i tutor, visto che non avevamo mai utilizzato Atlassian o Jira prima d'ora. Ma dopo aver tirato giù qualche idea insieme al team e aver iniziato a dare al plug-in quella che per noi era una base che avremmo voluto creare, ho iniziato a pensare che non è poi impossibile. Con le nostre idee di base e qualche informazione in più, il progetto poteva funzionare. Ce la potevamo fare, ovviamente non ognuno per conto suo ma come squadra. Grazie ai nostri diversi background siamo riusciti a tirare fuori tante idee interessanti che potevano funzionare come base per il progetto.
Quello che mi ha cambiato di più è stato capire che non dovevo fare le cose solo per conto mio, ma consultare il team. All'inizio pensavo al mio contributo come a qualcosa di distinto. Credevo che fare solo la mia parte e basta senza consultare gli altri su nulla potesse andare bene. Poi ho capito che non ero l'unico a lavorare su quel progetto. Dietro c'era una squadra intera, ognuno con le proprie responsabilità e il proprio modo di contribuire. Questo cambiamento di prospettiva mi ha reso più attento e più collaborativo. Ora so che ogni mia azione ha un effetto diretto sugli altri e quindi non potevo fare di testa mia senza consultare gli altri. Ho imparato che il vero valore del lavoro di squadra sta nel mettere da parte l'idea che ognuno debba occuparsi solo della propria parte. Alla fine siamo tutti sulla stessa barca e quindi serve aiutarsi a vicenda per raggiungere l'obiettivo.
Quello che porto via da questa esperienza è il modo giusto di lavorare in un gruppo. All'inizio tendevo a fare per conto mio senza chiedere parere agli altri o comunque cercando di risolvere i miei problemi da solo, ma quando abbiamo iniziato a parlare spesso in chiamata la mattina per aggiornarsi su ciò che dovevamo fare, abbiamo anche iniziato ad aiutarci a vicenda più spesso e il lavoro progrediva molto più rapidamente, lì ho capito che fermarsi ad ascoltare non è una perdita di tempo ma è ciò che fa la differenza tra un lavoro fatto giusto per essere fatto e un lavoro fatto bene.
A chi ha avuto il coraggio di leggere le avventure di 5 ragazzi, un progetto, 0 esperienze pregresse per quanto riguarda un lavoro strutturato e un cliente, vogliamo lasciare un messaggio sentito dal team:
L'esperienza di tirocinio ci ha fatto capire che crescere professionalmente significa anche saper chiedere, confrontarsi con il gruppo e accettare ogni difficoltà come un'opportunità di miglioramento. Riflettete sul vostro modo di lavorare, chiedetevi se comunicate davvero abbastanza o se, come facevamo noi prima, date per scontato che parlare una volta all'inizio sia sufficiente per finire il vostro compito.
Abbiamo capito che un progetto non cresce grazie al lavoro di una singola persona, ma attraverso la capacità del team di adattarsi ai cambiamenti e che raramente il problema risiede nel codice. È questa la differenza più grande che non avremmo mai potuto comprendere prima di vivere questa esperienza.
Vi vediamo con il muro troppo pulito, è ora di abbellirlo un po' con dei post-it in cui raccontate il vostro lavoro:
Non sappiamo se quella in cui abbiamo lavorato diventerà un'azienda grande. Sappiamo cosa è successo a noi, passandoci dentro.
E adesso? Noi non vi diciamo niente a parte questo: se volete sapere i prossimi possibili step ci vediamo all'evento di novembre!
Essere * * * — 19 novembre 2026, Bologna
Negli ultimi anni abbiamo colloquiato decine di profili senior e middle: le competenze che cercavamo non c'erano. Abbiamo inserito persone da altri settori: non ha funzionato. E ogni azienda con cui parliamo lamenta la stessa cosa — junior pronti non se ne trovano. Così a giugno abbiamo fatto una scommessa che, detta da fuori, suona irresponsabile: mettere cinque persone che non avevano mai visto questa piattaforma davanti a un cliente. Volevamo verificare un'ipotesi: che un junior seguito nel modo giusto valga più di un curriculum già pronto.
Loro hanno vissuto ciascuno la propria storia; noi le abbiamo guardate tutte e cinque insieme. Il momento in cui il gruppo è cambiato lo abbiamo visto da lì: dopo la prima presentazione dal cliente, il loro lavoro era fresco ma senza struttura, e usava male l'intelligenza artificiale. Allora l'app l'abbiamo rifatta noi, in tre giorni, iterando tra mockup e codice davanti ai loro occhi. In quegli occhi c'era delusione per non esserci arrivati da soli. Da quel giorno hanno cambiato marcia: poche settimane dopo eseguivano le cerimonie di Scrum — una parola che il 15 giugno non avevano mai sentito — come se fosse normale.
Nella loro retrospettiva hanno scritto ansia, stress, ambiente rigido. Parlano di noi. È vero: prima li abbiamo lasciati sbagliare da soli troppo a lungo, poi abbiamo preteso in una settimana il ritmo di chi lavora da anni. La prossima volta staremo più vicini all'inizio, non alla fine.
Anche noi però siamo usciti diversi, e per tre motivi. Abbiamo imparato come ragionano i ventenni: cosa può mancare a chi entra nel mondo del lavoro e come si costruisce un percorso per accompagnarli. Abbiamo guardato Forge con i loro occhi, e quello sguardo ha aperto competenze nuove anche a noi: da quando è iniziato questo esperimento abbiamo costruito quattro plugin che presto saranno sul marketplace Atlassian. E rifacendo il loro lavoro abbiamo capito che un team Scrum che lavora con l'IA non è più il team di due anni fa — cosa che cambia il mestiere a tutti, non solo a loro.
Per questo l'esperimento per noi è riuscito. E da qui è nata l'idea di ForgIA: continuare il percorso, per integrare quella parte che di solito manca quando le persone entrano nel mondo del lavoro. Ma questa storia la raccontiamo un'altra volta, Il 19 novembre a Bologna.
Apri la presentazione a schermo intero
C'è una tappa intermedia, e riguarda proprio l'app di cui avete appena letto la genesi. Giovedì 15 ottobre 2026 Bologna ospita l'Atlassian Community Event "Forge, Community e nuove app per ottimizzare il lavoro di squadra", nella sede di Performer in Via della Liberazione 6. È un evento della community italiana Atlassian, gratuito, con posti limitati.
Sul palco ci saranno Caterina Curti, Senior Developer Advocate di Atlassian e riferimento internazionale su Forge, e Simone Pancaldi, Channel Manager EMEA South di Atlassian. Si parlerà di Forge e di estensibilità del Cloud — best practice, scalabilità, sicurezza — e del valore di una community locale in cui scambiarsi esperienze. Poi le demo dal vivo di due app: una sulla gamification dei team, l'altra sulla collaborazione con persone esterne senza dover assegnare licenze Jira aggiuntive.
La prima è la nostra, e quel giorno la presenteremo in anteprima pubblica: è l'app nata da questo tirocinio, che nel frattempo è cresciuta ed è già in uso presso alcuni dei clienti che seguiamo. Non è più un esercizio di formazione: è un prodotto, e chi lo ha costruito sarà in sala. Se vi interessa capire come si porta un'idea da un team di ventenni a un'installazione in produzione — e cosa c'entra Forge in tutto questo — è l'occasione giusta per chiedercelo di persona.
Bologna, giovedì 15 ottobre 2026, dalle 16:00 alle 20:30. Iscrizione gratuita su ACE Bologna: registrati finché ci sono posti.
— Michele