Prova, prova.Bene e benvenuti su Gitbar, nuova settimana e nuovo episodio qua nel bar degli sviluppatori.Questa settimana il bar è particolarmente affollato e questo mi rende molto molto felice.Infatti sono venuti a trovarci padroni di casa, la cosa suona un po' strana ma è così.Oggi abbiamo infatti con noi Andrea, Leonardo e Luca.Ciao ragazzi! Ciao Paolo, ciao a tutti.Ciao.Ormai le vacanze le abbiamo dimenticate, no? Quindi stiamo ritornando a regime belli pronti per la nuova stagione 2021-2022 di Gitbar.Ma non siamo soli.Con noi oggi abbiamo un ospite speciale.Prima però di svelarvelo, il mio solito ruolo da rompiballe è quello di ricordarvi i contatti.quindi info@gitbar.it è la nostra email, naturalmente gitbar.it è il nostro sito @brainrepo è il nostro recapito twitter.Contatti importanti ma mai? Quanto? Il gruppo telegram.Il nostro gruppo telegram, esatto, il nostro gruppo famiglia dove ogni giorno ci scambiamo idee, pensieri, rant, un po' di tutto insomma.Se non l'avete ancora fatto perché so che molti di voi non si sono ancora iscritti mi raccomando facetelo ma detto questo io non voglio tirarla alle lunghe e direi che possiamo iniziare naturalmente dopo la sigla benvenuti su github il podcast dedicato al mondo dei full stack developer i mezzo artigiani, i mezzo artisti che ogni giorno infilano le mani nel fango per creare nel modo più efficiente possibile quei prodotti digitali che quotidianamente usiamo.[Musica] [Musica] Eccoci qua.Andrea, so che ci volevi presentare un amico.Esatto, esatto Mauro, esatto.Non è vero, non lo conosco! Sei già il secondo che fa così.[Risate] Ci ritrovo oggi tu.Ne ha portati due, quindi non...Due sono più.con un recito di ogni 700 anni una alla volta ma non sapete ancora il nome, state ascoltando soltanto la sua voce è riconoscibilissimo secondo me non esageriamo se ora mi vibra il telefono e qualcuno ci sta sentendo live che non si sa, che hanno bugato la registrazione di Mauro che lo sta lanciando su Twitch e lo sta streammando mi può scrivere e vediamo se è indubito A parte gli scherzi, cosa dire del nostro ospite di oggi? Ho voluto fortemente la sua presenza ai microfoni di Geekbar perché porta un bagaglio di esperienza un po' particolare, un punto di vista completamente differente dal classico tecnico sviluppatore.Sì, è stato uno sviluppatore pull stack, qualcosina forse lo fa ancora ma si è evoluto in altro che al tempo stesso questa evoluzione lo ha portato ad essere un grande mentore, un grande divulgatore ed oratore, è un consulente strategico, gli piace definirsi così, sì lavora nella consulenza ma in quella che io chiamo la consulenza fatta bene ed è anche un cantante ma non credo che oggi sia il posto giusto dove parlarne.Infine spoiler è anche uno scrittore? Sì, ha scritto un libro, in molti mi dicono che sia bellissimo, io purtroppo non ho ancora avuto modo di leggerlo, è in coda nel mio Kindle, ma rimedierò al più presto e quindi andremo a parlare di tutto questo insieme a lui, bando agli idulci oggi e qui con noi Jacopo Romei.Ciao, ciao Jacopo, che presentazione roboante, troppo! Eh, docca! Per le docce! Eh questa volta me la sono un po' preparata, di solito capito mi cogli impreparato, Mauro oggi ha detto "te lo frego io" allora mi sono buttato un po' di note così.Eppure è così, anche se devo dire che è una cosa che ritorna spesso, io sono andato un po' a cercare, esplorare sulla tua figura e sulla tua carriera, pensa ho beccato dei talk vecchissimi e ne parlevamo in pretrasmissione, io ricordo benissimo un tuo blog post dove raccontavi come si facevano le cosine in action script quindi mi stavi simpatico da tempo però la mia domanda è oggi da ieri che eri sviluppatore, oggi che sei un consulente strategico diciamo così come è cambiato il tuo lavoro? Allora mi stai chiedendo perché è cambiato o come è cambiato, nel senso come si è evoluto e cosa è diventato.Allora intanto il motivo che ha spinto a questa metamorfosi e poi soprattutto le evoluzioni non sono mai dall'oggi al domani complessive ma ci sono dei tasselli che suappiamo giorno per giorno non sostituiamo giorno per giorno e che poi ci portano a essere quello che siamo.Allora, innanzitutto cominciamo dal perché, che in genere è epicentrico l'approccio, nel senso che se capiamo il perché probabilmente poi capiamo anche come.Allora, il punto è, io sono, è vero, 1996 è stata la prima volta che sono stato pagato per fare software e ho fatto software l'ultima volta pagato nel 2014, quindi diciamo quasi per 20 anni.D'altra parte, lo dico subito tanto per ringraziarmi gli ascoltatori più nerd l'ultima volta che ho scritto codice è stato adesso è settembre cinque mesi fa ad aprile mi sono stampato un robot esapode con 18 servocomandi e ho scritto tutto il software per radiocomandarlo con il controller di una ps2 super nerd infatti quindi era per dire il codice è ancora una cosa che che mi piace fare a me piace molto programmare Allora, però, e uno dice "Ah, perché hai smesso di farlo per lavoro?" Allora, non sono scappato dal codice, assolutamente, e anzi ho combattuto insieme a personaggi tipo Gabriele Lana e tutta la community agile dei primi dieci anni di Manifesto Agile in Italia, abbiamo combattuto una lotta, una battaglia, una guerra ben precisa per condannare questo fenomeno.Un programmatore spesso, e non è solo un fenomeno italiano, per guadagnare di più deve smettere di essere uno sviluppatore e darsi al project management, al product management, all'architettura del software, ok? Cioè deve cambiare nome.Se sei uno sviluppatore, cioè questo è proprio il cito Gabriele Lana, a 43 anni se sei uno sviluppatore ti dicono "ah, sei ancora uno sviluppatore?" come se fosse un lavoro dishonorevole.E in realtà, cioè l'impatto, e non starò qui ad argomentarlo, lo diamo per scontato in questa sede, l'impatto che uno sviluppatore può avere su un business è enorme, ok? Non voglio arrivare a a concetti che sono stati anche piuttosto controversi, non voglio arrivare a dire che ci sono le rockstar developer che valgono per i time stand developers, però è vero che la resa di uno sviluppatore può essere molto alta, quindi non sto assolutamente parlando del paragone con gli altri sviluppatori, ma indubbiamente uno sviluppatore può diventare una persona che crea un sacco di valore per il proprio latore di lavoro o per se stesso, dove per sé stesso è una dichiarazione corroborata dai fatti, cioè fra le prime 100 persone più ricche del mondo gli sviluppatori, forse è il lavoro più ricorrente, tipo uno dei 5 più ricorrenti, ok? Parlo dei vari, va bene, insomma, dai, i nomi tipo Bezos, Big e Gates, ok perfetto.Va bene, va bene, va bene, va bene.Però il punto è, quindi non ho smesso di fare lo sviluppatore perché mi ero rotto, ok? Ho smesso di fare lo sviluppatore perché in realtà io non mi sono mai visto come uno sviluppatore in quanto tale, ok? Nemmeno nel '96.Cioè per me era uno degli strumenti, una delle attività chiave con cui erogare valore che avesse sia un valore commerciale per chi mi comprava, sia una sostenibilità in primi se emotiva per me, a me non piace fare lavori che non mi piacciono, dici è è un po' ovvio, è consentito un minimo di turpilogio, posso dire tipo che ne so, grazie a c***o se voi ci mettete il bip sopra, ok perfetto, quindi grazie a c***o che ti piace, è tautologico no? Mi piace fare quello che mi piace, però occhio perché c'è un sacco di gente che invece fa lavori che non gli piacciono.Quindi ho cominciato a fare lo sviluppatore perché c'era un'opportunità, erano gli anni '90, ho beccato un'onda pazzesca, io comunque il primo codice che ho scritto era l'84, io ho detto che il '96 è stata la prima volta che sono stato pagato.Io sono un nerd, cioè proprio Stranger Things, io sono uno di loro, sono quelli con la BMX versus bicicletta col sellino lungo, io sono BMX, ok? Bene.Però il punto era, quando poi nel 2003, poi nel 2006, poi nel 2011 ho fatto l'imprenditore, sempre in contesti legati al software, comunque emergeva proprio come il valore da creare per i clienti non dovrebbe essere mai legato ad una specifica attività, ma dovrebbe essere legato al bisogno che io posso risolvere o sostenere a seconda per il mercato e per i clienti che sono là fuori.E a un certo punto è emersa per me la possibilità di creare più valore in un altro modo.Invece di risolverti il problema di automazione da singolo sviluppatore, se vedo, intravedo, facciamo così, meglio ancora, facciamoci guidare dal mercato, se qualcuno mi chiede di comprare le mie competenze di organizzazione di 5, 6, 10 sviluppatori, oppure degli sviluppatori più dei designer, oppure di concepire come venga portato sul mercato un prodotto digitale, se lo so fare, oppure se qualcuno pensa che io lo sappia fare e poi sono soddisfatti, effettivamente questo impatto mi permette questa professionalità mi permette di avere un impatto maggiore sul mercato e di conseguenza non lo nascondo di essere pagato di più ok chiarissimo permettimi di agopo sì e in tutto questo ovviamente tu partivi dalla parte dev ti sposti di scrivania e diciamo anche avvicinandoti al business no dall'altra parte e quindi secondo te cosa cambia tra questi due punti di vista? Cioè che cosa davvero ti hanno portato a fare tutta la serie di ragionamenti e le esperienze da una parte e dall'altra? Allora ti rispondo subito, ma prima faccio una puntualizzazione sulla premessa ed è io mi sono spostato a un certo punto.In realtà i due binari sono sempre scorsi in parallelo per me perché io comunque nel 2003 la mia prima azienda era un'azienda, avevo dei dipendenti, avevo 23 anni, cioè comunque non era esattamente...poi non avevo ereditato dalla famiglia nessun imprenditore in casa, ok? Quindi proprio non è una cosa che ho...quindi il problema del business disaccoppiato dal codice in realtà in me, io non l'ho mai vissuto, cioè per me era sempre impresa, ed era un'impresa in cui alcune cose potevo delegarle e alcune cose no, e quindi continuavo scrivere codice per esempio.A un certo punto questo regime imprenditoriale si è visto appunto delle opportunità non legate a delegare la scrittura del codice ma a creare valore in un altro modo e quindi la tua domanda qual era? Ritimila uguale così rispondo precisamente.Ci stavi arrivando proprio nel senso cambia il punto di vista per individuare e spingere sul valore no? Quindi quali sono questi due punti di vista per arrivare al valore in un ambiente? E' questa dicotomia che non vivo, cioè proprio questa separazione di punto di vista secondo me è funzionale solamente al mantenimento di una differenza fra professioni in un mondo in cui ciò che fai è più importante del perché lo fai.Mi spiego, se io sono un imprenditore devo risolvere, si suppone un problema per il mercato per una certa categoria di utenti qualcuno da qualche parte deve iniettare denaro nel mio sistema in modo tale che ci sia una plusvalenza fra revenue, farricavi e costi ok? questo è il compito dell'imprenditore che poi può assumere un aroma digitalizzato, un aroma frutti vendolico oppure designer, ci sono un sacco di lavori e sono tutti rispettabili, si creano valore, ok? Lo sviluppatore è quel soggetto a cui già 15 anni fa, appunto quando ero ancora io stesso uno sviluppatore, si chiedi in una conferenza, diciamo sei ad una conferenza super techy, pieno di nerd in aula e tu gli chiedi "qual è il vostro, il valore che producete?" Il codice, il valore che producete, tutti ti rispondono di sì.E questa notate bene, è una premessa per la seconda metà della telefonata dell'intervista di oggi.Però intanto rimaneva...Me ne dia un chilo, no? Me ne dia un chilo, cioè il punto è se conoscete la Business Model Canvas che è uno strumento diciamo per descrivere il business model in nove blocchi, popolari, inventato, reso popolare da Alexander Ostellwalder nel libro Business Model Generation ora, lui pone una differenza fra la cosiddetta value proposition di un lavoro e la key activity.Ora, Voglio fare breve.Il motivo per cui uno sviluppatore viene pagato non è scrivere codice.Perché, se ci pensate, se il valore fosse quello, verremo pagati per creare più codice possibile e invece sarete d'accordo che l'eleganza degli algoritmi, uno dei parametri estetici e funzionali e di performance del codice che scriviamo è, meno codice scrivo, indicativamente, a parità di problema risolto, meglio è.significativamente perché poi ci sono dei problemi di sostenibilità di lungo termine per cui non puoi scrivere una porcata qualsiasi, ok, però c'è un compromesso, non è che non veniamo pagati un tanto al chilo appunto come diceva Mauro, nel senso, notate bene.Per risolvere problemi.Per risolvere problemi, cioè per automatizzare, proprio lui ha proprio una frase proprio pre-programmata ed è "per automatizzare soluzioni a problemi analizzati una volta sola.Quindi il punto è, se tu hai a cuore questo punto, anche come sviluppatore, te ne frega di meno, per esempio, del fatto di scrivere codice o meno, e dopo ci torneremo, o per esempio, ti frega di meno di quale stack utilizzi, per esempio.Io, allora, diciamo, lo stack su cui ho fatto più soldi, perché è l'unico modo in cui mi sento di definirlo, perché non è quello "ah mi è piaciuto di più" è stato PHP e JavaScript, ok? Nell'epoca in cui PHP era ruggente, ok? Tra il dubbato...- Qui mettiamo una "ola" ovviamente.- Sì, sì certo, certo.Ora, a un certo punto mi ricordo quando facevo ancora conferenze da sviluppatore, tipo nel 2013, quando si avvisava un certo passaggio della moda di PHP, la gente chiedeva "ah ma come ti vivi l'eventuale declino di PHP?" E io rispondo "ma che me frega!" cioè il punto è se hai imparato a scrivere codice bene in c++ in java in php in javascript e in ml cioè il nuovo linguaggio di programmazione sarà una lo impari cioè non è un problema non c'è affetto non ci deve essere affetto non ci deve essere affetto per il linguaggio di programmazione per le architetture per le tecnologie e nemmeno per la nostra professione Dico nostra come se fossi ancora un sviluppatore.Notate bene, io non avevo affetto nemmeno per le mie aziende, le aziende sono dei dispositivi per fare reddito.Il nostro lavoro non dovrebbe definirci come persone ed è un mezzo per avere una vita.E questo poi, se volete, apriamo tutto il capitolo del work-life balance, eccetera, eccetera.Però per me il lavoro è sempre stato un mezzo per avere una vita che mi piacesse.Per questo anche il lavoro deve essere bello, notate bene.Quindi non è...C'è gente che fa un lavoro orribile per poi andare in ferie quattro settimane l'anno pagarsele.Ma qual è il ritorno di investimento? Parliamo proprio di 11 mesi l'anno per fartene uno, ma fai il contrario.Lavora un mese per andare in vacanza a 11, è difficile, lo so, ma almeno come ambizione.E di conseguenza anche il mio lavoro attuale, che non è molto ben definito su LinkedIn, adesso vi spiego perché, è uno strumento, non c'è un particolare affetto.Prima Mauro ha citato, presentandomi, oppure noi, era Andrea, dicendo "Ah, sul LinkedIn è consulente strategico".Io una volta avevo scritto altre cose più precise su LinkedIn, però questo è proprio interessante, cioè c'era scritto a un certo punto "Per tanti anni agile coach".Io passavo il tempo a rispondere alla gente che cercava un coach agile sulla base della definizione di agile che loro avevano in testa.Pensate che sforzo immane, tutti i lead falsi, tutta gente, tutti i potenziali clienti che non erano potenziali clienti.Quelle sono ore di vita sottratte a me stesso.Perciò metto su LinkedIn "consulente strategico" che non vuol dire nulla, mi rendo conto, ma così tanto chi viene su LinkedIn già sa chi...cioè non mi trovano sul linkedin scusate non mi cercano sul link è il contrario facciamo così la faccio pace con me stesso non è che mi trovano sul linkedin dopo aver fatto una ricerca generica ma mi cercano sul linkedin dopo aver saputo di jacopo in un altro modo a maiari a jacopo arrivano meno clienti ma tanto quanti clienti volete avere nella vita c'è 24 ore al giorno di cui si suppone almeno 16 li utilizzate in un altro modo oltre che lavorare quindi questa è la risposta articolata pippone concluso? Hai citato Agile, in realtà Agile è un elemento che ricorre quotidianamente nelle nostre vite.Sono grato al manifesto agile.E allora io ti voglio fare questa domanda.Agile, secondo Jacopo, cosa è oggi in quello che vede nelle aziende e invece cosa dovrebbe essere secondo la sua visione.C'è una discrepanza tra questi due elementi? Tra queste due realtà, una che è quella che riusciamo a vedere nelle aziende e una che è quella che in qualche modo hai nella tua mente? Allora io lo so che questa domanda presuppone che io abbia un'immagine catastrofica dell'agine nel mercato mainstream.In realtà non la penso così.Io la penso un po' così.Allora, faccio un'analogia, ok? Un'analogia forte, che faccio proprio per rispetto di certi problemi, in modo tale che poi noi possiamo parlare del nostro problema, che è troppo più piccolo, ok? Allora, la schiavitù nel mondo occidentale, grosso modo, è arrivata fino all'Ottocento, ok? Quella ufficializzata, sto pensando agli Stati Uniti, ok? Come riferimento.Poi si può discutere in un sacco di casi.Però il punto è che, grazie a Dio, è finita.Questo ha concluso ogni manifestazione di razzismo nella vita quotidiana? Assolutamente no! E c'è un problema gravissimo da questo punto di vista, ok? Per tutto il '900 e anche adesso.Torniamo all'agile.Allora, l'agile oggi se tu ne parli, nessuno dice come invece era 15-20 anni fa, al ridosso della scrittura del manifesto, "Ah, ma cosa state dicendo?" ridicolizzati dalla gente che invece stava lì e voleva pianificare rilasci software a dieci anni.Waterfall supremo proprio.In generale c'era proprio questa...noi eravamo trattati come una popolazione inferiore e notate sto facendo proprio questo riferimento alle supremazie ok? bene.oggi il messaggio dell'agile è vissuto in maniera diversa, migliore secondo me ed è un po' come lo sport serio cioè nessuno dubita che andare in palestra faccia bene e nessuno dubita che se comunque ti alleni se vuoi mettere su muscolatura e fai l'allenamento giusto la muscolatura crescerà se vuoi aumentare la resistenza e fai l'allenamento giusto la resistenza aumenterà, nessuno dubita che se fai il disciplinato come l'agile prevede, tu riesca a migliorare il modo in cui scrivi codice in questa sede e io generalizzo, crei prodotti digitali.Il problema è che oggi, come nello sport serio, manca la volontà di, come dire, di accettarla quella disciplina.Tutti sanno che se scrivi test automatici le cose vanno meglio.Poi dopo di che, esattamente come la gente sa che il fumo fa male e non smette di fumare, sa che fare sport fa bene e non va in palestra e non va a correre, così la gente sa che l'agile comunque è meglio delle cose fatte a cazzo di cane come vengono fatte oggi, però poi siccome ci vuole energia, sforzo, siamo in opposizione al secondo principio della termodinamica per cui bisogna spendere energia, allora poi la gente si inventa gli alibi per non farlo.Però è una situazione migliore della situazione in cui la gente dicesse, immaginate l'analogia, "No, no, no, ci sono razze inferiori e possiamo dirlo mainstream".Oggi la gente è costretta a dirlo di nascosto, pure chi raccoglie i voti di chi lo pensa non lo dice apertamente.Oggi nessuno dice "lo sport fa male".Capite? Cioè quindi il messaggio mainstream è quello giusto, l'agile risolve e poi la gente nel privato, semipubblico delle aziende, trova degli alibi per evitare di fare quello sforzo aggiuntivo o quello sforzo che nel caso della società razzista è di inclusione, nel caso, sempre continuando l'analogia, non sto dicendo che sia la stessa cosa, e nel caso dell'angile è lo sforzo di andare in palestra tre volte a settimana.Voi andate in palestra tre volte a settimana, se mi rispondete di no, per me sa, Andrea dice di no, Mauro dice di no, amen, però non vi aspettate risultati da chi invece in palestra va 5-6 volte a settimana, giusto? L'agile è uguale, la gente che non vuole fare agile dovrebbe stare serena con il fatto che otterrà quei risultati, soprattutto quella qualità di vita per sempre, shalla, ma non finì da rompanoi, ma infatti nessuno ci rompe più, tant'è che i clienti che chiedono di sviluppare prodotti digitali, creare prodotti nel modo che a me piace di più ci sono me lo chiedono e notate bene sono abbastanza da permettersi di scordarsi gli altri ed è questa la migliore notizia se uno vuole lavorare solamente con clienti giusti lo può fare deve avere il coraggio di dire di no a quelli sbagliati però e questo eccoci qua parlando di alibi eccetera eccetera il colpo il colpa colpa non è mai del mercato la fori è pieno di clienti potete lavorare con chi volete se vi scegliete la gente giusta se continuate a lavorare per gli integratori pachidermici non faremo nomi che continuano a fittare gente che poi dopo nove mesi si licenzia e c'è un turnover pazzesco qualunque cosa insegno io da senior oggi a un giovane programmatore questo poi se ne va via e questa conoscenza dell'azienda viene dilapidata in questo modo.De che stiamo a parla? Secondo di buone concluso.No vabbè tra l'altro parlando di questo tipo di aziende avrai sicuramente triggerato Carmine che ci sta ascoltando da casa in questo in questo episodio e che da tempo sventola proprio la bandiera di questa battaglia quindi ne approfittiamo per salutarlo.Ma ci tengo, non è una crociata, questo è un po' più importante, cioè se la gente vuole lavorare, siamo liberi, se la gente vuole lavorare in un posto orribile è libera di farlo, ma non mi venga a dire che allenarsi tre volte a settimana sia meno salutare che non fare sport per sette anni di seguito.Ok? Però permetti anche di dirmi che non puoi prendere il manifesto e calarlo in tutte le aziende? No! Nel senso anche perché forse dovrebbe essere più il contrario che l'azienda si adatta a ciò di cosa può prendere da quel manifesto per migliorare.Ah voglia! Ma infatti guarda che bella cosa come dire riappacificante che ti dico.A parte già il messaggio che ho trasmesso fino adesso spero sia non di conflitto al contrario.Sì sì sì.Ma lo estendo, lo rafforzo.Io quando mi chiedono di definire l'agile uso la definizione di Claudio Perrone che se mai ascolterà questo podcast saluto.È un amico, vive a Dublina, italianissimo però lui è uno diciamo, lo trovate su Twitter come Agile Sensei, vi dico solo questo.Bene.Ora, la sua definizione di agile è, io la amo, la uso sempre, è quella che uso di più, Ed è la frequenza con cui un individuo o un'istituzione apprende lezioni sul proprio operato.La cosa bella di questa definizione è che innanzitutto è, notate è end to end, no? Cioè in qualunque modo tu impari queste lezioni, con esperimenti in carta intervista agli utenti, o con spike o con test automatici sviluppati prima del...in qualunque modo ti procuri questo feedback, va bene.Ma la vera figata di questa definizione è che è relativa.Cioè noi stiamo dicendo, grazie a questa definizione, che là non c'è un agile e un non agile.L'agilità è una misura di quella frequenza, perciò più lo fai frequentemente, meglio è.Quindi se fino ad oggi noi abbiamo fatto il punto end to end sullo stato dell'art della nostra produzione di un prodotto digitale, e l'abbiamo fatto una volta all'anno, se cominciamo a farlo una volta a trimestre, che potrebbe essere pochissimo da certi punti di vista, potrebbe essere super lento, siamo quattro volte più agili di prima.Così come se oggi facciamo un rilascio ogni due settimane, passare a fare un rilascio ogni due rilasci alla settimana significa essere quattro volte più agile.E il nostro obiettivo, se ci teniamo alla performance, è avere questa frequenza il più alta possibile.Esattamente come se una persona deve correre i 100 metri, o i 5000 metri, vuole il tempo più basso possibile, ma a partire dal tempo, dal primo tempo misurato, se avrò 60 anni sarà normale fare un certo tempo, se ne avrò 12 avrò un certo, un altro, un altro numero sarà plausibile, se avrò 26 anni i 100 metri li farò in 980 e vinco l'Olimpia di me, chiamo Jacobs, ok? Però l'obiettivo, se ci interessa l'agonismo sui 100 metri è abbassarlo quel tempo, che io sia in classe cadetti master o professionista, ok? E così è uguale, se ci interessa l'agile noi prendiamo il manifesto e lo interpretiamo come quattro drittone per aumentare la frequenza con cui ci proporiamo feedback e quindi va bene per le banche monolitiche e per la startup nel garage che fa sette rilasci al giorno.In realtà la parola chiave l'hai detto prima, lavoro, cioè l'agile una volta che lo hai capito, lo hai compreso, ti è calata dall'alto o è cresciuta dal basso, alla fine devi comunque lavorare, cioè devi andare quelle tre volte a settimana in palestra perché è un continuo lavoro.Ma certo, tutto un movimento cugino, anzi proprio fratello del movimento agile è quello della software craftsmanship, ok? Cioè dell'artigiano del software.Ragazzi se non è questo un riferimento al fatto che io affino la mia tecnica attraverso la pratica lungo gli anni di espressione della mia professionalità non capisco cos'altro.Chiaro, chiarissimo.E da qui poi mi piace ritornare sempre sulla figura dello sviluppatore.e già anche l'implementazione di Agile all'interno della nostra azienda un po' ci porta gli occhi fuori dal codice, cercare di capire il contesto, che è quello che secondo me è più importante.Secondo te quali sono gli strumenti che un sviluppatore può utilizzare? parlo di strumenti non pratici non fisici i meccanismi che uno sviluppatore può attivare per facilitare il passaggio da fully focused sul codice a capire un contesto più grande in un'ottica di generare valore.Poi una risposta precisissima.La retrospettiva agile in cui ha luogo una analisi delle cause a monte, delle root cause.Dobbiamo essere amichevoli, friendly e usabili per tutti gli ascoltatori.Quindi c'è qualcuno che avrà già capito cosa sto dicendo, chiariamolo bene.Allora, la retrospettiva è un momento in cui i team che intendono raccogliere quel feedback ad alta frequenza sul proprio perato, smettono di lavorare un'ora, due ore, una giornata, dipende da quanto frequentemente lo facciamo, eccetera eccetera, ma ci chiediamo come lavoriamo, ok? Cioè la retrospettiva è quel momento in cui io esplicito lo standard di lavoro e poi, avendolo esplicitato, posso migliorarlo, ok? Bene.Poi se volete approfondiamo, adesso non voglio dilungarmi troppo.All'interno di questa retrospettiva, che di tutte le pratiche distillate nei vent'anni, perché ragazzi 2021 sono vent'anni della scrittura del manifesto, in questi vent'anni di manifesto agile la pratica della retrospettiva agile è l'unica per me obbligatoria, diciamo, cioè tutte le altre sono opzionali, quella come dire che fa il problema di bootstrap a dei nerd come noi ci possiamo attaccare a questi concetti, cioè, cosa c'è scritto nella e-prom di un team agile? Cioè il rituale della retrospettiva, ok? Da lì poi possiamo discutere tutto il resto, però ciclicamente mi devo fermare e parlare di come sto lavorando, se no non parlo mai di come lavoro.All'interno della retrospettiva una delle tecniche classiche è quella del 5 why, dei 5 perché, diciamo in generale tecniche per analizzare la causa a monte, sistemica di un problema.Per esempio, esco tutti i giorni di casa bagnato quando piove.Perché? Perché? Perché mi scordo l'ombrello.Ok, perché? Perché esco di corsa.Ok, perché? Perché mi sveglio male la mattina e rimando la sveglia.Ok, perché? Perché vado sempre a letto tardi.Ok, perché? E arriva la fine e dico perché mi ubriaco tutte le sere.Ah, fai una cosa.Smetti di ubriacarti, risolviamo questo problema e risolviamo un'intera famiglia di problemi tra cui quello di uscire di casa col temporale e bagnarti perché ti sei scordato l'ombrello.Ok? Questo è un esempio stupidissimo, ma gli esempi devono essere stupidi, perché se no diventano...non so più esempi, sono la cosa reale.Bene.Quindi, fare un ragionamento di questo tipo, cioè chiedersi quale sia la causa o il monte dei nostri problemi, permette ad un gruppo di sviluppatori, anche in assenza del business, anche in assenza di designer, anche in assenza di altre professionalità, di chiedersi "Ok, c'è stato questo problema durante il rilascio di giovedì scorso".Ok, perché? Vi faccio proprio un esempio biografico.post mortem.Vi faccio un esempio biografico.Ok, perché abbiamo consegnato il ritardo? Perché c'era una scadenza.Se non ci fosse stata una scadenza non ci sarebbe stato nessun ritardo.Perché c'era una scadenza? Perché il cliente ha bisogno di una scadenza.Perché il cliente ha bisogno di una scadenza? Perché non si fida e vuole essere sicuro che investa i suoi soldi su un team affidabile.Perché ha bisogno di questa affidabilità? Perché non gliela diamo in un altro modo? Perché non gliela diamo in un altro modo? Perché c'è scritto da nessuna parte se siamo stati bravi o no a fare il nostro lavoro? Allora facciamo una cosa, andiamo a parlare alle conferenze e andiamo a far vedere che la nostra azienda è un'azienda che è in grado di scrivere software serio e anzi magari organizziamole pure le conferenze.Nell'epoca d'oro del PHP User Group, la mia azienda organizzava, uno degli sponsor principali della più grande conferenza sul PHP in Italia, perché? Perché era un modo di esporre la nostra qualità e preacquistare la fiducia dei nostri potenziali clienti e avere meno problemi nel poter, e poi questo è stato proprio il terreno in cui è partita la miccia, nel poter scrivere poi contratti meno basati su uno scope fisso e in cui fosse più possibile avere, più facile avere uno scope negoziabile.Lo scope negoziabile cioè un set di feature che non è detto che sia esattamente quello purché si risolva il problema che il cliente ha e ci siamo riconnessi con il discorso che facevamo all'inizio chiarissimo chiarissimo grazie e con questo ci hai aiutato diciamo a capire come poter sfruttare le pratiche agili per migliorare l'ansia la retrospettiva è stata proprio la sede in cui ho capito che era inutile, la faccio proprio un riassuntone, era inutile continuare a parlare di test automatici e di duplicazione del codice e di usiamo la dependency injection o no, all'epoca se ne parlava, quando in realtà il problema, la root cause di un sacco di problemi era il cliente che non aveva capito per esempio che se fai una startup è difficile pianificare le cose a nove mesi e quindi ogni mese dobbiamo cambiare lo scope delle funzionalità.Quindi il contratto va corretto, non il test automatico che è un problema se il test automatico cambia continuamente.No, era fisiologico.Ci punivamo per aver fatto la cosa giusta, cioè cambiare la funzione del nostro software in base alle nuove informazioni che raccoglievamo insieme al cliente dal mercato.Ecco, per rispondere proprio a Mauro, come dallo sviluppatore siamo passati a pensare a tutta la filiera.Sì, sì, no.Io posso portare anche un'esperienza.da qualche tempo sto lavorando con un team su un prodotto, non posso dire granché, però nelle tech demos, quindi le demo interne tra i vari team di sviluppo, ho notato un pattern che rendeva le demo stesse noiose, statiche, molto flat.L'esperimento che ho voluto fare è stata quella di portare nella tech demo, ancora prima della feature, il valore.Quindi evidenziare il valore e poi raccontare la feature.Questa cosa ha fatto...ne ho già parlato in un altro episodio di Gitbar...Ah, in qualche modo, dicevo, ha dato qualcosa in più alla consapevolezza alcuni miei colleghi che erano concentrati sul ticket e non sul valore che stavano generando quindi c'è proprio il passaggio di alzare gli occhi dal computer e capire dove stai andando e dove stai andando a farlo cosa stai facendo e perché lo stai facendo ancora prima di farlo quindi da quest'altro punto di vista mi piaceva proprio evidenziare il fatto che il valore generato può essere da una parte consapevolezza esatto poi ce lo citi perché siamo un podcast audio e non riusciamo a vederlo, però da una parte lo sviluppo della consapevolezza, dall'altro questa stessa consapevolezza può essere un boost anche in termini di produttività perché hai uno stimolo senza dubbio maggiore.Perché? Perché gli effetti pratici di quello che stai facendo sta dicendo a te stesso? Stanno dicendo a te stesso sì ma allora sto facendo qualcosa che ha senso qualcosa che vale qualcosa che è utile.Esattamente esattamente non c'è niente di più gratificante in qualunque ruolo da sviluppatore da cantante in una band o prodotto oner di un prodotto digitale di vedere gente che non conosci che adotta il tuo servizio, che lo compra, che lo scarica, che lo installa.Assist perfetto perché ovviamente ora abbiamo visto tutte queste pratiche per avvicinarci al prodotto e capire come migliorare e portare più valore al prodotto.Ritorniamo sulla persona, sul singolo, ok? Cosa invece potrei fare per capire io se il mio lavoro porta davvero valore.Gli stessi strumenti mi potrebbero aiutare a capire sul singolo, su me stesso o c'è altro? Questo è un po' difficile capisco.È difficile no, però è una domanda a cui ho risposto, sto cercando una sintesi, ok? Mi sto chiedendo quale sia la risposta che posso dare in questo spazio.Allora, il primo pensiero che ho fatto è se c'è qualcuno che te lo paga sta generando valore superiore per qualcun altro.Questo è proprio fondamentale.Cioè se qualcuno te lo paga per quella persona vale almeno tot e questo vale per esempio, notate bene questa è una posizione controversa che potrebbe...Ma dipende se lo faccio.Sì sì sì, certo certo, però per esempio ai calciatori sono pagati troppo, se qualcuno li paga qualcuno sta facendo più soldi di quelli che fa sui calciatori, quindi o mettiamo in discussione il sistema calcio nel suo insieme oppure è inutile prendersela con l'unica manifestazione visibile dell'intero sistema, ok? Bene.Quindi, una cosa che è molto difficile, noi lavoratori intellettuali non seriali, in inglese è più facile, non abbiamo questo problema, creiamo un valore di business che spesso è impalpabile.Dopo vi consiglierò non solo un libro, ma anche più di uno, e uno di questi è proprio dedicato a questo tema.Non voglio fare spoiler, a meno che non mi chiediate di farlo, però il punto è il valore che noi creiamo è difficilissimo stabilirlo, concretizzarlo.Questo è proprio anche un problema legato a un sacco che affronto quando faccio per esempio i miei workshop sul risk management per i freelancer.Ok? Cioè i freelancer hanno questo grosso problema.Sono la mia persona, con tutte le mie competenze, lavoro per un cliente.Quanto mi devo far pagare? È un casino perché non c'è quasi mai una misura oggettiva del valore creato.Quando c'è, è incredibile quanto spesso lo ignoriamo.ok questo è un difetto di noi esseri umani che lavoriamo, di noi knowledge worker, ma molto frequentemente è impossibile.Bene, sicuramente è possibile però chiedere, per esempio una cosa che facevo io l'ultimo anno che sono stato un lavoratore dipendente, io facevo ogni mese un sondaggio particolare secondo un formato che si chiama NPS, Net Promoter Score, che si usa in genere per i prodotti, sapete quella, sicuramente vi è è arrivata questa domanda a un certo punto nella vostra mailbox.Quanto consiglieresti il prodotto X a amici e parenti? Perfetto.Io questa domanda l'ultima volta che ho fatto il lavoro ed era dipendente, quindi in realtà mi davano un salario, quindi la mia performance finanziaria non dipendeva direttamente dalla qualità del mio lavoro, però mi interessava sapere quale fosse il valore generato per i miei colleghi.Io mandavo a tutti i colleghi con cui avevo lavorato nel mese di ottobre, alla fine di ottobre mandavo un...sulla base di quello che abbiamo fatto insieme a ottobre.Quanto consiglieresti il bla bla bla bla bla bla bla bla bla? E se il punteggio non era massimo gli chiedevo "Ok che cosa potrei fare per generare...che cosa avrei potuto fare?" Era retrospettivo."Quindi cosa avrei potuto fare per avere un punteggio più alto di quello che mi hai dato, non importa se è alto o basso, se mi hai dato 9, vuol dire che stai pensando a qualcosa che non mi fa meritare il 10.Cosa avrei potuto fare per arrivare a 10?" E lì, lì c'erano tutte frasi in linguaggio naturale in italiano che descrivevano il valore che avevo generato che si supponeva io avrei dovuto generare e questo era già un ottimo modo per misurarlo almeno in termini qualitativi anche perché l'approccio è feedback chiedere chiedere chiedere chiedere ragazzi il mercato e gli altri lo sanno qualcosa di voi pensano la differenza è se lo sappiamo o se non lo sappiamo non saperlo non rende la notizia più bella se avete paura di una notizia brutta.Chiarissimo.Ma questo è proprio importante, cioè è come dire, è come la gente che vorrebbe fare una dieta e non sale sulla bilancia, ma qual è il punto? Hai toccato un tasto dolente in questo momento.Quando si dice dieta, bilancia...Lo so, ma perché questo è un argomento che infatti arriva, che arriva molto più diretto perché tutti noi abbiamo un'ambizione, un peso ambito, chi pesa poco vuole pesare di più, chi pesa...però, a parte, per esempio, guarda, è incredibile perché la metafora funziona perfettamente, anche quella del peso è un KPI che dobbiamo decidere noi, è come quello dell'agile all'inizio che dicevamo, cioè se non ti frega niente di essere agile, a me va bene uguale, così come se ti accetti col peso che hai, bomba! L'accettazione di sé è un pezzo fondamentale della felicità, però se vuoi dimagrire e poi non sali sulla bilancia allora che stiamo a parlare capito cioè uno dei due va sciolto di vinco prima parlavi anche di rischio il management di freelance di questo tema un po particolare no quindi spesso il discorso è parliamo di soldi che può essere sia nella contrattazione tra dipendente e azienda ma molto spesso chi tratta questa tematica molto più spesso appunto il freelance.Purtroppo di passione non mangiamo, esatto bravissimo, quindi hai dei consigli da darci su questo tema? Come approcciare o con quale spirito o strategia avvicinarsi a questi temi per avere la miglior resa possibile? in due reparti.Allora, il motto è "genera valore e poi comincia a chiedere denaro".La lettura più...come dire...se qualcuno sentisse solo queste parole potrebbe già condannare...Dicendo "ma ecco un altro che vuole i tirocinanti gratis".No, no, no, no, no.Per esempio, visto che l'hai citato tu a questo punto, il mio gruppo l'anonimo armonisti non si è mai esibito gratis se non per beneficenza e questa è una cosa che per esempio nel mondo della musica è rarissima, cioè i gruppi all'inizio fanno un sacco di cose gratuite perché "ti prego fammi suonare" è sbagliato, ma no non è sbagliato perché Non si può, cioè quello che voglio dire è perché uno dice "ma devo fare la gavetta" ma la gavetta falla, ma fatte pagà Cioè nel senso, se tu svolti la serata ad un piccolo pub, magari poco, ma fatti pagare, perché andare gratis? Oppure, non andare a suonare, saper dire di no è fondamentale.Quindi il punto è...Fatti pagare in birre come se verrai pagato tu per essere qui in birra.Esatto, esatto.Ma questa è beneficenza.Io voglio che questo messaggio venga accolto da tutta la comunità deb italiana e questo è il punto.Il… chiaramente per efficienza nel rispetto del messaggio che io credo valido, non sto dicendo che la mia è verità colata all'alto, però è evidente se mi chiedete che cosa ne penso io vi dico cosa ne penso io, ok? Bene, io vorrei un mondo così, così come, vorrei un mondo in cui le persone sono talmente tanto concentrate sul svalordire il proprio cliente che il cliente non ha nessuna intenzione di non pagarti, oppure che il valore erogato per i propri clienti sia talmente alto da avere una fila fuori dalla porta sempre con un bafferetto un po' pieno in modo tale da poter noi dire di no a chi ci vuole.La scarsità di lavoro per chi eroga veramente valore, per chi è veramente dedito, non esiste.Io sono convinto che, facciamo così, chiedo a voi due.Voi, quando arriva un nuovo cliente, subito dove piazzarlo e c'è spazio per metterlo in calendario o gli dovete dire aspettate un attimo perché fra un po' c'ho un attimo il calendario pieno? Ora magari voi non fate freelance, magari non fate gli imprenditori, ma gli amici quelli che lavora con cui vi confrontate quando arriva un cliente sono liberi domani? Certo che no.E' incredibile quanto male viene vissuta la notizia di un cliente nuovo che arriva a cui dobbiamo dire di no perché siamo siamo già pieni.Ma che problema c'è? Sei già pieno, però sono soldi persi.Non sono soldi persi, è un mancato guadagno che comunque in realtà si ripercuota invece in un guadagno strategico, cioè qualcuno che voleva lavorare con te e che si è beccato un "no, sono già pieno" perché c'è già gente che...ogni tanto qualcuno, come dicono dalle mie parti, dalle nostre parti, Andrea dice...qualcuno rosica, qualcuno prova un forte disappunto e dice "eh però non è possibile che non puoi lavorare per me domani".Io gli dico però ti do una buona notizia non solo se vuoi fra sei mesi no no ma in generale te da una notizia caro cliente che protesti primo va beh questa non gliela diciamo ma è una cosa che pensiamo noi ed è se rompi le palle così e non abbiamo ancora cominciato a lavorare non ci lavoreremo mai, scusandote dai bacioni va beh aspetta aspetta aspetta aspetta notate bene a chi mi diceva come fai a farlo andare via ma sei già pieno ok si auto giustifica ma in più la cosa che invece dice al cliente è caro cliente il punto è che questa per te è la migliore prova del fatto di star parlando con una persona competente lei caro cliente si sarebbe dovuto preoccupare se io avessi avuto tempo a disposizione a partire da oggi da domani perché sarebbe significato un incontro con un professionista che non ha lavoro e la gente brava senza lavoro non ce rimane e uso romanesco perché è praticamente utile a arrivare meglio il messaggio.E quando la dici questa cosa, io la dico ogni tanto, "ah però non puoi" tipo la gente ci prova tipo una volta all'anno no? Magari la gente fa i budget a gennaio settembre così "Iacopo ti piace?" "Eh no non posso, ho da fare" "Eh ho capito ma non ci sei mai, ci sono quelle persone che hanno aspettato un anno, non è una colpa, è un merito mortacci tua" "Mortacci tua" ok? Sì, da tanto tempo...ah, vai vai vai! No no no, poi il messaggio qual è? Non è l'arroganza del "Mortacci tua" ok? Che adesso ho buttato lì per strapparci due risate.Ma il punto è, la prima cosa per riconoscere il valore a se stessi, vi manderò poi un link ad un TED Talk di 8 minuti fichissimo, con i sottotitoli in italiano, quindi proprio commestibile per chiunque.Bellissimo, è un TED Talk in cui si dice La prima persona che deve credere di valere X, se vuole chiedere X, siamo noi stessi.Nesso è giusto, notate che questa è proprio semerissima, è giusto che le persone non accettino una quotazione X se voi stessi non credete di valere X.Perché gli altri dovrebbero crederci più di voi? E non è, e come faccio a crederci? Non date il bene, il messaggio non è quello da reality tipo "e dai se ci credi lo ti diventi, ma è se non ti fai le pippe mentali e sgobbi, studi e fai pratica, a un certo punto ci arrivi.Io non ho mai visto nessuno sviluppatore non diventare una persona pagata sette volte quello che veniva pagata agli esordi per il semplice fatto di aver insistito con passione nel proprio lavoro.Assolutamente d'accordo.Almeno in questa fase storica, cioè siamo ancora in una fase crescente, un giorno la professione dello sviluppatore saturerà ma non è ancora saturata perciò non ci rompete se non se non state diventando ben pagati grazie allo sviluppo del software è perché non state sviluppando le competenze giuste che spesso vogliono dire anche alzare gli occhi da quel maledetto editor di codice il problema credo del del non riuscire a parlare di soldi io per tanti anni ho sofferto di questa patologia.Avevo proprio dei problemi a parlare di soldi.Questa cosa l'ho capita poi quando ho aperto la prima azienda, nel senso che qualcuno di soldi doveva pur parlare perché qualcuno aveva i dipendenti da pagare.A quel punto, volente o nolente, devi capire necessariamente l'impatto che hai verso il tuo cliente o verso il tuo datore di lavoro.Adesso mi piacerebbe con te portare il discorso verso questo lato.Tu hai parlato in lungo e in largo di contrattazione e di di extreme contracts e di negoziazione.Ok, e qui poi suggeriremo anche il tuo libro, metteremo i link a tanti i tuoi talk sull'argomento.Però una cosa che ho notato all'interno del gruppo di Gitbar, che è un po' la nostra casa, è che spesso si parla di cercare una posizione di lavoro dipendente quindi che ne so, applichi a una richiesta di un'offerta di lavoro e devi parlare di soldi quindi parlare di valore.Adesso quello che voglio chiederti è i concetti dove spesso tu li quando li racconti spesso fai l'esempio del freelance perché probabilmente è più comune questo ragionamento sul flusente ma il concetto di extreme contract e di negoziazione dal tuo punto di vista può essere calato applicato in un contesto di lavoro dipendente.Assolutamente sì assolutamente sì.Allora chiediamo una cosa a monte extreme contracts che cos'è un tipo di contratti specifici.No è un set di otto principi che io posso seguire nelle mie negoziazioni se sono un knowledge worker.Ok si chiama extreme contracts in analogia, questa è una sede in cui posso dirlo, in analogia all'extreme programming, che è una delle chiese dello sviluppo agile dei software.L'extreme programming si chiama così perché Kent Beck ha detto, nel primi anni del 2000 diceva, "Io ho notato che i progetti software che vanno bene hanno tutti in comune delle caratteristiche, fanno tutte un po' le stesse cose.Cosa succede se portiamo queste cose al massimo livello? Tipo, ho notato che va meglio se rilasci il più spesso possibile.E quindi che succede se rilasciamo spessissimissimissimo Extreme Programming? Questo è il senso di Extreme.Extreme Contracts è un omaggio a uno dei miei maestri, Kemp Beck, purtroppo non lo conosco però...Sempre si ha lodato.Sempre si ha lodato, esatto.È un omaggio, il nome Extreme Contracts per questo brand, questo set di principi, è un omaggio a questo concetto.Nei primi 15 anni di imprenditoria o di freelancing vedevo che i contratti che funzionavano avevano dei tratti comuni.Ho fatto ricerca sui miei esperimenti, sul mio vissuto e ne sono emersi 8 tratti.Questi 8 tratti ho detto "che succede se li portiamo tutti al massimo?" Tipo, i contratti corti da 4 giornate, da 2 giornate vanno meglio di quelli lunghi, da una settimana a due settimane.oppure i contratti da un mese vanno meglio di quelli da sei mesi.Che succede se facciamo contratti da poche ore, da poche giornate, da pochissime decine di ore? Che succede? Le cose migliorano? La risposta è sì.Quindi tutti questi otto principi si chiamano extreme contracts perché sono, come dire, sono otto dimensioni lungo le quali se spingiamo il volume al massimo le cose non vanno peggio.Bene, questi otto principi si possono tranquillamente applicare anche nello scenario del lavoro, perché sostanzialmente si tratta di capire come farsi riconoscere il valore una contropartita monetaria del valore creato per un mio cliente che nel caso di un impiegato o di un'impiegata è l'azienda per cui lavoriamo tutti i giorni ok? cioè facciamo così forse l'assunto a priori è questo, la cosa che forse la gente potrebbe, gli ascoltatori potrebbero contestarmi ma quindi ci stai dicendo che un impiegato è come se fosse un imprenditore monocliente? Io lo concepisco così.Io ho fatto l'impiegato in due aziende, una particolarmente grande, lo posso dire perché tanto è su LinkedIn, io ho lavorato per ebay ai tempi era ebay paypal.Per me lavorare per ebay era un modo di essere un imprenditore al servizio di un'azienda sola in cambio di un fatturato "fisso".Ok? Chiaramente il paradigma monocliente, forzatamente monocliente, cambia le regole del gioco e quindi non sto dicendo che il lavoro da dipendente sia uguale a quello dell'imprenditore, però il mio compito era quello di generare valore per loro.Questa cosa per esempio, quindi finalmente ti rispondo Mauro, porta in gioco l'extreme per esempio in uno dei concetti chiave di Extreme Contracts, come tutti i concetti di Extreme Contracts non l'ho inventato io, gli Extreme Contracts sono un raccoglitore di concetti apparentemente distanti, attratti, ma i miei, per esempio quello della BATNA, cioè letteralmente è un acronimo che sta per Best Alternative to a Negotiated Agreement, quindi la migliore alternativa ad un accordo negoziato, ed è, significa questo, tutte le Una volta che io negozio, mi siedo al tavolo con Andrea, tutti pensano che la negoziazione sia quel momento in cui siamo seduti ai due lati del tavolo e dobbiamo scannarci per spuntarla sull'altro.La negoziazione non è un evento, la negoziazione è un processo e quindi la possibilità di prendere, di cambiare lavoro oggi, magari ho preso un giorno, tre ore di per me se vado a parlare con un altro datore di lavoro, le possibilità di prendere quel lavoro dipendono non da come me la gioco in quelle tre ore, o quantomeno non solo, e io dico in minima parte, ma dipendono invece da tutto il valore che io ho creato, come direbbe mia madre che è buddista, nell'infinito passato precedente a quella negoziazione di tre ore.Per esempio, mi hanno chiamato loro? Sono io che ho fatto un'application su un web, sono una persona che ha un certo stand in pubblico, ho un blog lettissimo, sono su Twitch, faccio conferenze, questi mi hanno visto parlare alle conferenze, questi hanno sentito parlare di me e hanno avuto delle raccomandazioni, oppure per esempio mi hanno chiamato perché hanno detto "se ti serve uno sviluppatore chiedi a Pinco Pallino".Tutta questa roba qui rende la negoziazione una cosa che avviene tutti i giorni quando noi non abbiamo ancora capito e nemmeno conosciamo la nostra controparte negoziale.Questa cosa viene riassunta nel concetto di BATNA, Best Alternative to a Negotiated Agreement, perché la nostra forza quando negoziamo con un datore di lavoro prossimo sta nella nostra possibilità di non andare nemmeno a quel colloquio.Vi ricordate quando ho detto che è bene avere da freelancer a imprenditore è bene avere la fila fuori dalla porta? Perché è bene avere opzioni ulteriori a quelle già sotto sfruttamento, cioè abbiamo già dieci clienti, avere un undicesimo, un dodicesimo, un tredicesimo cliente a cui dire di no, questo per noi non fa danno se razionalizziamo quel dispiacere di dire no a qualcuno, sono opzioni per sostituire uno dei dieci clienti che stiamo servendo oggi con uno migliore, ok? Questa è di nuovo la patna, cioè la possibilità di negoziare bei contratti con i primi dieci clienti che possiamo servire dipende da quanto sono fichi i clienti 11, 12, 13 che non sto servendo.E così con i datori di lavoro.Ed è il motivo per cui, siccome questo fenomeno è particolarmente vero nel knowledge work, molti di noi sviluppatori di questa epoca, io questa epoca intendo, diciamo l'epoca, come si dice, dopo Cristo, quindi dopo l'open source, dopo Linus, ok? L'epoca dopo Linus che ha democratizzato, ovviamente c'è stata proprio questa esplosione dello sviluppo software come professione, tutti noi abbiamo capito che il nostro salto di carriera non avviene dentro la stessa azienda, ma molto meglio quando cambiamo azienda, che non sto generalizzando, non sto dicendo che non siano possibili promozioni sballorditive all'interno della gerarchia di una singola azienda, ma tipicamente quello che ho visto nella mia esperienza e il mio punto di vista però è steso su decenni, anche adesso che non faccio più lo sviluppatore, gli amici sviluppatori mi raccontano "oh, c'ho il doppio dello stipendio di prima avendo cambiato azienda e ora lavoro pure in remoto".L'avete sentita questa storia no? Cioè io sono convinto, siete testimoni anche voi.Bene, quello è un'espressione intuitiva del concetto di Batman.Gli sviluppatori che giocano meglio questa, che surfano meglio questa onda sono quelli che magari partecipano alle community offline e online, sono quelli che mettono su un podcast come voi, sono quelli che organizzano le conferenze come per esempio Andrea, sono le persone che si espongono anche su aspetti che non sono solo "ho scritto il codice".Lo vedete come torna proprio il senso del modello di business del professionista sviluppatore in tutte le sue dinamazioni? Spero di averti risposto.LM: "chiarissimo, davvero bellissimo e interessante.Forse la mia domanda in parte ci hai già risposto, però vorrei chiederti se questi otto principi che ci aiutano a migliorare verso la negoziazione, la contrattazione, estremi o non, ha dell'impatto? C'è qualcosa che può cambiare se questo viene effettuato in fisico o da remoto? Nel senso c'è qualcosa che può funzionare di più se viene fatto di persona e non diciamo attraverso zoom o meet? È una domanda su cui ti rispondo in maniera agnostica, cioè i principi sono come dire il facciamo il principio del feedback no? Nel in extreme programming o nell'agile in generale l'abbiamo detto prima, è un principio e come tale prescindere e agnostico rispetto all'implementazione.Ok faccio consulenze in remoto su zoom, su meet, su teams.Come posso procurarmi più feedback? Questa è la domanda che mi posso fare.Come posso migliorare il feedback che ci diamo all'interno del team? Questo è già essere agili, è già essere extreme contracts e già essere lavorare nel modo giusto.Online da remoto a distanza su zoom e slack farò in un certo modo.Dal vivo in una stanza farò in un altro modo.Il principio non cambia è l'implementazione che cambia quindi sono decisamente la mia risposta è radicale nel senso che gli otto principi di extreme contracts sono validi come dire cross medium ok? Chiaro ma non c'è una diciamo una modalità in un'implementazione sono più convincente nell'altra o meno direi proprio direi proprio di no vorrei fare un esempio il problema che questo per esempio non vorrei attaccarvi un tipone atroce sui principi stessi però per esempio Per esempio...[sbuffa] [sbuffa] Facciamo così, c'è un principio degli otto che si chiama "skin in the game", cioè secondo me una collaborazione di successo è tale se tutte le parti che collaborano rischiano qualcosa in caso di fallimento e guadagnano qualcosa in caso di successo.Non per forza in parti uguali, ma, tra nerd posso dirla così, se l'orientamento del vettore è lo stesso.Ok? Bene.Skin in the game è una cosa che io posso mettere, posso mettere skin in the game letteralmente, sia in remoto che dal vivo.Cioè posso dire se questo progetto ha successo mi prendo un premio o un premio, oppure mi pagate, oppure mi pagate di meno se va male, oppure se...che ne so, per esempio io in passato ho fatto pure tipo ogni bug che trovi mi sconti i soldi.Cioè perché di Di fatto tu mi stai permettendo di scrivere un test automatico che catturerà quel bug e quel bug non si presenterà mai più E a quel punto se però il bug lo causi tu perché un tuo fornitore esterno Scassa quel codice con un commit mi dai 5 euro in più.Voi lo fareste in questo gioco? Vi lo farei Chiarissimo voglia.Questo si può fare in remoto, da fisico, c'è proprio...Si si si Chiaro 5 euro, tipo un euro, poca roba.Però ogni bug che trovi che è colpa mia, che non ho ancora catturato con un test automatico, ti do un euro.Però tutte le volte che me lo scassi tu, mi dai un euro.Ci stai? Scopriti che il cliente dice "no, no, va bene anche gratis il debugging", invece se non metti skin in the game di tutte e due, lui ti dice "eh, il debugging deve essere garantito".Magari il bug ci sta nel tuo espresso delle specifiche orribili.Ti voglio fare una domanda.Abbiamo parlato a lungo e si sarà capito, per i pochi che non lo sapessero, tu sei anche uno scrittore.Mi sembra eccessiva.Non è che tu sia uno scrittore così come penso che anche cantante sia sopra labeling, sopra etichettante.Ho ho avuto un gruppo in cui cantavo, punto.Ho pubblicato dei libri adatti ai nerd, uno sul refactoring di codice PHP tantissimi anni fa, uno sul capitolo all'interno delle PHP best practice, quello dedicato ai test automatici e poi un altro sui extreme contracts.Mi fa piacere, ti ringrazio, non è assolutamente scontato.No però volevo dirti, uno sviluppatore che poi come abbiamo anticipato resale la piramide del business alla ricerca di come ragionare sul valore, cosa porta di questa esperienza nello scrivere e cosa lo scrivere poi porta al tuo lato sviluppatore che non vuoi ancora soffocare nonostante il fatto che tu magari faccia i sordi con altro.Sì.E al tuo essere invece consulente che ragiona attorno al valore.Perfetto allora scrivere un libro mi ha insegnato che scrivere codice è molto più divertente che scrivere un libro io odio scrivere libri è la cosa più noiosa della storia della Terra, anche se c'è una lieve compensazione per il fatto che un libro come Extreme Contracts lo può leggere anche chi non è uno sviluppatore e questo allarga come dire la fan base abbastanza.Però, diciamo, poi cosa ha portato? Allora, innanzitutto al mio lato consulente ha portato un sacco, cioè scrivere il libro sui contratti è stato proprio un momento di razionalizzazione e di sistematizzazione di tutto quello che avevo intuito negli anni, nei 10-12 anni precedenti.L'ho scritto il libro nel 2017, 12 anni, dal 2005, dal 2003 in poi.Devo dire, per il consulente è stato utilissimo, proprio nota bene, non sto dicendo perché ci sono consulenze che mi vengono chieste sulla base del libro, ok? Sto dicendo proprio per come io ho insegnato a me stesso nello scrivere quel libro, sistematizzando alcuni concetti, a fare il consulente in maniera, devo dire, ad oggi migliore.Qualunque...nota bene, è relativo questo giudizio, non sto dicendo che io sono bravo, sto dicendo rispetto a prima sono più bravo.Se prima era una pippaccia, adesso sono meno pippaccia, ok? Questo è il senso.Perché perché capire come certe esperienze mie del passato in cui intuitivamente trovavo soluzioni per esempio per essere pagato in virtù del valore e non dello sforzo e non delle cose che facevo così sulla base istintiva, razionalizzarle mi permette di farle proprio sistematicamente adesso ok? E proprio anche di capire quanto, cioè per esempio uno degli otto principi è Customer Channel, è un principio omonimo di uno dei blocchi della Business Model Canvas citavamo all'inizio di questa intervista ok? Cioè uno dei pezzi di un business model di successo è capire dove i tuoi clienti vengono a sapere di te, dove fanno le valutazioni se comprarti, dove intendo in che luoghi fisici e virtuali ok? Quindi potrebbe essere un negozio, una conferenza, ma anche un sito web o questo podcast ok? Per esempio questo podcast è uno dei modi con cui io oggi sto creando consapevolezza del fatto che esista Jacopo Romei per chi non ha sentito parlare di me.Ok? Futura negoziazione.Esatto, sto alzando il mio batna futuro.Comunque, statisticamente, notate bene, non sto dicendo che sono il pifferaio magico e saranno tutti quanti sedotti dalle mie parole, anzi, quasi nessuno, ma qualcuno ogni tanto dice "Mh, Jacopo sta dicendo cose sensate, allora sentiamolo".Bene, per esempio, lavorare sul concetto di Customer Channel capire quanto fosse importante lavorare sulle proprie negoziazioni anche quando di negoziazioni non c'era traccia e quindi come dire fare la cosa giusta ogni giorno no vado a questa conferenza o no oddio che pizza doveva fare un altro treno alle sei del mattino per andare a parlare alla conferenza eccetera eccetera quante volte è successo che qualcuno mi abbia sentito una conferenza su cui non avrei scommesso due speech eppure da da lì è uscito fuori una collaborazione fichissima.E adesso sto lavorando per una grande azienda del caffè italiano.Di cui non faremo il nome.Ti stai trattenendo in maniera incredibile.No no, diciamo, non c'è nessuna polemica in agguato.Mi sto trattenendo semplicemente perché non vorrei fare pubblicità in debita.Ma puoi farla senza nessun problema.No no no, comunque, insomma, vivo a Torino, fatevi due.se non è una è l'altra.Quindi il punto è, per esempio, quello è un lavoro che mi sta piacendo tantissimo, di individuazione di prodotti di esperienze digitali nuove per il brand di cui stiamo alludendo, che è uscito fuori da un workshop fatto a Torino in un'ora e mezza, una sera di pioggia, me lo ricordo perfettamente, dopo sei mesi qualcuno ha detto "Ah, per risolvere questo problema di creare nuove esperienze per l'utente dovremmo chiamare quel ragazzo che avevo visto, quel ragazzo, mi piacerebbe, quello là, che abbiamo visto quella sera lì a Torino, in quella notte buia e tempestosa".Io a priori non lo potevo sapere.E questo è, proprio, è importantissimo, cioè, scrivere il libro mi ha proprio fatto capire quanto il gioco non sia sulla previsione del successo, ma quanto sia sul...invece capire quanto ci possiamo permettere di investire al buio.non dobbiamo rischiare di investire troppo, dobbiamo investire sempre una quantità di tempo, energie e denaro che ci permetta di dire se va male, se la butto questa ora, se le butto questi soldi, se lo butto questo momento, domani sono ancora qui in piedi a raccontarla.Se noi riusciamo a essere sempre, questo è il concetto di robustezza nel contesto dell'antifragilità, cioè se io riesco sempre a cascare in piedi, prima o poi posso, ho detto, se casco in piedi vuol dire che non c'è niente che mi ammazza, ogni tanto arriva una botta di culo, la cavalchi e cambi paradigma, che è come il cambio di carriera dello sviluppatore, no? Che è la stessa cosa, è sempre lì, cioè esporsi alle buone notizie.Questo libro ha avuto questo impatto assolutamente sulla mia vita di consulente, proprio impararlo su me stesso.Come programmatore, il libro è arrivato in un momento in cui io, il programmatore professionista, non lo facevo più.Può aver influenzato come io concepisco il software rispetto alle aziende che aiuto e che magari dipendono pesantemente dal digitale, non sempre sono team di sviluppatori, però, per esempio, ok, quindi qual è il prossimo software che sviluppiamo? Qual è la prossima funzionalità che sviluppiamo? Come ordiniamo sto famoso backlog? E capire che, per esempio, le opzioni che ci lasciamo aperte dopo aver rilasciato una funzionalità sono un driver principale con cui scelgo di...è come...anche lì è il BATNA, no? cioè, quali sono le possibilità che ho aperte dopo che ho rilasciato...io ho in mente tre funzionalità per un software, A, B e C.Però dopo che ho rilasciato C, ho compromesso le possibilità di rilasciare B e A.Questo abbassa il valore della funzionalità C.Mi seguite? Non so...[intervallo inaudibile] C'erano quelle situazioni in cui hai delle funzionalità che sono asimmetriche, no? Se le rilascio faccio sempre tempo a tornare indietro.E poi ci sono invece quelle funzionalità che sono un salto nel buio irreversibile.Ecco, l'irreversibilità è una brutta cosa, sia per gli imprenditori, sia per i consulenti, sia per gli impiegati, ma anche per i programmatori.Infatti la figata dei test automatici è che permettono la reversibilità.Ho scritto una fregnace, ehm...com'era? Git checkout? e siamo a posto, ho il testa rosso e ricomincio da capo.Certo.Jacopo, noi ti abbiamo rubato un sacco di tempo, ma prima di lasciarti andar via ti dubbiamo altro minuto e mezzo per il nostro momento, il classico momento del Paese dei Balocchi.E conducono il Paese dei Balocchi.Ah, il Paese dei Balocchi.Allora, ho l'imbalazzo della scelta, diciamo, eventualmente costringetemi a usare un solo...vado in ordine.Il primo che voglio consigliare, perché sono sicuro che esista l'edizione italiana soprattutto, è un libro che in inglese si intitola "The Deep" di Seth Godin, che un guru del marketing.Peraltro, una delle prime sessioni pubbliche che ho fatto nella vita presso gli uffici di sketching nel 2007 era basato su un libro di Seth Godin che mi illuminò che si titolava "La mucca viola".Seth Godin continua a fornirmi materiale, Food for thought, cibo per la mente.Questo libro, che è uno degli ultimi che ha scritto, l'ho adorato, è un libro piccolissimo, vi dico quante pagine sono.Sono 76 pagine, cioè che manco l'amico ritrovato a scuola, proprio, cioè proprio lo sai che sei il primo.E il titolo è "The Deep", credo che in italiano sia una cosa tipo "Il Fossato", "Il non lo lo so, però poi semmai avremo premura sulle pagine del podcast di mettere il link al titolo italiano.È interessante perché parla, cito testualmente, dei benefici straordinari di sapere quando smettere, e poi trappa lentesi, e quando insistere.Che è proprio un trattatello sul concetto di "Batna" che abbiamo appena citato.Cioè il punto è, devo insistere a tutti i costi perché ormai mi hanno assunto qui devo...devo...ah ormai no, faccio una brutta figura se vado via dopo solo un anno e mezzo.Può essere sì, ma può essere no.Bisogna prendere bene queste decisioni perché ogni volta che diciamo di no a qualcosa, per la cultura mainstream è un fallimento e io invece sono d'accordo con lui nel dire che stai liberando risorse per qualcos'altro.Il problema è se perdi tempo non se lo riallochi su qualcosa di più giusto e questo è fondamentale.Vale anche per gli sluppatori proprio a livello più basso, cioè proprio più di codice.Quanto sta insistendo su un'architettura che effettivamente è un accollo.Decisioni tecnologiche, siccome l'abbiamo prese, che fai? Adesso rifai tutto da capo? Se ha senso rispetto a dei costi enormi che stiamo pagando per...Notate bene, questo è controintuitivo, perché io per anni ho detto "ma no, non si ricostruiscono le cose da capo, si fa un refactoring incrementale".Certo che sì, abbiamo detto, bisogna sapere quando insistere e quando smettere, quando licenziarsi e quando farsi un altro anno dentro un'azienda.Quando fare un altro lavoro con quel cliente che l'altra volta è stato un po' bastardello e quando invece dire sai che c'è? Avanti il prossimo, fuori il decimo, entra l'undicesimo e lo rimpiazziamo.Bellissimo.76 pagine va via in...boh...due ore e mezza.No lo recupero.Io di Seth Godin ho letto Mucaviole in un periodo mistico marchettaro che ho avuto a suo tempo e mi sono reso conto che in realtà era un libro ben più profondo di come lo immaginassi.Ne posso consigliare un altro? Vai! Spara! Vieta! Ok dai! Allora di Mark Schwartz.Qui purtroppo di questo l'ho consigliato per secondo perché non credo che esista l'edizione italiana quindi dovete...allora però è un inglese semplice nel senso è un inglese business quindi è piuttosto facile.Anche questo non è un libro enorme, sono 125 pagine.Se non hai fatto l'MBA non puoi leggerlo.Allora si intitola "The Art of Business Value" l'arte del valore di business ed è un libro che notate bene è proprio è un libro che io metto nel filone che mi piace chiamare "post-agile", e cioè, quel filone, così proprio guardate come richiama il tema da cui siamo partiti, è uno di quei libri che contesta l'agile, alcune figure tipiche, alcuni topos tipici dell'agile, ma riconoscendo la validità del messaggio agile a priori, capite? Cioè non è che dice "l'agile non funziona perché impossibile non pianificare".Ok, lui dice "insistete tanto su questa definizione, questo concetto del valore di business, la product ownership e lo scrum master che devi difendere, la capacità del team di rilasciare valori di business".Lui dice "ok, bello questo valore di business, ma è incredibile come nessun autore dell'Agile abbia mai chiarito ma che è il valore del business".E lui fa questa dissertazione di 125 pagine in cui prende un'informazione fondamentale per tutti i product owner che è quella di cos'è che ha valore per il business o meno, la seziona e la rimonta da capo in maniera più decente di come sia stato fatto.E' effettivamente anche in libri che io ho amato tantissimo come per esempio Extreme Programming di Ken Beck.Ok? Quindi è proprio il libro che arriva proprio a rispondere a questi problemi tipo "ok ho capito ma valore che vuol dire? Sta parola vaga".Ecco, in quel libro c'è una possibile risposta.Sì, un altro libro da aggiungere alla vostra libreria che questa volta è appunto super interno soltanto per gli ascoltatori di Gitbar.Sono riuscito a strappare un codice sconto di Extreme Contract prima della registrazione da Jacopo, quindi il balocco che vi porto io è appunto un bello sconto per tutti quelli che vorranno acquistarlo e leggerlo serenamente.Molto volentieri è un piacerone, vorrei però correggere l'aspettativa, solo sulle copie digitali quindi pdf, ipad e kindle, perché la versione cartacea è in mano ad amazon che immaginate mi fa una pacca sulla spalla e mi dice "sì sì ancora pensi che il libro sia tuo certo certo certo come io non posso fare coupon però sulle edizioni digitali proprio liberi tutti.Le metteremo nel commento di questo...per il noto dell'episodio metteremo il link direttamente con il codice sconto da applicare in fase di acquisto.Grazie E siccome siamo nel club del libro di Gitbar, anch'io ho portato dei libri.Mi aggancio un po' ai libri, almeno all'ultimo libro, forse anche al primo che ha proposto Jacopo.Nel mio caso però è un libro illustrato.Io, sapete, ho delle limitate doti a comprendere le cose quindi preferisco senza dubbio i libri illustrati.Il libro si intitola "Value Proposition Design" non ricordo l'editore ma è un libro illustrato bellissimo con dei grafici, degli schemi.Wiley! Esatto! In realtà c'è collegato anche il sito che è Strategies, è un bellissimo libro a me è piaciuto tantissimo perché è un libro pratico.Quello è proprio milestone assoluta cioè proprio Value Proposition Design è un must assoluto.Esatto e mettiamo la piccola easter egg secondo me si deve iniziare a leggere dall'ultima pagina.Altra cosa, altro libro che suggerisco sempre sullo stesso stile però questa volta edito da Oepli è Business Model U, l'ho usato qualche fa anche questo è un libro molto molto pratico e comodo sempre in un'ottica di comprendere e ragionare sul valore che da sviluppatori generiamo ragazzi si è fatto tardissimo io devo salutare Jacopo grazie per esserci venuto a trovare noi ti ringraziamo grazie a voi, grazie mille veramente noi ti ringraziamo infinitamente e volevamo ricordarti che da oggi GITBAR è anche un po' casa tua per cui vienici a trovare quando vuoi, per te c'è sempre una birra fresca lo faccio eh? vieni vieni ti aspettiamo, grazie Jacopo siamo sicuri che Andrea la spigli Alla prossima! Ciao! [Musica] GitBar, il circolo dei fullstack developer.Una volta a settimana ci troviamo davanti a due birre e con Brain Repo parliamo di linguaggi e tecniche di sviluppo web, di metodologie e di strumenti immancabili nella cassetta degli attrezzi dei fullstack dev.[Musica]
