Team di Progetto Senza Project Manager: Esplorando il Dilemma del PM

Leggi la Trascrizione:

Stiamo sperimentando la trascrizione dei nostri podcast tramite un programma software. Perdona eventuali errori di battitura, il bot non è sempre corretto al 100%.

Galen Low: Team di progetto auto-organizzati. Solo questa frase basta a scatenare una crisi esistenziale in qualsiasi project manager. Ma è davvero una minaccia alla nostra esistenza? O è la chiave per elevare il project manager verso un ruolo decisamente più strategico?

Se ti sei trovato a riflettere sul futuro del project management e se i digital project manager continueranno ad avere un ruolo rilevante, resta con noi. Andremo ad alzare il cofano per vedere come un'organizzazione sta riuscendo a costruire con successo soluzioni software complesse utilizzando squadre distribuite e auto-gestite, e cosa questo significhi per il project management digitale in generale.

Grazie per averci seguito, mi chiamo Galen Low e sono con il Digital Project Manager. Siamo una comunità di professionisti digitali con una missione: aiutarci a vicenda a migliorare le competenze, ad acquistare fiducia e a connetterci per poter consegnare progetti con scopo e impatto. Se vuoi saperne di più, visita thedigitalprojectmanager.com.

Ciao a tutti — grazie per essere qui con noi sul podcast DPM.

La mia ospite di oggi è una professionista IT con base a Kiev che da oltre 15 anni spinge sempre oltre i limiti del business process management e della gestione dei prodotti digitali. È stata business analyst, direttrice PMO, product director, customer success director, collaborando con brand come Heinz, Yandex, Adidas e Zyxel per implementare sistemi enterprise su larga scala.

Oggi è product manager presso Railsware, nel team di Coupler.io, dove coordina squadre remote e auto-gestite secondo il metodo Agile, che stanno creando prodotti di grande successo ormai noti a tutti, come Calendly.

Fuori dal lavoro, insegna business process e project management alla Lviv Business School e sta crescendo il suo bimbo per diventare la prossima generazione di donne nella tecnologia.

Vi presento con piacere Julia Ryzhkova. Ciao, Julia!

Julia Ryzhkova: Ciao! Ciao a tutti!

Galen Low: Grazie per essere con noi oggi. Grazie anche per le nostre ultime chiacchierate, sono davvero entusiasta per questo episodio perché credo tocchi qualcosa che tutti noi, come project manager, sentiamo: continueranno ad esistere i project manager?

Ne parleremo, ma prima volevo chiederti: come va la vita? Cosa ti sta ispirando ultimamente?

Julia Ryzhkova: In realtà sono due cose diverse. Se parliamo di qualcosa collegato a Railsware, direi il framework BRIDGeS. È un framework decisionale che permette, a un livello alto, di descrivere un problema e trasformarlo in soluzione.

Lo abbiamo aperto da poco e ora mi sto occupando di diffonderlo tramite il passaparola. È un lavoro che ci ha richiesto più di 15 anni di creazione, quindi il fatto di poterlo finalmente rendere pubblico è davvero stimolante.

Dal punto di vista personale, come hai citato, collaboro anche con la scuola di business di Lviv e stiamo tenendo un corso di formazione online sui processi aziendali per aumentare la maturità generale della cultura di processo in Ucraina.

Anche questo è fonte di grande ispirazione.

Galen Low: Mi piace molto. Entrambe cose splendide, congratulazioni!

Se qualcuno volesse saperne di più sul framework BRIDGeS, dove può andare?

Julia Ryzhkova: Sito di Railsware, abbiamo un sottodominio dedicato.

Galen Low: Fantastico. Molto bene. E, quando registriamo, è dicembre. Siamo a cavallo tra fine 2021 e inizio 2022. Cosa ti entusiasma di più per il 2022?

Julia Ryzhkova: Beh, ora tutti parlano di intelligenza artificiale e machine learning. Recentemente abbiamo fatto una riunione per discutere le vision di prodotto e sappiamo che potremmo usare l'AI nel mio prodotto, Coupler.io, e sono molto curiosa di provarlo e vedere cosa succede.

Galen Low: Che bello.

Bene, entriamo nel vivo. Oggi parliamo di come piccole squad di team Agile remoti possano auto-gestirsi e auto-organizzarsi per sviluppare soluzioni software complesse senza la necessità di un project manager in nessuna fase. È una minaccia per noi PM? Oppure è un'opportunità per essere più strategici? Farà emergere le ansie esistenziali dei nostri ascoltatori?

