Architektura
Czy decyzje projektowe mają uzasadnienie, gdzie są wąskie gardła i co się stanie, gdy ruch w sklepie wzrośnie trzykrotnie w Black Friday.
Oceniamy według jasnych kryteriów, a nie gustu: czy system udźwignie wzrost, czy da się go utrzymać bez bólu, czy jest bezpieczny i czy nie wisi na jednej osobie.
Czy decyzje projektowe mają uzasadnienie, gdzie są wąskie gardła i co się stanie, gdy ruch w sklepie wzrośnie trzykrotnie w Black Friday.
Czytelność, pokrycie testami automatycznymi, powielone fragmenty, sposób wdrażania zmian i to, czy w ogóle istnieje dokumentacja.
Przestarzałe i porzucone biblioteki, komponenty ze znanymi podatnościami, wersje PHP, Node.js czy frameworków bez wsparcia.
Połączenia z ERP, KSeF, bramkami płatności i kurierami. Sprawdzamy, co się dzieje, gdy zewnętrzne API odpowie błędem albo nie odpowie wcale.
Gdzie działa system, gdzie leżą dane klientów, czy konfiguracja jest zgodna z RODO i zawartymi umowami powierzenia przetwarzania danych.
Czy inny zespół mógłby przejąć system, czy cała wiedza siedzi w głowie jednego programisty lub w repozytorium na jego prywatnym koncie.
Ryzyka i rekomendacje opisane tak, żeby skorzystali z nich także członkowie zarządu bez technicznego przygotowania.
Czas przeglądu zależy od wielkości systemu, ustalamy go przed startem. Pracujemy na dostępie tylko do odczytu do repozytorium i środowisk.
Przejęcie, zmiana wykonawcy czy ocena ryzyka. Cel decyduje, na czym kładziemy nacisk i jak szczegółowy będzie raport.
Repozytorium kodu, dokumentacja, konsola hostingu, logi. Rozmawiamy też z zespołem w Teams, bo część wiedzy nie trafiła do żadnego pliku.
Oceniamy według kryteriów i każde znalezisko opisujemy razem z jego konsekwencją dla biznesu.
Raport z ryzykami uszeregowanymi według wagi i szacunkiem kosztu naprawy, omówiony na spotkaniu online.
Najgroźniejszym znaleziskiem rzadko jest brzydki kod. Częściej jest nim uzależnienie od jednej osoby. System może być napisany bez elegancji i nadal działać latami. Jeśli jednak rozumie go tylko jeden programista, a dokumentacji brak, firma jest w praktyce zakładnikiem. To ryzyko oceniamy osobno, niezależnie od jakości technicznej.
Tak, to jeden z typowych powodów zamówienia. Dostajesz rzeczowy obraz tego, co zostało dostarczone, w jakim stanie i ile kosztuje przejęcie. Z raportem w ręku negocjujesz na faktach zarówno z obecnym, jak i z nowym wykonawcą.
Tak. Przy transakcji skupiamy się na tym, co wpływa na wycenę: technicznej stronie praw do kodu i licencji open source (ocenę prawną zostawiamy Twojemu prawnikowi), długu technicznym, zależności od kluczowych osób i kosztach utrzymania po przejęciu. Raport przygotowujemy w terminie ustalonym z Twoim doradcą transakcyjnym.
Nie szukamy winnych, opisujemy stan i ryzyka. Nie oceniamy ludzi. Często zespół wręcz korzysta na raporcie, bo argumenty, które powtarzał od lat, wreszcie padają z niezależnego źródła.
Wtedy to napiszemy, z uzasadnieniem i rachunkiem dla obu dróg: naprawa krok po kroku albo przepisanie. Decyzja należy do Ciebie, ale lepiej ją podjąć na liczbach niż na przeczuciu.
Opisz system i powód audytu. Dostaniesz raport, w którym ryzyka są ułożone od najpoważniejszego.
Zapytanie dotarło do nas
Odpowiedź dostaniesz w ciągu dnia roboczego, a jeśli zgłaszasz awarię, która zatrzymuje pracę, zajmiemy się nią w pierwszej kolejności.
Nie mamy tego miasta na liście. Sprawdź pisownię albo wybierz najbliższe duże miasto - pracujemy zdalnie, więc nie wpływa to na zakres obsługi.