Audyt techniczny

Bezpłatna konsultacja Projekty

Odpowiedź na pytanie, które blokuje roadmapę - rozwijać to, co jest, wymienić kawałek czy przenieść produkt na inny fundament. Werdykt, rejestr długu wyceniony w dniach pracy zespołu i trzy scenariusze na dwa lata, w 15 dni roboczych.

Pracowaliśmy dla najlepszych firm i startupów

Wyzwania

Trzy sytuacje, w których audyt wyprzedza kosztowną decyzję

Nie wiesz, czy audyt jest teraz właściwym krokiem? Umów konsultację - powiemy wprost, czy wystarczy przegląd zależności, czy sprawa jest na pełne badanie.

  • „Przejmujecie kod po poprzednim wykonawcy”

    Umowa utrzymaniowa albo przejęcie produktu podpisuje się na stan, którego nikt po Waszej stronie jeszcze nie widział od środka. Audyt daje obraz przed podpisem - co dziedziczycie, czego nie da się utrzymać bez autora i które zobowiązania trzeba wpisać do umowy zamiast odkrywać je w trzecim miesiącu.

  • „Każde kolejne wydanie trwa dłużej niż poprzednie”

    Zespół nie zmienił składu, zakres pojedynczych zadań też nie urósł, a droga od pomysłu do produkcji wydłuża się kwartał po kwartale. Rozstrzygamy, czy hamuje architektura, brak testów, czy sam proces wydawania - bo każda z tych przyczyn ma inną cenę naprawy.

  • „Na stole leży wniosek o przepisanie produktu”

    Zespół techniczny chce zacząć od zera, zarząd pyta, czy naprawdę trzeba, i obie strony operują argumentami, których nie da się zważyć. Werdykt oparty na Waszym repozytorium i pomiarach zamienia ten spór w decyzję z liczbami, którą da się obronić przed komitetem inwestycyjnym.

Dla kogo

Kto zamawia u nas audyt techniczny

  • Zespoły przejmujące produkt po zewnętrznym wykonawcy

    Kod przychodzi razem z umową utrzymaniową, a wiedza o nim zostaje po stronie, która go pisała. Zaczynamy od tego, co da się utrzymać bez autora - gdzie dokumentacją jest sam kod, które integracje mają jednego właściciela i co trzeba przenieść w pierwszych tygodniach, zanim kontakt z poprzednim zespołem się urwie.

  • Firmy przed inwestycją albo przejęciem

    Prezentacja pokazuje produkt od strony rynku, a pytanie inwestora dotyczy tego, ile kosztuje utrzymanie tego, co pod spodem. Dajemy obraz techniczny w formacie, który wchodzi do dokumentacji transakcyjnej - z rejestrem zobowiązań i widełkami kosztu utrzymania na dwa lata.

  • Zespoły produktowe z hamującą roadmapą

    Kwartalne plany domyka się w coraz mniejszym stopniu, choć zespół i zakres zadań się nie zmieniły. Rozdzielamy przyczyny, które wyglądają identycznie z zewnątrz - architekturę, która wymusza zmiany w wielu miejscach naraz, brak testów odbierający odwagę i proces wydawania, który sam zjada dni.

  • Firmy z systemem napisanym wewnętrznie przez jedną osobę

    System obsługuje codzienną pracę firmy, działa od lat i ma dokładnie jednego człowieka, który wie, jak go uruchomić. Audyt opisuje ten stan bez oceniania autora - co jest udokumentowane, co trzeba odtworzyć i w jakiej kolejności przekazywać obszary, żeby odejście tej osoby nie zatrzymało operacji.

Wydruki czterech układów interfejsu na stole: pulpit, ekran telefonu, formularz i tabela, jeden blok zakreślony markerem

Nasza różnica