Vedremo tutto questo nel dettaglio e scopriremo insieme cosa succede davvero.

Ma prima, ci puoi raccontare il tuo percorso professionale? Qual è oggi il tuo ruolo e come ci sei arrivata?

Julia Ryzhkova: Oggi sono product manager, quindi gestisco lo sviluppo del prodotto, la strategia di marketing, il pricing e le vendite.

Ho una formazione tecnica che mi ha aiutato molto: informatica, anche se non amavo programmare. Quando cercavo una carriera, volevo qualcosa che mi permettesse di ideare algoritmi senza necessariamente scriverli in codice. Così sono diventata BA. Da lì ho sviluppato capacità di leadership, sono diventata team leader dei BA, poi project manager, responsabile del dipartimento BA.

Tuttavia ho notato che i risultati del mio lavoro dipendevano molto dal prodotto su cui lavoravo, quindi ho deciso di passare alla ricerca e sviluppo come product owner ed essere parte integrante del prodotto. Per la prima volta mi sono sentita nel posto giusto. Il mio prodotto è cresciuto, il team è cresciuto; ci sono stati più product owner e sono diventata vicedirettrice di prodotto, gestendo metà dei team scrum, poi ho voluto andare oltre.

Dato che c'era già un product director, ho scelto di puntare alla board, sono diventata customer experience director e ho gestito tutto ciò che riguardava servizi, academy support e altro. Ho creato processi efficaci e portato ottimi risultati.

Ecco perché abbiamo deciso di applicare queste competenze per costruire processi anche in altri dipartimenti ed è così che sono diventata pmo director. Poi è arrivata la maternità. Dopo quella parentesi importante, desideravo tornare alla gestione prodotto.

Forse ti chiedi perché prodotto e non progetto? Perché voglio concentrarmi sui benefici per i clienti lasciando la gestione dei processi fuori. Questa è la differenza che trovo tra product e project management: tante similitudini, ma il product manager si focalizza su prodotto e cliente, mentre il project manager sui processi e sui risultati.

È qui che le squadre auto-organizzate diventano cruciali. Quando ho scoperto Railsware, ho capito che era il posto perfetto per me.

Galen Low: Adoro questo percorso. Amo il tuo background tecnico, quello nell'esperienza cliente e nella leadership nei team di PM. Penso che sia davvero d'ispirazione per chi lavora nel nostro settore.

Puoi raccontarci qualcosa su Railsware, sulla struttura dei team che coordini e sui tipi di progetti che affrontate?

Julia Ryzhkova: Partiamo dai progetti, perché la struttura dei team dipende dal tipo di progetto su cui lavoriamo. Siamo una product studio, cioè creiamo prodotti sia per noi che per aziende esterne. In Railsware amiamo automatizzare tutto e a volte non troviamo sul mercato gli strumenti che ci servono.

In quei casi, sviluppiamo uno strumento per le nostre esigenze, poi, dopo averlo usato internamente, lo lanciamo pubblicamente perché sappiamo che anche altri ne avranno bisogno. Per questo iniziamo sempre con team piccoli, perché cerchiamo il fit nel mercato.

A volte può essere persino un solo sviluppatore part-time. Per esempio, un nostro prodotto, Smart Checklist per Jira, è stato inizialmente sviluppato part-time da una sola persona. Solo dopo aver raggiunto 50k MRR abbiamo deciso di allocare sviluppatori full-time.

Per prodotti piccoli come Coupler.io, abbiamo una squadra di sviluppo di 4-5 dev e una di marketing sempre da 4-5 specialisti.

Tutti gli altri lavorano part-time: data analyst, support manager, persino io come product manager sono coinvolta su questo e altri prodotti dei clienti. Poi, quando il prodotto cresce — come successo con Calendly — allarghiamo la dev team e la dividiamo in più squadre perché crediamo che piccoli gruppi siano più efficienti.

Ad esempio, ora Calendly ha tre team dal nostro lato più numerosi sviluppatori dal loro lato. Ecco come funziona.

Galen Low: Fantastico, mi piace davvero questo concetto di squad e swarm. Anche il marketing come una squadra dedicata. So che ho parlato prima di team Agile, ma Agile non significa solo ingegneria o sviluppo.

Può significare molte cose differenti, lo vedremo fra poco. Ti chiedo — qual è oggi la sfida più grande che affronti nello sviluppo prodotto?

Julia Ryzhkova: Nulla di sorprendente: la vera sfida di ogni product manager in una startup è trovare la tua miniera d'oro nel mercato.

