Najbardziej ryzykowny moment we współpracy przy sklepie internetowym rzadko wygląda groźnie.

Nowa firma lub freelancer prosi o dostęp do WordPressa, FTP, hostingu, płatności, wysyłek albo kopii bazy i mówi, że „sprawdzi temat”. Technicznie da się tak zacząć, ale przy działającym sklepie to zbyt kruche wejście w projekt.

Sklep, który już sprzedaje, nie jest pustą stroną do zabawy. Są tam zamówienia, dane klientów, integracje, płatności, logi, konfiguracje wysyłek, kody rabatowe, automatyczne maile i historia decyzji, które wpływają na sprzedaż. Jeden nieuważny test potrafi wysłać wiadomość do klienta. Jedna źle przygotowana kopia bazy potrafi wynieść dane tam, gdzie nie powinny trafić. Jeden szybki fix na produkcji potrafi zatrzymać checkout w piątek po południu.

W GeekRoom.pl zaczynamy inaczej. Przed wejściem w wdrożenie albo przejęcie rozwoju sklepu porządkujemy zakres dostępu, zasady pracy na danych i środowiska techniczne. Nie robimy tego dla dokumentów. Robimy to po to, żeby chronić sklep, klientów sklepu i relację z właścicielem biznesu.

Sklep, który działa, nie jest placem budowy

Przy nowym wdrożeniu można zacząć od pustego repozytorium, makiet i decyzji technicznych. Przy istniejącym sklepie sytuacja jest inna.

Istniejący WooCommerce ma już swoje życie. Nawet gdy działa źle, nadal przyjmuje zamówienia, obsługuje płatności, zbiera dane, komunikuje się z klientami i łączy się z zewnętrznymi systemami. Dlatego najpierw trzeba go zrozumieć.

Przejęcie rozwoju sklepu zaczyna się od diagnozy, a nie od przepisywania kodu.

Sprawdzamy, gdzie sklep zarabia, gdzie traci tempo, które integracje są krytyczne, jak wygląda proces zamówienia, co dzieje się po zakupie i które miejsca są zbyt ryzykowne, żeby dotykać ich bez przygotowania. Dopiero potem powstaje sensowna lista prac.

Przy sklepie z realnym ruchem każda zmiana techniczna ma kontekst biznesowy. Poprawka w checkoutcie może dotknąć konwersji, zmiana w płatnościach przychodu, a błąd w wysyłce maili transakcyjnych zaufania klientów.

Dlaczego NDA i powierzenie danych są u nas na początku

NDA kojarzy się często z formalnością przed przekazaniem poufnych informacji. Przy sklepie internetowym to za wąskie spojrzenie.

W praktyce dostęp do sklepu oznacza kontakt z wieloma rzeczami, które powinny zostać chronione. Nie chodzi tylko o hasła. W tym pakiecie są klucze API, tokeny, konfiguracje serwera, ustawienia wtyczek, fragmenty kodu, kopie baz danych, logi, eksporty, dane o zamówieniach, reklamacje, zwroty, faktury, marże, kampanie reklamowe i plany rozwoju.

W naszej umowie NDA i RODO opisujemy, po co w ogóle dostajemy dostęp do tych informacji. Korzystamy z nich wyłącznie do wykonania ustalonych prac programistycznych, testowych, diagnostycznych, utrzymaniowych, wdrożeniowych lub związanych z dalszym rozwojem sklepu.

To ma znaczenie także po stronie klienta. Właściciel sklepu wie, jakie dane przekazuje, po co są potrzebne i gdzie kończy się nasza rola. Klient zostaje administratorem danych, a GeekRoom.pl działa jako podmiot przetwarzający dane w zakresie potrzebnym do wykonania prac.

Taka umowa nie zastępuje oferty ani umowy wdrożeniowej, więc nie opisuje ceny, harmonogramu i zakresu projektu. Jej zadaniem jest uporządkowanie zasad wejścia w system przed realną pracą.

Zasada minimalizacji danych

Najprostsza dobra praktyka polega na tym, że nie bierzemy więcej danych, niż potrzebujemy.

Zadanie, które da się wykonać na danych testowych, robimy bez kopii produkcji. Gdy kopia produkcji jest potrzebna, ograniczamy w niej dane osobowe, a testy zamówień opieramy na zamówieniach testowych albo zanonimizowanych rekordach.

