Il developer e il Project Manager si odiano. Hanno torto entrambi. Dev vs PM: la guerra che nessuno vince e tutti perdono.

C'è una conversazione che si ripete in ogni team di sviluppo del mondo, da sempre. Il developer guarda il Project Manager e pensa: "Cosa fa esattamente questa persona? Organizza riunioni, manda email, chiede aggiornamenti. Io scrivo il codice vero. Lui gestisce il calendario."

Il Project Manager guarda il developer e pensa: "Perché risponde sempre a monosillabi? Perché stima tre giorni per qualcosa che poi ne richiede tre settimane? Perché ogni volta che chiedo un aggiornamento sembra che lo stia disturbando mentre salva il mondo?"

Nessuno dei due ha torto al 100%. Nessuno dei due ha ragione al 100%.

E nel mezzo, i progetti si arenano, i clienti si arrabbiano, i team si logorано. Non per mancanza di competenze tecniche. Non per mancanza di metodologie. Ma perché due figure che dovrebbero essere alleate passano il tempo a non capirsi, o peggio, a snobbarsi.

Questo articolo non è una difesa d'ufficio del PM né un attacco ai dev. È un tentativo di guardare la cosa in faccia, senza sconti per nessuno.

😢​ Perché i developer snobbano i Project Manager

Iniziamo dall'elefante nella stanza, perché negarlo non serve a nessuno.

C'è una certa tradizione nella cultura tech di considerare il lavoro "vero" quello che produce artefatti tangibili: codice, architetture, prodotti. Tutto il resto: riunioni, documentazione, aggiornamenti di stato, Gantt, tende a essere percepito come overhead. Come il costo necessario e fastidioso di lavorare in un'organizzazione.

Il PM, in questo schema mentale, diventa il simbolo di tutto ciò che rallenta. È quello che interrompe il flusso per chiederti "a che punto sei". È quello che trasforma una conversazione tecnica in una serie di bullet point su una slide. È quello che porta il cliente in call senza avvisarti, e tu ti ritrovi a spiegare perché una feature ovviamente impossibile "tecnicamente si potrebbe fare, ma...".

Ci sono anche PM che alimentano questo stereotipo. PM che non capiscono nulla di tecnologia e si limitano a trasmettere messaggi avanti e indietro senza aggiungere valore. PM che usano la metodologia come scudo invece che come strumento. PM che misurano il successo in riunioni organizzate invece che in problemi risolti.

Esistono. Sarebbe disonesto negarlo.

Ma confondere i PM mediocri con il ruolo di Project Manager è come confondere i dev mediocri con l'ingegneria del software. Il problema non è la figura, è la persona, e spesso è il contesto che la ha formata così.

🔍​ Cosa fa davvero un Project Manager (e perché non è ovvio)

Qui sta il cuore del malinteso: il lavoro del PM è per sua natura invisibile quando funziona.

Quando un progetto va bene, le scadenze reggono, il cliente è soddisfatto, il team lavora senza caos, le priorità sono chiare, nessuno pensa "ottimo lavoro del PM". Si pensa "ottimo team". Quando il progetto va male, invece, il PM diventa il capro espiatorio naturale.

Vediamo cosa c'è davvero dietro.

Traduzione tra mondi

Un PM vive costantemente al confine tra due linguaggi che non si parlano: quello del business e quello della tecnologia. Il cliente dice "vogliamo che l'app sia più veloce e faccia tutto quello che fa adesso ma meglio". Il dev dice "dobbiamo riscrivere il layer di persistenza e refactorare l'architettura degli stati". Il PM deve tradurre l'uno all'altro, in entrambe le direzioni, senza perdere il senso e senza perdere la fiducia di nessuno dei due.

Questo non è passacarte. È interpretariato ad alto rischio.

Gestione dell'incertezza

Solo il 35% dei progetti al mondo si conclude con successo, rispettando tutti gli obiettivi e le scadenze. Il restante 65% si perde nell'incertezza, requisiti che cambiano, risorse che saltano, priorità che si invertono, imprevisti tecnici che nessuno aveva preventivato.

Il PM è quella figura il cui lavoro principale è assorbire questa incertezza prima che raggiunga il team tecnico. Non eliminarla, è impossibile, ma trasformarla in qualcosa di gestibile. Dare al dev il contesto giusto nel momento giusto, proteggere il focus del team dalle oscillazioni del cliente, prendere decisioni difficili con informazioni incomplete.

Comunicazione verso l'esterno

La scarsa comunicazione è la causa principale del 30% dei fallimenti di progetto. Non i bug. Non le scelte architetturali sbagliate. La comunicazione.

