Siamo noi quelli che leggendo il codice cercano lo stronzo che ha scritto quello schifo, ma ahimè lo stronzo è mai medesimo e l'ho scritto giusto ieri.Siamo quelli che santificano il nuovo framework javascript preferendo segretamente jQuery, gli stessi per il quale il testing è importante e infatti la nostra codebase ha solo due test flakey pure.Siamo noi quelli che il tuo linguaggio fa cagare ma il mio è peggio.Quelli che la chiarezza nei comment message prima di tutto e dentro ce l'appella tutti i santi.Quelli che in call parlano per 5 minuti prima di accorgersi che il mic è muto.Quelli che non si può fare di default diventa velocemente un tutto è possibile se hai le risorse tempo e budget illimitato.Siamo noi quelli che l'AI va regolamentata, mai visto questo nuovo modello che disegna i rati di funambuli, quelli che il dipende e unisce gratis la prigione e quelli che la RAL...no vabbè fa già ridere così siamo quelli che fanno lo slalom tra le specifiche che cambiano costantemente ormai rassegnati che la definition of ready è solo una pia illusione quelli che si sentano dire "ho un'idea per un'app" ed è subito l'ennesimo social come Instagram ma meglio.Siamo noi che nonostante il deploy fallito, la CIA rossa, il business incazzato, ci troviamo al Gitbar e davanti a una birra tutto ci sembra un po' meno grave.Bene e benvenuti su Gitbar, nuova settimana e nuovo episodio qua nel nostro bar degli sviluppatori.Siamo noi che con la Ciros ci mettiamo a bere birra giusto per dimenticare, per dimenticare la stanchezza.Come potete vedere la mia faccia ormai è consunta, sono praticamente asciugato, si dice in italiano asciugato, drained, da una delivery che sono mesi che sto cercando di portare a casa ma sembra non arrivare mai e nel frattempo ci sono corse da fare a destra e a macca ma per fortuna ho con me Luca e il mio caro vecchio amico Luca con il quale posso condividere questa stanchezza enorme.Siamo in due faremo come Totò e Peppino che zoppicano uno a destra a sinistra e vanno avanti girando in tondo.Siamo sviluppatori, siamo stanchi, ma va bene.Poi dai, siamo sotto Natale.Sì, esatto.Tra l'altro vacanze di Natale che probabilmente lavoreremo, però almeno io per quanto mi riguarda ho paura di dover lavorare durante le vacanze di Natale, ma vediamo un po' come vanno le cose.Tu hai deciso di prenderti delle ferie? Qual era l'intenzione? Poi ho ricevuto una mail ieri tipo di uno che fa "ah sì, dobbiamo migrare, sta cosa" che lo sto aspettando da giugno.Tu lavori durante le vacanze di Natale? ma non lo so, dimmi tu.Se paghi bene.Esatto e quindi chissà, ci sarà una migrazione, ovviamente andrà storta, toccherà lavorare, ma siamo ottimisti, non andrà storta.Sì, pensavo una cosa, ma io che penso è già molto, io che penso in questa condizione psicofisica è praticamente impossibile, però facciamo che penso subito dopo aver ricordato i nostri contatti.Info che ho c'è la github.it @brainrepo su twitter sono i modi canonici per contattarci oppure il famigerato gruppo telegram, potete cercarlo, github podcast e il logo giallo github, non potete sbagliare siamo stabili a 1500 errotti membri.Abbiamo raggiunto diciamo il picco, c'è grande fermento, si parla di advent of code, si cerca di risolvere i puzzle, perché ovviamente lavoriamo sì, ma ovviamente ci dobbiamo anche distrarre in qualche modo.Questo è il periodo dell'anno dove su telegram ci sono le parti oscurate, no? Cioè un periodo dell'anno specifico, dove su telegram appaiono il messaggio oscurato e questo è quello.In realtà in questo periodo di me non ho grande tempo di seguire Telegram proprio perché come vi dicevo abbiamo questa release da fare e quindi sono completamente all in, credo di toccare il telefono solo la sera per chiedere a mia madre come sta e probabilmente niente più di questo.questo ci porta a introdurre una conversazione, un argomento specifico che è "work-life balance" che detto così sembra la classica buzzword "work-life balance" equilibrio tra vita privata e lavoro, l'azienda deve garantire...- La famiglia e il lavoro...ma noi siamo una grande famiglia e quindi… Esatto, esatto.Devo dire che questa cosa è ritornata nella top 5 pensieri ricorrenti di questo periodo proprio legata al carico di lavoro e pensavo a una cosa specifica, io è da un po' di tempo che sto facendo, o almeno sto facendo attività da tech lead all'interno dell'azienda per cui lavoro e all'interno del cliente e mi sono reso conto che il mio modo di vedere la delivery si allinea molto con i valori della mia azienda, ma talvolta non si allinea perfettamente con i valori generalizzati del mio cliente, nel senso che per me la delivery è tanto una sfida personale quanto la ragion d'essere per cui io lavoro in un certo contesto.Spesso questa cosa funziona se operi in società, come la società dove lavoro io, dove il concetto di delivery è in situ proprio nel nostro modo di lavorare.Cioè noi siamo persone che arrivano e devono deliverare e deliverano valore e portano a compimento le cose.Non siamo solo persone che muovono ticket dal to-do al done e finisce là, ok? Per noi portare la delivery, quindi il prodotto finito, è una missione che è, diciamo, la base fondamentale del nostro lavoro, però arrivi a un momento dove prendi un po' troppo seriamente questa cosa, nel senso, ci sono delle condizioni per cui, e questo mi è capitato anche in precedenza, soprattutto in precedenti esperienze, non sempre la delivery dipende da te, ma ci sono un sacco di fattori esterni, per esempio gli stakeholder coinvolti nella delivery hanno un grande impatto nella delivery stessa e a quel punto che metti in discussione il tuo "ho delivery o muori", il mio approccio molto molto competitivo del "o delivery o muori" e se tu prendi troppo a cuore la delivery poi rischi di entrare in burnout.Per cui mi chiedo, ti è mai capitato Lu di essere in questa situazione dove gli stakeholder sono un elemento ostattivo o comunque generano attrito complessità tra il team e la delivery stessa? Se dicessi di no mentirei, quindi sì, sicuramente è successo.A volte sembra che sei veramente l'unico che tiene alla delivery nei tempi e e nei modi giusti.Gli altri non so se è perché hanno completa fiducia di te, la stessa fiducia che magari tu non hai, dicono "vabbè, tanto andrà bene, tanto...che cosa vuoi che sia, questi piccoli contrattempi che ti do li sai risolvere".Oppure magari bellamente, a volte ignoranza, cioè non ignoranza ma si sottovaluta l'impatto che ha un determinato atteggiamento, un determinato modo di fare sulla delivery finale.Però è il nostro lavoro, io penso che sia il nostro lavoro anche questo e soprattutto di prendersi a cuore e di spingere dove c'è dove c'è da spingere.- Credo che mentre parlavi mi hai stimolato una riflessione.Non c'è niente di scritto in questo episodio, stiamo andando a braccio e l'argomento l'abbiamo deciso due minuti e mezzo prima di iniziare l'episodio, giusto perché stavamo rantando vicevolamente come in due vecchi davanti a un cantiere tenuto da giovani ragazzi, no? E quindi alla fine abbiamo detto andiamo e parliamo di delivery.In realtà credo che la delivery debba poter essere osservata da olive, da prospettive diverse.Proviamo a interpretare le varie prospettive.Prendiamo la prospettiva del developer single contributor, ok? Come guarda la delivery il developer single contributor.Il single contributor che è una delivery a cuore, la prima cosa che ti chiede è qual è l'obiettivo finale che vogliamo.Va bene le storie, va bene le technical specs, va bene tutto quello che vuoi ma cosa vuoi ottenere alla fine? E questo è quello che mi capita tutti i giorni quando parlo con gli ingegneri del mio team, che sono persone abbastanza sveglie, che io ostimo tantissimo, e talvolta ricevono le storie e dicono "Mauro, ok, sì, abbiamo ricevuto le technical spec ma dove cazzo vuoi andare a parare? Ecco quello è l'interesse alla delivery visto dal mio punto di vista dalla prospettiva del single contributor che non solo smash a stories e trascina stories da to do a done ma cerca di inquadrarle in un obiettivo chiaro.Altra cosa è la delivery vista da parte degli stakeholder.Gli stakeholder hanno bisogno di un ruolo, lo hanno bisogno di essere rassicurati e soprattutto hanno bisogno di essere coinvolti.Il problema spesso è un problema di linguaggi e di meccanismi, nel senso che quando si proxa parte degli stakeholder per aumentare velocità si scolla dagli stakeholder, specie quando ci sono delle deadline dove si deve correre, ci si scolla, ci si allontana dagli stakeholder E questo, da un certo punto di vista, dà un certo abbrivio, una certa velocità iniziale.Cosa succede però? Che scollandoci si dagli stakeholder, per quanto noi possiamo avere chiara la visione del progetto, noi ci stiamo allontanando da quelle persone che poi rientrano a gamba tesa quando siamo a massima velocità, e che percepiamo come elementi ostativi e rallentativi del percorso.E quindi penso, arriva un certo punto che l'information architect o il product manager o chi per loro, o il business analyst arriva e dice "Mauro, ma questa cosa forse, ma quindi dobbiamo cambiarla così, così, così" e gli lanceresti una scarpa, se non un sasso in faccia.Però questo fa parte della delivery e questa è una cosa che ho scoperto un po' troppo in avanti con l'età, avrei voluto scoprirla prima.Cioè la parte di stakeholder management, quando non sei più un single contributor, diventa uno degli elementi che assorbono più energia e che non può essere ignorata, che non può essere esclusa dal computo, quindi dalla stima iniziale di EFORT, e che deve essere sempre comunque considerata.Perché un software senza il coinvolgimento degli stakeholder è un software monco.Quando poi si arriva a pensare che sei l'unico che porta a casa la delivery, e lo si pensa sempre questa cosa, sei l'unico a cui interessa portare questo cazzo di prodotto in produzione, sei l'unico che fa qualcosa per portare questo prodotto in produzione, vuol dire che abbiamo già superato la linea rossa.Quando uno degli elementi campanello d'allarme di quello che è il burnout è la sensazione di essere da solo nel fare tutto e che tutti gli altri siano solo una grande rottura di cazzo a corredo, che venga out of the box con il contesto, E quando si arriva in questo tipo di condizione vuol dire che si è già superata la linea del non ritorno.A quel punto è necessario da una parte riprendere le energie e uscire da questa impasse, quindi adottare tutte le misure legate al burnout.Dall'altra fare il reframing del contesto e reframando il contesto il coinvolgimento degli stakeholder è l'elemento, non uno degli elementi.È difficile, perché le competenze sono difficili, però bisogna da una parte lavorare per la costruzione della fiducia e dall'altra sperare che si sia condiviso l'importanza dell'obiettivo che si deve raggiungere è l'entità dei rischi correlati al non raggiungimento o agli elementi che si presentano davanti.Ho parlato 20 minuti così a ruota libera perché stavo solo mettendo insieme pensieri che arrivano dalla mia testa.Da quel punto di vista sulla gestione degli stakeholder, come la vedi? Ti allinio un po' a quello che ho appena detto o pensi che non lo so? Allora io, mentre parlavi, mi veniva in mente anche l'enorme problema di comunicazione che bisogna affrontare, di riuscire a parlare la stessa lingua, lo stesso linguaggio con gli gli stakeholder, ma in generale con tutti i super sistemi che si trovano sopra quello tecnologico.E al contempo di quanto a volte i problemi che ci sono, o che quantomeno i problemi che vogliono risolvere gli stakeholder non sono problemi tecnici, anche se noi crediamo essere problemi tecnici.Mentre in realtà sono problemi di tutt'altro livello.Bisogna capirlo anche per poter dare il giusto contesto e la giusta dimensione a quello che stai facendo.Quindi, è vero, a volte quando non vedi chiaramente quello che c'è attorno, perché non puoi essere tu l'unico che tira avanti la bracca, anche perché lo pensiamo tutti e quindi non possiamo essere da soli.Mi viene in mente sempre quando tu stai facendo una corsa e sei talmente stanco che non riesci a guardarti attorno.Vedi soltanto la strada all'orizzonte ma non vedi nient'altro.Quello vuol dire che sei veramente stanco e che non è il modo giusto di affrontare quello che stai facendo, a che ti devi prodigare a fare.Dicevo comunque il grande problema che mi sono comunque ritrovato negli ultimi anni nella gestione sia del team che degli stakeholder e tutto è comunque sempre un grande problema di comunicazione.A volte ho dovuto veramente cedere le armi per dire "io non so come parlarvi, non riesco, datemi un giorno e ritorno perché mi devo preparare, non riesco, non riesco, non riusciamo ad avere lo stesso vocabolario.LM: Sai, una cosa che ho imparato da questo punto di vista è soprattutto se noi trasportiamo proprio questo concetto di comunicazione oltre e ragioniamo sul fatto che ci può capitare di lavorare in contesti internazionali, con persone di culture diverse.Quindi abbiamo una lingua diversa dove non si è native speaker, abbiamo culture diverse, abbiamo prospettive diverse perché magari stiamo parlando col business o stiamo parlando con un information architect che ha degli obiettivi, delle prospettive e dei parametri di valutazione del mondo completamente diversi.Cazzo, c'è, cambia praticamente tutto.E a quel punto come comunichi? Una cosa che ho visto funzionare o almeno per me ha funzionato è quella di non parlare.Quando si è in una corsa, e soprattutto se si è a feti di ADHD come me, sì, e voi lo sapete ormai, mi tollerate, ma si parte a parlare a macchinetta e si passa sopra a tutti finché non si è finito di parlare, si è finito di rappresentare quello che si ha in testa, completamente ignorando ciò che ci circonda e l'interlocutore che abbiamo davanti.Questo a me capita spessissimo e poi dico "quanto sono coglione", no? Tutta questa l'adrenalina forse è il caso che la fregni un attimo.Una cosa che con me ha funzionato è stata proprio quella di impormi l'ascolto, perché spesso quando diciamo "non capiscono un cazzo" è semplicemente perché siamo noi, sono io che non capisco loro e quindi come loro mai potrebbero capire me se io non capendo loro non posso mettermi in condizione di spiegarlo in una cornice, di rappresentare una cornice che è basata sul loro modello mentale.Questa cosa si basa sul fatto che noi non possiamo pretendere che tutti si adattino a noi per capire il nostro frame mentale, perché spesso il nostro frame mentale è anche ricco di tecnicismi e anche ricco di approcci tattici legati alla tecnologia, quando quelli parlano di business, parlano di funzioni, parlano di operation, no? Quindi, sai, noi le operation le capiamo o almeno possiamo capirle se le ascoltiamo, ma perché le vediamo, perché è logica, perché è solo "fermati, ascolta".Quindi, secondo me, lo sforzo, ahimè, non lo dirò mai davanti ai miei stakeholder, per fortuna non mi stanno ascoltando perché non parliamo la stessa lingua, però in questo caso ecco secondo me dipende molto da noi, da quello che dobbiamo fare noi, è dal aver messo in chiaro i principi ancora prima di iniziare.Una cosa che ha funzionato in questo caso con me è stata quella di partire con un obiettivo, quindi si fissa un incontro.Per fare queste cose la comunicazione asincrona non funziona mai, almeno dal mio punto di vista.Si fissa una meeting, si fissa l'obiettivo e si fissa praticamente l'outcome, quando dico obiettivo parlo dell'outcome che si vuole portare a casa e si crea una tabellina per gli action items, le azioni a portare a casa.Nel caso si debba prendere una decisione, io ho imparato a mettere, fare la tabellina delle varie decisioni potenziali e a metterla la linea del rischio.Facendo questo, durante il meeting, che deve essere time boxato assolutamente se non si finisce con un workshop di otto ore, dieci ore, cose aliene e fuori di testa e soprattutto se non si time boxa poi c'è sempre qualcuno che fondamentale nella discussione che dice mi si fredda la cena e pianta il meeting così all'ultimo momento, esperienza personale e quindi l'incazzo sale a livello super saiyan.Però ecco, utilizzando questo framework, questo approccio, ho notato che in realtà si riesce ad ascoltare molto di più, si formalizza l'ascolto e si formalizzano le varie posizioni.degli stakeholder, per cui questo dal mio punto di vista aiuta un botto.Dal tuo punto di vista hai delle tattiche per migliorare la relazione degli stakeholder quando dici "cazzo nessuno mi capisce.Tattiche, che parola borderline tra sporco trucco comunicazione autentica che c'è.Sto cercando di ricordare un'esperienza.Ci sono tecniche ma sono perlopiù di comunicazione.L'hai anche citato, mettersi nelle scarpe anche degli altri, capire "ok, questo è il loro modo di vedere, questo è il loro modo di affrontare la situazione che è diverso dal modo in cui io sto affrontando la situazione e io vedo i problemi".Perché appunto, come dicevo anche prima, alcuni problemi che noi crediamo tecnici non lo sono affatto.Quella del silenzio è un ottimo suggerimento, un ottimo consiglio.A volte capita per me di alzare quando c'è un motivo di scontro, perché capita anche quello, quando quando vedo che i toni cominciano a essere un po' alti perché non ci si capisce, ebbene, questo l'ho imparato anche dalla mia CEO di qualche mese fa, è quello proprio di interrompere tutto e rimandare a qualche ora, o a qualche mezz'ora, perché lì c'è proprio un problema, di, come sempre, comunicazione e di mancanza di questa tecnica di dire "oh, non mi stai ca...stiamo parlando di due problemi diversi, è inutile che continuiamo su questa direzione".Non ho altre tattiche.LM: Sai che quello di interrompere funziona, ma secondo me funziona parzialmente, perché da quel punto di vista tu stai interrompendo e poi stai riprendendo.Che può funzionare? Nel senso che addolcisce e poi semplicemente fa scaricare l'energia, perché quando si una discussione poi se secondo che tipo di personaggi metti nel pollaio, tipo se butti me io sono uno che tira sulla tensione durante la discussione ok? Quindi c'è ci mette adrenalina e ci mette energia io dopo un meeting di un'ora e mezza sono da strizzare ok? In questo periodo sto facendo circa 7-8 ore di meeting al giorno quindi per farvi capire la cosa però io sono veramente da strizzare per l'energia che metto nella comunicazione.E poi magari ci sono degli interlocutori, tipo alcuni degli interlocutori con cui mi confronto, culturalmente completamente diversi, che hanno il volume nelle vene, super chill, tipo tu impazzisci per fargli capire le cose e loro sono serafici, del tipo "no, non è così, tranquillo, ecco di energia a zero virgola.In quel caso quando io riprendo e vedo ancora quell'attitudine, quell'atteggiamento che poi in parte è guidato dal carattere della persona, in altra parte è guidato anche dal framework culturale nel quale si sviluppa quella persona che, credetemi, fa molto, fa molto, perché ne parlavamo con con Alessio da poco, lavorare con persone di cultura, che ne so, giapponese o cultura indiana è completamente diverso da lavorare con persone che vengono da un frame più europeo, è una questione di natura culturale.E una cosa che per me ha funzionato è stato quello di...ci sono Sono dei workshop che secondo me vanno necessariamente fatti di persona.E sono i workshop, gli incontri dove si può aumentare la tensione.Gli incontri online bisogna sempre evitare di aumentare la tensione perché è sempre difficile aprire la valvola della pentola a pressione, no? Perché manca la parte di water cooler, no? Di macchinetta del caffè dove dei comprimi.Quindi una cosa che ho trovato utile quando si fanno questi workshop in persona bloccare tutto, andare alla macchinetta del caffè, offrire alla persona con cui tiro l'attenzione un caffè, e questo lo faccio spesso quando faccio questo tipo di riunioni, per passare un messaggio chiaro.Ehi, credo che lavorativamente parlando, intanto lavorativamente parlando non ho bias, nel senso ti stimo o non ti stimo, non è importante, ma a livello personale io non ho un cazzo contro di te, ok? Anzi, offrendoti il caffè, offrendoti il caffè ti dimostro che mi prendo cura di te come persona anche se in quel terreno di confronto penso che stai dicendo delle puttanate colossali e per quello mi incazzo, no? Quindi questo scollamento secondo me è un elemento che amplifica quello che hai appena detto, questa attività proprio di prendersi cura della persona.Un modo per farlo online che mi è capitato è alla fine del meeting con quella persona avvicinarmi e dirgli che ne so come stanno i tuoi bambini o come fa in famiglia o beh cosa stai pianificando per le vacanze.È un modo per dimostrare care nei confronti della persona per dire sì, ci siamo tolti gli occhi fino a 5 minuti fa però adesso dobbiamo ragionare in questo caso.Poi potete anche venire da me e dirmi Mauro ma lo scontro in questo tipo di riunioni non dovrebbe mai portarsi? Bisogna sempre tenersi rilassati? Sì vabbè, nel mondo ideale.Quando si lavora si ha una deadline e si ha la tensione emerge e non venitemi a dire che non è così perché non ci credo manco per il cazzo, onestamente.Quindi le tensioni emergono, che però non devono essere di natura assolutamente personale.Questo è l'elemento secondo me importante.Quindi sì, sono d'accordo tensioni sono anche sintomo del fatto che ci tieni al lavoro, che tutti quelli diciamo coinvolti ci tengono alla buona uscita del lavoro o del progetto.Poi sì, ci sono delle altre tecniche o altre cose in base se stai, se devi gestire un team o se devi gestire in qualche modo i superiori o se devi gestire altre persone.Quello dell'entrare sul personale non funziona con tutti, o almeno ho visto, perché alcune, non so se è per alcune culture, non è non italiana, è quello con cui io ho avuto a che fare, vogliono completamente la separazione netta tra lavoro, cioè tu non devi nemmeno sapere se ho figli o gatti o fratelli a casa che mi stanno aspettando.E quando ci ho provato si vedeva proprio il chiaro muro eretto, dice "no, scusami, stai da quella parte, grazie".E va bene così, un modo bisogna sempre trovare per comunicare in modo efficace, in modo autentico, se vogliamo.Però in quel caso puoi sempre comunque dimostrare interesse verso la persona, anche se facendo tutti i cazzi tuoi, nel senso non è che mi devi dire quante volte esci a fare un picnic con tua moglie, però se io ti offro un caffè in quel caso mi sto prendendo cura della persona.A me è capitato per esempio di aver avuto...premesso che io in situazioni critiche di tensione con deadline performo da Dio.Quando sono nella merda performo, altrimenti non performo.Questo è proprio un problema di tipo personale legato alla mia gestione del focus e iper focus.no? Però detto questo mi è capitato per esempio di sollevare un po' la tensione con alcune persone e poi però il giorno dopo gli ho mandato un regalo a casa per esempio.Sono cose che raramente si fanno e in quel caso è perché ci tenevo, ci tengo veramente alla persona e allora cazzo, cioè ti dico sì, quello che stavamo facendo era lavoro, però ricordati che io tengo a te come persona, perché il care della persona secondo me è importante, non stiamo parlando con macchine che sbrigano del lavoro, ma con delle persone che secondo me su questa cosa sono pronto a… LM: sì, anche per ridimensionare un po' il tutto, insomma, quando succedono cose di questo tipo, un piccolo gesto quale che sia, che sia un regalo, un cioccolatino il giorno dopo o chissà che cos'altro, è comunque, sì, è qualcosa di personale che metti sul piatto ed è un modo per dire "ok, quello che è successo è successo a livello lavorativo, ma personalmente siamo persone, se tu hai sbagliato, non è un problema, sbagliare fa parte della nostra natura e quindi va bene.Adesso mi è successo recentemente, ma non c'entra con la gestione del team e tutto, che un'amministrazione aveva fatto un errore su alcune cose, lei era dispiaciutissima, ho soltanto avuto comunicazioni via via email.Poi, un giorno ero andato per incontrarla, questa non l'avevo mai vista, sono andato per incontrarla appunto per dire "guarda, non c'è problema" e non c'era.Però io, da mia attitudine, ho il viso cruciato quando quando mi approcciavo alle persone per la prima volta, non so perché, e c'erano altre persone, mi ha detto "no, no, guarda, non è ancora arrivata, arriverà tra un'oretta".E questi poi devono aver detto "guarda, è arrivato uno, incazzato, che ti cercava".Poi sono sceso un'oretta, lui mi guarda, spalanca gli occhi, non mi saluta nemmeno, ha detto "no, guarda, mi devi scusare", ha tirato fuori due cioccolatini che avevo comprato apposta.Ho detto "no, ma guarda, non c'è problema"."Ma come? Ma ho sbagliato io, mi dai cioccolatini?" "Ma sì, ma proprio perché hai sbagliato tu, ti do due cioccolatini, tranquillo".Non c'entra niente col team, era una cosa estemporanea che però ricorda che alla fine siamo tutte persone, anche durante anche durante l'orario di lavoro, finché saremo persone, perché poi si sa che lì e lì ci sostituiranno tutte.- Ah sì, tu l'hai già assunto David o come cavolo si chiama? - No ma ci sto pensando, perché per 500 dollari al mese può lavorare al posto mio e magari ci posso fare un bel ricarico sopra non lo so ci sto pensando.Per chi non lo sapesse è notizia recente che la beta di questo Devin che questa AI scritta è addestrata a risolvere sostanzialmente issue su GitHub, GitLab o quello che volete è chiusa e aperta e hanno dichiarato anche il prezzo.Puoi praticamente assumere una IA che sembra faccia un lavoro da junior abbastanza in gamba, un junior molto sveglio, ma mo dico che c'entra di 500 dollari al mese.Tu lo assumi? Eh non c'è sindacato dire, però io credo che...io no.Io no.Perché no? Perché trovo sempre qualcuno su Fiverr che prende meno di 500 euro al mese di un essere umano.Ho rilanciato con il Playmore 4 e più grande.Ma guarda, non lo so, onestamente non so più dove andremo a parare.Tu, fuori onda, hai fatto un'osservazione che mi piacerebbe ripetesti qua, perché secondo me è centrata.Quella sui junior, no? Se un junior che performa bene che bisogno c'è dei junior o degli stagisti? Ma i junior di oggi saranno i senior di domani, quindi chissà.Sì, molto probabilmente, secondo me, non lo puoi controllare.Come fai a dire a uno che ci mette i soldi, dire "guarda, puoi pagare 500 dollari al mese e hai questo output oppure ne paghi quanto? 2-3 mila? l'output non si sa, forse sì forse no.Quindi non lo so, io sono un po' preoccupato ma non tanto di perdere il lavoro, perché sono ancora senero, almeno sulla carta, ma proprio per il futuro, di quanto codice avremo che nessuno sarà in grado di capire, perché nel frattempo si evolveranno nello scrivere codice che solo loro capiranno, molto probabilmente, o quantomeno capiremo sempre meno.E poi chissà, questo è anche una questione filosofica in cui pian piano accederemo alle macchine il sapere, ma quello vero.Cioè cominceremo a delegare a loro, e non parlo solo dell'informatica, parlo in tutti i campi, soprattutto con lo medico, delegheremo loro le diagnosi senza possibilità di double check, perché non saremo in grado di farlo.Non perché perderemo la competenza, ma perché sarà un livello di competenza talmente alto che non potremmo eguagliare.Secondo me anche...E noi non lo faremo.E' un problema molto grande.ma le prossime generazioni saranno abituate pian piano a cedere questa competenza e sarà normale per loro affidarsi al risultato di una macchina senza che nessun umano faccia un double check.Sarà sempre più normale, non per noi perché noi non l'accetteremo, ma i nostri figli, i nostri in pochi probabilmente sì.No, il discorso è che secondo me anche tu trovalo quello che dice la macchina sta sbagliando e soprattutto cosa succede se l'umano dice che la macchina sta sbagliando e la macchina ha sbagliato dieci volte ma quella volta fa giusto? Eh questo è uno dei famosi dilemmi di natura etica.No dicevo, cosa succede se un umano dice "la macchina sta sbagliando", un medico dice "la macchina sta sbagliando, quella macchina ha sbagliato 50 volte ma quella volta ha fatto giusto.La natura, scusate questo dimostra la mia stanchezza, la natura di questo tipo di decisioni è legata proprio a questi parametri.Pensiamo una cosa, abbiamo parlato di sviluppatori però vorrei ritornare per un attimo agli sviluppatori in carne ed ossa.Prima abbiamo parlato di stakeholder management, però sai, avendo un ruolo da guida nel team, che può essere il CTO, che può essere il team lead della situazione, che può essere quello che volete, ma qual è il ruolo di questa figura nei confronti non dei portatori di interesse legati al prodotto, quanto del team stesso? Quanto il team lead deve fare proxy di queste complessità che avvengono a livello stakeholder e quanto deve lasciare permeare questo tipo di complessità dal tuo punto di vista Lu? Eh questa è un buon dilemma perché a me è capitato nella mia esperienza di schermare troppo e non ha funzionato o comunque ha funzionato parzialmente.Lo facevo in un'ottica di proteggere, lo facevo non ottica di diminuire la complessità, però era comunque, facevo io da proxy e c'è sicuramente il problema che poi senza di me le dinamiche erano tutte stravolte, quindi io ero il, come si dice, il bass factor ma il punto single point failure.E non è nemmeno giusto in ottica di crescita del team.Un po' però deve farlo perché il tuo ruolo di manager o leader è quello di districare, semplificare un po' sia in una direzione che dall'altra.Però due cose, non semplificare troppo e non nascondere, cioè dare visibilità alle cose sia alle persone stesso all'interno del team, agli occhi di chi sta sopra, sia viceversa.Anche in ottica di far crescere il tuo team, non puoi nascondere e mettere sotto il tapeto o semplificare o far trovare alla fine la Papa Pronta al tuo team e questo anche riduce la dipendenza da te e fai crescere alla fine anche il tuo team che si abitua a gestire la complessità.Tu che ne pensi? Allora, io l'errore che dicevi l'ho fatto, rifatto e continuo a farlo, no? Quello di fare mamma chioccia e provare a schermare tutto dalla complessità e come hai detto poi alla fine diventa overwhelming per te, nel senso che vieni soprafatto da tutto diventa scolla il team da quelli che sono i problemi veri e quindi scollandolo da quello che è la realtà il team lavora in questo mondo immaginario che hai costruito tu per loro e che in realtà non riflette frustrazioni contesti challenge per cui anche l'empowerment del team è limitata credo che quando si prova a fare a fare l'approccio da servant leader no? quindi da leader che aiuta il team il trannello di fare mamma chioccia è dietro l'angolo il tuo ruolo è quello di aiutarli a fare meglio e quindi li overproteggi.Cosa succede? Che io ho il mio modo per rappresentare questa situazione, è usare il noi al posto dell'io.Abbiamo un ruolo dove il leader è un capo, non è un leader, e usa l'io.Abbiamo il trannello del servant leader, come lo chiamo, dove il leader usa il noi e protegge il team, il team da, da, da schermandolo da molti problemi diventa poi il point of failure e sono arrivato a una considerazione che secondo me l'unica, l'unico modo che si ha per per evitare il problema o quanto meno per contenerlo se non è evitabile e non usare il noi ma essere il noi.Cosa vuol dire? Che se c'è un problema il colpo deve essere accusato non solo da te che sei il servant leader ma da tutto il team perché tu sei finito tu hai capacità finita, energie finite, emotivamente suscettibile come tutti gli altri e se sei tu a prendere sempre i colpi poi arriverà un momento dove questo non sarà più sostenibile e il team crollerà.Quando tu dicevi in un'ottica di formare il team, di far crescere il team è proprio proprio da questo punto di vista che è necessario essere noi.Per cui per esempio una cosa che ho trovato difficile all'inizio ma necessaria è stata quella del delegare, che non vuol dire delegare azioni ma delegare decisioni.E cazzo, quando deleghi decisioni e tu sei il punto di contatto tra più stakeholder e ti arriva uno stakeholder e tu non sai come cazzo rispondere perché la decisione non l'hai presa tu, l'ha presa il tuo ingegnere, ok? Ti senti una merda, pensi che non stai facendo il tuo lavoro.All'inizio la sensazione è questa ed è frustrante, mortificante, ti fa sentire una merda.Sai che a fin dei conti, questo era come mi sentivo all'inizio, ma a fin dei conti dire "Ehi, sai una cosa, aspetta un attimo, pullo Amid nella chiamata e ce lo facciamo spiegare da Amid o da Pinko Pal o da Fabio, Paolo, Lucia, chi vuoi tu" e questa cosa dà una sensazione di "non sono in grado di dare le risposte agli stakeholder diventa qualcosa del tipo "cazzo il mio team è forte, non ha bisogno di me, sono io che ho bisogno di loro paradossalmente" e si capovolge completamente la prospettiva e diventa una figata.Per cui il rischio del servant leader è "andiamo a proteggerli" quando in realtà il servant leader deve eliminare gli ostacoli che può eliminare ma nel contempo permettere a tutti di esprimere al massimo delle proprie capacità e questo se si entra in modalità "mamma chiocia" si cappa.Come si controllano le decisioni questo poi è un altro capitolo nel senso come si mettono i paletti di contenimento per dire tu sei libero di decidere ma questo è il frame dove ci dobbiamo muovere e la entriamo su su su su tutto un altro una un altro gioco no Lu perdonami ma quando quando parto così a ruota libera poi non mi fermo.Hai delle considerazioni in merito? No, è detto penso sacrosante verità che rispecchiano anche quello che ho vissuto io anche negli ultimi anni, quello di chiamare il tuo ingegnere nella colla, quando tu devi spiegare qualcosa e non sai perché spiegarla, non sai come spiegarla.Quella mi è anche successo ed è il sentimento che poi ho provato, è stato molto rassicurante, come per dire "ok, non sono solo, posso fare affidamento al mio team, decisioni le possiamo prendere perché sono perfettamente in grado di prenderli.Ovviamente poi dipende sempre dal ruolo, se hai quanti senior hai, se hai senior, comunque ovviamente si parla, si mettono in queste condizioni le persone che possono gestire situazioni di questo tipo.Io penso sempre anche alla crescita, questo è il modo migliore per farlo crescere, altro che corsi e controcorsi che pure ci vogliono eppure servono, ma questo permette loro anche di fare, di sbagliare, di fare errori in un contesto protetto alla fine, o quantomeno dove la piena responsabilità non è loro.Tu puoi dargli il giusto contesto affinché prendano la giusta decisione.Decisione che magari puoi anche non condividere.Anzi, nella maggior parte dei casi non condividi perché siamo persone diverse, con background diversi e potrebbero potrebbero sorgere dei conflitti.Ovviamente è successo e posso essere dell'opinione che una cosa non può funzionare e allora lì dici ok alla fine sono sempre io il responsabile, so che così non funziona, che poi ho torto o meno non lo so, ma io so che non funziona, quindi ti dico o convincimi, ma mi devi convincere molto bene, oppure si fa come dico io.Anche sbagliando, anche sbagliando perché nessuno è infallibile, però io ho bisogno di lavorare in modo convinto perché non posso sempre, sì, posso coinvolgere il team, posso chiamarlo in col… ma non posso delegare la responsabilità perché la responsabilità rimane mia e quindi devo essere convinto di tutte le scelte che vengono fatte.Perché il rischio mi è successo anche una volta che non ero convinto di una scelta ma l'ho lasciata, l'ho completamente delegata e lì mi sono trovato proprio in un deadlock.Mi sono ritrovato quasi a pensare come per dire "eh ma che volete da me? Non sono stato io".Ma non potevo dirlo perché alla fine sono io il responsabile, ero io il responsabile.Quindi è sempre una danza di responsabilità tra la tua responsabilità e la responsabilità del singolo individuo all'interno del team.Credo che sai… Una cosa su cui ho discusso, questa è una cosa un po' più particolare, una cosa un più particolare, secondo te la responsabilità di una pull request di chi è? Del team.Sempre? O di una feature che si trova all'interno della pull request? Del team.Del team? Sì, non esiste una responsabilità individuale? Secondo me no.Perché? Perché se la responsabilità è del team, il team è un'entità astratta, nessuno si sente responsabile alla fine.Io parlo di una pull request fatta da un singolo individuo mandato in code review e poi si immerge o non si merge.Con che cura una pull request può essere fatta sapendo che dovrà essere vista da 3-4 persone? E che non hai tu la responsabilità di quella pull request ma è condivisa.Dipende molto dalla conformazione del team onestamente nel senso che sì è vero magari sei un po' un po' lassista ma io per esempio una cosa che chiedo sempre al team è di essere super picchi con le code review e se tu vedi una cosa e non la segnali nella code review e poi la merge request va a merda, la responsabilità è di te che hai fatto la code review tanto quanto di chi ha scritto il codice, tanto che tutti sono responsabili non solo di scrivere il codice bene ma anche di fare la code review fatta bene e se tu non fai la code review, se tu non fai la review e manca quella review sei responsabile uguale perché non hai dato il tuo contributo.Quindi dipende da che valore dai alla code review e da come si fa la code review.Perché se tu non fai, non dai valore importante alla code review e metti a budget tempo e soldi per le code review e le code review sono solo una green light, ok? In quel caso hai ragione tu.Ma se la code review ha lo stesso valore di scrivere il codice, la responsabilità è condivisa? Sai perché? Sono d'accordo idealmente, ma praticamente no, perché come detto una responsabilità condivisa non vuol dire niente.Se la merge di questa va a merda è la responsabilità del team agli occhi di chi sta fuori dal team, è questo indubbio.La responsabilità è di tutto il team, e quindi anche del team lead che non ha coordinato alla fine bene il processo di code review eccetera eccetera.Ma all'interno del gruppo cosa accade? Accade che se la responsabilità è condivisa nessuno si sente veramente responsabile.Si ma perché nessuno si sente responsabile? Tu stai partendo dall'assunto...Aspetta, aspetta, aspetta."Balloccherò il libro alla fine, però tu sai come funzionano i processi di checklist sugli aerei?" "Sì" "Non ci sono due piloti, pilota e copilota, comandante e secondo, che fanno le stesse cose, fanno due cose diverse, sempre, ed ognuno è responsabile per quello che fa.Quindi il codice, quello che fa la pull request è responsabile di quello, di tutte le modifiche apportate.E questo che cosa vuol dire? Che deve mettere anche, siccome chi fa la pull request, chi fa il lavoro si sente responsabile, sa che dovrà mettere gli altri a fare la code review per, nelle condizioni di farla al meglio, perché altrimenti ti faccio una pull request gigamontostica, questo termine l'ho appena inventato, senza uno straccio di descrizione o se hai delle policy eccetera eccetera sì te la metto la descrizione fatta con cgpt o chissà che cosa, una descrizione che sembra una descrizione ma che in realtà non fa capire niente della...Lo fai tre volte nel mio team e sei fuori.Ciò che il Code Reviewer può fare, se puoi farli fuori, va bene.Io queste cose le dico una volta nell'onboarding.È chiaro, ho capito quello che vuoi dire, però per esempio una cosa che con me ha funzionato è chiarificare l'expectation all'inizio.Cioè, tu joini il team, se tu stai facendo una code review, tu devi farla.Se tu stai flaggando, perché capita, diciamoci la verità, capita di approvare i code review senza neanche leggerle, ok? Quando l'approvo, e specialmente a me, capita di approvare i code review in fiducia, perché non ho il tempo di fare i code review e magari c'è una merger request che deve uscire, Ma sai cosa faccio? In quel caso io scrivo "Approvata in trust".Quindi la persona, prima di immergiarla, un altro sguardo glielo dà.Sempre.La stai responsabilizzando? Sì, però...Ma responsabilizzala all'inizio, scusa? ma dovrebbe essere già responsabile, cioè io mi aspetto, nel mondo reale sicuramente, ma no ma nel mondo nel mondo reale devo usare delle tecniche, per esempio scrivere approvata infiducia è una tattica no? che serve a equilibrare il mondo reale, poi ma cioè raga la merda in produzione l'abbiamo lanciata a tutti eh, me compreso, cioè non è che questa cosa va bene, però ecco, secondo me la responsabilità individuale è un modo per permettere agli altri di lavarsi nelle mani.Quindi è vero, ne stai responsabilizzando uno ma stai sollevando dalle responsabilità gli altri.Secondo me tutto il team deve essere responsabile del prodotto finale, non della merger e quest, perché una merger e quest non ti manda puttane un prodotto.O almeno raramente.La responsabilità del prodotto finale è comunque sempre responsabilità del team.Però è curioso perché tu comunque dici che la responsabilità è di tutti ma facendo quel "approving in trust" stai responsabilizzando il singolo ha detto tu, ha poi un secondo occhio, ce la dà.Secondo me sono dinamiche più complesse, perché anche perché se io sono responsabile della Merge Request, non della Code Review, sono responsabile della Merge Request, Merge Request non so come si chiama, se io sono responsabile devo fare una Code Review di 40 file modificati di cui l'80% sono indentazioni o cose varie, o la rimando indietro, cosa che si può fare, ma a volte nemmeno si può fare, oppure non te la proverò mai, dico sì mi prenderò del tempo appena ho appena ho finito le mie cose e le cose stanno in code review per due settimane perché nessuno si può prendere la responsabilità di approvare una merge request.Io ti posso dare la mia responsabilità del dire ok ho fatto la code review al meglio delle mie capacità e al meglio di quello che potevo permettermi con una pull request di questo tipo.Io questo posso fare ma non posso testare o vedere se non ci sono errori di sintasi, io lo posso vedere anche riga per riga tutti e 40 file ma non posso essere responsabile della correttezza di un algoritmo complesso.Si tu ne puoi avere un.Intanto se se fai una cod review tu devi capire il codice, se tu approvi senza capire che cazzo sta facendo l'algoritmo tu non stai facendo una cod review, stai autorizzando l'altro a mergiare alla cazzo di cane.Quindi sì, ci può stare, è una tattica, è una scorciatoia, ci può stare, può funzionare in condizioni specifiche, ma in quel caso la persona che ha scritto la mergine di questi può dire "eh, ascolta, tu me l'hai approvata, approvandola mi hai detto che l'hai capita e che andava bene, perché se no la responsabilità nel dire "va bene" e quindi a provare un'emergere questo non ha alcun valore.Poi possiamo parlare su come fare il balancing delle responsabilità, ma occhio perché il responsabilizzare come lo metti tu nasconde un tranello enorme che è quello del finger pointing quindi il dire "Ehi Luca, Ehi Francesco, Ehi Lucia, Ehi Giuseppe hai fatto un bordello" e non "Ehi team abbiamo fatto un bordello" capisci che c'è il rischio...Qual è il problema del dire che una persona ha fatto un bordello che ha fatto un bordello.Che una persona non fa un bordello mai da sola se lavora in team.E che se una persona ha fatto un bordello vuol dire che c'era un ecosistema tale da permettere quel bordello.E siccome le persone sono fallibili, e io sono pienamente convinto che le persone sono fallibili, io sono il primo a essere fallibile, ok? Il team deve essere l'anello di salvaguardia della fallibilità individuale.Il team può fallire, ma dal momento che l'individuo può fallire, il team deve essere a salvaguardia.Poi è vero, il team può fallire nella sua interezza, nella sua interezza, in quel caso non è colpa di nessuno perché sarebbe finger pointing ma fa parte del contesto e bisogna comprendere dall'errore.La cosa che voglio passarti è, tu hai parlato di checklist in termini di piloti, ok? L'anello di salvaguardia là non è il team tra pilota e copilota.L'anello di salvaguardia là è la giunzione tra individuo e procedura.Nel team, almeno nel mio team, l'anello di salvaguardia è la giunzione tra individuo, team e procedura.c'è un terzo elemento che entra in gioco.Nel mio modo di vedere il lavoro la delivery non esiste se c'è un individuo.E cambiala la prospettiva, no? Tu vedi l'individuo dove io vedo il team, tu vedi la responsabilità individuale dove per me la responsabilità individuale arriva fino a pagina 2 perché c'è l'anello di salvaguardia del team e se l'anello di salvaguardia non funziona, è colpa dell'anello di salvaguardia o almeno è anche colpa, non mi piace la parola colpa.è un...no infatti non è colpa ma è proprio responsabilità.Se il team va male, come detto, il team ha un problema, il team sbaglia, ha fallito in qualche missione, bisogna vederle quali sono le responsabilità.Non colpe, perché qui la parola colpa non esiste, però ci sono delle responsabilità che vanno...allora il team deve essere maturo, questo ha anche colpito del team leader di eliminare il concetto di colpa e mettere sempre il concetto di responsabilità, ma se qualcosa va male c'è una responsabilità, anche perché se la persona che fa la Merge Request la fa sempre male e ha bisogno continuamente di due o tre persone che li correggono, uno, io come team leader non riesco a valutare la persona, non riesco a valutare se questo, se lo sviluppatore, fin dove arriva lo sviluppatore, perché io sono sempre nel dubbio che non dà il massimo perché tanto c'è sto pezzo che lo controllano gli altri.Però le responsabilità ci sono, a volte sono del singolo, a volte sono del team leader, perché se non hai i processi adeguati per far performare al meglio il team, magari è responsabilità anche del team leader, perché il team leader deve combattere con le armi che ha.Se una persona ha costantemente bisogno di supporto e che quindi che manda continuamente merge request pieni di merda, lì si fa un discorso per dire qual è il problema.Ma su questo siamo alleniati.Perché non stai performando, perché non stai dando un output decente.E il concetto di responsabilità in quel caso, quasi come colpa, quello è un argomento più complesso.Però, come detto, è un modo per responsabilizzare le persone.Poi bisogna sempre decidere, certo se tu responsabilizzi con il dito puntato, quello sicuramente non è… DL: sì sì, ho capito cosa intendevi, in realtà non si discosta molto dal mio ragionamento, è che io comunque guardo sempre tutto dalla prospettiva del team, quando ti dico responsabilità del team.Per me è responsabilità del team, ma la responsabilità collettiva è la somma responsabilità individuali.Le responsabilità individuali ci sono.Quello che volevo evidenziare io è che non è responsabilità tua che hai scritto la merge request ed è meno responsabilità di chi ti fa la code review.Sono due responsabilità diverse che si sommano perché è la responsabilità del team.Nel senso che prima sono stato brutale quando ho detto "se tu mi fai 4 PR alla cazzo di cane senza descrizione sei fuori.Forse è un po' troppo brutale, non è così, non è che butto fuori gente anche perché non potrei buttare fuori gente così alla cazzo di cane.Le cose scalano nelle varie gerarchie, però nel senso nel mio team funziona che ognuno ha le sue responsabilità individuali ma c'è la responsabilità collettiva che è quella più importante.Le responsabilità individuali si valutano in fase di review o di one to one, quando ci sediamo io osservo quello che succede perché mia responsabilità è osservare quello che succede e in fase di review a ogni X tempo che può essere due mesi, un mese, sei mesi, ci sediamo il sederino sulla sede e diciamo beh ascolta io ho visto che le manager request che stai facendo uscire hanno una descrizione che è una descrizione generata con, ci sto inventando, generata con chat gpt e spiegano quello che il codice fa al posto di spiegare l'obiettivo che vuoi raggiungere col codice.Oppure vedo che ci sono un sacco di type poi di rifusi dappertutto, oppure vedo che mi fai i commit message con scritto la la la fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa.Ecco, in quel caso la valutazione è una valutazione di natura individuale, va a impattare quella parte di responsabilità che tocca l'individuo, ma la responsabilità è del team e il contributo individuale alla responsabilità collettiva che va valutato.Fondamentalmente stiamo valutando le stesse cose, è solo la prospettiva dalla quale si guarda il punto, nel senso che per me non esiste responsabilità individuale senza una responsabilità collettiva.Seguendo il contesto della sola responsabilità individuale per me si fallisce.E' questa la mia premura più grande ed è per quello che batto tanto sulla parte di responsabilità collettiva, che per me è l'unica che vale veramente.Sì, alla fine non ci discostiamo molto dalla… Siamo praticamente allineati.Ovviamente davo per scontato che comunque in ogni caso vale… all'interno le dinamiche sono complesse ma dall'esterno ovviamente nessuno contende… la responsabilità, anzi, all'esterno la responsabilità sarebbe del team leader e basta.Però, come detto, le dinamiche sono molto di complessi.LM: Su quello a me piace costruire una narrativa.Sai, una cosa che ho imparato nell'ultimo periodo lavorando con grandi enterprise è che le narrative funzionano sempre.Quando parli con, che ne so, il project manager o le persone che gestiscono stakeholder tutti i giorni, ti dicono "ok, questa è la nostra situazione, perfetto, sediamo e sediamo sulla sede e iniziamo a scrivere giù la narrativa.Cioè cerchiamo di buttare giù la nostra versione dei fatti per portare tutti dalla nostra parte.Ecco, da quel punto di vista la narrativa che mi piace utilizzare è proprio quella che non può esserci una responsabilità sola del team di sviluppo.Anche in quell'ottica, coinvolgendo gli stakeholder.La responsabilità è di natura progettuale perché il team di sviluppo arriva fino a pagina due se il contesto e gli stakeholder non permettono di andare più veloci.Tu comunque, anche se hai 10 salvatori San Filippo della situazione, non vai da nessuna parte.Ho 10 super geni del linguaggio più complicato, non va da nessuna parte.È a quel punto che il pressare sulla responsabilità condivisa assume valore ed è a quel punto che l'over communication anche con gli stakeholder risolve il problema, così come il comunicare il più possibile col team, l'essere il più trasparente possibile su tutti i challenge col team aiuta.Anche l'over comunicare con gli stakeholder aiuta.Per esempio una cosa che ho trovato molto utile è quella di comunicare con gli stakeholder ogni potenziale problema che sta arrivando dagli stakeholder stessi.Ti arriva il PO che dice ok, Operation ci chiede quest'altra funzionalità, tu dici va bene questa è la nostra situazione, questo è l'impatto di questa nuova funzionalità e questi sono i rischi.Ride, tieni, anche se ride poi lo dovrebbe fare il product manager, però tu già glielo fai perché hai a cuore la delivery, quindi gli dice "eh, dalla nostra prospettiva questo è right" quindi sì, lo stakeholder sta mettendo un'interferenza esterna, ma occhio, io sto over comunicando, quindi se tutto va in merda non può essere mia responsabilità perché io ho over comunicato.tutti siamo...è la code review a livello stakeholder questa no? non ha mai funzionato veramente nel mio caso funziona, nel mio caso funziona poi magari ti dicono sì ma lo dobbiamo fare lo stesso e io gli dico sì ma è un fallimento sicuro, anche se c'è la regola di non dire mai "te l'avevo detto", io cosa faccio? Ho il documento salvato, quando arriva il momento io ho tale data, ho comunicato questo, io ho tale data...questo funziona in enterprise, dove il gioco del finger pointing va molto di moda.Però, insomma, tu sei trasparente, quello che stai facendo è tenere traccia delle decisioni e dei rischi, e essere completamente trasparente e poi alla fine credo che questa cosa in un modo o nell'altro, prima o poi paghi.Non so se il modo migliore, questo almeno è quello che faccio io praticamente tutti i giorni da 5 mesi a questa parte.LM: "il lavoro più difficile è quello di frenare e dire di no a tutte quelle richieste che tu sai che è un fallimento.Alla fine è sempre la tua opinione, o comunque per quanto informata possa essere rimane un tuo sentore, una tua opinione.Anche se essendo al motore abbiamo un grande, credo che abbiamo un grande sesto senso sulle cose che funzionano, che non funzionano.Non sempre, almeno nel mio caso, non sempre abbiamo ragione, però io personalmente quando provo a fare questo discorso il meglio che può succedere è "sì, sì, va bene, hai ragione, il giorno dopo".Allora la facciamo? Eh, vedi, vedi, sì, ti mando la mail, vedi però La cosa che mi hanno insegnato Filippo, il mio line manager, e Steve, il mio mentore, la cosa su cui hanno sempre insistito, tra l'altro ma non abbraccio a tutti e due, è di non dire no, perché io sono uno che tronca accorto, cioè sono uno che dice no, no, non funziona, specie con stakeholder molto demanding.E allora la cosa che funziona almeno in questo tipo di contesto è dire il "sì ma".Sì ma, questo è l'impatto, questo è il rischio, è sottof disegnare le due caselle tipo letterina d'amore degli elementari.Sì, no.Accetti il rischio, se no.Ma tu gli metti uguali, perché in quel caso stai forzando un'operazione di autoresponsabilizzazione e se questa cosa è scritta assume un valore, perché sai, la persona che ti torna il giorno dopo e ti dice "beh ma allora era un sì, vero?" La persona che fa così è perché non ha attentamente valutato o almeno potrebbe non aver valutato i rischi del sì.Mettendogli lì per iscritto e forzandolo ad assimilare quei rischi lui si sente, lui/lei, loro, si sente responsabilizzato, zatta zatti.- Vedi che la responsabilità singola alla fine.Ma è una responsabilità collettiva perché la somma della mia responsabilità che ti sto facendo le caselline sino è della tua responsabilità brutto stronzo di stakeholder che mi caghi il cazzo per farmi fare questa funzione che non serve a un cazzo ma che ti rende felice?" LM: "il problema, però, la maggior parte delle volte, almeno quando è successo a me, il problema era che non potevano valutare i fischi, quindi era la mia parola.E lì c'era, doveva essere anche una questione di fiducia.E anche lì mi è successo che non mi davano il giusto frame per poter dire il sì ma oppure il no convincenti.Perché se i rischi sono troppo tecnici, dispersione della code base o single failure point eccetera eccetera, sono rischi che si gli spieghi, si capiscono, ma non lo capiscono veramente.Questo almeno è quello che ho vissuto.No, no, non stavo, stavo nella startup, non stavo nelle single, nelle grandi enterprise, però questo è stato quello che ho vissuto anche abbastanza di recente.Vero, vero, però da quel punto di vista deve essere tu a costruire una narrative, devi essere tu a raccontare la storia di cappuccetto rosso che viene mangiato dal lupo.se tu gli dici "codebase dispersiva" o "adottare questo stack tecnologico ci crea problemi con l'onboarding" tu devi creare la narrativa e qua ritorniamo a quello che Eva mi fa tutti i giorni, cioè se Eva, la mia project manager, deve andare a un project sponsor, ok? Che è quello che ci che non si mette il grano per capirci nel progetto e gli devi dire ehi guarda che introdurre questa tecnologia eh fa eh introduce debito tecnico.Seva glielo dice così lui dice a me non mi fai un cazzo.introduciamo la tecnologia ma se gli dice arriva là con un grafficchino e dice costo dello sviluppo per ora, introduzione della feature per di grafico che con i dollari o con le stelline disegnate diventa in modo esponenziale e nello stesso livello disegna la linea del revenue e il project sponsor cambia completamente attitude.E' per quello che dico è un gioco di narrativa, di narrazione, non di narrativa, non sono più incapace di parlare italiano, porca palletta.Mi hai perso? Io ti ho perso, credo.No, adesso sì.Sì, no, hai ragione, non sempre è facile, non sempre la si trova, però è il lavoro facile.Esatto.Il lavoro che siamo tornati a fare.Anche perché non è facile perché non sempre ti danno tutto il contesto.A volte, vabbè, queste sono altre dinamiche, bisogna anche vedere gli interessi personali, ma queste sono altre dinamiche che esulteranno da altre, più generiche, dinamiche.Comunque Lu, abbiamo iniziato questo episodio dicendo "saremo brevi, dai facciamo una roba di 30 minuti" perché non era organizzato, è giusto una cosa al popolo.Si, mi voglio dire che mi sta aspettando ancora.Abbiamo finita con un'ora e mezza di sprolocchio.la cosa.Allora io direi di passare velocemente al momento dei donatori, di chi ci supporta, poi fare un palese dei balocchi volante.E bom, direi che ci siamo.ok ok è arrivato il momento di ringraziare chi ci supporta e fa sì che praticamente ogni settimana possiamo uscire con un nuovo episodio e tenervi compagnia, questa settimana abbiamo Alessandro Cortiana che ci invita a tre birre, tre birre capaci di aiutarci a sostenere i costi di mantenimento dei 70.000 servizi che ogni mese paghiamo ma che non intendiamo spendere o non siamo interessati a spendere in eventuali AI che chiudono i shu per conto nostro almeno per ora per cui se invece delle AI o invece di fare una donazione volete supportarci ci sono diversi modi c'è la donazione che insomma come ha fatto ha appena fatto Alessandro, oppure c'è la modalità che mi piace definire "time, talent and treasure", se pensate di supportarci con una donazione treasure c'è PayPal, ci sono le modalità del value for value, quindi bitcoin, lightning, whatever, oppure c'è sempre il talent and treasure, il talent and time, scusate.Tempo e talento, c'è il sito da sistemare, ci sono un sacco di cose da sistemare, per cui se vi fa piacere, ecco, pingateci e qualche emerge request, ci fa piacere sempre riceverla, in modo da migliorare anche l'insieme di tool a corredo del nostro appotecchio.Insomma, bando alle ciance, passiamo rapidissimamente al paese dei balocchi.Il paese dei balocchi è il momento in cui i nostri host e i nostri guest condividono con un libro, un film, o qualunque cosa abbia catturato la loro attenzione e pensino sia valuable, sia importante, possa essere utile essere condiviso con la nostra community.Quindi, oggi inizia Luca, la mia domanda è, hai qualcosa da condividere con noi? LM: abbiamo parlato delle procedure dei piloti di aerei e quindi mi è venuto in mente il libro "La caffettiera del masochista.Il design degli oggetti quotidiani" di Donald Norman.Un libro che sinceramente a me ha cambiato sostanzialmente il mio modo di vedere il mondo, in peggio ovviamente, e lo consiglio per capire tante cose per quanto riguarda l'esperienza.A me ha aiutato anche per la developer experience, sinceramente parlando.Quindi niente, mi è venuto in mente e oggi soltanto un balocco.Mauro tu hai un balocco? In realtà lo stavo cercando ma non mi è venuto nulla in mente.Questo periodo mi farebbe guardate di portare un CMS.Ne ho parlato a lungo qua nel nel podcast, ma credo che sia utile ricitarlo.Il tool è Directus, è un CMS headless che è un po' più di CMS, loro lo chiamano una data platform, quindi ha tutte le funzionalità il CMS headless, grafql, rest, sdk...non ce la posso fare oggi! sdk per scaricare i dati ma in più ha anche un'interfaccia super figa per il caricamento dei dati che è comunque tanta roba buttateci un occhio - Bene, bene, bene, bene, Luca.Oggi doveva essere una puntata rapida, invece è diventata lunghissima, praticamente.Cioè, noi possiamo impegnarci a farle brevi le puntate, ma quando non sono da solo, alla fine va sempre a finire un'ora e mezza.Io, boh, secondo me è qualcosa di metafisico ecco che ci spinge a questo durato.Esatto, è paradossale.Infatti quando ha detto "no dai mezz'ora, mezz'ora" ha detto "no no no, ma sì dai mezz'ora, proviamo questo nuovo format".Evidentemente non possiamo, ma ci amano così probabilmente.le nostre mogli sono un po' meno felici su questo comunque tra l'altro altra cosa da valutare, altro stakeholder da tenere in considerazione e per loro la responsabilità condivisa non è un'opzione è sempre colpa nostra.Finger pointing, cosa vuoi che sia? Grazie Luca, grazie davvero per questa chiacchierata che ci ha aiutato anche per mettere un po' in ordine le nostre idee su stakeholder, team, team lead, leadership e cos'è.Grazie.E grazie a voi che siete rimasti ad ascoltarci per...ti ho perso Lu, scusami, ma ho un lag orribile mandate lettere a orange telecom.No, se abbiamo un lag.Mandate lettere a orange telecom.Per le donazioni una connessione decente.Ho fatto, io non so se ve l'ho già raccontato, ho fatto domanda a orange telecom per portarmi la fibra a casa, devono fare uno scasso di circa 20 metri per portarmi la fibra a casa, perché devono portarla dalla cassetta al mio giardino, poi da dentro il giardino a casa ho tutto l'impianto fatto.Oragio Telecom mi ha risposto che vogliono 2.000 euro a metro di lavori sono 20 metri fate voi i conti se l'avessi saputo prima non avrei comprato questa casa detto questo io vi ringrazio nuovamente ringrazio di nuovo tantissimo luca per averci fatto compagnia per essere stato compagno di viaggio di questa fantastica discussione, noi ci sentiamo la prossima settimana.Ciao ciao! - Ciao! Ciao.Ciao!