Czym różni się nasze podejście

  • Audyt pod decyzję produktową, nie test penetracyjny

    Jesteśmy agencją UX z zapleczem developerskim i badamy jedną rzecz - czy na tym kodzie da się budować dalej i ile to będzie kosztować w czasie zespołu. Testy penetracyjne, audyt zgodności z normami bezpieczeństwa i przegląd infrastruktury pod kątem ataku to inna specjalizacja; sprawdzamy oczywiste zaniedbania, a przy realnej potrzebie wskazujemy zespół, który się tym zajmuje zawodowo.

  • Dług wyceniony w dniach pracy, nie w etykietach

    Ocena „wysoki priorytet" nie mówi zarządowi nic, czego nie wiedział. Każda pozycja rejestru dostaje szacunek, ile dni zespołu zjada rocznie i co konkretnie blokuje w planach, więc rozmowa o kolejności napraw toczy się w tej samej walucie co rozmowa o roadmapie.

  • Kod czytamy tam, gdzie repozytorium pokazuje ruch

    Przegląd losowo wybranych plików mówi o produkcie tyle, co otwarcie książki na chybił trafił. Historia zmian wskazuje obszary, przez które przechodzi większość pracy zespołu, i to one dostają najwięcej naszej uwagi - bo tam każda przyszła zmiana będzie kosztować najwięcej.

  • Werdykt powstaje przed rozmową o wdrożeniu

    Rekomendacja nie zależy od tego, czy potem dostaniemy zlecenie na przebudowę. Jeśli z badania wychodzi, że stack jest zdrowy, a problem leży w procesie albo w liczbie osób, zapisujemy dokładnie to - łącznie ze scenariuszem, w którym nie robicie z nami nic poza tym audytem.

Proces

15 dni roboczych od dostępów do werdyktu

  1. Dzień 1–2

    Zakres i dostępy

    Ustalamy, co wchodzi do badania - które repozytoria, środowiska i integracje. Bierzemy dostęp do odczytu, dokumentację, jaka istnieje, i listę osób, które odpowiadają za poszczególne obszary.

  2. Dzień 2–5

    Architektura i zależności

    Mapujemy podział na moduły i usługi, granice odpowiedzialności, sposób trzymania danych i punkty styku z systemami zewnętrznymi. Osobno idzie przegląd bibliotek - wersje, tempo aktualizacji, daty końca wsparcia i znane podatności.

  3. Dzień 4–8

    Kod tam, gdzie zmienia się najczęściej

    Historia repozytorium wskazuje pliki o największym ruchu - to tam czytamy kod najuważniej, bo każda kolejna zmiana będzie przechodzić właśnie przez nie. Sprawdzamy pokrycie testami, powtórzenia i miejsca, w których jedna poprawka wymusza pięć następnych.

  4. Dzień 7–11

    Wydajność i droga na produkcję

    Mierzymy zachowanie produktu u realnych użytkowników i w warunkach laboratoryjnych, sprawdzamy zachowanie przy większym obciążeniu oraz to, jak długo trwa przejście zmiany od zatwierdzenia do produkcji i co się dzieje, gdy trzeba ją wycofać.

  5. Dzień 9–12

    Rozmowy z zespołem

    Godzina z każdą osobą, która utrzymuje produkt na co dzień. Pytamy, gdzie praca się zacina, czego wszyscy unikają i co według nich pęknie przy dziesięciokrotnym ruchu. Te odpowiedzi zwykle celują lepiej niż jakikolwiek automat.

  6. Dzień 12–15

    Werdykt i sesja decyzyjna

    Składamy raport, rejestr długu i trzy scenariusze, a potem prowadzimy dwugodzinną sesję z zespołem technicznym i osobą decydującą o budżecie. Wychodzicie z wybraną drogą, nie z materiałem do przemyślenia.

Zakres

Trzy dokumenty, z których pierwszy zaczyna się od werdyktu

  • Raport z jednoznaczną rekomendacją

    Pierwsze zdanie raportu mówi wprost, co robić dalej - rozwijać obecny stack, wymienić wskazany moduł albo przenieść produkt na inny fundament. Reszta to uzasadnienie: mapa architektury, zależności z datą końca wsparcia, miejsca o największym ruchu w repozytorium i wyniki pomiarów wydajności.

  • Rejestr długu wyceniony w dniach zespołu

    Każda pozycja opisana tym, co realnie blokuje - ile dni pracy zjada w skali roku, którą pozycję z roadmapy powstrzymuje i co się stanie, jeśli przeleży kolejny rok nietknięta. Arkusz sortuje się po koszcie, nie po etykiecie „krytyczne", więc wchodzi prosto na planowanie kwartału.

  • Trzy drogi z policzonymi konsekwencjami

    Rozwijanie obecnego kodu, wymiana wybranych modułów i przeniesienie produktu na nowy fundament - każda droga z horyzontem czasowym, ryzykiem i listą rzeczy, których przy niej nie zrobicie. Liczymy je na dwa lata, bo w krótszym oknie łatanie zawsze wygląda na tańsze, niż jest.

Warsztat

Co stosujemy

Publiczne mierniki i standardy zamiast autorskiej skali punktowej - chodzi o to, żebyście mogli powtórzyć nasz pomiar bez nas i za pół roku porównać wynik.

