Potresti Star Guardando Alle Pietre Miliari Nel Modo Sbagliato (con John Carter di TCGen)

Leggi la Trascrizione:

Stiamo testando la trascrizione dei nostri podcast utilizzando un programma software. Ci scusiamo per eventuali errori di battitura, il bot non è corretto al 100%.

Galen Low

Eccoti lì, di nuovo a fissare il tuo piano di progetto, temendo proprio quelle pietre miliari che hai contribuito a creare. Sembrano avvicinarsi ogni volta che le guardi, come degli Space Invaders a forma di diamante. All’inizio sembravano così innocue: erano solo semplici linee sulla sabbia per aiutarti a pianificare a grandi linee. Ora sono diventate un peso al collo: scadenze pesanti, immobili, con cui non si può ragionare. Sono i mormorii del dubbio che minacciano di trascinarti nella tana di un drago fatta di stakeholder arrabbiati quando arriverà il fatidico giorno. Se tutto ciò ti suona familiare, mi spiace dirti che sei uno di quei PM che ha usato le pietre miliari di progetto in modo completamente sbagliato. Tranquillo, siamo in tanti sulla stessa barca. Ma se vuoi trasformare le pietre miliari del tuo progetto da un fardello terrorizzante a una Stella Polare per la collaborazione di team e stakeholder, continua ad ascoltare.

Grazie per l’ascolto. Mi chiamo Galen Low e sono con il Digital Project Manager. Siamo una comunità di professionisti digitali con la missione di aiutarci a vicenda a diventare più competenti, sicuri e connessi per consegnare progetti migliori. Se vuoi saperne di più, vai su thedigitalprojectmanager.com.

Bene. Ciao a tutti, grazie per essere con noi nel DPM Podcast. Il mio ospite di oggi è un esperto ampiamente rispettato nello sviluppo prodotto e anche non estraneo alla gestione di progetti. È una delle menti chiave dietro alle cuffie con cancellazione del rumore di Bose, così come del processo Apple per lo sviluppo di nuovi prodotti. Oggi la sua azienda, TCGen, consiglia marchi di peso come Amazon, Apple, Cisco, Hewlett-Packard, IBM, Mozilla, Roche e 3M. E di recente ha assunto anche un tutor per imparare la teoria musicale e ora sta componendo musica. Quindi, signore e signori, diamo il benvenuto a John Carter. Ciao, John.

John Carter

Ciao Galen. Felice di essere qui.

Galen Low

Un piacere averti nel nostro show. Davvero grazie. Guardando il tuo CV pensavo: probabilmente tutti ne sono invidiosi. Innovazione di prodotto per Bose, collaborazioni con Apple, ora un’impresa tua, libri scritti… Quindi vorrei iniziare chiedendoti: cosa volevi fare da grande?

John Carter

Domanda simpatica. Ed effettivamente lo faccio ancora nel tempo libero, cioè l’ingegnere. Ho sempre voluto progettare cose, fare calcoli e prevedere risultati. È qualcosa che ancora oggi mi motiva, e continua a spingermi avanti.

Galen Low

Fantastico! È stato un’ispirazione per tuffarti nel lato più innovativo delle cose? Immagino che la mentalità ingegneristica si presti naturalmente a creare cose nuove, fattibili, e che la gente possa realmente usare.

John Carter

Beh, non credo fosse così ponderato quando ho iniziato, ma ero il classico ragazzino scienziato. Avevo il kit di chimica, un microscopio, il telescopio, la licenza radioamatoriale. Facevo tutte queste cose da nerd. Amavo davvero ciò che facevo. Mi ha portato a ciò che amo ora: amavo l’elettronica e il fatto di non poter vedere l’elettricità o gli elettroni ma comunque poterli misurare e utilizzarli. Oggi la stessa cosa succede con il suono: non lo vedi, ma ha un grande impatto su come ti senti e pensi. Ho sempre cercato di comprendere fenomeni che non puoi vedere.

Galen Low

C’è stato un momento ispiratore in cui hai deciso di uscire dal puro ingegneristico e buttarti più verso tecnologia o prodotti digitali?

John Carter

