Come scegliere un consulente IT: 10 domande da fare prima di firmare un contratto

Ogni anno subentro su almeno due o tre progetti PHP lasciati in stato deplorevole da consulenti o agenzie che non avevano le competenze dichiarate. Non parlo di codice "non perfetto" - parlo di applicazioni senza version control deployate via FTP, database con credenziali root accessibili dalla rete pubblica, server con PHP 5.6 nel 2025, e contratti di manutenzione che prevedevano 20 ore al mese di lavoro ma ne producevano 2, con le restanti 18 fatturate ma non erogate. Non è sempre malafede - in molti casi è un problema di asimmetria informativa: il titolare della PMI non ha le competenze tecniche per valutare se il consulente sa davvero fare ciò che dichiara, e il consulente non ha gli incentivi per evidenziare le proprie lacune. Il risultato è un rapporto che produce valore negativo per anni prima che qualcuno se ne accorga.

In vent'anni di lavoro nel settore IT per PMI italiane, ho sviluppato una lista di dieci domande che un titolare o un responsabile IT dovrebbe fare a qualsiasi consulente prima di firmare un contratto. Non sono domande tecniche - sono domande di processo che rivelano la maturità professionale del consulente, la sua capacità di gestire un progetto in modo strutturato, e i segnali di allarme che indicano problemi futuri. Questa lista nasce dai casi reali di subentro che ho gestito, dove in ogni caso il titolare mi ha detto: "Se avessi saputo fare queste domande tre anni fa, avrei evitato tutto questo."

Le prime tre domande: competenze verificabili

Domanda 1: "Puoi mostrarmi due o tre progetti simili al mio che hai completato negli ultimi 3 anni?" Un consulente competente ha un portfolio di lavori recenti che può descrivere in dettaglio - non screenshot generici, ma una descrizione del problema, della soluzione implementata, delle tecnologie usate, e dei risultati misurabili. Se la risposta è vaga ("ho lavorato con molti clienti simili, ma non posso fare nomi per ragioni di riservatezza") senza fornire nessun dettaglio tecnico verificabile, è un red flag. La riservatezza è legittima, ma un consulente esperto sa descrivere un progetto in modo anonimizzato con sufficiente dettaglio tecnico per dimostrare competenza.

Domanda 2: "Quale version control usi e come gestisci i deploy?" Questa domanda da sola elimina il 40% dei consulenti inadeguati. Se la risposta è "mando i file via FTP" o "non uso version control perché il progetto è piccolo" o "uso Git ma non faccio branch", il consulente non ha le basi minime per gestire un progetto software in modo professionale. Nel 2025, Git con branching strategy e deploy automatizzato non è un lusso - è il minimo sindacale. Un consulente che deploya via FTP non può garantire rollback in caso di problemi, non può tracciare chi ha modificato cosa e quando, e non può collaborare con altri sviluppatori senza sovrascrivere il lavoro reciproco.

Domanda 3: "Come gestisci i backup del mio sistema e come verifichi che funzionino?" Se la risposta è "il provider fa i backup" o "ho un cronjob automatico" senza dettagli su retention, verifica periodica e test di ripristino, i backup probabilmente non funzionano. Ho ereditato server dove il "backup automatico" era un cronjob rotto da 8 mesi che nessuno controllava - e il titolare lo ha scoperto il giorno in cui il database si è corrotto e il backup non c'era. La risposta corretta include: frequenza (giornaliero minimo), destinazione (remota, non sullo stesso server), retention (almeno 30 giorni), test di ripristino (almeno trimestrale), e monitoring dello stato del backup (alert se il job fallisce). Ho descritto il framework completo nel mio articolo sul piano di disaster recovery per PMI.

Nel mio profilo professionale trovi il dettaglio dell'esperienza che porto in queste valutazioni - e le risposte che do io stesso a queste domande quando un potenziale cliente me le fa.

Le domande 4-6: processo e comunicazione