Blat warsztatowy z góry: dwa wydruki układu interfejsu, lupa powiększająca jeden blok, stalowa linijka i wzornik szarości od bieli do czerni, jedna linia podkreślona pomarańczowym markerem
  • Core Web Vitals - LCP, INP, CLS
  • Lighthouse i WebPageTest
  • Cztery mierniki DORA
  • ISO/IEC 25010 - charakterystyki jakości
  • Analiza historii repozytorium
  • Przegląd zależności i znanych podatności

Następny krok

Porozmawiajmy o Waszym projekcie

Powiedzcie, co macie do zrobienia. Wracamy z zakresem i wyceną.

Bezpłatna konsultacja Projekty

Realizacje

Realizacje z produktów, które audytujemy

Przekrój aplikacji webowych, paneli i serwisów firmowych, czyli produktów, przy których najczęściej oceniamy stack przed decyzją o budowie. Same raporty opisują kod klienta, więc pokazujemy je wyłącznie na konsultacji.

Projekty

Efekty

Co zostaje po audycie i w jakim terminie

  • 15–20 dni

    Dni roboczych od przekazania dostępów do werdyktu i sesji decyzyjnej - kilka repozytoriów albo aplikacja natywna obok webu przesuwają termin w stronę dwudziestu

  • 3

    Scenariusze techniczne na wyjściu, każdy z horyzontem, ryzykiem i listą rzeczy, których przy nim nie zrobicie

  • 2 lata

    Horyzont, na jaki liczymy koszt każdego scenariusza, bo w krótszym oknie łatanie zawsze wygląda na tańsze niż wymiana

  • Core Web Vitals

    Publiczny zestaw mierników Google, którym opisujemy wydajność u realnych użytkowników, nie tylko w pojedynczym uruchomieniu Lighthouse

Terminy, liczba scenariuszy i horyzont wyliczeń pochodzą z zakresu i harmonogramu opisanych wyżej na tej stronie; Core Web Vitals to publiczny standard Google. Wyników z konkretnych audytów nie podajemy - raport wraz z rejestrem długu jest dokumentem klienta i opisuje jego kod, więc fragmenty pokazujemy imiennie na konsultacji.

Opinie klientów

Co mówią nasi klienci

  • „Praca z zespołem Wzór była naprawdę świetnym doświadczeniem! Zawsze szybko odpowiadali na nasze pytania i elastycznie podchodzili do naszych uwag. Mają mnóstwo kreatywnych pomysłów, a jednocześnie są bardzo rzetelni i terminowi. Efekt końcowy w pełni spełnił nasze oczekiwania, zdecydowanie polecamy każdemu, kto szuka profesjonalistów z pasją.”
    Maja Wieloch-Silecka Dyrektor operacyjny, Bosfor Group
  • „Nasi Klienci oczekują od nas szybkiego, skutecznego działania w bardzo szerokim zakresie. Od stworzenia brandu, przez budowę strony internetowej wraz ze sklepem po przeprowadzenie skutecznej kampanii sprzedażowej. Temat niełatwy, ale do zrobienia jeśli ma się zgrany zespół i firmy, z którymi wyzwania bierze się z marszu. Dla nas jakość, odpowiedzialność i zaangażowanie są kluczowe, a współpraca z Agencją UX Wzór zapewnia nam to w 100%.”
    Piotr Alberski Chief Operating Officer, Agencja XO Media
  • „Współpraca z Agencją UX Wzór rozpoczęła się od naszej strony internetowej. Bardzo spodobał się nam sposób ich pracy. Dlatego podjęliśmy decyzję o podzlecaniu projektów realizowanych dla naszych Klientów w formie White Label. Bardzo spodobał nam się ich flow pracy, przekazywanie projektów naszemu zespołowi, ich dokumentacja czy praca na design systemie. Teraz możemy podejmować większe ryzyko.”
    Mateusz Swół Chief Operating Officer, Sellace

Czas i zakres

Ile trwa audyt i od czego zależy wycena

15–20 dni roboczych

Piętnaście dni wystarcza przy jednym produkcie w jednym repozytorium, z dostępem do środowiska testowego i danych o wydajności. Rozbicie na kilka usług, aplikacja natywna obok webu albo brak jakiejkolwiek dokumentacji przesuwają termin w stronę dwudziestu dni - wtedy pierwszy tydzień idzie na odtworzenie obrazu, który normalnie dostajemy na starcie.

  • Liczba repozytoriów, usług i integracji w zakresie

  • Wielkość kodu i wiek produktu liczony w latach zmian

  • Zakres dostępu - odczyt repozytorium, środowiska testowe, dane o wydajności

  • Platformy w zakresie - web, aplikacja natywna, warstwa danych

  • Liczba rozmów z zespołem utrzymującym produkt

  • To, czy scenariusze mają obejmować migrację danych