Solitamente risolviamo un pain del cliente, per cui la base utenti cresce, aumentano i KPI, ma vogliamo mantenere il ritmo e raddoppiare. Per questo dobbiamo trovare un altro pain per cui i clienti sarebbero disposti a pagare il doppio per risolverlo.

Galen Low: Siete dei risolutori di problemi. Mi piace il fatto che risolviate problemi prima per voi stessi e poi li condividiate con il resto del mondo. Siete una sorta di prodotto interno che si irradia all'esterno. Ma anche una società di servizi che aiuta altre organizzazioni a costruire i prodotti dei loro sogni.

Molto interessante. Ottimo.

Diamo un po' di punti di riferimento agli ascoltatori. Nel mio giro di conoscenze, il concetto di team auto-gestiti è una lama a doppio taglio. Da una parte, la maggior parte dei PM vorrebbe team indipendenti così che il lavoro proceda senza che il loro ruolo sia di collo di bottiglia. Dall'altra, però, molti PM vogliono continuare a essere necessari e non perdere il lavoro.

Ma l'idea di team di progetto senza project manager non è certo nuova. In uno Scrum Agile team, ad esempio, il project manager non è previsto, esistono solo product owner, scrum master e team di sviluppo. In un certo senso, il messaggio era già chiaro da tempo, ma stiamo ancora cercando di capirne l'applicazione concreta.

Per alcuni versi è una minaccia: chi ha bisogno dei PM se i team si auto-gestiscono? Ma in altri può essere la vera nirvana del project management: molti PM desiderano essere più strategici, vicini al prodotto e al cliente, meno presi dalla gestione del lavoro in sé.

Quindi esiste un equilibrio da trovare? Ma iniziamo dal principio. Puoi spiegare come funziona la logica delle squad auto-gestite in Railsware e nel team Coupler.io?

Julia Ryzhkova: La risposta è legata al nostro concetto di mentalità prodotto degli sviluppatori.

Abbiamo organizzato un webinar su questo tema di recente. Cerchiamo sviluppatori maturi, con competenza a T, cioè, come me, hai molte esperienze diverse, quello è il tipo di persona che cerchiamo. Possono iniziare a lavorare con il cliente già da sviluppatore, PDM, PM durante la fase MVP.

Abbiamo affinato il nostro processo di selezione negli anni proprio per trovare queste persone, perché ovviamente non è facile. Inizialmente lavorano sui prodotti interni, così imparano le nostre metodologie e sviluppano la mentalità prodotto.

Poi possono lavorare con il cliente facendo di tutto, veri e propri "one-man orchestra". Lo stesso vale per gli altri ruoli: ogni Railswarian (come ci chiamiamo) può lavorare in autonomia. Molti hanno esperienza manageriale o di gestione di attività proprie: HR, designer, PM e altri, praticamente tutti.

Tuttavia nessuno di noi è un responsabile diretto del team. Diventi un punto di riferimento con il principio "lead by example". Guidi il prodotto e mostri con l'esempio di meritare la fiducia del team. Non puoi semplicemente dire cosa bisogna fare, devi dare il meglio per avere impatto sul prodotto e sui risultati. Così il team ti segue e dà il massimo.

Galen Low: Mi piace molto il principio di team a T, che portano esperienze eterogenee. Voglio approfondire la selezione e l'onboarding.

Sì, il processo di selezione non riguarda solo skills tecniche, ma anche esperienze manageriali, chi ha condotto business propri e guidato team. Quell'esperienza è preziosissima anche se poi il ruolo è abbastanza piatto come organizzazione.

Abbiamo detto prima che tu provieni da una formazione di project management, sei stata a capo di un PMO: hai trovato questo modello di team auto-gestiti difficile da accettare o persino minaccioso?

Julia Ryzhkova: Divertente che tu lo chieda. Sì, all'inizio, nel periodo di prova in Railsware, è facile valutare la propria necessità quando sei quella che salva tutto ogni giorno e senza di te tutto va in crisi. Tuttavia, quando le cose filano anche senza di te, non percepisci più l'impatto come prima.

Apporti cambiamenti, migliori processi, vedi risultati, ma sai che potresti prenderti due settimane di ferie senza che nulla crolli. Quindi ti chiedi: perché servirei? Alla fine però smetti di voler controllare tutto, e con tutto quel tempo "libero" trovi altri modi per avere impatto.

