Una Senior PM afferma che i team di consegna devono concentrarsi sull’attrito invece di inseguire l’automazione

Per quanto riguarda la consegna dei progetti, mi concentro su cosa costruiamo e perché, allineando i team sulle priorità e assicurando che il rilascio sia affidabile e veloce. Questo significa lavorare da vicino con l’ingegneria sull’esecuzione, mantenendo però sempre un forte focus sull’impatto al cliente, sulla qualità e sul miglioramento continuo.

You should also read

• Sovraccarico di Strumenti AI? Una Guida per Gestire le Tue Opzioni

• Strumenti AI che hanno sostituito il lavoro manuale nel 2026

• Vibecoding per Project Manager: 6 Esempi di Progetti Vibecodificati da Veri PM

Perché l’IA sposta la delivery dei progetti da reattiva a strategica

L’IA ha cambiato radicalmente sia il mio ruolo sia la routine della delivery di progetto. Prima, la consegna dipendeva da coordinamento manuale, debug reattivo e analisi umana. Oggi, con l’integrazione dell’IA nei nostri flussi di lavoro, il lavoro è diventato più strategico.

A cosa dedico meno tempo ora:

• Smistamento e debug manuali: Prima identificare la causa principale dei bug richiedeva numerosi passaggi tra i team. Ora i sistemi di IA possono rilevare, classificare e persino suggerire soluzioni in automatico. Questo ha ridotto notevolmente lo sforzo iniziale.
• Scrivere specifiche dettagliate per ogni caso limite: Anziché documentare tutto in modo esaustivo subito, ci affidiamo di più all’esplorazione assistita dall’IA, simulazioni e iterazioni rapide per perfezionare le soluzioni.
• Monitoraggio dello stato e coordinamento: Tracciamento dei progressi, sintesi e reportistica ora sono automatizzati, riducendo la necessità di continue verifiche.

Saloni condivide

Il mio ruolo si è evoluto dal gestire da vicino l’esecuzione al modellare come i sistemi intelligenti lavorano al nostro posto.

Cosa richiede più attenzione ora:

• Definire i problemi e i segnali giusti: Poiché l’IA può agire rapidamente, la qualità degli input è molto più importante. Dedico più tempo a pensare cosa monitorare, quali segnali sono rilevanti e come i sistemi dovrebbero rispondere.
• Progettare workflow assistiti dall’IA: Invece di singole funzionalità, stiamo progettando flussi end-to-end in cui agenti IA rilevano problemi, intervengono e, a volte, li risolvono. Questo passaggio da strumenti a sistemi rappresenta una parte importante del mio ruolo.
• Qualità e fiducia: Quando l’IA prende o suggerisce decisioni, assicurare affidabilità, spiegabilità e fiducia dell’utente è fondamentale. Dedico più tempo a validare i risultati e definire le regole di controllo.
• Velocità con accountability: Rilasciamo più rapidamente di prima, ma anche le aspettative sono più alte. Non si tratta solo di andare veloci, ma di farlo senza regressioni. Questo equilibrio richiede un’attenzione più stringente al prodotto.

In generale, cosa è cambiato nella delivery dei progetti: siamo passati da un modello umano e reattivo a uno arricchito dall’IA e più proattivo. Rileviamo prima i problemi, i cicli di risoluzione si accorciano e i team dedicano meno tempo a risolvere urgenze e più tempo a migliorare il sistema stesso.

Quindi il mio ruolo si è evoluto dal gestire da vicino l’esecuzione al modellare come i sistemi intelligenti lavorano al nostro posto.

Come l’IA trasforma la gestione degli incidenti

Non abbiamo cercato di automatizzare tutto. Invece, ci siamo concentrati sulle aree più frequenti e ripetitive dal punto di vista cognitivo che rallentavano gli ingegneri. La gestione degli incidenti e la RCA era una di queste, perché capita ogni giorno, comporta un alto costo in termini di tempo ed è ricca di schemi ricorrenti.

La nostra struttura di agenti comprende un agente Signal che rileva anomalie tramite telemetria; un agente Context che recupera log, tracce ed esecuzioni correlate; un agente RCA che genera la causa principale e le evidenze correlate; e infine un agente Action che crea un ticket con tutto il contesto. Questa è stata l’area migliore da cui partire, perché il successo è misurabile tramite il MTTR.

Questo ci ha portato a costruire un motore RCA sopra il nostro livello di osservabilità.

Come i sistemi guidati dall'AI risolvono la complessità nei casi reali