In un certo senso è avvenuto spontaneamente mentre lavoravo con il Dr. Bose presso la Bose Corporation, il mio punto di partenza. Era fenomenale, sia sul marketing che sull’ingegneria — una capacità molto rara. Faceva domande basilari su ciò che la gente voleva, cosa fosse importante per loro. Quella sua visione di vita mi ha fatto capire l’importanza di comprendere davvero i bisogni del cliente e assicurarsi di consegnare davvero ciò che conta. Capivamo che, anche da inventori, non avevamo idea di cosa i clienti avrebbero davvero apprezzato finché non glielo mettevi in mano. Quindi è stato un passaggio graduale dall’ingegneria all’innovazione, grazie a Dr. Bose.

Galen Low

Fantastico. Hai fatto tanto nella tua carriera; oggi c’è qualcosa su cui stai cercando di migliorare ancora?

John Carter

Sempre! Due cose mi interessano particolarmente: l’intersezione tra Agile e project management e le implicazioni di ciò che chiamo sviluppo prodotto digitale. Com’è lavorare sul machine learning rispetto allo sviluppo prodotto classico? Come innovare in un ambiente digitale e con il lavoro da remoto? È un momento affascinante e cerco di comprendere cosa guida l’onda dell’innovazione.

Galen Low

Fantastico. C’è qualcos’altro che ha reso la tua vita entusiasmante ultimamente?

John Carter

Penso che una cosa che ha rinnovato la mia fiducia nel genere umano sia la capacità di innovare continuamente. Basta guardare i problemi attuali e a come il mondo ha dovuto cambiare su temi come lavoro remoto, istruzione, sviluppo e distribuzione farmaceutica. C’è una trasformazione positiva da questa crisi che mi fa credere nella nostra capacità di innovare di fronte a ogni situazione. Questo mi dà molta speranza.

Galen Low

Bello trovare il lato positivo in uno scenario non proprio ottimale. Parliamo allora del tuo recente articolo su thedigitalprojectmanager.com, dedicato alle pietre miliari di progetto. Personalmente mi ha fatto capire di averle sempre approcciate in modo sbagliato. E mi ha fatto riflettere sul legame tra milestone e successo/fallimento di un prodotto sul mercato, come non avevo mai fatto. Ma torniamo all’inizio: cosa sono per te le pietre miliari di progetto e perché dovrebbero interessare a qualcuno?

John Carter

Bella domanda, e giusta per iniziare, perché penso che la gente abbia visioni sbagliate sulle milestone nella gestione di progetti digitali. La gente pensa che le milestone servano a misurare i progressi. Esistono molti altri modi migliori per misurare i progressi, modi che non consumano il team e non producono una valanga di report inutili e che inducono il micromanagement. Quindi l’errore comune è usare le milestone per monitorare, ma in realtà sono punti di svolta, periodi o decisioni critici dove investi di più, assumi rischi o stringi accordi, dove serve davvero fare i compiti a casa. Inoltre, nel mondo digitale e interconnesso, esistono tante dipendenze tra attributi di progetto, e le milestone sono un ottimo modo per sincronizzare le dipendenze tra team che lavorano in modalità Agile: arriva un punto in cui il lavoro di uno serve all’altro. Le milestone servono proprio a coordinare queste attività.

Galen Low

Mi piace questa visione. Hai citato alcuni equivoci sulle milestone, come il fissarsi sul monitoraggio. Quali sono le conseguenze di questo approccio in un progetto?

John Carter

Ce ne sono molte. Anzitutto, erode la fiducia nel fatto che il management si fidi del team. Se i progetti sono pieni di check-in, revisioni e milestone review, il team si guarda sempre le spalle domandandosi cosa pensi il management.

È un atteggiamento corrosivo, perché non rafforza la fiducia in sé stessi e nella capacità di consegnare risultati eccellenti grazie alla propria iniziativa, cosa in cui tutti credono.

E poi è un peso: si producono montagne di report che nessuno legge, grafici noiosi e aggiornamenti inutili. Ma qual è il senso? Comunicare? Beh, ci sono dashboard, backlog, tanti modi migliori. Se bisogna decidere, allora vale la pena fare una milestone vera, ma dovrebbero essere rare. Ridurre il numero e la frequenza delle review è fondamentale. E così si implementano milestone davvero efficaci.

