Quanto costa un Fractional CTO: come leggere un preventivo

Un preventivo per un Fractional CTO deve chiarire quale direzione tecnica viene affidata e con quale presenza. Una revisione periodica dell’architettura è diversa dalla responsabilità di coordinare fornitori, gestire priorità e preparare un rilascio critico. Confrontare soltanto il canone mensile può nascondere questa differenza.

Non esiste qui una media di mercato documentata da usare come tariffario. Per stimare il tuo incarico servono informazioni sul software esistente, sulle persone coinvolte e sulle decisioni da prendere. Diffida di un importo che non esplicita le ipotesi: potresti confrontare una consulenza occasionale con una disponibilità continuativa.

Chiedi a tutti i candidati di rispondere allo stesso brief. Indica sistemi coinvolti, interlocutori e decisioni previste nel periodo. Se è in corso una migrazione ERP, specifica chi esegue il lavoro, chi autorizza il passaggio e chi garantisce supporto operativo.

La reperibilità va distinta dalla presenza pianificata. Un incontro settimanale non comprende automaticamente assistenza serale o gestione degli incidenti. Allo stesso modo, dirigere lo sviluppo non equivale a includere nel compenso tutte le ore degli sviluppatori.

Un incarico iniziale può comprendere inventario dei sistemi, accessi, fornitori e decisioni aperte. Le consegne devono essere utilizzabili: una mappa delle dipendenze, un elenco dei rischi verificati e priorità con motivazione. Non basta una presentazione che ripeta ciò che il team sapeva già. Chiedi quali informazioni verranno controllate direttamente e quali resteranno ipotesi da approfondire.

Se il problema urgente è un rilascio, il perimetro può includere criteri di accettazione, responsabilità dei fornitori e piano di ritorno. Se riguarda costi poco chiari, può partire da licenze, ambienti e lavoro di manutenzione. Sono attività diverse: il preventivo dovrebbe mostrare quale viene prima e cosa viene rimandato, invece di promettere una revisione completa senza definirne il confine.

Indica chi rende disponibili documenti e accessi. Un professionista esterno non può verificare un collegamento se nessuno conosce il proprietario dell’account o il contratto del fornitore. Prevedere questa raccolta nel piano evita di consumare il primo mese in attesa di informazioni, per poi attribuire il ritardo soltanto a chi ha ricevuto l’incarico.

Quando un fornitore dichiara conclusa una funzionalità, qualcuno deve verificare che soddisfi il requisito concordato. Chiedi al CTO come organizzerà questa verifica e come renderà leggibili i problemi alla direzione. Il controllo non consiste nel riscrivere ogni riga di codice, ma nel collegare requisito, prova, esito e responsabilità di correzione.

La sicurezza va inclusa nel confronto con chi realizza il software. Il Secure Software Development Framework del NIST propone pratiche per lo sviluppo sicuro e può aiutare a formulare domande ai fornitori. Non trasforma un incarico CTO in una certificazione: le verifiche necessarie dipendono dai sistemi e dai rischi dell’azienda.

Nel brief inserisci almeno titolarità degli ambienti, gestione degli accessi e modalità di consegna della documentazione. Per un componente importante, chiedi una prova di ripristino o di gestione dell’errore coerente con il compito. Se il contratto esclude queste attività, rendi visibile chi dovrà svolgerle e con quale costo, senza lasciarle implicitamente al team interno.

Una giornata a settimana viene usata male se inizia sempre dalla ricostruzione degli ultimi messaggi. Stabilisci un registro breve: decisione richiesta, alternative, informazioni mancanti e data entro cui serve una risposta. I referenti possono preparare il materiale prima dell’incontro, lasciando il tempo condiviso alle scelte che richiedono davvero un confronto.

Definisci quali decisioni possono essere prese fra un incontro e l’altro e quali devono aspettare un’approvazione. Un fornitore non dovrebbe interpretare il silenzio come autorizzazione a cambiare il progetto. Anche la gestione delle urgenze deve avere un canale e un confine: la disponibilità concordata va distinta dalla reperibilità continua.

Alla revisione del compenso, confronta responsabilità assunte e consegne effettive, non soltanto il numero di riunioni. Se l’azienda ha recuperato visibilità sui sistemi e il team può mantenere alcune decisioni, il perimetro può cambiare. Se emergono dipendenze nuove, va rinegoziato esplicitamente. Questo rende il costo leggibile senza inventare una tariffa standard per situazioni molto diverse.

Accanto al compenso considera sviluppo esterno, strumenti, eventuale bonifica dei dati e tempo delle persone interne. Separali nel conto: attribuire al CTO un budget che include licenze e realizzazione, confrontandolo con un incarico di sola direzione, porta a una scelta falsata.

Può essere ragionevole iniziare con una ricognizione circoscritta se lo stato del software è sconosciuto. L’esito dovrebbe essere una mappa verificata e una decisione sul passo successivo, non un impegno automatico a costruire. La guida comprare, integrare o costruire aiuta a formulare questa decisione.

La documentazione deve essere accessibile all’azienda. Account e repository devono avere un proprietario chiaro, i fornitori un referente e le decisioni una motivazione ricostruibile. Se dopo mesi tutto dipende ancora dalle spiegazioni a voce di una persona, manca una parte della consegna.

Definisci un momento di revisione dell’incarico: cosa è stato deciso, cosa è stato eseguito e quali responsabilità possono rientrare nel team. Il servizio Fractional CTO descrive questo tipo di lavoro. Se il bisogno riguarda soprattutto applicazioni e adozione dell’AI, confrontalo con il ruolo di Fractional Head of AI prima di scegliere il titolo.