Ti focalizzi sul prodotto, sul cliente, sulla strategia e riesci ad avere un impatto persino maggiore con quel tempo. Ancor di più, lasciando più autonomia al team, loro riescono a creare cose incredibili nelle "guild". Abbiamo squad (4 ingegneri, 1 QA) ma anche guild di ingegneri, di QA, di PM.

Ad esempio la guild PM ha creato il framework BRIDGeS che ho citato. È impossibile creare risultati simili se non hai spazio creativo e libertà di azione.

Galen Low: Concordo molto. Le squadre migliori con cui ho lavorato erano indipendenti o auto-gestite, non perché il PM fosse assente, ma perché avevano autonomia. Spesso nel nostro ruolo ci troviamo anche noi troppo "micromanagy", giusto?

Gestiamo mille cose, facilitiamo la delivery, ma in realtà dovremmo guidare, ispirare, e dare autonomia. Sembra proprio questa la cultura. Non si tratta di eliminare Julia o i PM, ma di farli crescere, portarli su un livello più strategico. Anche la possibilità di andare in ferie è fondamentale!

Oggi il tuo ruolo, dato che ora sei product manager e non PM, ti senti ancora di usare le tue competenze come PM? Ti sono tuttora utili?

Julia Ryzhkova: Assolutamente sì. Non riesco a immaginare un product manager senza una minima base di project management. È una parte fondamentale. La formazione tecnica mi ha dato un vantaggio ma le competenze di project management sono essenziali per il ruolo di PM prodotto, per quanto ho visto.

Come parte delle nostre skill metric, ogni ruolo senior in Railsware ha competenze di project management, come la comunicazione. Sono tutte utili per i risultati.

Se parliamo di skill specifiche, pensando alle aree PMBOK, non faccio quasi integrazione e comunicazione (parte della self-management), ma gestione di scope, costi, tempi e stakeholder ci sono ancora tutte.

Per il resto? Qualità è responsabilità di QA e ingegneri, non la gestisco direttamente. Risk management e procurement sono condivisi fra tutti: se serve qualcosa, fai una richiesta e spieghi il perché.

Non immagino come o perché dovrei capire io perché serve uno specifico tool o libreria. Ed è bello così.

Galen Low: Mi piace molto che i ruoli senior abbiano skill di PM. Prendiamo sotto gamba aspetti come scope, costi e gestione stakeholder solo perché fanno parte del lavoro, ma in realtà sono centrali per un business responsabile. Fa parte del processo di selezione per ruoli senior? Chiedete formazione specifica?

Julia Ryzhkova: Per ruoli senior intendo anche ingegneri e QA, non solo ruoli amministrativi. Tutti coloro che contribuiscono a prodotti e progetti devono sapersi auto-gestire — il proprio scope, il proprio tempo, i costi, il procurement. È qualcosa che ci si aspetta. Ecco perché cerchiamo sviluppatori e collaboratori maturi.

Non ci aspettiamo una formazione dedicata o background di project management, ma ognuno lo fa già senza rendersene conto e possiamo solo far affinare queste skill, non insegnarle da zero.

Galen Low: Mi piace e chi mi conosce sa che promuovo questa visione. Come PM digitali dobbiamo imparare molto dai team tecnici, ma possiamo anche insegnare la gestione a loro. Non stiamo creando "per gioco", costruiamo per clienti, in un contesto di vincoli e responsabilità.

Addentriamoci in come funziona tutto questo soprattutto per aiutare chi ci ascolta e vuole provare questo modello: cosa devono considerare?

La mia impressione è che piccoli gruppi auto-gestiti richiedano processi definiti e onboarding solidissimo. Come comunicano e restano allineati queste squadre?

Julia Ryzhkova: Probabilmente è una questione culturale. Quando c'erano solo i due fondatori in Railsware, definivano processi anche solo come semplici elenchi di cose da fare, ma già così. Un approccio strutturato e documentato. Ovviamente, volevano nuovi membri mossi dalla stessa cultura. Non è comune nelle piccole realtà.

Il più delle volte le aziende cominciano a pensare ai processi solo quando c'è già confusione. Qui invece è partita da subito. È diventato parte della cultura.

Quindi il nostro onboarding è processuale e vige il principio “documenta tutto via via”. Ogni meeting ha condiviso documenti/schede dove tutti annotano, prima o durante l'incontro, non dopo. I classici verbali fatti a posteriori qui non esistono. Così, se qualcuno condivide qualcosa fuori dalla documentazione condivisa, gli altri aggiungono comunque note per tenere tutto tracciato.