Galen Low

Quindi conta più “fare” che “fermare e valutare”.

John Carter

Esatto. E poi accade che il management vuole “aggiungere valore” e invece aggiunge solo attività inutili, costringendo il team a produrre ancora più report perché qualcuno vuole “vedere di più”. È come se mettessero sedie lungo il percorso del team, mentre in realtà dovrebbero toglierle e farsi da parte.

Troppe milestone stimolano il micromanagement; il giusto numero incoraggia le scelte giuste.

Galen Low

Sei mai arrivato a pensare “lo sto facendo nel modo sbagliato, dovrebbe essere più sul team e meno sul reporting?”

John Carter

Sì, subito dopo essere stato promosso a chief engineer in Bose. Avevo la tendenza a micromanagement, a fissare più review e milestone e mi sono reso conto che stavo annegando nei dettagli e le review non aiutavano nemmeno i team. E poi ho capito che alcuni leader e tecnici dei team sapevano molto più di me. Dovevo solo lasciarli lavorare. La consapevolezza è avvenuta quando uno degli ingegneri disse che stavo creando solo distorsione, ritardo e rumore. Da quel momento ho smesso con le troppe milestone.

Galen Low

Hai visto un miglioramento immediato?

John Carter

Non subito. Col tempo il team è diventato più produttivo, io più felice. Senza il mio controllo, lavoravano anche meglio. Sollevi un peso al team: diventano più produttivi, motivati, soddisfatti e fanno prodotti migliori.

Galen Low

L’atmosfera di sfiducia è un peso, quella di fiducia alleggerisce il lavoro.

John Carter

Proprio così, è come un’atmosfera caustica sempre presente.

Galen Low

Parliamo di come si fa bene: hai detto che le milestone sono più per il team che per manager. Come si fa a farlo capire, se non lo vedono già così?

John Carter

Tutto ruota attorno all’ambiente di fiducia. Serve un product owner competente, uno scrum master valido e un capo tecnico capace. Con questi tre ruoli, il management dovrebbe fidarsi. Con la competenza, non serve il micromanagement continuo. E allora spieghi al team perché alcune milestone sono davvero importanti. Ecco il punto più importante. Le milestone non devono mai essere periodiche.

Non serve un meeting settimanale fisso o review mensili. Se proprio servono, che sia per macro decisioni. Le milestone devono essere “guidate dagli eventi”, non dal calendario, legandosi a maturità, dimensione, rischio, velocità del team e alla sfida. Se le milestone sono a cadenza regolare c’è un problema di fondo.

Galen Low

Quasi una questione di sfiducia: “ti controllo ogni due settimane”.

John Carter

Esattamente.

Galen Low

Meglio che siano collegate a tappe essenziali per la collaborazione e la pianificazione futura.

John Carter

Esatto. O, ad esempio, prima di firmare un assegno a sette cifre: dobbiamo essere certi di fare la cosa giusta.

Galen Low

Parlando invece dei team pronti a gestirsi le proprie milestone, che comportamenti osservi in chi le capisce davvero?

John Carter

Ottima domanda. La risposta semplice è: la storia. Il team è stato affidabile in passato? Ha portato risultati? La fiducia si costruisce nel tempo. L’indicatore migliore è la storia e il successo pregresso. Ogni ruolo chiave deve avere le competenze: chi si occupa del prodotto deve conoscere a fondo il perché e il cosa, il capo tecnico deve saper fare le scelte architetturali giuste, il project manager deve essere trasparente e comunicare velocemente eventuali problemi. Questi comportamenti, insieme alla storia, fanno la differenza.

Galen Low

Quindi vuoi persone con esperienza, ma anche spazio per i giovani.

John Carter

Assolutamente, e conta non l’età ma le esperienze, i cicli di apprendimento: se ne hanno avuti vari con buoni esiti, puoi fidarti del team.

Galen Low

Cicli di apprendimento… interessante. E invece se la dirigenza è abituata a review mensili o a dodici milestone in poco tempo, come la convinci a cambiare approccio?

John Carter