Pytania

Pytania, które padają najczęściej

Ile kosztuje audyt techniczny?

Wycena zależy od kilku rzeczy - liczby repozytoriów i usług w zakresie, wieku produktu liczonego w latach zmian, tego, czy dostajemy dostęp do środowiska testowego i danych o wydajności, liczby platform (sam web czy web razem z aplikacją natywną) oraz tego, czy scenariusze mają obejmować migrację danych. Zakres ustalamy na trzydziestominutowej rozmowie, a wycenę razem z harmonogramem odsyłamy w dwa dni robocze. Umów rozmowę - powiemy też, jeśli w Waszym przypadku wystarczy węższy przegląd.

Czy to jest audyt bezpieczeństwa?

Nie. Jesteśmy agencją UX z zapleczem developerskim i badamy zdatność produktu do dalszej budowy, nie odporność na atak. Sprawdzamy rzeczy, których nie da się przeoczyć przy czytaniu kodu - biblioteki ze znanymi podatnościami, sekrety trzymane w repozytorium, brak kontroli dostępu w oczywistych miejscach - ale testy penetracyjne i audyt zgodności z normami bezpieczeństwa zlecajcie zespołowi, który robi wyłącznie to. Chętnie wskażemy taki na konsultacji.

Czy musimy dać wam dostęp do kodu?

Do pełnego werdyktu tak - wystarczy dostęp do odczytu repozytorium i środowiska testowego. Bez kodu da się zbadać warstwę zewnętrzną, czyli wydajność u użytkowników, zachowanie interfejsów programistycznych, obserwowalność i drogę wydania, ale wtedy o architekturze i o długu mówimy z poszlak, a nie z pomiaru. Mówimy o tym wprost na starcie, żeby nikt nie oczekiwał rekomendacji mocniejszej, niż pozwala materiał.

Czy powiecie nam, że trzeba przepisać wszystko?

Rzadko taki werdykt wychodzi. Najczęściej okazuje się, że problem koncentruje się w jednym albo dwóch obszarach, przez które przechodzi większość zmian, a reszta kodu spokojnie wytrzyma kolejne lata. Jeśli natomiast z pomiarów wyjdzie, że fundament nie udźwignie planów, napiszemy to bez łagodzenia - razem z ceną takiej decyzji i z tym, co tracicie w trakcie przenosin.

Czym to się różni od audytu UX?

Innym pytaniem i innym materiałem. Audyt UX ocenia, czy użytkownik dochodzi do celu, i patrzy na produkt od strony ekranu. Audyt techniczny ocenia, czy da się na tym budować dalej, i patrzy od strony repozytorium, architektury i pomiarów wydajności. Bywa, że jeden problem widać w obu - wolna lista produktów to jednocześnie porzucenie ścieżki i zapytanie do bazy bez indeksu.

Kto prowadzi audyt po waszej stronie?

Developer senior czyta kod, mierzy wydajność i rozmawia z Waszym zespołem, a osoba odpowiadająca za produkt przekłada jego wnioski na konsekwencje dla roadmapy i budżetu. Dzięki temu raport nie jest listą uwag technicznych, tylko materiałem, z którym da się wejść na zarząd. Skład znacie przed startem, z nazwiska.

Mamy tylko ofertę od software house'u - da się ocenić sam stack z dokumentacji?

Da się ocenić propozycję, ale to inne badanie niż audyt istniejącego produktu. Sprawdzamy wtedy, czy zaproponowane technologie pasują do skali i tempa zmian, jakie zakładacie, gdzie oferta przemilcza koszty utrzymania i jakie pytania zadać wykonawcy przed podpisem. Wynik jest krótszy i idzie szybciej, bo nie ma czego mierzyć - jest tylko co porównać z planem.

Czy wdrażacie potem rekomendacje?

Możemy, ale to osobna umowa i osobna decyzja. Werdykt powstaje przed jakąkolwiek rozmową o wdrożeniu, więc scenariusz „poprawiacie to własnym zespołem" jest w raporcie traktowany na równi z pozostałymi. Część klientów zabiera rejestr długu do swojego zespołu i wraca po pół roku na powtórny pomiar tych samych mierników - to też jest dobry sposób na korzystanie z tego dokumentu.

Powiązane usługi

Powiązane usługi

Umów bezpłatną konsultację z ekspertem, aby omówić Twój projekt i otrzymać odpowiedzi na nurtujące Cię pytania.

- Patryk Korycki, CEO

Zaplanuj spotkanie
Umów bezpłatną konsultację