Dopo due settimane di ferie apro i documenti rilevanti, li leggo e so tutto, senza bisogno di sincronizzarmi ulteriormente o chiedere aggiornamenti.

Fa parte della cultura della trasparenza. Anche la comunicazione avviene in canali pubblici, su Slack: abbiamo oltre 300 canali, quasi niente conversazioni private. Tutto si svolge in pubblico e chiunque può leggere, rispondere prima o capire da solo cosa è successo.

Galen Low: Molto interessante. È quello che tante realtà stanno cercando di apprendere: una comunicazione asincrona dove puoi recuperare tutto quello che ti sei perso, perché le conversazioni sono lì davanti a te.

Mi sembra che Railsware sia stata molto progressista fin dall'inizio, anche con strumenti semplici. Non servono sistemi complessi, basta documentare e rendere chiaro a tutti.

Mi piace davvero.

Julia Ryzhkova: Anch'io lo ammiro. In passato insegnavo che i business process servono solo quando l'azienda cresce. Se sei solo tu e sai cosa fare, non ti servono ancora.

Conoscendo meglio Railsware ho cambiato idea. È meglio iniziare subito, anche con cose semplici come checklist. Anche nella vita personale, se cerchi lavoro crei un elenco di aziende e indichi a che punto sei in ogni processo. Anche quello è un processo documentato: serve sempre se vuoi gestire con criterio.

Oggi penso che fare business senza processi sia impossibile.

Galen Low: Esatto. Mi piacerebbe toccare anche il tema delle metriche per il team.

In questo modello, gli ascoltatori si chiederanno: quali sono i KPI chiave per sapere che tutto va come dovrebbe? In team tanto autonomi, la responsabilità è condivisa. Come tenete sotto controllo tutto? Cosa misuri?

Julia Ryzhkova: Bella domanda, e la risposta forse sorprenderà. Non tengo traccia di performance metrics classiche. Sembra assurdo forse, ma io misuro solo metriche di prodotto.

Tracciamo la crescita, i SaaS metrics, conversioni, ricavi, ecc. Ok, in realtà monitoro la velocità del team, ma non come metrica di performance, bensì per fare previsioni sulle release e per i prossimi tre mesi. La gestione dei tempi c'è ancora.

Applico la velocity alle stime sui nuovi epici per avere date possibili. Tuttavia, consegnando ogni giorno o almeno ogni 2 settimane, va bene anche se qualcosa slitta di due settimane. Nessuno muore per questo.

Le squad gestiscono la loro performance. Pair programming con i nuovi, cross-testing, code review. Si danno feedback chiari fra loro su cosa migliorare.

Emerso nelle daily, nelle retro. Non abbiamo il tabù che i PO o gli stakeholder non partecipino alle retro. Io ci sono sempre, anche i clienti vengono talvolta. Tutti ricevono feedback trasparenti.

La cultura del feedback è molto forte: ogni nuovo riceve feedback da tutto il team, e chiunque può segnalare un problema anche qualitativo, come il nuovo stesso può darci insight sui processi, sull'azienda, persino su di me come PM.

Risultato: o non superi il periodo di prova o vai alla grande e nessuno deve più monitorare le performance.

Galen Low: Interessante. Può diventare intenso?

Julia Ryzhkova: Potrebbe, ma di solito tutti sono allineati.

Se un problema viene visto da qualcuno, lo vedono tutti, si segnala il feedback e non ci sono conflitti gravi.

Galen Low: E in effetti è qualcosa di radicato nella cultura e che curate già dalla selezione. Chi entra è già abituato a ragionare e operare così, pronto a dare e ricevere feedback per migliorare come team in una struttura flat.

Julia Ryzhkova: Esatto, lo verifichiamo durante l’assunzione. Dedichiamo molto tempo a selezionare bene.

Per i PM, ad esempio, c’è una giornata intera di collaborazione concreta sul campo: otto ore di pairing con un altro PM, con feedback costruttivi in tempo reale. È un grande investimento anche per i candidati: nessuna offerta senza aver dedicato almeno una giornata a questo processo.

Non vale per tutti i ruoli (può essere due, quattro ore a seconda del ruolo), ma per i PM sì. Così capiamo se c’è adesione culturale, non solo tecnica. Un'ottima selezione.

Galen Low: Mi piace molto, anche perché molti processi di selezione attuali sono fatti da test arbitrari. Qui invece si investe per verificare davvero il fit del candidato.

Non tutte le aziende possono permetterselo, ma se hai bisogno di sicurezza sulle persone è il modo migliore.

