03 Jun 2023
Ieri notte ho letto nel mio feed reader la notizia che Red Hat non manterrà più nessun pacchetto RPM relativo alla suite d’ufficio LibreOffice, per via di una riorganizzazione delle risorse e di una ottimizzazione che allocherà praticamente tutto lo staff disponibile a implementare un sacco di “goodies” dentro lo stack grafico del sistema operativo, tra cui il supporto all’HDR e ovviamente (ma non troppo) chiudere il gap tra Wayland e X.
Devo ammettere che sono stato parecchio stupito dal non aver letto troppi pareri negativi rispetto a questa decisione: di stracci ne sono volati pochi nelle scorse ore, e stamattina sono stato anche sorpreso da un post di Jorge Castro che fa una riflessione piuttosto accurata su questa decisione in particolare e tutto l’ecosistema che ne è a supporto.
Coincidenza delle coincidenze, tutto questo sta accadendo nemmeno una settimana dopo che ho cominciato a sperimentare a casa con un laptop d’avanzo che avevo e openSUSE MicroOS. Ovviamente questa congiunzione astrale mi ha stimolato un paio di riflessioni.
Flatpak, our lord and savior
La triade leggendaria delle soluzioni per installare applicazioni “grafiche” containerizzate (e impacchettate staticamente) su Linux è composta da Flatpak, Snap e AppImage. Onestamente Flatpak è l’unico che mi abbia dato una user experience decente, è supportato estremamente bene da SUSE, e se uno non vuole esplorare quello che c’è sotto il cofano si integra con GNOME e KDE come un cittadino di prima classe.
Sul laptop aziendale ho praticamente qualsiasi applicazione grafica installata tramite Flatpak, e devo dire che anche come sviluppatore non mi ci sono trovato male: quando si è trattato di distribuire NewsFlash è stata una scelta che ha pagato tantissimo perché praticamente una volta fatto il bump della versione e costruito l’artefatto si ha un pacchetto che funziona su qualsiasi distribuzione. In caso di richieste di supporto, a meno di build da AUR per gli utenti Arch Linux, più o meno sai che cosa sta succedendo sotto al cofano. Sono sempre stato un grande fan del packaging per le distro, ma questo per gli sviluppatori è semplicemente… come dovrebbero funzionare le cose.
MicroOS, immutabilità e tutto il resto
Flatpak è solo uno degli ingredienti del futuro(tm) dei sistemi operativi: il suo degno compare è un sistema di base come MicroOS, che ho provato questa settimana, cogliendo l’occasione per testare la nuovissima openSUSE Aeon. Attraverso un layer immutabile che fa da base system e le applicazioni eseguite attraverso OStree (ossia Flatpak) si raggiunge un estremo grado di isolamento tra quello che c’è “sotto” e quello che c’è “sopra”.
Se per le applicazioni grafiche abbiamo Flatpak in user mode che ci consente di installare questi “pacchettoni” con i programmi all’interno, esattamente come avviene ad esempio su MacOS (avete mai provato ad aprire un file .app?), per la nostra developer toolchain e qualsiasi tool da riga di comando di cui abbiamo bisogno possiamo utilizzare distrobox, uno strumento che non mi ero mai filato fino all’altro ieri e del quale una volta presa un po’ la mano non penso che riuscirò mai più a fare a meno. È facile da usare, e il livello di granularità che permette è infinito: possiamo avere un solo container con tutto quello di cui abbiamo bisogno, oppure separare il nostro tooling progetto per progetto e avere decine di container, ognuno ritagliato appositamente per quello che ci serve. Ogni ambiente, che monta trasparentemente la nostra home, è a un distrobox enter di distanza.
In questo modo MicroOS diventa un affidabilissimo base system di quartiere, che semplicemente a ogni aggiornamento si “spacchetta” dove gli compete, lavorando in completo isolamento rispetto ai workload che ci girano su.
Inutile dire che questa compartimentalizzazione estrema fa sì che i malfunzionamenti introdotti da package “meno supportati di altri” siano minimi. Sicuramente questo tipo di outage non ha più effetto sul sistema operativo in sé, ma solo, magari, nello specifico di un container di podman (di cui distrobox fa uso) o qualche Flatpak ballerino.
Solo un dettaglio implementativo, ovvero il futuro dei sistemi operativi
Il 22 dicembre del 2011 è uscito su ZDNet “Why the Operating System is becoming irrelevant”, un articolo che metteva a nudo come l’open source permettesse un’omogeneizzazione della disponibilità di software tra sistema e sistema. Allo stesso modo sul blog di Flameeyes nel 2017 è stato trattato come le differenze tra distro e distro si stessero assottigliando sempre di più.
Nel cloud è già così: ormai il base system di un container è niente più che un FROM dentro un Dockerfile o qualcosa di simile. Niente più che un dettaglio implementativo che assume importanza solo se lo si guarda da estremamente vicino, senza prendere in considerazione che un artefatto è la somma delle parti che lo compongono. Sul desktop stiamo arrivando allo stesso tipo di paradigma: un filesystem immutabile alla base di tutto è davvero così importante se poi le applicazioni che vengono eseguite sono tutte, nessuna esclusa, containerizzate e statiche?
Ha davvero così tanta importanza che io utilizzi una o l’altra distro se poi le “scatole” che ci stanno sopra non hanno nulla a che fare con il sistema di base?
A questo punto il sistema operativo perde la rilevanza che aveva e ne assume piuttosto una tutta nuova: le scelte tecnologiche vengono analizzate sotto l’unica lente della stabilità, in pratica. Il ruolo tutto nuovo del sistema operativo ad oggi e per il futuro è essere una roccia senza nessun tipo di crepa nei confronti dei workload containerizzati.
Vedremo nei prossimi anni come andrà a finire. Sono molto curioso.
Per ora ho solo l’enorme tarlo in testa di sostituire il sistema operativo che ho sulla mia workstation con MicroOS.
08 Feb 2023
Sono appena rientrato a casa da un’esperienza che per me ha avuto del magico: il FOSDEM 2023. Avendo avvisato “la gang” già da un po’ di tempo prima usando Mastodon sono stato fortunatissimo a poter incontrare di persona gente con cui di solito il massimo che posso fare è scrivermi, e devo dire che mi sono veramente emozionato a trascorrere questi tre giorni a Bruxelles. È stato il mio primo FOSDEM, ma decisamente non sarà l’ultimo. Lo scrivo già da ora: ci vediamo l’anno prossimo. Per forza.
Volendo scrivere un resoconto mi accorgo di non sapere da che parte iniziare, quindi probabilmente è meglio che io inizi direttamente da un banale ordine cronologico.
Gli stand
Innanzi tutto, appena arrivato e appena presa confidenza con la città e i suoi mezzi, ho comprato la maglietta del FOSDEM di quest’anno. È un modo per sostenere economicamente la conferenza (almeno a livello infinitesimale), e allo stesso tempo per aggiungere un pezzo di valore al mio guardaroba nerd. Non ho preso la felpa per due motivi:
- Costava un rene;
- Metterla in valigia sarebbe stato più complicato: adesso che so che ci sono le felpe riserverò dello spazio l’anno prossimo, potenzialmente costruendomi il guardaroba direttamente in loco. :-D
A parte questa parentesi fashion, ho rimediato altre magliette al mio stand preferito, ovvero quello di openSUSE (momento aziendalista lol), presso il quale ho potuto incontrare degli adorabili membri della community molto radicati, e svariati colleghi con cui ho potuto chiacchierare a proposito dei progetti su cui stiamo lavorando con il nostro team. È stato strano da una parte, perché non abbiamo quasi mai occasione di vederci di persona, estremamente appagante dall’altra.
Intorno allo stand di openSUSE c’erano chiaramente anche altri stand di altre distribuzioni Linux: il più divertente tra questi per me è stato lo stand di Gentoo, dove per onorare lo spirito della distribuzione in cui ogni utente compila i software sulla sua macchina, se volevi spillette o adesivi te li dovevi stampare da solo.
Le devroom
A strapparmi dalle risate per l’autoironia clamorosa dello stand di Gentoo sono stati chiaramente i talk che si sono tenuti nelle varie devroom: dopo le sessioni di keynote il resto dei contenuti sono stati ospitati da aule più piccole, che in alcuni casi erano purtroppo decisamente sottodimensionate rispetto all’affluenza suscitata da determinate tematiche. Le mie devroom di riferimento sono state quella di Rust il primo giorno, e quella di Erlang e Elixir il secondo giorno. Ovviamentea scrivere Elixir siamo sempre in quattro gatti, quindi non è stato un grosso problema assistere a tutti i talk e anche andare a fare un giro ogni tanto senza la paura di non trovare più posto.
Viceversa per quanto riguardava la devroom di Rust ho capito abbastanza in fretta che una volta rimediato un buon posto non mi sarei più alzato per quasi tutta la giornata: ho letto svariate lamentele durante i talk, soprattutto mentre parlava Kris Nóva, e i post parlavano sempre di file chilometriche. Mi sono trovato incagliato anch’io in una fila del genere cercando di entrare nella track di Continuous Integration and Continuous delivery per seguire il talk di Olivier Vernin, e devo dire che non è stato per niente piacevole.
Dall’altra parte, mi rendo conto che non avendo la vendita di biglietti come metrica di quanto si riempirà la location, è difficile per gli organizzatori prevedere il macello che si farà in un posto del genere.
Ma tornando al nostro argomento: le devroom! Al 99% i talk che ho seguito sono stati interessantissimi e tenuti da persone molto preparate. Sono stati veramente pochi gli speaker che ho visto che mi hanno fatto pensare “questa persona avrebbe potuto fare meglio di così”, e ognuno è stato efficace al suo massimo livello, dallo speaker più navigato alla persona che aveva bisogno di misurarsi con un pubblico un po’ più grandicello.
Della devroom di Rust ho apprezzato in particolare Building a distributed search engine with tantivy, di Harrison Burt, e Aurae: Distributed Runtime, di Kris Nóva. In particolare il talk su Aurae è stato per me una bellissima occasione di riflessione su come concepire qualcosa di più digeribile da un utente comune in uno spazio operativo dove quando si parla di container è impossibile prescindere dalla demagogia della CNCF e dallo strapotere di Kubernetes.
Della devroom di Elixir ho adorato Running Erlang and Elixir on microcontrollers with AtomVM di Davide Bettio, principalmente per il fatto che è durato cinque minuti scarsi in cui Davide ha praticamente ownato il suo pubblico. Ci mancava solo il mic drop finale. Non vedo l’ora di poter guardare il video.
Una menzione speciale va alla devroom di LLVM, che mi è stata consigliata da Michelangelo, in cui ho trovato una selva di scoppiati che parlavano di cose allucinanti. È stato strano e meraviglioso al tempo stesso immergermi in una realtà di cui capivo mediamente una parola su tre.
Gitbar @ FOSDEM
Un evento particolarmente emozionante è stato per me incontrare di persona Mauro, Luca, e Leonardo, che insieme a Carmine con cui ho la ~s~fortuna di lavorare tutti i giorni formano la quasi totalità degli host di Gitbar. Nonostante ci conosciamo ormai da diverso tempo non ci eravamo mai incontrati, e abbiamo sfruttato questa occasione non solo per prenderci le birre che non ci eravamo mai potuti prendere fisicamente ma solo virtualmente, ma anche per registrare una puntata pirata piena di scurrilità in presa diretta usando il telefono di Carmine e occupando un’aula della facoltà di Diritto e Criminologia.
Spero che l’episodio esca quanto prima, anche se sono estremamente consapevole che il montaggio richiederà del tempo. Scusa Mauro per la pressione che ti sto aggiungendo in questo momento :-D
Considerazioni finali
FOSDEM è stato un evento di portata gigantesca, sia oggettivamente parlando che da un punto di vista squisitamente personale. Quest’anno hanno partecipato tante persone che non c’erano mai state, e ho veramente l’impressione che si sia un po’ tornati a certe vibrazioni e alla consapevolezza che un’intera industria multibiliardaria si regga in realtà sulla passione di relativamente poche persone. A volte capita di perdere la concentrazione e dimenticare quali sono gli aspetti importanti, specialmente del lavoro che si fa. Per me questa conferenza ha significato riprendere contatto con un ecosistema che ritenevo ormai al lumicino, tastarne il polso, e scoprire che è ancora vibrante di buone idee, seppur con i suoi problemi.
Ho capito che ci sono ancora un sacco di lande inesplorate, e che come software engineer siamo circondati di tantissimi amici pronti a darci una mano anche nei momenti più bui, in cui ci sentiamo isolati e senza motivazione. E ogni volta che ci sentiamo così, forse la cosa migliore è darsi appuntamento e parlare tra noi di static typing con una birra davanti, senza scemenze corporate in mezzo.
31 Dec 2022
Se dovessi cominciare a fare una lista di tutte le cose che sono accadute quest’anno per metterle in fila e fare il mio personale bilancio, non saprei nemmeno da dove iniziare. Probabilmente sarà meglio andare direttamente in ordine sparso, raccontarvi un po’ di roba, fare le mie solite sezioncine e alla fine vedere se c’è da tagliare, limare, sistemare, lettera, testamento.
È stato sicuramente un anno in cui mi sono messo alla prova. E devo dire che l’ho fatto in molti modi, a tratti esagerando, ma il bilancio è positivo e la soddisfazione che ne ho tratto complessivamente è stata enorme. Se dovessi riassumerlo in una frase, questo 2022 che sta terminando è sicuramente una fila di 365 giorni da cui mi porto dietro una migliore consapevolezza di me.
Ma veniamo agli eventi tangibili.
Creare Mondi: e mondi sono stati creati
L’anno scorso ho menzionato di aver intrapreso insieme ad Agnese un corso di scrittura creativa. Il corso in questione è stato Creare Mondi, curato e “insegnato” da Eulama Litlab. Voglio scriverlo esattamente come lo penso: probabilmente uno degli investimenti migliori che abbia fatto in vita mia. Mi ero iscritto pensando di voler accumulare qualche attrezzo in più per diventare essenzialmente un Dungeon Master migliore, invece come primo elemento di questa lista destrutturata mi sono stati dati degli strumenti analitici per nulla banali, che hanno aumentato a dismisura le mie capacità di sviscerare non solo un testo scritto, ma in generale una storia.
E non parliamo solo di strumenti di analisi, ma anche di progettazione e di esecuzione: la nostra classe di Creare Mondi ha deciso infatti di intraprendere un’esperienza di scrittura collettiva di un romanzo. Se vi dovessi descrivere che cosa è uscito fuori, i più direbbero che è un romanzo cyberpunk. Io vi direi che è un bel libro.
Abbiamo terminato nel corso di quest’anno la prima stesura. Non sappiamo bene che cosa ci faremo, ma è stato un viaggio talmente emozionante che ora, su due piedi, non so nemmeno descriverlo a parole. Entrare nella psicologia dei propri personaggi da una parte, dei coautori dall’altra, è qualcosa che auguro a chiunque voglia mettersi in gioco con qualcosa di inaspettato e nuovo.
Il mio grazie più profondo, per quello che Tolkien chiamerebbe assolutamente un viaggio inaspettato, va a (in rigoroso ordine alfabetico) Agnese, Alexander, Anja, Anna Chiara, Pasquale e Roberto.
Siete il gruppo di avventurieri migliore in cui uno possa sperare di imbattersi.
Un anno di Casa Blaster
Non c’è molto da scrivere su questo aspetto, ma è una cosa importante quindi ho voluto dedicargli una porzione tutta sua del bilancio di quest’anno. A Marzo abbiamo compiuto ben un anno di permanenza dentro questa casa. Il 2022 è stato il primo anno in cui ci abbiamo vissuto dentro dall’inizio alla fine. Come i proprietari terrieri (heh) che stanno leggendo questo post sapranno, il possesso di un immobile si porta dietro tantissime cose; principalmente bestemmie e imprecazioni.
Ma sotto questa coltre di madonne in realtà c’è tantissima felicità, la felicità di avere un posto sicuro. Il proprio angolo di mondo di cui si è assoluti signori e padroni, liberi di riempirlo di qualsiasi scemenza. Sia io che Agnese non ci siamo tirati indietro: chi ha visitato casa nostra ha ripetuto anche più di una volta che dovremmo far pagare il biglietto d’entrata.
Se state leggendo, mi auguro che veniate a visitare il nostro museo.
Fanno dieci euro.
SUSE Trento 1.0
Lavorativamente è stato un grande anno, sicuramente pieno di sentimenti intensi. Trento, il prodotto di cui mi occupo praticamente a tempo pieno insieme al mio team, è arrivato alla sua versione 1.0 passando per svariate gestazioni complicate e, devo dirlo, una riscrittura pesante cambiando completamente stack: siamo passati da Go, static templates e una manciata di componenti React a un’implementazione completamente scritta in Elixir, che implementa il modello CQRS/ES (ovvero Event Sourcing e Command/Query Responsibility Segregation), con spalmata sopra una bella single-page application basata su React.
Il viaggio è stato clamoroso, e ho imparato tantissime cose sia su Elixir e Commanded (il framework che usiamo per implementare CQRS/ES), sia su JavaScript. Una riscrittura non è mai facile, soprattutto una riscrittura della larghissima parte di un’applicazione web: i rischi sono tanti, e in molti faticano a vedere i benefici di un’operazione simile. La verità? Eravamo disperati. Ma dalla disperazione è nato qualcosa di meraviglioso. Probabilmente è materiale per un racconto più approfondito, sempre su queste pagine.
#Fedi23
All’incirca verso Marzo di quest’anno è stato chiaro che nell’ecosistema dei social media “tradizionali”, se così vogliamo chiamarli, stavano per verificarsi degli eventi di portata colossale. Dipende da quale lato si guarda la questione, ma per alcuni sono stati eventi con un impatto catastrofico. Bryan Cantrill ha definito l’acquisizione di Twitter da parte di Elon Musk e gli accadimenti successivi qualcosa di portata “Enron-ique”.
Per questo motivo durante quest’anno ho ripreso lo studio del protocollo ActivityPub, che avevo già esaminato nel 2017 ma che avevo lasciato perdere per questioni di tempo e di perdita d’interesse.
A oggi penso che valga la pena spendere più tempo e sforzi a comprendere come poter migliorare quello che abbiamo a disposizione per mantenere Internet un meta-luogo decentralizzato. Ho ideato e intrapreso alcuni sforzi in merito, ma per ora sono solo caccole e non meritano nemmeno di essere raccontati :-) Quello però che posso dirvi è che alcuni li ho intrapresi in solitaria, su altri invece ho trovato dei sodali con i quali a inizio 2023 probabilmente concretizzeremo qualcosa di tangibile.
Impiadinando
Non mi andava di scrivere “ricapitolando”, e “wrapping up” mi suonava troppo scontato e esterofilo. Quindi: impiadinando. Questo 2022 è stato una piadina con dentro un sacco di cose. Chi ha avuto contatti più o meno stretti con me è a conoscenza del fatto che ancora più che curioso io sono insaziabile, per cui ho solo un proposito e un augurio per l’anno venturo: che sia una piadina colma da scoppiare, per me e per voi che leggete, di ingredienti meravigliosi che ci facciano strabuzzare gli occhi di stupore. Che ci allarghino il volto in un sorriso.
Daje.
12 Dec 2022
Qualche giorno fa stavo pensando a tutti i generatori di siti statici che sono usciti “ultimamente” (dove per ultimamente intendo negli ultimi anni, non nell’ultima settimana e mezza). Per coincidenza, sono cascato sopra questo thread nel bosco selvaggio del fediverso, proprio qualche giorno dopo che Mauro ha mandato un breve rant contro Astro nel gruppo Telegram di Gitbar.
E mi sono detto, ma lo sapete che c’è? C’è che io sono un maledetto nerd e adesso vi spiego che io sono felice di come è implementato questo blog, che da Settembre 2014 è completamente scritto con Jekyll e una chilata di file markdown. E basta. A parte qualche singhiozzo durante qualche upgrade non si è mai rotto, e ho sempre integrato qui e là qualche funzionalità quando ne ho sentito il bisogno. In realtà, per la maggior parte del tempo, non ne ho sentito la necessità. Da un annetto e mezzo genero le preview dei post in formato card usando ImageMagick e una svomitazza di Ruby amatoriale che i meno schizzinosi definirebbero un plugin.
Non ci è voluto molto perché arrivasse qualcuno a dirmi che era uscito Hugo e che se non stavo migrando tutto a Hugo stavo perdendo tempo. Me l’hanno detto in tanti devo dire, e Hugo è l’unico generatore con cui farei cambio a oggi, forse. Qualche tempo dopo è uscito Gatsby. Fichissimo. Tutto a componenti. Ci ho pensato a migrare, poi ho lasciato perdere: il risultato sarebbe stato più o meno lo stesso, ovvero la solita chilata di file markdown e il solito rendering. Certo, avere JSX al posto della sintassi Liquid è un grosso avanzamento, ma alla fine chi se ne frega.
Sono passati quasi dieci anni (melodrammatico: comunque più di otto). Adesso c’è altra roba in giro, e vedo tutti affannarsi a rincorrere il trend e riscrivere il primo sito che gli passa tra le mani nello static site generator del giorno. Tutti sembrano quasi aver dimenticato che Jekyll esiste, almeno da quella che è la mia percezione. Io nel frattempo ho imparato a scrivere plugin per Jekyll, e ho scrito il mio. Sicuramente i tempi di generazione sono biblici e si potrebbe fare in duecento modi migliori. Eppure c’è una parte di me che si sente estremamente bene nel non aver cambiato una virgola di come funziona il software che sta sotto questo blog in otto anni. Un po’ il detto ormai stantio, “choose boring technology”, un po’ il fatto che sul mio blog preferisco scrivere prosa rispetto al codice. Un misto di un po’ di tutto, anche di dimenticanza.
Perché alla fine secondo me l’indice di uno stack che ti soddisfa è questo, specie per qualcosa come un blog: ha valore quando te lo scordi. Per questo, senza alcuna vergogna, vi dico che questo blog da otto anni è generato tramite Jekyll, e non ho intenzione di cambiare una virgola di tutto questo almeno per altri quasi-dieci anni. :-D
30 Oct 2022
Tempo fa, il mio amico Marco mi ha inviato un libro dicendo che lo avrei trovato illuminante. Consentitemi uno spoiler: lo è stato. Quando ho iniziato a leggere The Five Dysfunctions Of A Team, di Patrick Lencioni, non avrei mai immaginato che nonostante la semplicità dei concetti esposti l’avrei trovato così “eye-opening”. Una delle cose che mi hanno colpito, per esempio, è stato il fatto che il paradigma che viene esposto funzioni a tutti i livelli, senza distinzioni, che si tratti di un team di exec che fa del prendere decisioni ad alto livello il proprio mestiere, o che si tratti di un team di sviluppatori.
O ancora, che si tratti di un team con competenze orizzontali.
Esattamente come The Phoenix Project, che ho letto ma che non ho più pensato di recensire (mannaggia a me), i teoremi vengono esposti in una forma narrativa piuttosto gradevole: la storia, piuttosto lineare, racconta di un team di exec che, posto di fronte a nuove sfide e sostanzialmente una compagnia che non riesce più a carburare, deve reagire e riassestarsi. Chiaramente è tutto posto in una chiave piuttosto didascalica, ma diciamo che il punto non è tanto quello di una bella storia, quanto di mostrare le criticità di un team disfunzionale e come superarle.
Le cinque disfunzioni in breve
In ordine di importanza, lungo il racconto Lencioni fa descrivere alla nuova “capoccia” del suo artificioso team di exec i principi disfunzionali che affliggono un team malandato, suddividendoli in delle lezioni essenziali. Questi sono:
- Assenza di fiducia;
- Armonia artificiale e assenza di conflitto;
- Mancato coinvolgimento delle persone nelle decisioni e mancanza di impegno;
- Mancanza di iniziativa dovuta alla mancanza di responsabilità;
- Focus eccessivo sull’ambito personale tralasciando il team.
Le soluzioni che vengono proposte sono molteplici, ma sostanzialmente il punto dell’opera è quello di battere sempre sugli stessi pilastri per fissarli in maniera indelebile. Lencioni rende in maniera clamorosa tutto questo, mostrando anche chiaramente la difficoltà delle persone coinvolte nell’accettare un altro tipo di mindset rispetto a quello a cui sono abituate.
Le soluzioni a queste cinque disfunzioni sono cinque pilastri, secondo l’autore, che dovrebbero portare un team a performare molto meglio e in maniera estremamente più fluida. In ordine, rispetto ai difetti elencati sopra:
- Ristabilire la fiducia, il rispetto, la tolleranza all’interno del team, soprattutto mettendo in evidenza le vulnerabilità di ognuno cercando di far passare il concetto per cui ogni componente del team ha bisogno dell’aiuto degli altri per massimizzare la sua personale possibilità di successo;
- Creare spazio per del conflitto costruttivo. Tantissimi tizi americani sono estremamente fan di quello che viene chiamato “radical candor”. Io penso che “radical candor” sia un modo socialmente accettato di fare gli stronzi, quindi non è che ci creda più di tanto: i feedback vanno anche saputi consegnare al destinatario. Viceversa, è assolutamente vero che tanti leader osteggiano il dialogo all’interno di un team. Bisogna ricordarsi però che dopo la mutua fiducia il dialogo è la risorsa più importante per il lavoro di gruppo.
- Coinvolgere le persone nelle decisioni crea un clima migliore, e favorisce l’impegno che tutta una squadra si può prendere rispetto a un traguardo. Volete un esempio? Provate a chiedere, in un team Scrum, a tutti i membri del team se pensano che il planning che viene fatto sia ragionevole. Di solito, nella mia esperienza, domandare questo alla fine di una sessione di planning crea un grosso senso di responsabilità condiviso. Non fatelo, e un domani vi troverete un team che sta in silenzio, vi lascia in balia dell’overcommitment, e buca gli sprint. Matematico.
- Rendere le persone responsabili delle proprie vittorie e dei propri errori favorisce azioni immediate per raggiungere il successo o evitare i burroni. Pensate che quello che ho appena scritto sia banale? Pensateci di nuovo. Una vostra vittoria è una vostra vittoria, o è una vittoria del vostro capo? Ve lo lascio come quesito da risolvere a casa. Potete mandarmi la risposta via mail. (Non sto scherzando: [email protected] se volete)
- Porre il focus costantemente sui traguardi del team e fare sì che il raggiungimento di questi si tramuti in crescita personale è la più grande delle sfide. Ma vale comunque la pena affrontarla.
Possono sembrare consigli da frasi dei cioccolatini o da biscotti della fortuna, eppure a me hanno aiutato recentemente a rimettere un sacco di cose in prospettiva, a indirizzare i miei manager nella giusta direzione ma soprattutto a capire i miei, di errori. Spero che leggiate questo libro e ne traiate gli stessi insegnamenti che ne ho tratto io, o anche di più: scrivetemi se trovate che abbia mancato dei punti. :-)