Bella domanda. Dipende. Se in azienda esistono strumenti di misurazione del progresso (backlog, story point, deliverable completati), ci sono metriche oggettive e leggere che possono fare da proxy. I manager spesso confondono trasparenza e monitoraggio con la decisione vera, che sono cose diverse. Il tracciamento del progresso può essere fatto con dashboard o indicatori, o in riunione solo quando serve. Dobbiamo assicurarci che il manager abbia modo di vedere i progressi e di essere avvisato dei problemi. C’è anche il concetto di “condizioni di confine”: se il team rischia di non rispettarle, sta al team stesso avvisare la direzione. Quindi se il management ha trasparenza, riceve tempestivamente le notizie negative e si fida della storia del team, possiamo spiegare bene perché servono meno milestone.

Ti torna?

Galen Low

Assolutamente. Mi piace la distinzione fra tracciamento e milestone decisionali — che sono momenti chiave per valutare la direzione del progetto prima di ingaggiare nuove risorse o passaggi.

John Carter

Proprio così. Un check di valore aggiunto.

Galen Low

Parlando di pianificazione: questa visione cambia il modo di creare le milestone e i piani di progetto? O si tratta solo di spostare il check-in da cadenzato a su bisogno?

John Carter

Assolutamente sì. Tutti gli altri report di stato e aggiornamenti a steering committee andrebbero ridotti o eliminati. Serve una struttura di lavoro leggera con pochi punti di svolta standard, adatti al tuo business. Ogni azienda ha le sue specifiche: se produci componenti, la fase di ordine è critica; nei progetti digitali è fondamentale che l’analytics sia pronto quando vai live. Le milestone devono essere standardizzate, poche e leggere, sufficienti a guidare le grandi decisioni, tipicamente tre-cinque.

Galen Low

Ottime analogie (componenti, dipendenze…). Ogni settore ha i suoi punti critici.

John Carter

Esatto. Nei progetti digitali hai cloud, client, desktop da integrare, DevOps da coordinare: ogni azienda è diversa.

Galen Low

Nel tuo articolo parli di tre milestone principali come punti di svolta legati a obiettivi aziendali fondamentali. Puoi spiegarle meglio?

John Carter

Certo, sono fondamentali specie quando parliamo di innovazione “con la I maiuscola”. All’avvio del progetto digitale bisogna chiedersi: il concetto è allineato con la nostra strategia? È il tipo di prodotto che vogliamo portare sul mercato? Sposterà davvero il fatturato? Dato che ci impegneremo per mesi e con risorse importanti, deve essere una scelta strategica. Poi serve assicurarsi di avere il product-market fit: i consumatori lo sceglieranno? Ci sono delle unique selling proposition reali? I dati lo dimostrano (costi di acquisizione, proof point, vitalità di mercato…)? La seconda fase, quindi, serve soprattutto prima di far crescere il team. Infine lo sviluppo e il lancio: ora che abbiamo la strategia e il mercato, per rendere reale il prodotto ci serviranno investimenti e partner specifici (UI, grafica, sviluppo desktop/tablet…), quindi si valuta se procedere e investire. Questi sono i tre snodi decisivi che, secondo la mia esperienza, regolano lo sviluppo prodotto digitale; ogni realtà può aggiungere fasi come ideazione iniziale o validazione finale, ma avere tappe comuni aiuta a confrontare e allocare risorse sui progetti.

Galen Low

Mi piace l’idea di “benchmarking” tra progetti: non solo per misurare l’avanzamento ma per capire lo stato evolutivo della soluzione e l’impegno richiesto a breve.

John Carter

Esatto. Le tre milestone che citiamo non sono collegate a data. Sono “ci siamo con la strategia?”, “abbiamo il product-market fit?”, “siamo pronti all’investimento?”. Gestirne tre non è mai un carico pesante.

Galen Low

Chiave: queste tappe sono immobili o no? Spesso le milestone sono considerate fisse. Tu cosa ne pensi?

John Carter

C’è una differenza tra speranza e realtà. Nello sviluppo agile puro, teoricamente una milestone non si mancata mai. In pratica, sposti Sprint non milestone. Anche facendo agile, c’è un momento di feature complete che è cruciale. Queste milestone sono generiche e adatte a ogni situazione, e aiutano a velocizzare l’innovazione.

Galen Low

Hai esempi pratici di milestone “concept fit” e “product-market fit”?

John Carter

