Due diligence tehnic nu este un concurs de calitate a codului, iar echipele care se pregătesc pentru el își consumă de obicei timpul pe lucrul greșit. Nimeni care cumpără o companie nu vine să îți dea note pentru abstracțiuni. Cumpărătorul încearcă să afle cât va costa deținerea acestui sistem și cât de rău poate merge totul după ce banii schimbă proprietarul.

Reformularea contează, pentru că schimbă ce anume ar trebui să repari mai întâi. Un cod urât care funcționează, pe care echipa îl înțelege și pe care îl poți schimba în siguranță este o constatare minoră. Un cod elegant pe care îl înțelege o singură persoană este una serioasă, iar a doua situație este cea care mișcă prețul.

Întrebarea din spatele fiecărei întrebări: dacă inginerul fondator pleacă în săptămâna de după finalizarea tranzacției, sistemul acesta continuă să funcționeze și continuă să poată fi schimbat? Aproape orice constatare care scade o ofertă este un răspuns concret la asta. Cunoaștere concentrată într-un singur cap, un deployment nedocumentat, licențe pe care nu le-a verificat nimeni, credențiale care există doar în memoria unei persoane.

Ce evaluează de fapt un due diligence tehnic

Patru riscuri, aproximativ în ordinea în care afectează evaluarea.

Riscul de persoană cheie. Dacă sistemul depinde de oameni anume în loc să depindă de procese documentate. Este constant cea mai dăunătoare constatare, pentru că este cel mai greu de reparat după fapt și pentru că amenință direct chiar lucrul care se cumpără.

Costul continuării. Ce presupune menținerea sistemului în funcțiune și dezvoltarea lui mai departe: cheltuiala cu infrastructura, obligațiile de licențiere, mărimea echipei necesare și cât din foaia de parcurs va fi înghițit de mentenanță în loc de lucru nou.

Răspunderea. Licențe care intră în conflict cu utilizarea comercială, date personale prelucrate în moduri care nu ar rezista unei plângeri, expunere pe zona de securitate și orice obligație de reglementare pe care compania nu o respectă în realitate.

Capacitatea de a schimba. Dacă funcționalitățile noi pot fi livrate într-un ritm previzibil sau dacă fiecare modificare vine cu riscul de a strica ceva fără legătură cu ea.

Calitatea codului contează doar prin al patrulea punct, motiv pentru care un evaluator va petrece mai puțin timp citindu-ți codul decât se așteaptă fondatorii și mai mult timp întrebând cum se fac livrările în producție.

Constatările care reduc prețul

Nimeni nu poate face deployment în afară de o persoană. Un proces de release care trăiește în capul cuiva sau pe laptopul lui este tratat ca risc operațional serios, indiferent cât de bine funcționează astăzi.

Fără acoperire cu teste pe traseele care contează. Nu vorbim despre un procent de acoperire, pe care evaluatorii în mare parte îl ignoră, ci despre dacă sistemul poate fi modificat cu vreun strop de încredere. O bază de cod fără teste în jurul traseului care aduce venit include în preț o foaie de parcurs mai lentă. Ghidul nostru despre strategii de testare software arată ce merită cu adevărat efortul.

Contaminarea cu licențe. Cod copyleft în interiorul unui produs proprietar este una dintre puținele constatări care pot opri o tranzacție în loc să o reevalueze doar ca preț, iar un scanner îl găsește de obicei în câteva minute.

Date personale fără un temei apărabil. Date colectate fără un temei legal clar, păstrate la nesfârșit sau ținute undeva unde compania nu le poate enumera. Mecanismele din conformitatea tehnică cu GDPR sunt exact cele pe care le verifică un evaluator.

Dependențe nedocumentate de persoane sau furnizori. O integrare critică cu un furnizor fără niciun contract sau infrastructură ținută într-un cont personal: ambele se citesc ca risc negestionat.

Lipsesc elementele de bază de securitate. Nu rezultatul unui test de penetrare, ci dacă secretele stau în sistemul de versionare, dacă accesul este retras când oamenii pleacă și dacă există acum ceva neactualizat și expus în internet.

Ce nu îi interesează pe evaluatori

Merită spus, pentru că timpul de pregătire este limitat și de obicei este cheltuit prost.

Nu îi interesează ce framework ai ales, atât timp cât se pot angaja oameni pentru el. Nu îi interesează moda arhitecturală: un monolit care livrează nu este o constatare. Nu îi interesează stilul codului, denumirile sau absența unui șablon pe care îl recomandă cineva pe internet.