Anonimizacja oznacza, że usuwamy lub zmieniamy dane, które pozwalają rozpoznać konkretną osobę. W sklepie WooCommerce chodzi między innymi o imiona, nazwiska, adresy e-mail, telefony, adresy rozliczeniowe, adresy wysyłki, adresy IP, notatki do zamówień, logi i dane kont użytkowników.

Nie kasujemy historii zamówień z prawdziwego sklepu, tylko pracujemy na kopii przeznaczonej do testów. Produkcja zostaje produkcją.

W NDA zapisujemy też zasadę, że pełna produkcyjna baza danych nie powinna być wynoszona poza serwer klienta przed anonimizacją albo usunięciem danych osobowych. Wyraźne, udokumentowane polecenie klienta jest wyjątkiem od tej zasady, więc odpowiedzialność nie zostaje w domyśle.

Produkcja, staging i dev: po co są trzy środowiska

Jednym z pierwszych technicznych kroków jest oddzielenie miejsc pracy.

Produkcja to prawdziwy sklep, w którym klient kupuje, płaci i dostaje maile, a zewnętrzne systemy odbierają webhooki. Pomysły testowane metodą „zobaczmy, czy zadziała” nie powinny trafiać w takie miejsce.

Staging, czasem nazywany stage, to kopia sklepu możliwie bliska produkcji. Służy do sprawdzania zmian przed publikacją. Można tam przejść checkout, obejrzeć nowy widok, przetestować integrację, pokazać klientowi etap prac i złapać błąd przed wejściem na żywy sklep.

Dev to środowisko developerskie, w którym powstaje kod i pierwsze wersje zmian. Może działać lokalnie u programisty albo na osobnym serwerze. Nie musi wyglądać idealnie jak produkcja, ale ma dawać bezpieczne miejsce do budowania, testowania i sprawdzania technicznych hipotez.

Te trzy warstwy chronią tempo pracy. Programista nie dotyka produkcji przy każdej małej zmianie, a klient może zobaczyć postęp przed publikacją. Ryzyko zostaje zamknięte wcześniej, zamiast trafiać od razu na żywy sklep.

Co wyłączamy na stagingu

Staging ma być podobny do produkcji, ale nie może zachowywać się jak produkcja w kontakcie ze światem.

Dlatego po skopiowaniu sklepu pilnujemy, żeby środowisko testowe nie wysyłało przypadkowych wiadomości do klientów, nie odpalało prawdziwych płatności, nie uruchamiało produkcyjnych webhooków i nie przekazywało testowych danych do zewnętrznych systemów.

To brzmi jak detal techniczny, dopóki testowy sklep nie wyśle klientowi maila o fikcyjnym zamówieniu albo nie zgłosi testowej transakcji do systemu księgowego.

W praktyce oznacza to między innymi kontrolę maili transakcyjnych, tryb testowy płatności, odpięcie lub ograniczenie integracji oraz zabezpieczenie stage i dev przed publicznym dostępem. Hasła, tokeny i klucze API nie trafiają do publicznych repozytoriów ani przypadkowych narzędzi.

Co dzieje się z kopiami baz i plikami roboczymi

Przy pracy nad WooCommerce czasem trzeba stworzyć kopię bazy, eksport, paczkę plików albo techniczny zrzut danych. Sam fakt tworzenia takich materiałów nie jest problemem. Problem zaczyna się wtedy, gdy nikt nie wie, gdzie te pliki leżą, kto ma do nich dostęp i jak długo zostają.

W naszym standardzie tymczasowe kopie, eksporty i pliki robocze zawierające dane osobowe są przechowywane tylko przez czas potrzebny do wykonania prac. Po zakończeniu zadań usuwamy je albo zwracamy zgodnie z ustaleniami. W umowie wpisujemy termin 14 dni dla tymczasowych eksportów, kopii roboczych i plików testowych, o ile strony nie ustalą inaczej.

To porządkuje coś, co w projektach technicznych łatwo się rozlewa. Najpierw powstaje eksport do debugowania, potem kopia do testu, a później jeszcze plik w narzędziu do migracji. Bez jasnych zasad po miesiącu trudno odtworzyć, co naprawdę zostało po drodze.

