Quando c'è bisogno di un punto di vista esterno.
C'è un team di sviluppo interno ma non i risultati attesi. Oppure una società o un consulente esterno sviluppa il servizio, ma senza che sia possibile valutare se quello che arriva è solido, mantenibile, espandibile, o soltanto qualcosa che sembra funzionare finché non serve davvero.
In entrambi i casi, l'unica fonte di informazione disponibile è la stessa che andrebbe valutata in modo indipendente.
Ci sono strumenti che possono raccogliere dati e indicatori molto velocemente ma è con l'esperienza di trent'anni che si trasformano in una diagnosi che ha senso per chi gestisce il business.
L'unica fonte di informazione disponibile è chi dovrebbe essere valutato in modo indipendente.
Ogni volta che c'è un problema, una feature in ritardo, un bug critico o una scadenza saltata, la spiegazione arriva da chi ha causato il problema.
I meeting settimanali producono aggiornamenti che non consentono di capire se la direzione sia quella giusta. Oppure ci si trova a dover prendere una decisione importante, assumere un CTO, scalare il team o ingaggiare un fornitore, senza dati indipendenti su cui appoggiarsi.
Non è un problema di fiducia. Servono conoscenze tecnologiche e relazionali insieme, perché i problemi tecnici e quelli organizzativi hanno spesso gli stessi sintomi, ma si risolvono in modi completamente diversi.
Cosa trovi nel referto.
Non solo numeri ma una lettura organizzativa dei sintomi tecnici. Questo è un estratto fittizio, ma è il tipo di analisi che riceveresti.
Startup SaaS B2B · team 2 sviluppatori
Bus factor critico, maturità operativa: 28/100
Tutta la conoscenza critica del sistema risiede in una sola persona. Il tech lead copre da solo sviluppo frontend, backend e operazioni DevOps, una competenza trasversale che è un asset, ma che diventa un rischio strutturale nel momento in cui quella persona si ammala, va in ferie o cambia progetto.
Il segnale che l'ha reso visibile nell'analisi: il lavoro viene svolto spesso anche in orari notturni. Non è un problema di impegno ma il sintomo di un carico che ha già superato la soglia sostenibile.
Il processo non esiste, e i dati lo confermano
Non esiste un workflow che copra l'intero ciclo di vita dalla raccolta della richiesta al rilascio in produzione. Le specifiche con cui arrivano le richieste di sviluppo sono spesso insufficienti: il livello di dettaglio inadeguato genera rilavorazioni e incomprensioni che si accumulano sprint dopo sprint senza che nessuno le contabilizzi.
Non vengono rilevate né metriche pre-sviluppo né post-sviluppo. In assenza di questi dati, qualsiasi conversazione sulle priorità diventa soggettiva e ogni stima è una negoziazione, non una previsione.
Prima una call. Poi, se ha senso, iniziamo.
Call conoscitiva
Una prima conversazione per conoscerci e capire il contesto, per entrambi. Si illustra la situazione e si chiarisce cosa è possibile leggere e cosa no. Nessun accesso a niente, nessun impegno. Se ha senso andare avanti, si organizza il setup tecnico.
Accesso in lettura
NDA, accessi alla codebase, ad ambienti demo e, se disponibile, al project management tool in uso (Jira, Linear, Notion). Nessun accesso in scrittura, nessun rischio.
Analisi
I miei strumenti analizzano tutto il materiale messo a disposizione: la storia completa della codebase nel tempo, chi tocca cosa e con quale frequenza, dove ci sono test e ci dovrebbero essere, i tempi di chiusura delle PR, eventuali problematiche di sicurezza e scalabilità. Non è solo analisi del codice ma anche dei pattern organizzativi e delle abitudini di processo che il repository registra senza saperlo. Ci ragiono sopra con trent'anni di esperienza con le persone, non solo con i sistemi.
Intervista tecnica
Se emergono pattern che richiedono contesto, posso condurre una breve call con il tech lead o con il fornitore esterno. Non per confrontarmi sulla diagnosi, ma per non lasciare buchi su ciò che i dati da soli non spiegano. Come gestire questa conversazione viene concordato insieme prima.
Il referto + call
Un documento scritto con la diagnosi organizzativa che emerge dai sintomi tecnici. Spiegato in linguaggio comprensibile, seguito da una call di 45 minuti.
I dati restano riservati.
Prima di vedere una riga di codice, firmiamo un NDA. Non è burocrazia, è il modo in cui stabilisco che la riservatezza è un prerequisito, non un'opzione.
NDA prima di qualsiasi accesso
Firmiamo un accordo di riservatezza prima di condividere repository, credenziali, o qualsiasi altra informazione. Il documento è standard, leggibile, senza clausole opache.
Analisi in ambiente privato e controllato
Nessun codice o documento viene caricato su servizi AI di terze parti senza accordo esplicito. L'accesso è in sola lettura e viene revocato al termine dell'analisi.
LLM locali su richiesta
Se si preferisce che il codice non venga processato da Claude, GPT, o qualsiasi servizio equivalente, l'analisi viene condotta con modelli AI installati localmente su server virtuale privato. Nessun dato trasmesso a AI provider.
Una nota onesta: probabilmente chi sviluppa per l'azienda sta già usando Copilot, Claude o qualche tool AI sul codice, spesso senza policy aziendale esplicita. Se è importante avere certezza su come e dove viene analizzato il codice, viene garantito per iscritto prima di iniziare.
Un referto, non una dashboard.
La differenza tra uno strumento di monitoring e un Audit Tech Indipendente è che lo strumento mostra i numeri mentre il referto dice cosa significano per l'organizzazione.
Executive Scorecard
Cinque indicatori su scala 0–100: Status Asset Tech, Scalabilità, Sicurezza e Resilienza, Utilizzo AI, Maturità Operativa, calcolati su dati reali e pesati per rilevanza strategica. Più un'analisi dell'allineamento del management: dove la visione è coesa, dove emergono divergenze che limitano le decisioni tech.
Analisi di dettaglio per indicatore
Per ogni area: punti positivi, elementi da monitorare, criticità. Non bullet generici, ognuno è collegato a evidenze specifiche emerse dall'analisi del codice, dei processi, e delle conversazioni con il team. I problemi tecnici e quelli organizzativi vengono separati: hanno sintomi simili ma si risolvono in modi completamente diversi.
Dimensione umana e organizzativa
Carico operativo reale, bus factor, sostenibilità del team, qualità dei processi dalla richiesta al rilascio. Se emerge la necessità di un nuovo profilo tecnico, il referto include un'ipotesi di hiring: ruolo, livello, fascia RAL, priorità rispetto alla situazione attuale.
Piano 100 giorni in 3 fasi
Stabilizzazione, Consolidamento, Scalabilità. Roadmap con obiettivi verificabili a fine di ogni fase, bilanciata tra urgenze operative e costruzione strutturale.
Appendice tecnica
Metriche di complessità ciclomatica, centralità architetturale, weighted complexity per file. I file più critici con il problema specifico e l'azione raccomandata. Non è pensata per il business, è la documentazione per il tech lead, se decide di condividerla con il team.
Call di 45 minuti
Leggiamo il referto insieme. Non è una presentazione, è una conversazione in cui la diagnosi esce dal dominio tecnico.
Il tech non è solo un centro di costo.
Assumere la persona sbagliata per guidare il team tech, tenere un fornitore che non consegna valore reale, scalare su un'architettura che non regge: ognuna di queste decisioni, presa senza dati indipendenti, costa molto più del previsto, in ritardi, in turnover, in opportunità mancate.
L'Audit Tech Indipendente serve esattamente a questo: una lettura chiara prima di decidere e un piano operativo e strutturato.
Consegna entro la fine della settimana successiva dall'acquisizione di materiale e svolgimento interviste.
La call conoscitiva è gratuita. Si paga solo se si decide di procedere.
Prenota una call conoscitivaMeglio dirlo prima.
Non è un servizio adatto a tutte le situazioni. Meglio verificare prima di procedere.
Non è adatto se
- Esiste già un rapporto di fiducia e totale trasparenza con il CTO o Head of Engineering
- Il prodotto è ancora in fase di prototipo (la codebase non ha abbastanza segnale)
- Si cerca qualcuno che riscriva il codice o gestisca il team al posto del cliente
- Ci sono più team o prodotti distinti da analizzare, in quel caso è meglio parlarne nella call
- Si cerca conferma di quello che si pensa già, non un'analisi indipendente
È adatto se
- C'è un team tecnico ma non è possibile capire cosa succede davvero dentro
- Le scadenze slittano e le spiegazioni non convincono fino in fondo
- È imminente una decisione importante, assumere un CTO, scalare il team o cambiare architettura, e servono dati reali
- C'è un fornitore esterno o un'agenzia che produce codice, ma non esiste un modo indipendente per valutare quello che viene consegnato
- Il team sembra bravo ma qualcosa nel processo non funziona
La tecnologia cambia, leggere le organizzazioni no.
Sono Antonello Calamea. Trent'anni nel settore ICT, come tecnico, come manager, come CTO, e ora come Fractional CTO per startup e PMI digitali.
Sono anche Coach certificato EMCC EAI Practitioner, il che in questo contesto significa che so distinguere un problema di codice da un problema di comportamenti organizzativi. E so lavorare su entrambi.
La combinazione non è comune. La maggior parte dei consulenti tecnici non ha gli strumenti per leggere le dinamiche umane e la maggior parte dei coach non sa cosa significa stare in una war room durante un'emergenza in produzione. Io ho fatto entrambe le cose per molti anni.
La prima cosa è capire se ha senso farlo insieme.
Call conoscitiva gratuita · 30 minuti · Prima di condividere accesso a qualsiasi cosa.
L'Audit Tech Indipendente è €2.500, si paga solo se si decide di procedere. In caso di continuità come Fractional CTO, €1.000 vengono assorbiti nei primi due mesi.