Julia Ryzhkova: Spieghiamo ai candidati che anche per loro è un investimento: non sprecano tre mesi per scoprire che non è la realtà in cui volevano lavorare! Noi invece ci assicuriamo che ci sia cultura condivisa.

Galen Low: Giustissimo. Hai detto prima che "se una consegna slitta di due settimane nessuno muore", ma come product manager devi gestire la roadmap, prometti delle feature ai clienti: cosa succede quando cambiano le priorità o le date di delivery? Quali comportamenti cerchi nelle squadre di fronte al cambiamento?

Julia Ryzhkova: Probabilmente ti sorprenderò, ma... nulla succede! Posso togliere task dagli sprint, inserirne altri, spiegare il perché. Se serve, pianifichiamo una call di stima e poi il team si riallinea. La roadmap non cambia continuamente: la aggiorno una volta al mese con nuovi insight, metriche, ecc.

Il team è a conoscenza di tutto, condivide le vision di prodotto, partecipa ai sync strategici con il C-level per portare la prospettiva tecnica. Talvolta sono loro a suggerire cambi di strategia. Ad esempio, quando abbiamo modificato il pricing model, uno sviluppatore ci ha fatto notare che uno dei nostri partner aveva cambiato a sua volta modello, suggerendo di allineare i limiti ai nuovi pricing. Fantastico.

Durante i primi sei mesi in azienda ho cambiato tool di project management tre volte: da Trello a Coda, poi Pivotal Tracker, quindi JIRA. Il team ha sempre accettato senza problemi: “Basta che ci dai un training di 15 minuti sul nuovo tool e siamo operativi”. Una squadra davvero ispirante.

Galen Low: È davvero notevole, specialmente cambiare gestione progetti, che per molti è un trauma. Ma qui conta il mindset prodotto che coinvolge tutte le professionalità.

Se scomponiamo questo concetto, è una mentalità orientata al business. Tu ci hai detto: basta spiegare il motivo del cambiamento, il perché di una nuova feature, e tutto viene capito e accettato. Il prodotto è cambiamento!

Con project management classico si tenta la "perfezione stabile". Invece, il lavoro vero (sia progetto sia prodotto) è saper rispondere al cambiamento: pianificare, organizzarsi, ma accettare che tutto cambi.

Julia Ryzhkova: Aggiungo una cosa: un developer mi ha detto recentemente che sente stabilità proprio dal fatto che abbiamo backlog per diversi sprint futuri. Non conta se cambia tutto: sapere che c’è un backlog lo rassicura. In JIRA preparo i prossimi 3-4 sprint pieni, ma a loro interessa solo sapere che c’è un piano e una vision condivisa verso cui andiamo.

Esaminiamo il backlog durante il grooming prima dello sprint: questo dà stabilità e senso di sicurezza al team.

Galen Low: Sì, è una fiducia creata dalla trasparenza: condividete vision, piano, il team fa parte integrante della rotta e questo insuffla autonomia e stabilità.

Vorrei tornare un attimo sulla questione: backlog, cambiamenti... Qualcuno penserà: “Ok, stiamo parlando di sviluppo agile, è facile così”. Ma secondo te, questo modello funziona solo con team di sviluppo Agile, o lo vedi possibile anche per altri team cross-funzionali di prodotto?

Julia Ryzhkova: Devi essere Agile, ma Agile secondo il manifesto — e non vuol dire solo software.

Tutte le nostre squad lavorano nello stesso modo: marketing, finance, operations. Ho insegnato loro a stimare, fare grooming, gestire roadmap, stimare progetti HR con story points, tracciare la velocity... Tutto può essere gestito così.

Galen Low: Sarebbe tema da altre puntate: so che molti sognano una squadra marketing Agile, backlog e sprint compresi. Lo si vede poco fuori da sviluppo/design, ma dovremmo provarci tutti: agilità significa reazione rapida ovunque.

Julia Ryzhkova: Infatti. Engineering e design lavorano in Scrum, marketing in Kanban, con roadmap a board, e va meglio per loro. Sono tutti metodi Agile, però!

Galen Low: Sì, decisamente, è corretto. Ognuno trova la sua modalità continua.

Veniamo alle note dolenti: ogni modello ha difetti, nulla è perfetto. Per chi vuole adottare le auto-gestioni e crede che sarà la perfezione assoluta, vorrei chiederti: quando qualcosa va storto, dove può fallire questo modello?

Julia Ryzhkova: Domanda difficile. Ci sono questioni di alto livello.