Il PM gestisce stakeholder multipli con aspettative diverse, livelli di comprensione tecnica diversi, e interessi spesso conflittuali. Mantiene allineate persone che non sono mai nella stessa stanza, su progetti che durano mesi, mentre le condizioni cambiano continuamente.

Risk management anticipatorio

Un buon PM vede i problemi tre settimane prima che diventino emergenze. Nota che la dipendenza da una libreria esterna potrebbe diventare un collo di bottiglia. Si accorge che due sviluppatori stanno lavorando sulle stesse parti del sistema senza coordinarsi. Capisce che il cliente sta cambiando aspettative senza dirlo esplicitamente, e interviene prima che la divergenza diventi irrecuperabile.

Questo lavoro non ha commit visibili. Non ha release notes. Ma senza di esso, i progetti collassano in modi che sembrano improvvisi ma non lo erano affatto.

Le competenze che servono davvero

Secondo PMI, il 75% dei project manager afferma che le soft skill sono più importanti delle competenze tecniche per ottenere risultati. E la ricerca di Standish Group mostra che il 59% dei fallimenti di progetto è dovuto a lacune nelle soft skill.

Tradotto: un PM eccellente deve saper leggere le dinamiche di gruppo, gestire i conflitti prima che esplodano, costruire fiducia con persone molto diverse tra loro, comunicare brutte notizie senza distruggere i rapporti, e motivare un team anche quando le condizioni esterne sono avverse.

Non sono skill minori. Sono tra le più difficili da acquisire e da mantenere.

❤️‍🩹​ Cosa i PM spesso sbagliano con i developer

Parliamo anche dell'altro lato, perché la critica deve valere per tutti.

Interrompere il flusso senza capirne il costo. Per un developer, entrare in stato di flusso profondo richiede tempo, spesso 20-30 minuti di concentrazione non interrotta. Una riunione improvvisata, uno Slack urgente per un aggiornamento di stato, una call "veloce" di 15 minuti nel mezzo del pomeriggio: possono costare ore di produttività. Un PM che non capisce questo finisce per generare molto più rallentamento di quanto ne eviti.

Chiedere stime senza dare contesto. "Quanto ci vuole per fare questa feature?" è una domanda quasi impossibile da rispondere senza sapere lo stato del codice attuale, le dipendenze, i vincoli architetturali, il livello di test richiesto. Quando un PM preme per una stima rapida senza fornire contesto, ottiene un numero inventato e poi si lamenta che la stima era sbagliata.

Usare la metodologia come fine invece che come mezzo. Agile, Scrum, Kanban, SAFe: sono strumenti, non religioni. Un PM che applica la cerimonia del framework indipendentemente dal contesto, che insiste su daily di 30 minuti quando il team è di due persone, che aggiunge burocrazia invece di rimuoverla, sta lavorando contro il team, non con il team.

Non imparare la lingua tecnica di base. Non serve saper programmare. Ma capire cosa significa "debito tecnico", perché un refactoring ha valore anche se non produce feature visibili, cosa vuol dire "questa parte del sistema è fragile", queste cose fanno la differenza tra un PM che facilita e uno che ostacola.

💔​​ Cosa i developer spesso sbagliano con i PM

Ora l'altra metà della storia.

Confondere "non capisce il codice" con "non capisce niente". Il PM conosce cose che il developer spesso non vede: le aspettative reali del cliente, le pressioni politiche interne, i vincoli di budget, le dinamiche tra stakeholder. Ignorare questa conoscenza perché "non è tecnica" è un errore costoso.

Non comunicare i problemi finché non sono crisi. Il developer che passa tre giorni su un problema senza dirlo al PM, poi si presenta in sprint review con "non ho finito", sta rendendo impossibile la gestione del progetto. I problemi emergenti comunicati presto si gestiscono. Quelli comunicati tardi diventano emergenze.

Snobbare la documentazione e la comunicazione come "non lavoro". Scrivere documentazione, partecipare attivamente alle cerimonie, dare aggiornamenti chiari sullo stato del lavoro, non sono overhead. Sono parte del contratto implicito di lavorare in un team. Un codice perfetto che nessuno capisce come usare, manutenere o evolvere ha un valore molto inferiore al suo potenziale.

Stimare male per proteggere se stessi. Stime eccessivamente conservative per avere margine, o eccessivamente ottimiste per fare bella figura, creano lo stesso problema: un PM che non può pianificare in modo affidabile. La stima onesta, "non lo so ancora, ho bisogno di 4 ore per analizzare", è sempre meglio di un numero inventato.