Abbiamo costruito un motore RCA per ridurre l'MTTR, ma il vero cambiamento è stato passare da un'indagine manuale a una diagnosi guidata dal sistema. Il problema era che, quando si verificava un bug, i log erano sparsi tra i servizi, gli ingegneri dovevano ricostruire manualmente il flusso e l'analisi della causa principale dipendeva fortemente dall'esperienza individuale. Anche per problematiche note, l'MTTR era incoerente perché il processo non era ripetibile.

Come soluzione, abbiamo creato un motore RCA che si appoggia al nostro livello di osservabilità ed esegue automaticamente tre attività:

Ricostruzione del contesto

• Recupera log, metriche e tracce di esecuzione tra i servizi
• Ricostruisce il percorso esatto del fallimento (passo dopo passo all'interno di un batch o di un flusso)

Riconoscimento di pattern + rilevamento di similarità

• Confronta il problema con gli incidenti storici
• Utilizza embeddings per identificare incidenti simili già avvenuti

Suggerimento della causa principale assistito dall'AI

• Classifica il problema (problema di dati, configurazione, regressione del codice, infrastruttura)
• Suggerisce la causa principale più probabile
• Fornisce prove a supporto, non solo una risposta

Perché l'impatto dell'AI dipende dalla qualità del sistema

All'inizio, abbiamo ipotizzato che uno strato LLM avrebbe migliorato direttamente i risultati. Non è stato così. Le prime versioni sono state deludenti. Abbiamo imparato subito che l'AI non risolve i sistemi disordinati. Li amplifica. E abbiamo capito che la qualità dei dati conta più della qualità del modello.

Abbiamo trascorso molto tempo sistemando log incoerenti, contesto mancante tra servizi e segnali poco definiti. Una volta che i dati sottostanti sono diventati strutturati e affidabili, anche semplici soluzioni d'AI hanno funzionato bene.

La fiducia è importante quanto la precisione. Anche quando il motore RCA o il sistema di triage si dimostravano tecnicamente corretti, gli ingegneri non li utilizzavano. Perché? Perché non si spiegavano.

All’inizio, abbiamo ipotizzato che uno strato LLM avrebbe migliorato direttamente i risultati. Non è stato così. L’AI non risolve i sistemi disordinati. Li amplifica. La qualità dei dati conta più della qualità del modello.

Share This Quote on:

• Share on Twitter
• Share on LinkedIn
• Share on Facebook

Saloni MalhotraOpens new window

Senior Product Manager, R&D team at o9 Solutions

Le persone non hanno bisogno di un'AI perfetta. Hanno bisogno di un'AI comprensibile. Il vero guadagno non è la velocità — è la focalizzazione. Credevamo che l'AI ci avrebbe semplicemente reso più veloci. Ma gli ingegneri non si limitavano a chiudere i ticket più in fretta. Hanno iniziato a chiedersi: “Perché esiste questo tipo di problema?” È un modo di pensare diverso. Stretto e specifico batte ambizioso e ampio. Il nostro istinto iniziale era di costruire un sistema intelligente e ampio. Quello è fallito. L'adozione dell'AI non è stato un big bang. È stata una serie di piccoli successi mirati.

Abbiamo visto un cambiamento solo quando abbiamo allegato prove (log, tracce, confronti) e mostrato perché era stata raggiunta una certa conclusione. Di conseguenza, abbiamo trascorso meno tempo su indagini ripetitive e più tempo su miglioramenti a livello di sistema. Abbiamo poi ottenuto risultati scegliendo casi d'uso specifici (come l'RCA per i fallimenti dei batch), risolvendoli a fondo ed espandendo gradualmente.

Come gli strumenti AI aumentano l'efficienza nella delivery dei progetti

Ecco il nostro stack.

Livello AI e di intelligenza:

• LLM (modelli classe GPT) — RCA, sintesi, classificazione
• Embeddings + Vector DB (FAISS / Pinecone) — ricerca per similarità, recupero di incidenti
• Pipeline RAG — grounding degli output AI con log e dati storici
• Rilevamento anomalie (regole + ML) — individuazione pattern di fallimento

Osservabilità e dati:

• Logging e monitoraggio (Elastic / Datadog / OpenTelemetry)
• Sistemi di tracciamento distribuiti
• Pipeline di dati (Python, elaborazione in streaming/batch)
• Livelli di archiviazione delle telemetrie e di feature engineering

Delivery e workflow:

• CI/CD (GitHub Actions / Jenkins)
• Tracciamento delle issue (Jira o simili)
• Framework per la validazione/simulazione delle release

Produttività degli sviluppatori:

• Assistenti di codice (GitHub Copilot o simili)
• Copiloti AI interni per debugging e interrogazione dei sistemi