Nici nu se așteaptă la datorie tehnică zero. Orice companie are, iar prezența ei este normală. Ce contează este dacă echipa știe unde se află și poate descrie cât costă. O echipă care produce o listă clară a propriilor probleme cunoscute se citește ca fiind competentă. O echipă care pretinde că nu există niciuna se citește ca fiind neinformată, iar evaluatorul trebuie atunci să le găsească singur, ceea ce durează mai mult și produce un raport mai prost.

Pregătirea fără a rescrie nimic

Cea mai mare parte din ce ajută se măsoară în zile, nu în luni, și nimic din toate acestea nu atinge arhitectura.

Scrie cum se face deployment. De la o mașină goală până la un sistem care rulează. Acest singur document acoperă cea mai dăunătoare categorie de constatări și poate fi scris într-o după-amiază.

Enumeră dependențele și licențele lor. Uneltele automate produc lista repede, iar faptul că știi răspunsul înaintea evaluatorului valorează considerabil mai mult decât un rezultat curat.

Scoate secretele din sistemul de versionare și inventariază cine are acces la ce. Apoi retrage accesul oricui a plecat din companie.

Documentează ce știi că este greșit. Un registru scurt și onest al problemelor cunoscute, cu un cost aproximativ de remediere. Oferirea lui din proprie inițiativă este unul dintre puținele lucruri care îmbunătățesc constant tonul unei evaluări.

Asigură-te că infrastructura este deținută de companie, nu de un cont personal, și că domeniile, certificatele și repository-urile stau toate sub control corporativ.

Ce se întâmplă cu constatările

Rareori omoară o tranzacție. Devin condiții.

Constatările se rezolvă de obicei într-una din trei forme: o ajustare de preț care reflectă costul remedierii, o garanție contractuală sau o clauză de despăgubire în acord, ori o condiție de îndeplinit înainte de finalizare. Doar contaminarea cu licențe și o expunere serioasă și neabordată pe protecția datelor opresc în mod regulat tranzacțiile de tot.

Ceea ce înseamnă că obiectivul practic nu este un sistem perfect. Este un sistem ale cărui probleme sunt cunoscute, delimitate și descriptibile, pentru că o problemă cuantificată intră în preț, în timp ce una necuantificată este presupusă a fi mai gravă decât este.

Mecanik face evaluări tehnice de acest fel ca parte din activitatea noastră de dezvoltare software , de obicei din partea cumpărătorului. Tiparul este stabil: sistemele care ies bine dintr-o evaluare nu sunt cele sofisticate, ci acelea în care cineva a pus lucrurile pe hârtie.

Lecturi conexe: Software escrow: cine are nevoie de el cu adevărat , Dezvoltare software fintech în Marea Britanie: FCA, rails și costuri , Contract la preț fix sau în regie? și Dezvoltare software la comandă în Marea Britanie: ghidul complet al cumpărătorului .

Întrebări frecvente

Ce este due diligence tehnic? O evaluare a cât va costa deținerea unui sistem software și a cât de rău poate merge totul după o achiziție sau o investiție. Analizează riscul de persoană cheie, costul continuării, răspunderea juridică și capacitatea de a schimba sistemul mai departe, în loc să dea note calității codului de dragul ei.

Ce constatări reduc cel mai mult prețul? Concentrarea cunoașterii în anumite persoane, în special un proces de deployment pe care doar un om îl poate executa. După aceea: lipsa unei acoperiri reale cu teste pe traseele care aduc venit, contaminarea cu cod copyleft într-un produs proprietar, date personale fără un temei legal apărabil și secrete comise în sistemul de versionare.

Îi interesează pe evaluatori datoria mea tehnică? Se așteaptă la ea. Orice companie are ceva datorie tehnică, iar prezența ei nu este o constatare. Contează dacă echipa știe unde se află și poate descrie cât costă repararea. Un registru clar al problemelor cunoscute se citește ca o dovadă de competență; pretenția că nu există niciuna se citește ca lipsă de conștientizare și înrăutățește evaluarea.

Cum mă pregătesc pentru un due diligence tehnic? Scrie cum se pune sistemul în funcțiune pornind de la o mașină goală, enumeră dependențele și licențele lor, scoate secretele din sistemul de versionare, verifică cine mai are acces, confirmă că infrastructura și domeniile aparțin companiei și nu unor persoane și pregătește un registru onest al problemelor cunoscute, cu costuri aproximative de remediere.

Poate o constatare tehnică să oprească total o tranzacție? Rar. Majoritatea constatărilor devin ajustări de preț, garanții în acord sau condiții de îndeplinit înainte de finalizare. Excepțiile care chiar opresc tranzacțiile sunt contaminarea cu licențe copyleft într-un produs proprietar și o expunere serioasă și neabordată pe protecția datelor.