❤️​ Come lavorare meglio insieme: pratiche concrete

Abbastanza diagnosi. Vediamo cosa funziona davvero.

Per i PM verso i developer

Proteggi il focus, non aggiungerci rumore. Raggruppa le comunicazioni non urgenti. Definisci orari in cui il team è raggiungibile per aggiornamenti e rispetta le finestre di lavoro profondo. Usa strumenti asincroni per tutto ciò che non richiede risposta immediata.

Impara il minimo tecnico indispensabile. Non devi saper programmare. Devi capire cosa significa quando il team dice "questo ha debito tecnico serio" o "questa feature richiede una modifica all'architettura". Chiedi, studia, costruisci un vocabolario minimo condiviso.

Trasforma le richieste del cliente prima di portarle al team. Il tuo valore aggiunto non è trasmettere le richieste, è tradurle. Porta al team problemi da risolvere, non soluzioni già definite dal cliente. "Il cliente vuole che gli utenti possano fare X più velocemente" è molto più utile di "il cliente vuole che aggiungiamo questo bottone qui".

Rendi visibile il tuo lavoro di protezione. Quando eviti che una richiesta impossibile arrivi al team, dillo. Non per vantarti, ma per costruire fiducia reciproca. Il team deve capire che il PM non è un imbuto di pressione, ma un filtro.

Per i developer verso i PM

Comunica presto, comunica spesso. Se stai incontrando un problema, dillo il giorno che lo scopri, non il giorno della demo. "Ho trovato una complessità che potrebbe spostare la stima di 2 giorni" è un'informazione gestibile. La stessa informazione comunicata il giorno prima della deadline non lo è più.

Traduci il tecnico in impatto di business. "Dobbiamo refactorare il modulo di autenticazione" non comunica niente al PM. "Il modulo di autenticazione attuale ci renderà impossibile aggiungere il login social nei prossimi sprint, e ci espone a problemi di sicurezza" comunica tutto. La tua expertise tecnica ha valore quando riesci a renderla comprensibile a chi deve prendere decisioni.

Partecipa alle cerimonie come protagonista, non come spettatore. Lo sprint planning non è una riunione dove il PM assegna lavoro. È il momento in cui il team negozia cosa è fattibile. Se non porti la tua voce tecnica in quella conversazione, non lamentarti delle stime che escono.

Tratta il PM come un alleato informativo. Ha accesso a contesto che tu non hai. Sa cose sul cliente, sulle priorità aziendali, sui vincoli che non ti vengono comunicati direttamente. Chiedere "perché è prioritaria questa feature?" non è essere difficili, è essere professionali.

👁️​ La verità scomoda per entrambi

I knowledge worker passano il 60% del loro tempo in "work about work": inseguire aggiornamenti di stato, riunioni non necessarie, switching continuo tra strumenti. Questo numero non è colpa dei PM né dei dev. È colpa di come i team sono strutturati e comunicano.

Il conflitto tra developer e Project Manager è spesso il sintomo di un problema di sistema, non di un problema di persone. Team senza processi chiari, organizzazioni che cambiano priorità ogni settimana, clienti con aspettative mal gestite fin dall'inizio, cultura aziendale che premia l'urgenza invece della qualità, tutto questo genera attrito, e quell'attrito si scarica sul rapporto tra le figure più visibili del conflitto.

Non si risolve "lavorando meglio insieme" come slogan. Si risolve costruendo contesti in cui lavorare bene insieme è la cosa più facile da fare.

🫂​ Conclusione: alleati per scelta, non per obbligo

Un developer senza un PM efficace passa il tempo a gestire richieste caotiche, cambiamenti improvvisi, pressioni dirette dal cliente, riunioni senza struttura. Perde focus, perde produttività, perde motivazione.

Un PM senza developer che comunicano in modo affidabile non può pianificare, non può gestire le aspettative del cliente, non può proteggere il team. Lavora nel buio.

Hanno bisogno l'uno dell'altro, non per cortesia professionale, ma perché i problemi che ciascuno risolve sono reali e necessari. Il progetto complesso, con più stakeholder, scadenze, vincoli e incertezza, non si gestisce da soli, né dal lato tecnico né dal lato organizzativo.

La guerra infinita tra dev e PM non è inevitabile. È il risultato di stereotipi non interrogati, comunicazione insufficiente, e aspettative non esplicitate.

Smettila di difendere il tuo territorio. Inizia a costruire il progetto.

Sei un developer o un Project Manager? Qual è la cosa che vorresti che l'altra figura capisse davvero del tuo lavoro? Scrivicelo nel nostro server Discord.