La due diligence tecnica non è una gara di qualità del codice, e i team che si preparano ad affrontarla di solito investono il proprio tempo nella cosa sbagliata. Nessuno che stia comprando un’azienda è lì per dare un voto alle vostre astrazioni. Chi acquista sta cercando di capire quanto costerà possedere questo sistema e quanto male possa andare dopo che il denaro ha cambiato mano.

Questo cambio di prospettiva conta, perché cambia che cosa conviene sistemare per primo. Del codice brutto che funziona, che il team comprende e che si può modificare in sicurezza è un rilievo minore. Del codice elegante che una sola persona capisce è un rilievo serio, ed è il secondo caso a muovere il prezzo.

La domanda dietro ogni domanda: se l’ingegnere fondatore se ne va la settimana dopo il closing, questo sistema continua a funzionare e continua a poter cambiare? Quasi ogni rilievo che abbassa un’offerta è una risposta precisa a questo. Conoscenza concentrata in poche teste, deployment non documentato, licenze che nessuno ha mai verificato, credenziali che esistono solo nella memoria di una persona.

Che cosa valuta davvero la due diligence tecnica

Quattro rischi, più o meno nell’ordine in cui incidono sulla valutazione.

Il rischio persona chiave. Se il sistema dipende da singole persone anziché da un processo documentato. È con costanza il rilievo più dannoso, perché è il più difficile da rimediare a posteriori e perché minaccia direttamente proprio la cosa che si sta comprando.

Il costo di continuare. Che cosa serve per tenere il sistema in funzione e farlo evolvere: spesa per l’infrastruttura, obblighi di licenza, dimensione del team necessario e quanta parte della roadmap verrà divorata dalla manutenzione anziché da lavoro nuovo.

La responsabilità. Licenze in conflitto con l’uso commerciale, dati personali trattati in modi che non reggerebbero a un reclamo, esposizione sul fronte della sicurezza e qualsiasi obbligo normativo che l’azienda in realtà non sta rispettando.

La capacità di cambiare. Se le nuove funzionalità possono essere rilasciate a un ritmo prevedibile, oppure se ogni modifica porta con sé il rischio di rompere qualcosa di completamente scollegato.

La qualità del codice conta solo attraverso il quarto punto, ed è la ragione per cui un revisore passerà meno tempo di quanto i fondatori si aspettino a leggere il codice, e molto più tempo a chiedere come avvengono i rilasci.

I rilievi che abbassano il prezzo

Solo una persona sa fare il deploy. Un processo di rilascio che vive nella testa di qualcuno, o sul suo portatile, viene trattato come un rischio operativo serio a prescindere da quanto funzioni bene oggi.

Nessuna copertura di test sui percorsi che contano. Non una percentuale di copertura, che i revisori ignorano quasi sempre, ma se il sistema si possa modificare con un minimo di fiducia. Una base di codice senza test intorno al percorso che genera ricavi si porta dietro nel prezzo una roadmap più lenta. La nostra guida alle strategie di test del software spiega che cosa si guadagna davvero il proprio posto.

Contaminazione da licenze. Codice copyleft dentro un prodotto proprietario è uno dei pochi rilievi capaci di fermare un’operazione anziché limitarsi a riprezzarla, e di norma uno scanner lo trova in pochi minuti.

Dati personali senza una base difendibile. Dati raccolti senza una base giuridica chiara, conservati a tempo indeterminato o custoditi in luoghi che l’azienda non è in grado di elencare. I meccanismi della conformità tecnica al GDPR sono esattamente quelli che un revisore verifica.

Dipendenze non documentate da persone o fornitori. Un’integrazione critica con un fornitore privo di contratto, oppure infrastruttura ospitata su un account personale: entrambe si leggono come rischio non governato.

Mancano le basi di sicurezza. Non il risultato di un penetration test, ma se i segreti stiano nel controllo di versione, se gli accessi vengano revocati quando le persone se ne vanno e se ci sia qualcosa di non aggiornato ed esposto su Internet.

Che cosa non interessa ai revisori

Vale la pena dirlo, perché il tempo di preparazione è poco e quasi sempre viene speso male.

Non interessa a nessuno quale framework abbiate scelto, purché sia possibile assumere persone che lo conoscano. Non interessa la moda architetturale: un monolite che rilascia non è un rilievo. Non interessano lo stile del codice, i nomi delle variabili o l’assenza di un pattern che qualcuno su Internet raccomanda.