Domanda 4: "Cosa succede se sparisci?" È la domanda più scomoda e la più importante. Se il consulente viene investito da un autobus domani, qualcun altro può prendere il suo posto? Le credenziali del server sono in un password manager condiviso o nella testa del consulente? L'account del provider è intestato al cliente o al consulente? Il codice è in un repository accessibile al cliente o solo sul computer del consulente? Ho gestito almeno sei subentri dove il consulente precedente era sparito (malattia, trasferimento, conflitto economico) e il cliente non aveva accesso a nulla - come ho descritto nel mio articolo sui server dedicati abbandonati. La risposta corretta include: l'account del provider è intestato al cliente, le credenziali sono in un password manager condiviso, il codice è su un repository a cui il cliente ha accesso admin, e una documentazione operativa minima esiste e viene aggiornata.

Domanda 5: "Come mi tieni aggiornato sullo stato del progetto?" Un consulente che non comunica proattivamente è un consulente che nasconde problemi. La comunicazione minima accettabile è: un report settimanale con ore lavorate, attività completate e prossimi passi; un canale di comunicazione diretta (non solo email, che ha latenza di ore) per le urgenze; e una modalità di escalation quando qualcosa non va come previsto. Se il consulente dice "ti chiamo quando ho finito", stai per vivere settimane di silenzio intervallate da sorprese sgradite.

Domanda 6: "Puoi darmi il contatto di un cliente attuale - non un ex cliente, un cliente attuale?" Un ex cliente può essere stato soddisfatto ma non può confermare che il consulente sia ancora attivo, aggiornato e affidabile. Un cliente attuale può dirti come è lavorare con il consulente adesso - se risponde al telefono, se rispetta le scadenze, se i deploy sono stabili, se la fatturazione è chiara. Se il consulente non ha un singolo cliente disposto a confermare la collaborazione in corso, è un segnale che le collaborazioni finiscono male.

Le domande 7-10: contratto e tutele

Domanda 7: "Il codice che scrivi per me è di mia proprietà?" Sembra ovvio, ma molti contratti di consulenza IT non specificano la proprietà intellettuale del codice prodotto - e in assenza di clausola esplicita, il diritto d'autore resta del programmatore. Il contratto deve dichiarare esplicitamente che il codice sorgente prodotto nell'ambito dell'incarico è di proprietà del cliente. Senza questa clausola, il consulente può legalmente impedire al cliente di usare il codice dopo la fine del rapporto.

Domanda 8: "Quali sono le tue tariffe e come fatturi?" La trasparenza sulla fatturazione è un indicatore di professionalità. Un consulente serio fattura a consuntivo con report dettagliato delle ore lavorate, o a corpo per progetti con scope definito e milestone. Un consulente che fattura "a pacchetto mensile" senza report delle ore e senza definizione delle attività incluse sta vendendo un contratto opaco che permette di fatturare senza dover dimostrare il lavoro svolto. Il rapporto dettagliato delle ore non è burocrazia - è la base per verificare che il valore ricevuto corrisponda al prezzo pagato.

Domanda 9: "Cosa succede se non sono soddisfatto del risultato?" Un consulente che non ha una policy per gestire l'insoddisfazione del cliente non ha esperienza con progetti reali - perché nei progetti reali le aspettative disallineate e le incomprensioni sono la norma, non l'eccezione. La risposta corretta include: milestone con validazione intermedia (il cliente approva ogni fase prima di procedere alla successiva), periodo di garanzia post-consegna (tipicamente 30-60 giorni durante i quali i bug vengono corretti senza costi aggiuntivi), e clausola di uscita che permetta al cliente di interrompere il rapporto pagando solo le attività completate e approvate.

Domanda 10: "Hai un'assicurazione professionale?" Per un consulente IT che gestisce sistemi critici per il business - server di produzione, database con dati dei clienti, applicazioni di fatturazione elettronica - l'assicurazione di responsabilità civile professionale non è un lusso: è la garanzia che, in caso di errore grave (perdita di dati, downtime prolungato, violazione GDPR causata da una misconfiguration), il danno sia coperto da una polizza e non ricada interamente sul consulente (che potrebbe non avere le risorse per risarcire) o sul cliente (che subirebbe il danno senza possibilità di rimedio). Non tutti i consulenti hanno l'assicurazione - e non è un requisito legale - ma la sua presenza è un indicatore di maturità professionale e di consapevolezza del rischio.