Ad esempio, una squad non è sempre allineata su cosa fanno le altre. Due nostri prodotti: Mailtrap e Coupler.io. La dev team di Coupler.io ha sviluppato molte nuove feature su cui il piccolo marketing team non riusciva a star dietro in termini di contenuti e promozione. In Mailtrap invece il contrario: marketing troppo veloce rispetto allo sviluppo, e così abbiamo deciso di scambiare alcune risorse tra le squad per accelerare entrambi i prodotti.

Queste decisioni non possono essere prese dalla singola squad che non ha la visione complessiva. Servono decisioni di livello direzionale.

Galen Low: Quindi chi prende davvero queste decisioni? Sei tu, qualcuno delle operations?

Julia Ryzhkova: È un ruolo tipicamente C-level. Io ho visione del mio prodotto e condivido le necessità strategiche. Mailtrap fa altrettanto. I C-level, non essendo impegnati nelle micro-attività, vedono il quadro alto, possono prendere facilmente decisioni come “scambiatevi le risorse”.

Galen Low: È stato uno scambio temporaneo? Ha introdotto il concetto di ruoli condivisi fra squad, o era più che altro per tamponare necessità?

Julia Ryzhkova: Dipende. Si può scegliere se assumere nuove persone o scambiare risorse temporaneamente. Attualmente usiamo un mix delle due. Siamo abbastanza agili anche per fare cambi squadra per sei mesi o un anno, senza problemi.

Galen Low: Alla fine conta l’allineamento fra le squad. Come comunicate fra squad (ad esempio tra marketing e ingegneria di Coupler.io)? Con che frequenza?

Julia Ryzhkova: Dipende. Abbiamo demo dove la squadra ingegneristica mostra alla marketing cosa verrà rilasciato; sincronizzazione settimanale dove condivido cosa stiamo facendo e cosa sta per uscire. Marketing mette in una shortlist quello che servirà, ha una roadmap globale per le campagne grandi, parte delle capacità va sempre al supporto del team sviluppo e viceversa.

Chiunque nel team può inserire input nel backlog di un’altra squadra, lo si rivede una volta a settimana. Se non allineato alla vision va in icebox, altrimenti viene pianificato nei prossimi sprint.

Così si genera allineamento costante. Marketing può chiedere, ad esempio, il re-design del sito, dev può chiedere template mail belli per la propria area. È uno scambio continuo.

Galen Low: Molto interessante. Un tema implicito finora è la distribuzione geografica e dei fusi orari: avete team sparsi nel mondo, come vi regolate? Essere efficienti è più difficile?

Julia Ryzhkova: Direi il contrario: il lavoro remoto ti permette maggiore efficienza. A volte è difficile trovare orari per una call se uno è in Argentina e uno in Thailandia, devi adattarti. Ma è l'unica sfida reale.

Oltre l’80% del team lavora da remoto, in oltre 15 paesi: funziona perché tutto è documentato su file condivisi e canali pubblici. Lavorando asincronicamente non servono troppe riunioni o incastri complicati.

Galen Low: Amo questa distinzione: lavoro asincrono non vuol dire niente riunioni, ma solo meeting davvero utili, a orari flessibili per tutti; e il lavoro remoto non coincide con il lavoro da casa. Tutto sta nella cultura di documentazione e trasparenza, e così non servono montagne di meeting." Paper trail" di comunicazione!

Mi chiedo se in squad auto-gestite il project management sia uno stigma, come dire: “Non abbiamo bisogno di essere gestiti!”. È una parola un po’ sporca?

Julia Ryzhkova: Assolutamente no, nessuno stigma.

Ci piace sperimentare. Nessun obbligo di nulla. Preferiamo condividere elementi chiave tramite la guild come parte della crescita delle competenze. Ho insegnato ad esempio ai team operation a stimare, usare story points, condividere alcune "pillole" di Kanban o Scrum quando serve.

Se qualcuno vuole approfondire può usare il budget di formazione. Crediamo però sia meglio insegnare ciò che serve, quando serve.

Galen Low: Questa è una visione condivisa: insegnare parti del mestiere, più che formare nuovi PM o ingegneri, condividendo le skill rilevanti per la collaborazione e risultati di qualità.

Veniamo alla domanda chiave. Da ex project manager e PMO, oggi product manager più strategico: vedi le squad auto-gestite come il futuro del project management?

Julia Ryzhkova: Sicuramente sono il futuro delle aziende prodotto di successo.

I team auto-organizzati permettono ai PM di focalizzarsi su strategia, prodotto e cliente, e finalmente lavorare sulle cose "importanti, non urgenti".

