Kod to tylko część obrazu
Due diligence powinno sprawdzić nie tylko jakość kodu, ale też architekturę, dane, bezpieczeństwo, proces wdrożeń, monitoring, dokumentację, zależności od dostawców i kompetencje zespołu. Produkt może działać dzisiaj, ale inwestora interesuje również koszt skalowania i ryzyko utrzymania.
Najważniejsze są ryzyka, których nie widać w demo
Demo nie pokaże braku testów, długu architektonicznego, problemów z danymi, ręcznych deploymentów czy jednego eksperta, który zna cały system. Dlatego analiza powinna obejmować repozytorium, historię zmian, incydenty, backlog techniczny i proces pracy zespołu.
Dobry wynik pomaga negocjować i planować
Celem nie jest znalezienie perfekcyjnej technologii. Celem jest zrozumienie ryzyka, kosztu i planu naprawczego. Raport powinien wspierać decyzję inwestycyjną, wycenę, harmonogram integracji i priorytety po transakcji. Wtedy technologia staje się elementem świadomej decyzji biznesowej.
Analiza powinna objąć zdolność zespołu do dowożenia
Produkt może mieć sensowną architekturę, ale nadal być ryzykowny, jeśli zespół nie ma procesu decyzji, testów, code review, planowania i reagowania na incydenty. Due diligence powinno sprawdzić, czy organizacja potrafi przewidywalnie rozwijać system po inwestycji, czy każdy większy krok zależy od improwizacji.
Wycena technologii zależy od długu i zależności
Dług techniczny nie zawsze dyskwalifikuje inwestycję, ale powinien wpływać na cenę, harmonogram i plan po transakcji. Jeśli produkt wymaga przebudowy infrastruktury, wymiany krytycznego dostawcy albo zatrudnienia brakujących kompetencji, te koszty muszą być widoczne przed podpisaniem umowy.
Raport powinien wspierać plan pierwszych 100 dni
Najbardziej użyteczne due diligence wskazuje, co zrobić zaraz po inwestycji: które ryzyka zamknąć, które obszary zostawić bez zmian, jakie kompetencje uzupełnić i jak mierzyć poprawę. Dzięki temu raport nie zostaje w folderze transakcyjnym, tylko staje się planem integracji i rozwoju produktu.