I red flag che ho visto nei subentri: cosa succede quando le domande non vengono fatte

I casi di subentro più costosi che ho gestito avevano tutti gli stessi segnali premonitori - segnali che il titolare avrebbe potuto riconoscere se avesse fatto le domande giuste all'inizio del rapporto. Il primo red flag è il consulente che rifiuta di dare accesso al repository di codice al cliente durante il rapporto. La giustificazione tipica è "il codice è in fase di sviluppo, lo consegno alla fine." In realtà, il consulente sta costruendo un lock-in: se il cliente non ha accesso al codice in corso d'opera, non può affidarlo a un altro consulente in caso di conflitto o di insoddisfazione. Ho gestito un subentro dove il cliente aveva pagato 18 mesi di sviluppo (circa 70.000 euro) senza mai vedere una riga di codice - e quando il rapporto si è interrotto per conflitto economico, il consulente ha trattenuto il repository come merce di scambio per ottenere il pagamento dell'ultima fattura contestata. Con il repository su un account GitHub intestato al cliente fin dal primo giorno, questa situazione non sarebbe stata possibile.

Il secondo red flag è il consulente che non ha mai "tempo" per la documentazione. "Documenteremo alla fine del progetto" è una promessa che non viene mai mantenuta, perché alla fine del progetto il consulente è già sul progetto successivo e la documentazione è l'ultima priorità. Il risultato è un sistema in produzione che funziona ma che nessuno può mantenere senza il consulente che l'ha costruito - un lock-in tecnico che costa al cliente migliaia di euro l'anno in manutenzione che solo quel consulente può fare, a tariffe che aumentano nel tempo perché il cliente non ha alternative.

Il terzo red flag è l'assenza di test automatici. Un consulente che consegna codice senza test sta consegnando codice che non può essere modificato in sicurezza da nessuno - incluso il consulente stesso. Ogni modifica è un salto nel vuoto perché non c'è modo di verificare che la modifica non abbia rotto qualcosa di preesistente. Ho ereditato una codebase di 60.000 righe senza un singolo test dove il team precedente deploiava in produzione il venerdì pomeriggio e "controllava manualmente il lunedì mattina" - con il risultato prevedibile di weekend passati a gestire emergenze che un test di regressione avrebbe prevenuto. Ho documentato le strategie per l'introduzione di test su codebase legacy nel mio articolo sui test automatici per codice PHP senza riscrittura - un articolo che il titolare può condividere con il consulente come requisito minimo di qualità.

Il quarto red flag è il preventivo che non specifica cosa è incluso e cosa è escluso. Un preventivo che dice "Sviluppo gestionale ordini: 30.000 euro" senza un document di specifica che definisca le funzionalità, le esclusioni, i tempi e i criteri di accettazione è un contratto che finirà in un conflitto - perché il titolare e il consulente avranno aspettative diverse su cosa significhi "gestionale ordini completato", e la differenza emergerà quando sarà troppo tardi per negoziare.

Queste dieci domande non garantiscono di trovare il consulente perfetto - nessuna lista può farlo. Ma eliminano il 70-80% dei consulenti inadeguati prima che il danno venga fatto, e stabiliscono le basi per un rapporto professionale trasparente dove le aspettative sono allineate e le tutele sono reciproche. Se stai valutando un consulente IT per la tua PMI e vuoi un secondo parere tecnico sulla proposta che hai ricevuto - o se sei nel mezzo di un rapporto che non sta funzionando e vuoi capire quali sono le tue opzioni - contattami per una valutazione indipendente: in una sessione di un'ora analizziamo la proposta, identifichiamo i red flag e le lacune contrattuali, e definiamo insieme i criteri di scelta basati sulla tua situazione specifica.