Certo, ho appena implementato un sistema chiamato venture board in una grande realtà tecnologica. Si parte da una mappa strategica delle idee: la tua è in linea col brand? Sposterà il fatturato? Questo è il “concept fit”. Il “product-market fit” invece si valuta su parametri esterni: ad esempio il costo di acquisizione cliente, le reali preferenze degli utenti. Nel caso delle cuffie Bose, all’inizio ci focalizzavamo sulla qualità audio, ma il vero valore per i clienti era la riduzione del rumore: abbiamo dovuto cambiare in corsa. Il “fit” si misura solo con il confronto reale col pubblico. Quanto al lancio, serve un business case: alla fine la marginalità e il ritorno devono essere davvero superiori ai costi. Questi tre punti sono fondamentali per decidere se vale la pena investire ulteriormente sul prodotto digitale.

Galen Low

Nel tuo esempio sulle cuffie, la milestone non era un punto di fallimento, ma di valutazione e svolta, giusto?

John Carter

Esatto, e lo abbiamo fatto in anticipo. Questa è la chiave.

Galen Low

Per chi segue metodologia agile: servono ancora le milestone? Come si integrano col project manager?

John Carter

È un pregiudizio sbagliato che Agile e milestone siano incompatibili. La verità è che ogni azienda che dice di fare Agile ha comunque milestone. Gli “integralisti” propagano il mito opposto, ma in realtà anche nei progetti agili, per gestire le dipendenze si mappano “milestone” (lavoro di altri team, Sprint Zero, pianificazioni). Anche l’investimento importante richiede una milestone decisionale. Quindi Agile e milestone convivono benissimo, e i migliori sistemi usano entrambi.

Galen Low

Giusto.

John Carter

Io credo in un agile con la “a” minuscola: prendere le pratiche agili che davvero creano valore per l’azienda.

Pianificazione Sprint, demo, feedback clienti… scegli le pratiche utili.

Galen Low

I tuoi spunti sulle pietre miliari sono preziosi. Mi colpisce l’idea di milestone standard come strumento di misura trasversale tra progetti e anche di dialogo con stakeholder e board nelle grandi decisioni.

John Carter

Esatto, è ciò che abbiamo fatto con Apple: poche milestone standard e linguaggio condiviso.

Galen Low

Dove partire per cambiare approccio? Qual è il primo passo per chi vuole adottare questa visione delle milestone?

John Carter

La prima cosa è capire come azienda quali sono davvero le decisioni chiave. Dove sono i “colli di bottiglia”, le tappe obbligatorie per ogni progetto? Mettetevi d’accordo su queste, chiamatele sempre allo stesso modo e fatele usare da tutti i team. È così che abbiamo scalato il processo di lancio nuovi prodotti di Apple: poche milestone standard, chiamate sempre uguale, chiarendo cosa serve per completarle. Sembra semplice, ma il primo passo è proprio adottare questa mentalità.

Galen Low

E una volta che si è imboccata la strada, qual è la cosa più importante da ricordare?

John Carter

Rimanere fedeli al ciclo di fiducia, decisione e monitoraggio: servono persone capaci di gestire i progetti in autonomia, milestones come puro strumento di decisione e un sistema di monitoraggio poco invasivo che dia ai dirigenti ciò che serve senza appesantire il team.

Galen Low

Fantastico.

John, grazie mille per essere stato con noi oggi. I tuoi insight sono stati illuminanti e penso cambieranno davvero la vita a molti ascoltatori.

John Carter

Grazie per l’opportunità di parlarne. Hai colto i punti chiave e sono felice di aver contribuito, Galen.

Galen Low

E voi che ne pensate? Avete consigli, hack e trucchi sulle pietre miliari? Cosa funziona, cosa no? Raccontateci la vostra esperienza nei commenti. Se volete imparare di più e migliorare nel lavoro, unitevi alla nostra community DPM Membership su thedigitalprojectmanager.com/membership per accedere a forum esperti, gruppi di mentorship, workshop, sessioni mentorship live, ask me anything, ebook, template e altro ancora. Se vi è piaciuto l’episodio, iscrivetevi e seguiteci su thedigitalprojectmanager.com. Alla prossima, grazie per l’ascolto.