Technical due diligence to niezależna kontrola kodu, systemów i technicznych nawyków firmy. Zwykle odbywa się przed inwestycją, przejęciem albo dużym partnerstwem i odpowiada na jedno proste pytanie dla osoby, która ma wypisać czek: czy technologia jest tak solidna jak biznes na niej zbudowany.
Większość założycieli widzi ten proces tylko z drugiej strony, kiedy zespół inwestora albo kupca przychodzi zajrzeć pod maskę. Mniej osób wpada na to, żeby najpierw przeprowadzić go na sobie, choć to często moment, w którym pomaga najbardziej. Częściowo to kwestia czasu. Due diligence jawi się jako coś, co przytrafia się tobie, a nie jako coś, na co się przygotowujesz, więc rzadko trafia na własną listę zadań założyciela, dopóki ktoś inny jej tam nie wpisze.
Dlaczego czas ma znaczenie
Założyciele, którzy szykują się do pozyskania finansowania albo sprzedaży firmy, dużo zyskują, robiąc technical due diligence na sobie, zanim zrobi to ktoś inny. Wczesne znalezienie własnego długu technicznego chroni później i wycenę, i twoją pozycję przy stole negocjacyjnym.
Potwierdzają to badania: tylko co czwarty CEO deklaruje, że przy większości swoich transakcji przeprowadza due diligence technologii, choć większość z nich widzi w technologii realny motor wzrostu, a nie tylko koszt prowadzenia biznesu. Właśnie w tej luce, między tym, jak ważna jest technologia, a tym, jak rzadko ktoś niezależnie ją sprawdza, zwykle pojawiają się niespodzianki, najczęściej w najgorszym możliwym momencie negocjacji.
Co naprawdę obejmuje technical due diligence
Rzetelny przegląd zwykle obejmuje kilka obszarów. Jak dobry jest kod i czy jest dobrze zorganizowany, bo chaotyczny kod później wolno i drogo się zmienia. Czy są wdrożone podstawowe praktyki bezpieczeństwa, te, które chronią i biznes, i jego użytkowników. Jak mocno system zależy od starych albo nieutrzymywanych technologii, które z czasem mogą stać się obciążeniem. Czy obecna konfiguracja wytrzyma dalszy wzrost biznesu, czy trzeba by ją przebudować za rok lub dwa. I ile wiedzy zespołu żyje tylko w głowach kilku osób, zamiast być gdziekolwiek spisane, co staje się realnym ryzykiem w chwili, gdy taka osoba odejdzie.
Żaden z tych punktów nie jest pytaniem typu zaliczone–niezaliczone. Baza kodu może nosić realny dług techniczny i nadal wspierać zdrowy, rosnący biznes. Liczy się, dla kupca i dla ciebie, czy ten dług jest zrozumiały, zmierzony i łatwy do wyjaśnienia, a nie czymś, na co nikt nie spojrzał z bliska.
Co się zmienia, gdy spojrzysz pierwszy
.jpg)
Kiedy zespół kupca znajdzie coś nieoczekiwanego, zwykle staje się to punktem, który wykorzystuje w negocjacjach, rzadko na twoją korzyść. Kiedy znajdziesz to pierwszy, jest to coś, co już rozumiesz, z dołączonym planem, jeśli jest potrzebny.
Ta różnica często waży więcej niż samo znalezisko. Znany problem z jasnym wyjaśnieniem wygląda dla inwestora zupełnie inaczej niż ten sam problem, który wychodzi na jaw przy okazji i jest przedstawiany przez kogoś, kogo zadaniem jest szukanie powodów do obniżenia ceny.
Jest też praktyczna korzyść uboczna. Założyciele, którzy robią taki przegląd wcześnie, dostają szczery obraz własnego systemu z zewnątrz, niezależnie od tego, czy jakaś transakcja jest blisko. Warto go mieć bez względu na to, co się stanie z konkretną rundą czy ofertą.
Zmienia to też samą rozmowę. Założyciel, który potrafi jasno, prostym językiem opowiedzieć o własnym długu technicznym, wypada jak ktoś, kto panuje nad swoim biznesem. Założyciel zaskoczony znaleziskiem, którego nigdy nie sprawdził, wypada inaczej, nawet jeśli sam problem ma dokładnie ten sam rozmiar.
Dla kogo ma to największe znaczenie
Dotyczy to szczególnie sytuacji, gdy części twojego systemu powstawały przez kilka lat, często szybko, żeby zdążyć na termin albo osiągnąć kamień milowy, a nie w jednym przemyślanym podejściu. Tak działa wiele rosnących, rentownych firm. Funkcja idzie na produkcję, żeby domknąć klienta, obejście trafia do kodu, żeby zdążyć z premierą, a kilka lat później system jest patchworkiem decyzji podjętych pod różną presją przez różne osoby. Nic z tego samo w sobie nie jest problemem. Mnóstwo dobrze prowadzonych, rentownych firm działa na systemach zbudowanych w ten sposób. Problem pojawia się dopiero wtedy, gdy nikt nie wrócił, żeby sprawdzić, co te wszystkie decyzje faktycznie po sobie zostawiły.
To samo dotyczy sytuacji, gdy przez lata pracowali z tobą różni deweloperzy lub agencje, a od tamtej pory nikt nie spojrzał na system jako całość. Łatwo przestać wiedzieć, które części wciąż odzwierciedlają wczesne, szybkie decyzje, a które naprawdę urosnęły razem z biznesem. Przegląd nie osądza, jak do tego doszło. Po prostu daje szczerą mapę tego, gdzie jesteś teraz, żeby to do ciebie należała decyzja, co dalej, a nie do zespołu kupca kilka miesięcy w głąb negocjacji.
Kiedy to zrobić
Przegląd ma największy sens na kilka miesięcy przed spodziewanym startem poważnych rozmów, a nie w ich trakcie. Daje to wystarczająco dużo czasu, żeby naprawdę naprawić wszystko istotne, co wyjdzie, zamiast wchodzić do negocjacji i wciąż tłumaczyć coś, co dopiero co odkryto.
Warto go zrobić nawet bez bliskiej transakcji. Rosnące firmy gromadzą decyzje techniczne tak samo jak wszystko inne, a zaglądanie na ten stos od czasu do czasu na własną rękę to rozsądny nawyk, a nie reakcja na jedno wydarzenie.
Jeśli nie masz pewności, czy to dobry moment, ta niepewność sama zwykle jest znakiem, że warto porozmawiać.
Tak wygląda to w Rocksoft. Nie sprzedajemy osobnego pakietu „due diligence”. Prowadzimy Code Audit, czyli ten sam niezależny, uporządkowany przegląd, tylko dopasowany do twojej osi czasu, a nie do osi czasu kupca.
Dostajesz jasny obraz tego, co jest solidne, co wymaga uwagi i co przyszły inwestor lub kupiec najpewniej oflaguje, zanim ktokolwiek spoza firmy zacznie się temu przyglądać.