Nessuno si aspetta nemmeno debito tecnico pari a zero. Ogni azienda ne ha, e la sua presenza è normale. Quello che conta è se il team sappia dove si trova e sappia descrivere quanto costa. Un team che produce un elenco chiaro dei propri problemi noti si legge come competente. Un team che sostiene di non averne si legge come inconsapevole, e a quel punto il revisore deve trovarli da solo, il che richiede più tempo e produce un rapporto peggiore.

Prepararsi senza riscrivere nulla

Quasi tutto ciò che aiuta si misura in giorni, non in mesi, e nulla di tutto questo tocca l’architettura.

Mettete per iscritto come si fa il deploy. Da una macchina vuota fino al sistema in esecuzione. Questo singolo documento affronta la categoria di rilievi più dannosa e si scrive in un pomeriggio.

Elencate le dipendenze e le loro licenze. Gli strumenti automatici producono l’elenco in fretta, e conoscere la risposta prima del revisore vale molto più di un risultato immacolato.

Togliete i segreti dal controllo di versione e censite chi ha accesso a che cosa. Poi revocate l’accesso a chiunque se ne sia andato.

Documentate ciò che sapete essere sbagliato. Un registro breve e onesto dei problemi noti con una stima di massima del costo di rimedio. Consegnarlo spontaneamente è una delle poche cose che migliorano in modo affidabile il tono di una revisione.

Assicuratevi che l’infrastruttura sia intestata all’azienda, non a un account personale, e che domini, certificati e repository siano tutti sotto controllo societario.

Che fine fanno i rilievi

Raramente fanno saltare un’operazione. Diventano condizioni.

I rilievi si risolvono di norma in uno di tre esiti: un aggiustamento di prezzo che riflette il costo del rimedio, una garanzia contrattuale o una manleva nell’accordo, oppure una condizione da soddisfare prima del closing. Solo la contaminazione da licenze e una grave esposizione non affrontata sulla protezione dei dati fermano con regolarità le operazioni in modo definitivo.

Il che significa che l’obiettivo pratico non è un sistema perfetto. È un sistema i cui problemi siano noti, delimitati e descrivibili, perché un problema quantificato viene prezzato mentre uno non quantificato viene dato per peggiore di quanto sia.

Mecanik conduce revisioni tecniche di questo tipo come parte del proprio lavoro di sviluppo software , di solito dal lato dell’acquirente. Lo schema è stabile: i sistemi che superano bene una revisione non sono quelli sofisticati, sono quelli in cui qualcuno ha messo le cose per iscritto.

Letture correlate: Software escrow: chi ne ha davvero bisogno , Sviluppo software fintech nel Regno Unito: FCA, rails e costi , Contratto a prezzo fisso o a consuntivo? e Sviluppo software su misura nel Regno Unito: la guida completa all’acquisto .

Domande frequenti

Che cos’è la due diligence tecnica? Una valutazione di quanto costerà possedere un sistema software e di quanto male possa andare dopo un’acquisizione o un investimento. Esamina il rischio persona chiave, il costo di continuare, la responsabilità legale e la capacità di continuare a far evolvere il sistema, anziché dare un voto alla qualità del codice fine a se stessa.

Quali rilievi abbassano di più il prezzo? La concentrazione della conoscenza in singole persone, in particolare un processo di deploy che solo una persona sa eseguire. Dopo di quello: nessuna copertura di test significativa sui percorsi che generano ricavi, contaminazione da codice copyleft dentro un prodotto proprietario, dati personali senza una base giuridica difendibile e segreti finiti nel controllo di versione.

Ai revisori interessa il mio debito tecnico? Se lo aspettano. Ogni azienda ne ha e la sua presenza non è un rilievo. Quello che conta è se il team sappia dove si trova e sappia descrivere quanto costa sistemarlo. Un registro chiaro dei problemi noti si legge come competenza; sostenere che non ce ne siano si legge come inconsapevolezza e peggiora la revisione.

Come mi preparo a una due diligence tecnica? Mettete per iscritto come si porta il sistema in esercizio da una macchina vuota, elencate le dipendenze e le loro licenze, togliete i segreti dal controllo di versione, verificate chi ha ancora accesso, accertatevi che infrastruttura e domini siano intestati all’azienda e non a persone fisiche, e preparate un registro onesto dei problemi noti con una stima di massima dei costi di rimedio.

Un rilievo tecnico può bloccare del tutto un’operazione? Raramente. La maggior parte dei rilievi diventa un aggiustamento di prezzo, una garanzia nell’accordo o una condizione da soddisfare prima del closing. Le eccezioni che fermano davvero le transazioni sono la contaminazione da licenza copyleft dentro un prodotto proprietario e una grave esposizione non affrontata sulla protezione dei dati.