Co to zmienia przy przejęciu rozwoju sklepu

Przejęcie rozwoju istniejącego sklepu bywa trudniejsze niż nowe wdrożenie. W nowym projekcie decyzje techniczne powstają od zera. W przejmowanym sklepie trzeba najpierw zrozumieć decyzje podjęte wcześniej.

Nie zakładamy automatycznie, że wszystko trzeba przepisać. Istniejący sklep jest aktywem, więc sprawdzamy, które elementy działają dobrze, które tylko wyglądają na bezpieczne, a które blokują dalszy rozwój.

W pierwszym etapie patrzymy na kod, wtyczki, hosting, proces zakupowy, wydajność, integracje, dane, logi i sposób pracy zespołu po stronie klienta. Interesuje nas nie tylko to, czy sklep działa dzisiaj. Interesuje nas też to, czy da się go rozwijać bez ciągłego gaszenia problemów.

Osobne środowiska pomagają właśnie tutaj. Błąd można odtworzyć bez ryzyka dla kupujących, aktualizację wtyczki sprawdzić przed publikacją, a zmianę w checkoutcie przepuścić przez test na kopii, zanim dotknie realnych zamówień.

Co to daje właścicielowi sklepu

Ten proces nie jest po to, żeby wyglądać poważniej w dokumentach.

Ma dać właścicielowi sklepu kilka bardzo konkretnych rzeczy:

• mniejsze ryzyko pracy na żywym sklepie,
• jasność, kto i po co ma dostęp do danych,
• oddzielenie testów od realnych zamówień,
• spokojniejsze wdrażanie zmian,
• lepszą kontrolę nad integracjami,
• mniej przypadkowych decyzji technicznych,
• podstawę do dłuższej współpracy sprintowej.

Dobre wejście w projekt zmienia też rozmowę o zakresie. Zamiast listy luźnych życzeń powstaje kolejność prac. Łatwiej ustalić, co trzeba zabezpieczyć od razu, co może poczekać do kolejnego sprintu, czego jeszcze nie dotykać i które zmiany mają realny wpływ na sprzedaż.

Tak rozumiemy partnerstwo przy WooCommerce. Najpierw trzeba zrozumieć, jaki sklep już masz, co w nim działa i gdzie technologia zaczyna ograniczać wzrost. Dopiero potem uczciwie rozmawia się o nowym sklepie albo dalszym rozwoju.

A co z case study po projekcie?

Zasady opisania projektu też ustalamy zawczasu.

Możemy opisać techniczne i organizacyjne elementy współpracy, ale bez ujawniania poufnych informacji klienta. Publiczne dane, czas ładowania strony, wyniki Core Web Vitals albo opis widocznych zmian w sklepie to inna kategoria niż przychody, marże, liczba klientów, dane z panelu, systemów płatności czy narzędzi analitycznych.

Użycie nazwy, logo, cytatu, screenów z panelu albo materiałów niewidocznych publicznie wymaga wcześniejszej akceptacji klienta. To uczciwe wobec obu stron. GeekRoom.pl może pokazać jakość pracy, a klient nie ryzykuje ujawnienia informacji, które nie powinny wychodzić poza projekt.

Dobry start jest częścią jakości wdrożenia

Sklep WooCommerce nie powstaje dopiero na etapie frontendu, stabilność nie zaczyna się dopiero przy testach, a dobra współpraca nie czeka na właściwą umowę wdrożeniową.

Jakość zaczyna się wcześniej, od sposobu przekazania dostępów, ochrony danych, przygotowania stagingu i dev oraz decyzji, czego nie wolno robić na produkcji.

To mało widowiskowy etap i nie daje efektu „wow” na stronie głównej. Daje za to mniejsze ryzyko, większy porządek i sklep, który można rozwijać bez napięcia przy każdej publikacji.

Jeżeli myślisz o nowym wdrożeniu WooCommerce albo chcesz przekazać istniejący sklep pod dalszy rozwój, zacznijmy od tego, jak sklep działa dzisiaj, gdzie jest ryzyko i jak bezpiecznie wejść w projekt. Lista funkcji ma sens dopiero po takim rozpoznaniu.