In generale, l'evoluzione degli ultimi 6-12 mesi è stata:

• Da dashboard → insight assistiti dall’AI
• Da triage manuale → RCA automatizzato
• Da strumenti isolati → pipeline collegate
• Da debugging reattivo → rilevamento proattivo

Come Claude e Figma aumentano la produttività del team

Combinare Claude con Figma si è rivelato sorprendentemente strategico per noi. Prima, il nostro flusso era così: il PM scriveva un PRD, il designer lo interpretava e si susseguivano più cicli di feedback.

Adesso inseriamo in Claude idee grezze, flussi o addirittura appunti disordinati e gli chiediamo di strutturare i flussi, suggerire casi limite e generare ragionamenti a livello di schermata.

Poi, traduciamo direttamente in Figma, dove creiamo wireframe molto più velocemente, esploriamo varianti rapidamente e riflettiamo su microcopy e stati.

Perché i sistemi leggeri stanno sostituendo la gestione dei progetti tradizionale

I sistemi tradizionali funzionavano, ma erano lenti nell’adattarsi, avevano un alto overhead di coordinamento e spesso erano slegati da ciò che accadeva veramente sul sistema. Il “tradizionale” si presentava così: PRD molto dettagliati all’inizio (spesso obsoleti nel giro di poche settimane), piani sprint fissi con ambito rigido, tracciamento manuale dello stato (standup, report, dashboard), strumenti separati per pianificazione, esecuzione e monitoraggio.

Ora siamo passati da PRD pesanti a specifiche modulari e contesto in tempo reale. Con questo nuovo approccio possiamo scomporre tutto in: definizione del problema, flussi chiave e vincoli. Possiamo anche archiviarli in formati leggeri (documenti + ticket) e usare LLM per espandere ai casi limite, generare scenari di test.

Trascorriamo molto meno tempo a scrivere documenti esaustivi (PRD da 10-15 pagine in Confluence). Al contrario, abbiamo un input strutturato in una pagina sola con problema, user flow e vincoli.

Per fare questo abbiamo utilizzato i seguenti strumenti:

• Confluence (utilizzo ridotto)
• Jira (fonte primaria di verità)
• Strato LLM (modelli di classe GPT via API)
• Figma
• Claude (per la strutturazione dei flussi)

Ecco il nostro processo:

• Input strutturato in 1 pagina:
  • Problema
  • User flow
  • Vincoli
• Lo inseriamo in Claude / LLM per:
  • Espandere i flussi
  • Generare casi limite
  • Redigere criteri di accettazione
• Convertiamo direttamente in ticket Jira + wireframe Figma

L’impatto è stato il seguente:

• Riduzione del 40–50% del tempo dall’idea al primo rilascio
• Meno cicli di feedback tra PM, design ed engineering
• Versione iniziale delle feature molto più chiara

Come l’integrazione dell’IA cambia i rituali di delivery

Inoltre, la definizione del perimetro è passata dall’essere esaustiva all’essere orientata. In passato si cercava di definire tutto in anticipo e di coprire ogni possibile caso nei PRD. Ora si definiscono il problema, i flussi chiave e i vincoli. Poi si usa l’IA per espandere i casi limite, simulare scenari e individuare le lacune. Il perimetro non consiste più nella completezza al giorno uno; consiste nel fissare una direzione chiara e nel consentire un ciclo di perfezionamento rapido.

Tra cinque anni, i piani non saranno più “scritti”, ma generati in modo continuo. Penso che i piani saranno sistemi viventi, non documenti. L’IA aggiornerà costantemente priorità, rischi e tempistiche sulla base dell’esecuzione reale, dei segnali dei clienti e della salute dei sistemi. La pianificazione sarà dinamica e sempre aggiornata, non un esercizio periodico.

Saloni Condivide

L’IA funziona al meglio quando elimina un dolore reale e quotidiano, non quando è aggiunta come ulteriore livello.

Perché è fondamentale affrontare gli attriti prima dell’adozione dell’IA

Non partire dall’IA. Parti dagli attriti.

È facile chiedersi: “Dove possiamo usare l’IA?” Di solito non è questo l’approccio giusto. Meglio domandarsi: In quali punti i team perdono tempo ripetutamente? Dove il lavoro dipende troppo da poche persone? Dove le cose rallentano sotto pressione? Scegline uno e risolvilo a fondo.

L’IA funziona al meglio quando elimina un dolore reale e quotidiano, non quando è aggiunta come ulteriore livello.

Rimani aggiornato

Puoi seguire il lavoro di Saloni su LinkedIn.

In arrivo altre interviste con esperti su The Digital Project Manager!