Sprawdzamy kod, architekturę, integracje, środowiska i zależności platformy. Raport pokazuje, które problemy wymagają reakcji, które można zaplanować później i co trzeba wiedzieć przed przejęciem, przebudową albo dalszym rozwojem sklepu.
Usługa jest przeznaczona dla firm posiadających działający e‑commerce, ale bez pewności, czy jego obecny stan techniczny pozwala bezpiecznie realizować kolejne zmiany. Zakres dobieramy do technologii, stopnia customizacji oraz decyzji, którą ma wesprzeć audyt.
Dług techniczny rzadko pojawia się jako jeden łatwy do nazwania błąd. Częściej widać go w rosnących estymacjach, powtarzających się regresjach, ręcznym pilnowaniu integracji i obawie przed większą aktualizacją.
Pojedynczy sygnał nie przesądza o stanie całej platformy. Powtarzalność problemów i brak jasnego wyjaśnienia ich przyczyn uzasadniają szerszą analizę.
| Sygnał | Możliwa przyczyna | Konsekwencja |
|---|---|---|
| Niewielka zmiana wymaga dużej estymacji | Silne powiązania między modułami, powielona logika lub brak dokumentacji | Backlog rozwija się wolniej, a koszt zmian jest trudniejszy do przewidzenia |
| Poprawka w jednym miejscu wywołuje błąd w innym | Brak testów regresji albo zależności niewidoczne dla zespołu | Wdrożenia wymagają ostrożności i dłuższej ręcznej weryfikacji |
| Zamówienia lub stany magazynowe trzeba ręcznie kontrolować | Integracja nie obsługuje błędów, ponowień albo alertów | Zespół operacyjny przejmuje pracę, którą powinien wykonywać system |
| Aktualizacje są stale odkładane | Konflikty modułów, nieaktualne zależności albo brak powtarzalnego procesu wdrożenia | Rosną koszty utrzymania i ryzyko związane z bezpieczeństwem |
| Tylko jedna osoba rozumie działanie wybranego obszaru | Wiedza nie została zapisana w kodzie, testach ani dokumentacji | Odejście specjalisty może zatrzymać rozwój części platformy |
| Każda agencja inaczej ocenia stan sklepu | Brakuje wspólnej dokumentacji, kryteriów i materiału dowodowego | Decyzje opierają się na opiniach zamiast na ustaleniach możliwych do sprawdzenia |
Niewielka zmiana wymaga dużej estymacji
Możliwa przyczyna
Silne powiązania między modułami, powielona logika lub brak dokumentacji
Konsekwencja
Backlog rozwija się wolniej, a koszt zmian jest trudniejszy do przewidzenia
Poprawka w jednym miejscu wywołuje błąd w innym
Możliwa przyczyna
Brak testów regresji albo zależności niewidoczne dla zespołu
Konsekwencja
Wdrożenia wymagają ostrożności i dłuższej ręcznej weryfikacji
Zamówienia lub stany magazynowe trzeba ręcznie kontrolować
Możliwa przyczyna
Integracja nie obsługuje błędów, ponowień albo alertów
Konsekwencja
Zespół operacyjny przejmuje pracę, którą powinien wykonywać system
Aktualizacje są stale odkładane
Możliwa przyczyna
Konflikty modułów, nieaktualne zależności albo brak powtarzalnego procesu wdrożenia
Konsekwencja
Rosną koszty utrzymania i ryzyko związane z bezpieczeństwem
Tylko jedna osoba rozumie działanie wybranego obszaru
Możliwa przyczyna
Wiedza nie została zapisana w kodzie, testach ani dokumentacji
Konsekwencja
Odejście specjalisty może zatrzymać rozwój części platformy
Każda agencja inaczej ocenia stan sklepu
Możliwa przyczyna
Brakuje wspólnej dokumentacji, kryteriów i materiału dowodowego
Konsekwencja
Decyzje opierają się na opiniach zamiast na ustaleniach możliwych do sprawdzenia
Samo znalezienie błędów nie jest celem. Przed rozpoczęciem ustalamy, jaka decyzja ma zostać podjęta po analizie i które obszary mogą mieć na nią wpływ.
Audyt techniczny warto rozważyć w następujących sytuacjach:
Trzeba ustalić stan kodu, zakres customizacji, działanie integracji, dostępne środowiska oraz braki w dokumentacji. Bez tej wiedzy nowy zespół może przejąć odpowiedzialność za problemy, których skali wcześniej nie znał.
Nowy rynek, model B2B, rozbudowana integracja albo przebudowa procesu zakupowego mogą dotknąć wielu części systemu. Audyt pokazuje, które elementy obecnej architektury wymagają uporządkowania przed rozpoczęciem prac.
Kolejne estymacje są wyższe, choć zakres funkcji nie wydaje się bardziej skomplikowany. Przyczyną może być narastający dług techniczny, brak automatycznych testów lub zbyt silne zależności między obszarami platformy.
Powtarzające się regresje mogą wskazywać, że zespół usuwa objawy bez dostępu do przyczyny albo nie posiada narzędzi potrzebnych do bezpiecznej weryfikacji zmian.
Audyt pokazuje, które elementy można dalej rozwijać, które wymagają przebudowy i gdzie koszt utrzymania obecnego rozwiązania może przestać być uzasadniony. Zakres samej migracji ustala się później, w osobnej analizie.
Część zależności istnieje tylko w pamięci obecnych lub byłych programistów. Brakuje dokumentacji, opisów integracji, historii decyzji i powtarzalnego sposobu wdrażania zmian.
Jeżeli sklep nie został jeszcze uruchomiony, a projekt utknął przed startem, punktem wyjścia jest zwykle dokończenie sklepu na Magento 2, które zaczyna się od przeglądu tego, co zostało już zbudowane.
Poniższa lista stanowi bazę do ustalenia zakresu. Przed rozpoczęciem audytu określamy technologie, dostępne środowiska, najważniejsze integracje oraz decyzję, którą raport ma wesprzeć.
Analizujemy sposób podziału odpowiedzialności między modułami, poziom powiązań, powtarzalność logiki i miejsca szczególnie trudne do dalszego rozwoju.
Sprawdzamy między innymi
Rodzaj dowoduFragmenty kodu, mapa zależności między modułami i lista nadpisań względem standardu platformy.
Sprawdzamy pochodzenie, aktualność i rolę zewnętrznych komponentów. Oceniamy konflikty, nadpisania, duplikowanie funkcji oraz zależność platformy od rozwiązań, które nie są dalej utrzymywane.
Raport rozdziela elementy potrzebne, zbędne i wymagające osobnej decyzji.
Sprawdzamy między innymi
Rodzaj dowoduLista zależności z wersjami, historia zmian w repozytorium i konfiguracja menedżera pakietów.
Analiza obejmuje sposób wymiany danych między sklepem a ERP, PIM, WMS, CRM, systemami płatności, dostawami i innymi usługami.
Sprawdzamy między innymi
Rodzaj dowoduKonfiguracja połączeń, logi wymiany danych i opis procedury stosowanej po nieudanej synchronizacji.
Weryfikujemy ustawienia wpływające na bezpieczeństwo platformy, role i uprawnienia, sposób przechowywania sekretów, aktualność komponentów oraz ekspozycję środowisk.
Audytu technicznego nie komunikujemy jako testu penetracyjnego, jeżeli taki zakres nie został osobno uzgodniony.
Sprawdzamy między innymi
Rodzaj dowoduUstawienia platformy, lista kont i ról oraz konfiguracja serwera w zakresie udostępnionym do wglądu.
Sprawdzamy podział środowisk, proces przygotowania wersji, obsługę zmian konfiguracji, możliwość wycofania wdrożenia i sposób weryfikacji przed publikacją.
Celem jest ustalenie, czy zespół może powtarzalnie wdrażać zmiany i reagować, gdy nowa wersja powoduje problem.
Sprawdzamy między innymi
Rodzaj dowoduKonfiguracja procesu wdrożeniowego, historia publikacji i opis kroków wykonywanych ręcznie.
Analizujemy, jakie zdarzenia są rejestrowane, kto otrzymuje alerty i czy zespół ma dane potrzebne do odtworzenia przebiegu błędu.
Brak danych diagnostycznych często wydłuża naprawę, ponieważ problem trzeba najpierw odtworzyć zamiast przejść od razu do jego źródła.
Sprawdzamy między innymi
Rodzaj dowoduPróbki logów, konfiguracja monitoringu i historia ostatnich zgłoszeń.
Sprawdzamy, czy najważniejsze procesy posiadają testy, czy dokumentacja odpowiada obecnemu stanowi systemu oraz ile wiedzy pozostaje wyłącznie w rękach pojedynczych osób.
Ocena obejmuje również możliwość przejęcia kodu przez inny zespół.
Sprawdzamy między innymi
Rodzaj dowoduZakres testów w repozytorium, dokumentacja projektu i instrukcja uruchomienia środowiska.
Analizujemy sposób podziału odpowiedzialności między modułami, poziom powiązań, powtarzalność logiki i miejsca szczególnie trudne do dalszego rozwoju.
Sprawdzamy między innymi
Rodzaj dowoduFragmenty kodu, mapa zależności między modułami i lista nadpisań względem standardu platformy.
Sprawdzamy pochodzenie, aktualność i rolę zewnętrznych komponentów. Oceniamy konflikty, nadpisania, duplikowanie funkcji oraz zależność platformy od rozwiązań, które nie są dalej utrzymywane.
Raport rozdziela elementy potrzebne, zbędne i wymagające osobnej decyzji.
Sprawdzamy między innymi
Rodzaj dowoduLista zależności z wersjami, historia zmian w repozytorium i konfiguracja menedżera pakietów.
Analiza obejmuje sposób wymiany danych między sklepem a ERP, PIM, WMS, CRM, systemami płatności, dostawami i innymi usługami.
Sprawdzamy między innymi
Rodzaj dowoduKonfiguracja połączeń, logi wymiany danych i opis procedury stosowanej po nieudanej synchronizacji.
Weryfikujemy ustawienia wpływające na bezpieczeństwo platformy, role i uprawnienia, sposób przechowywania sekretów, aktualność komponentów oraz ekspozycję środowisk.
Audytu technicznego nie komunikujemy jako testu penetracyjnego, jeżeli taki zakres nie został osobno uzgodniony.
Sprawdzamy między innymi
Rodzaj dowoduUstawienia platformy, lista kont i ról oraz konfiguracja serwera w zakresie udostępnionym do wglądu.
Sprawdzamy podział środowisk, proces przygotowania wersji, obsługę zmian konfiguracji, możliwość wycofania wdrożenia i sposób weryfikacji przed publikacją.
Celem jest ustalenie, czy zespół może powtarzalnie wdrażać zmiany i reagować, gdy nowa wersja powoduje problem.
Sprawdzamy między innymi
Rodzaj dowoduKonfiguracja procesu wdrożeniowego, historia publikacji i opis kroków wykonywanych ręcznie.
Analizujemy, jakie zdarzenia są rejestrowane, kto otrzymuje alerty i czy zespół ma dane potrzebne do odtworzenia przebiegu błędu.
Brak danych diagnostycznych często wydłuża naprawę, ponieważ problem trzeba najpierw odtworzyć zamiast przejść od razu do jego źródła.
Sprawdzamy między innymi
Rodzaj dowoduPróbki logów, konfiguracja monitoringu i historia ostatnich zgłoszeń.
Sprawdzamy, czy najważniejsze procesy posiadają testy, czy dokumentacja odpowiada obecnemu stanowi systemu oraz ile wiedzy pozostaje wyłącznie w rękach pojedynczych osób.
Ocena obejmuje również możliwość przejęcia kodu przez inny zespół.
Sprawdzamy między innymi
Rodzaj dowoduZakres testów w repozytorium, dokumentacja projektu i instrukcja uruchomienia środowiska.
Elementy objęte audytem
Czego audyt techniczny nie zastępuje
Audyt techniczny może wskazać, że dany problem wymaga dalszego pomiaru, ale nie zastępuje:
Oba badania patrzą na tę samą platformę, ale odpowiadają na różne pytania. Techniczny ocenia jakość rozwiązania i ryzyka dalszego rozwoju. Wydajnościowy mierzy, jak szybko sklep działa dla użytkownika.
Jakość rozwiązania i ryzyka technologiczne
Ocenia kod, architekturę, moduły, zależności, integracje, bezpieczeństwo i dług technologiczny. Odpowiada na pytanie, czy platformę można bezpiecznie rozwijać, przejąć albo utrzymywać dalej — i jakim kosztem.
Szybkość działania i doświadczenie użytkownika
Koncentruje się na szybkości działania, Core Web Vitals i doświadczeniu użytkownika związanym z wydajnością. Mierzy czasy odpowiedzi, zachowanie pod obciążeniem i wąskie gardła w konkretnych widokach.
Audyt techniczny może wskazać, że dany obszar wymaga pomiaru — mówi wtedy, co zmierzyć, a nie ile wynosi wynik. Jeżeli problemem jest przede wszystkim szybkość sklepu, właściwym pierwszym krokiem jest audyt wydajnościowy.
Dług technologiczny rzadko wynika z jednej złej decyzji. Zwykle jest sumą zmian wprowadzanych pod presją terminu, bez uporządkowania tego, co zostało po drodze. Audyt nazywa te miejsca i pokazuje, ile kosztują przy każdej kolejnej zmianie.
Co składa się na dług technologiczny
Nie każdy dług trzeba spłacić. Raport rozdziela obszary, które blokują dalszy rozwój, od tych, które można świadomie utrzymać — razem z kosztem tej decyzji.
Przejęcie projektu bez sprawdzenia jego stanu przenosi na nowego dostawcę zobowiązania, których nikt nie policzył. Audyt wykonany przed rozpoczęciem developmentu zamienia je w listę znanych ryzyk.
Co sprawdzamy przed przejęciem
Audyt nie kończy się oceną „dobrze” albo „źle”. Dla każdego obszaru wskazuje jedną z trzech dróg, razem z kosztem i konsekwencją.
Obszar spełnia standard albo jego braki nie blokują dalszego rozwoju. Prace idą dalej na tym, co jest, z listą drobnych poprawek do planu.
Rozwiązanie działa, ale jego dalsze utrzymanie kosztuje więcej niż przebudowa. Raport wskazuje zakres i kolejność, żeby zmiana nie zatrzymała sprzedaży.
Moduł, integracja albo mechanizm, którego koszt utrzymania nie ma pokrycia w wartości dla firmy. Zamiast naprawy — wycofanie albo zastąpienie.
Jeżeli decyzja dotyczy nie tyle stanu obecnej platformy, ile tego, co należy zbudować, właściwym punktem wyjścia jest analiza przedwdrożeniowa. Dla projektu rozpoczętego i nieukończonego przez innego wykonawcę osobnym zakresem jest dokończenie sklepu.
Innego zakresu wymaga przejęcie platformy, innego ocena przed większą integracją, a jeszcze innego decyzja o dalszym utrzymaniu obecnej architektury.
Etapy przebiegają po kolei, a każdy z nich ma opisane wejście i rezultat. Dzięki temu wiadomo, czego potrzebujemy od zespołu klienta i w którym momencie.
Zbieramy informacje o platformie, zespole, bieżących problemach i planowanych zmianach. Ustalamy, kto będzie korzystał z raportu i jakie decyzje powinny zostać podjęte po jego otrzymaniu.
PotrzebneTechnologia, integracje, planowane zmiany, obecny dostawca, historia najważniejszych problemów
RezultatSpisana decyzja, którą ma wesprzeć audyt
Przygotowujemy listę potrzebnych repozytoriów, środowisk, logów, dokumentacji i osób posiadających wiedzę o systemie. Ograniczenia dostępu są zapisywane, a raport nie przedstawia kategorycznych wniosków o obszarze, którego nie można było sprawdzić.
PotrzebneZgody, konta dostępowe i osoby kontaktowe po stronie klienta
RezultatUzgodniony zakres wraz z listą obszarów wyłączonych z analizy
Specjaliści przeglądają uzgodnione obszary, zapisują dowody i oceniają zależności między problemami. Znaleziska są grupowane według wpływu na działanie platformy i planowane decyzje.
PotrzebneDostęp do kodu, konfiguracji, logów i dokumentacji
RezultatZestaw znalezisk z przypisanym materiałem dowodowym
Najważniejsze obserwacje są konfrontowane z dokumentacją i wiedzą zespołu klienta. Pozwala to oddzielić świadome decyzje architektoniczne od przypadkowych pozostałości po wcześniejszych zmianach.
PotrzebneRozmowa z osobami znającymi historię projektu
RezultatZnaleziska potwierdzone albo wycofane, z podanym uzasadnieniem
Przekazujemy raport zawierający znaleziska, dowody, konsekwencje, priorytety i rekomendowane warianty. Wnioski omawiamy z osobami odpowiedzialnymi za technologię i e‑commerce.
PotrzebneTermin spotkania i lista odbiorców raportu
RezultatRaport z priorytetami oraz omówione warianty dalszego działania
Samo wskazanie problemu nie mówi jeszcze, co firma powinna z nim zrobić. Każdy problem opisujemy tym samym łańcuchem, aż do estymacji prac — dzięki temu raport da się czytać po kolei, po obszarze albo po priorytecie.
Raport wskazuje wagę problemu, rekomendację, czasochłonność i estymację naprawy, więc na jego podstawie da się zbudować backlog i porozmawiać o budżecie bez powtarzania analizy.
| Pole | Treść |
|---|---|
| Problem | Mechanizm synchronizacji z ERP nie ma widocznego procesu ponowienia po błędzie. |
| Obszar | Integracje i przepływ danych. |
| Poziom ryzyka | Wysoki — awaria kończy się rozbieżnością danych, a nie komunikatem o błędzie. |
| Wpływ | Wybrane zamówienia mogą wymagać ręcznej kontroli po przerwaniu synchronizacji. |
| Rekomendowane rozwiązanie | Kolejka z ponowieniami, identyfikacja zdarzeń i alert dla zespołu przy przekroczeniu progu błędów. |
| Priorytet | Po znaleziskach blokujących sprzedaż, przed porządkowaniem struktury kodu. |
| Estymacja prac | Widełki roboczogodzin dla rekomendowanego rozwiązania, z zaznaczeniem, co wymaga doprecyzowania przed wyceną. |
Format pojedynczego problemu
Mechanizm synchronizacji z ERP nie ma widocznego procesu ponowienia po błędzie.
Integracje i przepływ danych.
Wysoki — awaria kończy się rozbieżnością danych, a nie komunikatem o błędzie.
Wybrane zamówienia mogą wymagać ręcznej kontroli po przerwaniu synchronizacji.
Kolejka z ponowieniami, identyfikacja zdarzeń i alert dla zespołu przy przekroczeniu progu błędów.
Po znaleziskach blokujących sprzedaż, przed porządkowaniem struktury kodu.
Widełki roboczogodzin dla rekomendowanego rozwiązania, z zaznaczeniem, co wymaga doprecyzowania przed wyceną.
Przykład formatu. Nie jest to wynik audytu konkretnego klienta.
Raport zawiera
Jeżeli znaleziska wskażą, że problem wymaga pomiaru pod ruchem, kolejnym krokiem jest audyt wydajnościowy e‑commerce. Raport techniczny mówi wtedy, co zmierzyć, a nie ile wynosi wynik.
Raport przekazujemy w formie, którą może wykorzystać zespół wewnętrzny, obecny dostawca albo inna firma. Dokument ma być użyteczny również wtedy, gdy dalszych prac nie realizuje Aurora Creation.
Najczęstsze pytania o cenę, dostępy, zakres, bezpieczeństwo i wykorzystanie raportu.
Pierwsza rozmowa służy kwalifikacji: sprawdzamy, czy audyt techniczny jest właściwym krokiem, i co trzeba przygotować przed jego rozpoczęciem.
Omówmy zakres i potrzebne dostępyWróć do kategorii Audyt i analizaPodstawowy audyt kosztuje od 3600 zł netto. Szerszy zakres wyceniamy na podstawie zakresu projektu: liczby integracji, stopnia customizacji, liczby środowisk, dostępności dokumentacji oraz tego, czy badanie ma objąć bazę danych, infrastrukturę i proces wdrożeniowy. Kwotę i termin potwierdzamy przed rozpoczęciem prac.
Czas zależy od wielkości platformy, liczby integracji, zakresu customizacji, dostępności dokumentacji oraz celu analizy. Zakres, harmonogram i sposób rozliczenia potwierdzamy przed rozpoczęciem prac. Audyt podstawowy jest wyraźnie krótszy niż badanie obejmujące bazę danych, infrastrukturę i pełny proces wdrożeniowy.
Lista zależy od ustalonego zakresu. Może obejmować repozytorium kodu, środowisko testowe, panel administracyjny, logi, konfigurację integracji, dokumentację i narzędzia używane do wdrażania zmian. Dostępy do produkcji nie powinny być wymagane, jeżeli potrzebne dane można bezpiecznie pozyskać z innych źródeł.
Tak. Ocena jakości kodu, zgodności ze standardem platformy, zakresu nadpisań i stanu modyfikacji indywidualnych jest podstawą audytu technicznego — bez dostępu do repozytorium część znalezisk pozostałaby przypuszczeniem. Jeżeli dostęp do kodu nie jest możliwy, mówimy wprost, których wniosków nie da się wtedy postawić.
Obejmuje aktualność komponentów i wersji oprogramowania, konfigurację, konta, role, uprawnienia oraz widoczne ryzyka techniczne. Nie należy tego utożsamiać z testem penetracyjnym — taki zakres uzgadniamy osobno, jeżeli sytuacja go wymaga.
Tak. Dla każdej integracji sprawdzamy konfigurację połączenia, kierunek i zakres wymienianych danych, obsługę błędów, ponowienia, identyfikację zdarzeń oraz to, co dzieje się po nieudanej synchronizacji. Dotyczy to również CRM, płatności, przewoźników i marketplace’ów objętych zakresem.
Audyt techniczny ocenia jakość rozwiązania: kod, architekturę, integracje, bezpieczeństwo i ryzyka technologiczne. Audyt wydajnościowy e‑commerce koncentruje się na szybkości działania, Core Web Vitals i doświadczeniu użytkownika związanym z wydajnością. Audyt techniczny obejmuje sygnały, które mogą wpływać na wydajność, ale szczegółowe pomiary frontendowe, serwerowe i obciążeniowe należą do audytu wydajnościowego.
Tak, i jest to jedno z najczęstszych zastosowań tej usługi. Przed rozpoczęciem dalszego developmentu sprawdzamy repozytorium, dokumentację, środowiska, integracje, bezpieczeństwo, backlog, jakość kodu i zależności. Wynik wskazuje, które obszary da się kontynuować, które warto przebudować, a których dalsze utrzymanie nie ma uzasadnienia.
Tak, jako osobny zakres ustalany po akceptacji priorytetów. Nie jest to jednak warunek: raport przekazujemy w formie, którą może wykorzystać zespół wewnętrzny, obecny dostawca albo inna firma. Dla projektu rozpoczętego i nieukończonego przez innego wykonawcę osobnym zakresem jest dokończenie sklepu.
Nie. Audyt może zostać wykonany jako niezależna analiza. Raport może później wykorzystać obecny dostawca, zespół wewnętrzny albo inna firma.
Analiza nie obejmuje zmian produkcyjnych bez oddzielnego uzgodnienia. W przypadku wykrycia pilnego ryzyka najpierw przekazujemy informację i proponowany sposób postępowania.
Może wskazać ograniczenia obecnej architektury i ryzyka dalszego rozwoju. Jeżeli migracja okaże się uzasadnionym wariantem, jej zakres i technologia powinny zostać określone w analizie przedwdrożeniowej.
Raport podaje estymację prac dla każdego problemu, razem z priorytetem i zależnościami między poprawkami. Nie jest to jednak umowna wycena całości: przy części znalezisk zaznaczamy, co wymaga doprecyzowania przed wyceną, bo niektórych prac nie da się wiarygodnie oszacować na podstawie samej obserwacji problemu.
Raport może posłużyć do uporządkowania backlogu, rozmowy z obecnym dostawcą, przygotowania przejęcia, zaplanowania refaktoryzacji albo rozpoczęcia analizy przedwdrożeniowej.
Podczas pierwszej rozmowy omawiamy obecną platformę, problemy, planowane decyzje i dostępne materiały. Jeżeli inny rodzaj analizy będzie lepiej odpowiadał sytuacji, powiemy to przed przygotowaniem zakresu.
Nie potrzebujesz gotowego opisu technicznego. Wystarczy informacja, co obecnie budzi wątpliwości i jaką decyzję firma planuje podjąć.
Co warto mieć pod ręką