Di solito non abbiamo mai tempo per queste attività, i team invece dedicano le energie a ripulire le "urgenti, non importanti" che consumano gran parte dei project manager.

Ma non tutti sono pronti alla self-management, soprattutto chi ha appena iniziato. I junior hanno bisogno di mentoring e gestione classica. E ci sono persone (anche senior!) che senza scadenze esterne non funzionano. Lo spazio per il project management classico quindi resterà sempre.

Ma credo che ogni azienda che mira a risultati straordinari debba arrivare al punto in cui la self-management supera la gestione diretta, liberando tempo prezioso dei PM per la strategia e il miglioramento globale.

Galen Low: Splendido. Tanti project manager si sentono schiacciati dalle urgenze, ma in realtà il vero salto è nella cultura, nelle persone e nei processi. Più autonomia al team equivale a più strategia per i PM. Non vuol dire che il PM sparisce, ma che potrà finalmente occuparsi delle cose davvero utili.

Julia Ryzhkova: Il project management resta importante! Con team auto-gestiti posso essere meno assorbita dal controllo, mentre con altri team è ancora cruciale “far succedere le cose”.

Il ruolo del PM è garantire che il progetto si chiuda nei tempi e nei budget, sempre. Con team autonomi, puoi ottenere risultati senza coinvolgimento asfissiante e invece pensare a cosa dev'essere fatto, non solo al come.

Galen Low: Esatto. Elevare il ruolo e anticipare le esigenze.

Julia grazie infinite per questi spunti. Il tema della mentalità prodotto mi ha illuminato: non tanto pensare a cicli di vita e release, ma a sviluppare un'attitudine fluida al cambiamento. Un prodotto è guidato dagli utenti, dal mercato — tutto cambia sempre.

Quindi mentalità prodotto vuol dire saper reagire, essere agili e recettivi. Vuol dire capire il perché dei cambiamenti, non subirli. Il ruolo cambia, il backlog cambia, le release cambiano, i tool di project management cambiano tre volte l’anno, ma questa è la vera mentalità prodotto. Serve a far evolvere i prodotti in modo dinamico e agile.

Ultima domanda. Che consiglio daresti a un'organizzazione che vuole adottare piccole squad auto-gestite?

Julia Ryzhkova: Non pensarci troppo: fallo! Parti da un piccolo team, ma comincia. Non pensare di applicarlo a tutta l’azienda da subito, soprattutto se è grande.

Metti insieme i tuoi migliori elementi, dagli l’autonomia e osserva i risultati. Quando vedrai i benefici, farai tutto il possibile per estendere il modello a tutta la compagnia. Il successo verrà: serve solo iniziare con le persone giuste.

Galen Low: Fantastico, Julia, grazie ancora per essere stata con noi. La tua esperienza su squad auto-gestite, processo Agile e creazione prodotto nella product studio credo abbia dato spunti e idee a molti!

Speriamo di riaverti per raccontare come l’AI entrerà in Coupler.io e tutti i prossimi sviluppi…

Julia Ryzhkova: Spero anch’io di poter condividere presto altri insight.

Galen Low: Davvero interessante. Grazie mille.

Julia Ryzhkova: Grazie a voi. È stato bello confrontarmi e raccontare tutto questo, spero che possa ispirare altri a seguire la nostra strada e ottenere risultati appaganti.

Galen Low: Meraviglioso. Grazie ancora.

Julia Ryzhkova: Grazie!

Galen Low: E voi cosa ne pensate? Le squadre auto-gestite sono il futuro, o hanno limiti che le rendono inadatte a certi settori?

Raccontateci la vostra esperienza nei commenti: qual è stato il team più auto-gestito con cui avete lavorato e com'è andata? Qual è stato il vostro caso più frustrante come “cat herder” invece che leader strategico?

E se volete affinare le vostre skill da leader strategico di progetto, unitevi alla nostra community!

Visitate thedigitalprojectmanager.com/membership per accedere a una comunità di supporto che condivide conoscenze, risolve sfide complesse e costruisce il futuro del nostro mestiere — insieme.

Da template robusti a sessioni mensili di formazione che fanno risparmiare tempo ed energie, dal supporto dei colleghi nel nostro forum fino agli eventi e ai mastermind group: far parte della community significa avere oltre mille persone dalla tua parte nella crescita del project delivery digitale.

Se ti è piaciuto l’episodio iscriviti e resta in contatto su thedigitalprojectmanager.com

Alla prossima, grazie per l’ascolto.