Il restart ha risolto. Il problema è ancora lì.
Un incident che si chiude senza causa ricostruita non è un episodio isolato. Come leggere AWR, ASH e change log a freddo prima che arrivi il secondo guasto.

Leadership tecnica e project management IT: decisioni, team, metodo e consulenza, con storie vere e numeri da 30 anni di progetti in banche, telco e PA.
Questa sezione racconta la parte del mestiere che non sta nei piani di esecuzione: le decisioni, i team, il metodo. È lo spazio della leadership tecnica, dove persone, sistemi e scelte devono funzionare insieme.
Ho visto project manager far piangere sviluppatori senior in riunione. Ho visto team brillanti distrutti da PM che confondevano l’autorità con l’autoritarismo. Ho visto software consegnati “in tempo” che non funzionavano, e progetti da milioni di euro finiti nel nulla.
E ho visto l’esatto contrario: team piccoli, autonomi, rispettati — che costruivano sistemi solidi in una frazione del tempo e del budget.
La differenza non è mai stata la tecnologia. È sempre stata il metodo.
Dopo trent’anni in questo mestiere, una cosa l’ho capita: le persone non danno il meglio quando hanno paura. Danno il meglio quando hanno fiducia.
Fiducia nel team. Fiducia nel processo. Fiducia nel fatto che se sbagliano non verranno punite — verranno aiutate.
Il project manager che funziona non è quello che controlla, terrorizza e conta le ore. È quello che:
Il mio approccio è Scrum — ma Scrum fatto sul serio, non la liturgia dei post-it.
Lo Scrum che funziona si basa su un patto: trasparenza radicale, responsabilità condivisa e autonomia nel “come”. Il PM definisce il cosa e il perché. Il team decide il come. Perché chi scrive il codice sa meglio di chiunque altro come scriverlo.
E questo patto funziona ancora meglio nello smart working. La daily standup? 15 minuti in call. La sprint review? Screen sharing con il cliente, che vede il software — non le slide. La retrospettiva? Un’ora in cui il team dice la verità, perché non ha il PM a due metri che lo fissa.
Misuro poche cose, ma le misuro bene:
| Metrica | Cosa dice |
|---|---|
| Velocity | Quanto il team consegna per sprint |
| Lead time | Quanto passa da richiesta a rilascio |
| Bug escape rate | Quanti difetti sfuggono in produzione |
| Sprint goal success | % di obiettivi di sprint raggiunti |
| Team happiness | Come si sente il team — la metrica più importante |
L’ultima — team happiness — è quella che i PM tradizionali non misurano mai. Un team felice non è un team che si diverte. È un team che si sente rispettato, ascoltato e valorizzato. E un team così produce di più. Non perché lavora più ore. Perché lavora meglio.
Storie vere, numeri concreti e lezioni apprese. Niente teoria da manuale. Solo quello che ho visto funzionare — e quello che ho visto fallire.
Si parla di intelligenza artificiale applicata al workflow, di consulenza IT e dei suoi costi nascosti, di smart working come vantaggio competitivo. Ogni articolo nasce da un’esperienza reale — la mia.
Non servono rivoluzioni. Servono scelte precise, implementate con metodo.
E la capacità di dire “no” a chi ti vende complessità quando la soluzione è semplice.

Datadog e Dynatrace mostrano sintomi, non cause. Come spiegare al board perché l'observability moderna non basta senza un lettore competente.

Un incident che si chiude senza causa ricostruita non è un episodio isolato. Come leggere AWR, ASH e change log a freddo prima che arrivi il secondo guasto.

Aggiungere CPU, RAM o IOPS a un database lento spesso non risolve il problema. Come distinguere la causa reale dal sintomo prima di firmare il preventivo.

Come un bambino curioso, un programma in BASIC e una porta chiusa a chiave hanno tracciato la strada verso il mestiere di diagnosticare sistemi complessi.

La storia dei Three Amigos di UML e RUP: come Booch, Rumbaugh e Jacobson, da rivali, hanno unificato l'object-oriented modeling. E cosa ne resta oggi.

Project management: 5 regole osservate nei team che reggono sotto pressione. Psychological safety, bus factor, outcome vs output, knowledge transfer.

AI Manager: il ruolo che governa l'impatto dell'intelligenza artificiale su architetture, processi e persone. Riflessioni da 30 anni di IT.

Pagamenti a 60-90-120 giorni nella consulenza IT italiana: confronto con le regole europee. DSO, direttiva 2011/7/UE e strategie per freelance.

Pendolarismo Roma: bici elettrica Brompton vs auto. 18 minuti vs 50, 35€ di parcheggio risparmiati. La scelta di mobilità sostenibile, dati reali.

Smart working nella consulenza IT: analisi economica e strategica del lavoro da remoto. Numeri reali, KPI, presenteismo e produttività vs ufficio.

Project management con AI e GitHub: trasformare un progetto caotico in workflow misurabile con issue tracking, code review e intelligenza artificiale.
Standup meeting Scrum: perché solo i 15 minuti li fanno funzionare. Timeboxing, parking lot, regole pratiche del daily meeting che reggono nel tempo.

La tecnica Yes-And dal teatro di improvvisazione applicata alla gestione dei conflitti nei team IT. Caso reale di riunione che stava degenerando.

Project management caso reale: cliente assicurativo spende 4 milioni in consulenza IT e ottiene zero software funzionante. Lezioni di vendor lock-in.
Inizia a digitare per cercare…
Seleziona un risultato per vedere l'anteprima