Pagina 1 di 3
La consulenza IT che offro non è rivendita di prodotti confezionati. È analisi del contesto, comprensione del business, una roadmap tecnica realistica e poi implementazione o coordinamento di chi implementa. Dal 2014 lavoro come consulente freelance con PMI italiane che cercano un interlocutore competente e indipendente, e questa categoria raccoglie quel modo di lavorare.
Il primo tema è l'indipendenza: un buon consulente non ha un prodotto da venderti, ha il tuo problema da risolvere. La differenza fra un professionista e uno smanettone, o fra chi ti propone sempre la stessa soluzione e chi parte dal tuo contesto, è tutta qui. Parte del mio lavoro è dirti anche quando un intervento non serve, e questo è esattamente ciò che un venditore non farà mai.
Il secondo tema è come si sceglie e si inquadra un consulente: le domande da fare prima di firmare, cosa deve contenere un contratto di manutenzione per proteggere l'azienda (a partire dalla proprietà del codice), come si evita di ritrovarsi in mano un progetto lasciato in stato deplorevole. So bene dove si nascondono i problemi, perché ogni anno subentro su progetti gestiti male da chi non aveva le competenze giuste.
Il terzo tema è il rapporto di lungo periodo: governance tecnologica, ROI, affiancamento al management non tecnico, la traduzione fra il linguaggio della tecnologia e quello del business. Una consulenza che vale è quella che ti fa prendere decisioni migliori, non quella che ti vende l'ennesimo strumento.
Se cerchi una visione tecnica indipendente, guarda la panoramica dei servizi o chiedi un preventivo gratuito.
Un buon consulente IT ti dice anche quando NON serve l'intervento. Chi vende sempre soluzioni probabilmente non sta facendo consulenza.
L'ingegnere che l'AI sostituisce non è quello che fa il lavoro che l'AI può fare. È quello che non ha mai costruito il giudizio per riconoscere quando l'AI sbaglia. Il riposizionamento da autore di codice a intent manager non è una concessione, è la skill tecnica che decide chi sopravvive a questa transizione di carriera. Continua a leggere
Sono passato da dipendente con stipendio fisso a consulente autonomo nel 2015. Nei primi due anni ho commesso tutti gli errori possibili: clienti senza contratto, pricing troppo basso, scope creep senza tutela. Vi racconto cosa avrei voluto sapere prima, con numeri reali su pricing, contratti e gestione del rischio. Continua a leggere
Subentro dopo un fornitore precedente. Il contratto firmato dall'azienda non menzionava la proprietà del codice sorgente, non prevedeva escrow, non definiva SLA. Quando il rapporto si è deteriorato, l'azienda ha scoperto di non avere diritti sul software che usava da tre anni. Vi dico cosa pretendere per iscritto. Continua a leggere
Ogni anno subentro su almeno due o tre progetti lasciati in stato deplorevole da consulenti che non avevano le competenze dichiarate. Non è malafede sistematica - è asimmetria informativa. Vi insegno le domande che avrebbero smascherato i problemi in anticipo, basandomi su casi reali. Continua a leggere
I cinque principi di sicurezza che qualunque manuale elenca al capitolo uno - defense in depth, least privilege, separation of duties, secure by design, KISS - sono facili da conoscere e difficili da applicare in una PMI italiana da 5 a 40 persone. Racconto come li spiego ai clienti, gli errori più comuni che vedo in audit, e il principio anti-sicurezza che uccide chi ci crede. Continua a leggere
Il Verizon DBIR 2025 conferma che il 60% delle violazioni coinvolge il fattore umano (errore, manipolazione, abuso di credenziali). KnowBe4 documenta che il 33.1% dei dipendenti clicca su email di phishing simulato prima del training, ma dopo 12 mesi di formazione continua il click rate scende al 4.1% - una riduzione dell'86%. NIS2 (Articolo 21, comma 2, lettera g) rende la formazione cybersecurity un obbligo normativo per tutte le entità essenziali e importanti. Continua a leggere
La National Cybersecurity Alliance stima che il 60% delle piccole imprese che subisce una perdita dati significativa chiude entro 6 mesi. Un Disaster Recovery Plan con RPO/RTO definiti dalla Business Impact Analysis (ISO 22301), backup conformi alla regola 3-2-1-1-0 e test periodici trasforma il recovery da speranza a procedura verificata - un requisito esplicito dell'Articolo 21 della Direttiva NIS2. Continua a leggere
Infrastructure as Code definisce l'infrastruttura in file versionabili invece che in procedure manuali. Il report Firefly State of IaC 2025 mostra che l'89% delle organizzazioni ha adottato IaC, ma solo il 6% ha codificato il 100% dell'infrastruttura. Per le PMI, Ansible (agentless, YAML) per la configurazione e Terraform (dichiarativo, multi-cloud) per il provisioning coprono i casi d'uso principali. Continua a leggere
Ignorare il refactoring del codice legacy limita crescita e sicurezza aziendale. Scopri perché questa attività è fondamentale per migliorare performance, ridurre rischi e garantire la competitività futura della tua azienda. Continua a leggere
Continuare a utilizzare PHP 5 è rischioso per sicurezza e performance aziendali. Scopri perché migrare subito a PHP 8 è una scelta strategica essenziale per proteggere il tuo business, migliorare le prestazioni e garantire compliance normativa. Continua a leggere
Una raccolta di tool professionali gratuiti, utili nel lavoro IT quotidiano:
Autovalutazione NIS2 per PMI, e l'intera raccolta di strumenti online.
