Rozwój i wsparcie techniczne projektów po wdrożeniu

Proces rozwoju projektu

Uruchomienie pierwszej wersji projektu nie oznacza końca prac. Potrzeby firmy zmieniają się wraz ze wzrostem sprzedaży, pojawianiem się nowych klientów, zmianami procesów wewnętrznych, kolejnymi kampaniami, rebrandingiem czy wejściem na nowe rynki. Dlatego działający sklep, aplikacja lub system może być rozwijany przez kolejne miesiące i lata.

W Sopchy rozwijamy zarówno projekty, które stworzyliśmy od początku, jak i istniejące rozwiązania przejęte po innych software house'ach lub programistach. Najczęściej rozwój obejmuje nowe funkcje i integracje, które nie były potrzebne na etapie MVP albo zostały świadomie odłożone na później. W zależności od projektu pracujemy również nad UX, wydajnością, aktualizacjami technologicznymi, automatyzacją procesów, migracjami i problemami technicznymi.

Prace programistyczne realizuje własny, wewnętrzny zespół Sopchy. Nie zlecamy developmentu na zewnątrz. Klient ma stałego PM-a, może komunikować się z zespołem przez panel Sopchy, e-mail i telefon, a przy większych projektach regularnie omawiamy postęp prac i kolejne decyzje. Dzięki temu rozwój projektu nie jest przekazywany pomiędzy przypadkowymi wykonawcami, a klient ma jedno miejsce kontaktu i wiedzę o tym, co aktualnie dzieje się z projektem.

1. Zaczynamy od celu, a nie od funkcji

Pierwsze pytanie, które zadajemy przy nowym zadaniu, brzmi: „Po co chcesz to zrobić?”. Klient nie musi znać rozwiązania technicznego. Ważniejsze jest dla nas zrozumienie problemu albo efektu, który chce osiągnąć.

Ma to znaczenie, ponieważ ten sam cel biznesowy można osiągnąć na kilka sposobów. Rozwiązanie wskazane przez klienta nie zawsze jest rozwiązaniem, którego rzeczywiście potrzebuje firma. Najpierw chcemy więc zrozumieć, jaki problem ma zostać rozwiązany i co ma się zmienić po wykonaniu prac.

Przykładowo klient może powiedzieć: „Chcemy zwiększyć wartość koszyka i dlatego chcemy dodać możliwość tworzenia zestawów produktów.”

W takim przypadku nie zaczynamy od szukania modułu do zestawów produktów. Najpierw ustalamy, jak ma działać sprzedaż zestawów, dla kogo jest przeznaczona, jakie produkty mają być ze sobą łączone i jaki efekt biznesowy ma przynieść zmiana.

Dzięki temu firma nie płaci za wdrożenie funkcji tylko dlatego, że wydaje się ona dobrym rozwiązaniem. Najpierw ustalamy, czy rzeczywiście odpowiada na problem, który firma chce rozwiązać.

Inny przykład to problem techniczny: „Zmieniliśmy cenę przesyłki InPost, ale nowa cena nie pojawia się w checkoutcie. Proszę to sprawdzić.”

Klient nie musi wiedzieć, czy problem znajduje się w konfiguracji sklepu, module płatności lub dostawy, integracji czy kodzie. Zadaniem Sopchy jest ustalenie przyczyny.

Dzięki temu klient nie musi sam diagnozować technologii ani wskazywać programiście miejsca, które należy zmienić. Może opisać efekt, który nie działa, a zespół sprawdza, gdzie znajduje się przyczyna.

Podobnie wygląda zgłoszenie związane z rozwojem rynku: „Chcemy rozpocząć sprzedaż na Litwie i potrzebujemy wersji litewskiej oraz obsługi lokalnej waluty.”

Dopiero po poznaniu celu możemy ustalić, jakie elementy sklepu trzeba zmienić i jak najlepiej to zrobić. Może to obejmować nie tylko tłumaczenie interfejsu, ale również walutę, ceny, płatności, dostawy, podatki, integracje czy sposób prezentowania informacji.

Zaczynanie od celu pozwala więc spojrzeć na zmianę z perspektywy całego procesu, a nie tylko pojedynczej funkcji.

2. Analizujemy problem i dobieramy rozwiązanie

Kiedy znamy cel, sprawdzamy, w jaki sposób można go osiągnąć.

Nie zakładamy automatycznie, że rozwiązanie zaproponowane przez klienta będzie najlepsze. Sprawdzamy jego wpływ na istniejący system, możliwość dalszego rozwoju, zależności z innymi elementami projektu oraz potencjalne problemy techniczne.

Jeśli klient wskazuje konkretny moduł, technologię lub sposób wykonania, sprawdzamy, czy rozwiązanie pasuje do istniejącego systemu i czy nie stworzy problemów przy dalszym rozwoju.

Jeżeli wiemy, że dany moduł ma problemy techniczne, złe opinie, ograniczenia albo może utrudnić późniejszy rozwój sklepu, informujemy o tym klienta. W razie potrzeby przedstawiamy alternatywne rozwiązania i wyjaśniamy różnice między nimi.

Ma to znaczenie szczególnie w przypadku sklepów i systemów, które mają działać przez wiele lat. Rozwiązanie, które jest szybkie i tanie do wdrożenia dzisiaj, może później zwiększyć koszt kolejnych zmian albo uzależnić projekt od technologii, której trudno będzie aktualizować.

Decyzja należy do klienta, ale powinna być podejmowana na podstawie informacji o kosztach, możliwościach, ograniczeniach i ryzyku technicznym.

Dlatego rozwój projektu w Sopchy nie polega wyłącznie na wykonywaniu poleceń. Naszym zadaniem jest również ocena, czy proponowane rozwiązanie ma sens w konkretnym projekcie i jakie mogą być jego konsekwencje dla dalszego rozwoju.

3. Weryfikujemy, z czym mamy do czynienia

Zakres analizy zależy od zadania.

Przy małej zmianie często wystarczy sprawdzić działający system, odtworzyć problem i ustalić, co trzeba zmienić. Nie ma potrzeby tworzenia rozbudowanej dokumentacji, jeśli problem można szybko zweryfikować bezpośrednio w projekcie.

To pozwala ograniczyć koszt prac przygotowawczych przy prostych zadaniach. Nie każda zmiana wymaga wielogodzinnej analizy tylko dlatego, że jest realizowana w istniejącym systemie.

Przy większej zmianie potrzebujemy dokładniej poznać istniejące rozwiązanie. Możemy analizować dokumentację, kod, konfigurację, integracje i sposób działania systemu. Czytanie dokumentacji, testowanie i poznawanie projektu są częścią pracy potrzebnej do prawidłowego określenia zakresu.

W takim przypadku analiza pozwala sprawdzić, czy zakładany zakres jest zgodny z rzeczywistym stanem projektu. Ogranicza to ryzyko sytuacji, w której prace rozpoczynają się na podstawie założeń, a dopiero podczas developmentu okazuje się, że istnieją dodatkowe zależności lub ograniczenia.

Nowi klienci często trafiają do Sopchy z istniejącym projektem, którego dokumentacja jest ograniczona albo nie ma jej wcale. W takich sytuacjach nie wymagamy przeprowadzenia pełnego audytu przed rozpoczęciem współpracy. Możemy zacząć od konkretnych zadań testowych i poznawać projekt podczas rzeczywistej pracy.

Jest to istotne dla firm, które chcą szybko rozwiązać konkretny problem, ale nie chcą ponosić kosztu pełnego audytu, jeśli nie jest on potrzebny do rozpoczęcia prac.

Przykładowo, jeśli w sklepie PrestaShop nie działa mechanizm Omnibus, zaczynamy od sprawdzenia, jak został wdrożony, gdzie występuje problem i co trzeba zmienić. Nie zakładamy z góry, że potrzebny jest pełny audyt całego sklepu.

Jeżeli klient chce przeprowadzić osobny audyt techniczny przed rozpoczęciem dalszego rozwoju, możemy go również wykonać.

4. Proof of concept przed rozpoczęciem większych prac

W przypadku nowych klientów pierwsza analiza często odbywa się jeszcze przed oficjalnym rozpoczęciem współpracy. Jest to potrzebne wtedy, gdy musimy najpierw ustalić, z jakim systemem mamy do czynienia i czy zakładany zakres jest technicznie możliwy do wykonania.

Taka weryfikacja może obejmować analizę istniejącego rozwiązania, dokumentacji, konfiguracji, integracji lub konkretnego problemu technicznego. Jej celem jest również uzyskanie informacji potrzebnych do przygotowania realnej estymacji.

Dzięki temu estymacja większego zadania może być oparta na rzeczywistym stanie projektu, a nie wyłącznie na opisie przygotowanym bez dostępu do systemu.

W przypadku większych zmian możemy również przygotować proof of concept, prototyp lub wizualizację rozwiązania. Pozwala to sprawdzić założenia przed rozpoczęciem pełnego developmentu.

Jest to szczególnie istotne wtedy, gdy błędna decyzja na początku projektu mogłaby oznaczać wykonanie dużej ilości kodu, którego później trzeba byłoby zmieniać lub usuwać.

Dotyczy to między innymi kluczowych mechanik aplikacji, panelu klienta, karty produktu, sekcji hero czy innych elementów, których sposób działania lub prezentacja mają istotne znaczenie dla projektu.

Do szybkiego prototypowania możemy wykorzystywać również narzędzia AI. AI pomaga nam szybciej uporządkować informacje, przygotować opis funkcji, rozpisać ścieżki użytkowników lub stworzyć pierwszą wizualizację pomysłu. Nie zastępuje jednak analizy ani decyzji zespołu. Jest narzędziem wspierającym pracę.

Dzięki temu możemy szybciej przejść od pomysłu do pierwszej wersji rozwiązania i wcześniej sprawdzić, czy założenia wymagają zmiany.

5. Małe, średnie i duże zmiany wymagają innego podejścia

Nie każde zadanie wymaga takiego samego procesu.

Mała zmiana może polegać na poprawieniu istniejącej funkcji, konfiguracji lub błędu. Jeśli jej zakres jest jasny, możemy szybko ją zweryfikować, wyestymować i rozpocząć realizację.

Przy takich zadaniach rozbudowany proces przygotowawczy mógłby być niewspółmierny do wartości samej zmiany. Dlatego przy prostych pracach staramy się przejść szybko od zgłoszenia do realizacji.

Średnia zmiana może wymagać dokładniejszej analizy, sprawdzenia kilku rozwiązań, aktualizacji dokumentacji, przygotowania projektu UX albo konsultacji technicznej.

Duża zmiana może wymagać osobnej analizy, proof of concept, prototypu, szczegółowej specyfikacji, oceny zależności z innymi elementami systemu, estymacji i zaplanowania prac w kolejnych etapach.

Dzięki temu poziom analizy jest dopasowany do rzeczywistego ryzyka i wielkości zadania. Nie rozbudowujemy procesu przy prostych zmianach, ale też nie zaczynamy dużego developmentu bez sprawdzenia kluczowych założeń.

Dla firmy oznacza to proporcjonalne podejście do kosztu przygotowania prac. Prosta poprawka nie wymaga takiego samego procesu jak przebudowa dużej części systemu.

6. Ustalamy zakres, priorytet i estymację

Po analizie określamy, co dokładnie trzeba zrobić, ile pracy wymaga zmiana i jakie zadania są od siebie zależne.

Klient określa priorytet biznesowy. Jeżeli jednak kolejność prac wynika również z zależności technicznych, informujemy o tym i rekomendujemy odpowiednią kolejność.

Przykładowo nowa funkcja może wymagać wcześniejszej zmiany sposobu przechowywania danych albo przygotowania API. W takiej sytuacji nie realizujemy zadań wyłącznie według kolejności ich zgłoszenia, ale uwzględniamy zależności techniczne.

Pozwala to uniknąć sytuacji, w której wykonanie jednej funkcji blokuje kolejne prace albo powoduje konieczność ponownego przebudowania wcześniej wykonanych elementów.

Przy większych zadaniach przygotowujemy estymację. Estymacja określa przewidywany nakład pracy na podstawie informacji dostępnych na etapie planowania. Nie traktujemy jej jako gwarancji, jeśli rzeczywisty stan systemu może ujawnić dodatkowe zależności.

Jeśli podczas realizacji okaże się, że rzeczywisty zakres jest większy niż wynikało z początkowej analizy, informujemy klienta o różnicy i wspólnie ustalamy dalsze działania.

Dzięki temu klient może zdecydować, czy chce kontynuować dodatkowe prace, zmienić zakres czy podzielić zadanie na kolejne etapy.

7. Rozwój zaczyna się również od rzeczy odłożonych poza MVP

Nie wszystkie funkcje muszą powstać w pierwszej wersji projektu.

Podczas tworzenia MVP wspólnie określamy zakres niezbędny do uruchomienia rozwiązania. Kolejne funkcje mogą zostać zapisane jako elementy dalszego rozwoju.

Takie podejście pozwala uruchomić projekt bez konieczności finansowania i wdrażania wszystkich planowanych funkcji jednocześnie. Firma może zacząć korzystać z rozwiązania, a kolejne elementy dodawać wtedy, gdy pojawi się na nie rzeczywista potrzeba.

Po wdrożeniu klient może więc wrócić do rzeczy, które wcześniej zostały odłożone, ponieważ nie były konieczne do uruchomienia projektu. Mogą to być nowe funkcje sklepu, dodatkowe automatyzacje, rozwój B2B, nowe integracje, kolejne wersje językowe czy zmiany w procesie zakupowym.

Wraz z rozwojem firmy pojawiają się również potrzeby, których nie można było przewidzieć na etapie MVP. Dzięki dalszemu rozwojowi nie trzeba traktować pierwotnego zakresu jako zamkniętego na zawsze.

8. Aktualizujemy projekt razem ze zmianami firmy

Rozwój systemu nie polega wyłącznie na dodawaniu nowych przycisków i funkcji.

Firma może zwiększyć budżet na kampanie, wejść na kolejny rynek, rozpocząć sprzedaż B2B, zmienić sposób obsługi zamówień, przejść rebranding, zmienić UX sklepu albo zacząć automatyzować procesy, które wcześniej wykonywał zespół ręcznie.

Wtedy zmienia się również system.

Ma to znaczenie, ponieważ rozwiązanie, które było odpowiednie przy mniejszej skali działalności, nie zawsze odpowiada potrzebom firmy po kilku latach. Rozwój technologii powinien wynikać ze zmian w sposobie działania firmy, a nie z samej potrzeby dodawania kolejnych funkcji.

Przykładowo rozwój może obejmować zwiększenie możliwości sprzedaży, dodatkowe funkcje cross-sell i up-sell, automatyzację pracy zespołu, zmianę prezentacji produktów, nowe wersje językowe i waluty, integracje z kolejnymi systemami albo przebudowę procesu zakupowego.

Dlatego nie traktujemy wdrożenia jako zamkniętego projektu, który pozostaje niezmienny przez kolejne lata. System powinien zmieniać się wtedy, gdy zmieniają się potrzeby firmy.

9. Rozwijamy funkcje i integracje

Najczęstszym zakresem prac po wdrożeniu są nowe funkcje i integracje.

W sklepie internetowym może to oznaczać między innymi: rozwój procesu zakupowego i checkoutu, funkcje B2B, nowe sposoby prezentacji i grupowania produktów, rozbudowę panelu administracyjnego, automatyzację obsługi zamówień, nowe metody płatności i dostawy, integracje z ERP, integracje z BaseLinkerem, integracje z magazynem, integracje z operatorami płatności, integracje z firmami kurierskimi, integracje z systemami fakturowania oraz integracje z marketplace'ami.

Takie integracje mogą ograniczać ręczne przepisywanie danych pomiędzy systemami, zmniejszać liczbę błędów i usprawniać obsługę zamówień, produktów, płatności czy dostaw. Ich zakres zależy od tego, jakie procesy firma chce zautomatyzować i jakie systemy wykorzystuje.

Jeżeli dostępny jest odpowiedni moduł lub API, możemy wykorzystać gotowe rozwiązanie. Jeżeli nie spełnia ono wymagań projektu, możliwe jest przygotowanie dedykowanego modułu, funkcji lub integracji.

Dobór pomiędzy gotowym rozwiązaniem a developmentem dedykowanym pozwala uwzględnić zarówno koszt wdrożenia, jak i wymagania konkretnego projektu oraz jego dalszy rozwój.

10. Nie rozwijamy projektu za wszelką cenę

Czasami analiza pokazuje, że istniejący system nie pozwala sensownie zrealizować celu klienta.

Przykładem może być klient, który chce wdrożyć rozbudowane funkcje B2B w istniejącym WooCommerce, ale sposób zbudowania obecnego sklepu uniemożliwia ich poprawne wdrożenie.

W takiej sytuacji nie próbujemy na siłę dopisywać funkcji do systemu, jeśli wiemy, że rozwiązanie będzie niestabilne, trudne w utrzymaniu albo ograniczy dalszy rozwój.

Ma to znaczenie dla firmy, ponieważ pozornie szybkie wdrożenie może później oznaczać większe koszty utrzymania, kolejne problemy techniczne albo konieczność przebudowy wykonanych wcześniej prac.

Najpierw informujemy klienta o problemie i sprawdzamy, czy można osiągnąć ten sam cel w inny sposób. Jeśli istnieje sensowna alternatywa, przedstawiamy ją. Jeśli nie, mówimy wprost, że w obecnym rozwiązaniu nie podejmiemy się realizacji zadania.

Dotyczy to również sytuacji, w których projekt wykorzystuje technologię spoza naszych kompetencji. Nie udajemy, że możemy zrealizować każde zadanie. Jeżeli nie jesteśmy w stanie zapewnić odpowiedniego rozwiązania, informujemy o tym klienta.

Dla klienta oznacza to jasną informację o granicach odpowiedzialności Sopchy i mniejsze ryzyko rozpoczęcia prac, których nie jesteśmy w stanie prawidłowo zakończyć.

11. UX rozwijamy na podstawie rzeczywistego używania projektu

Po wdrożeniu pojawiają się informacje, których nie da się zawsze przewidzieć na etapie projektowania.

Może się okazać, że użytkownicy nie korzystają z funkcji w zakładany sposób, określony etap procesu jest zbyt skomplikowany albo część informacji na karcie produktu powinna być prezentowana inaczej.

W takich sytuacjach analizujemy z klientem sposób działania obecnego rozwiązania i możliwe zmiany.

Dzięki temu rozwój UX może wynikać z rzeczywistego działania sklepu, a nie tylko z założeń przyjętych przed jego uruchomieniem.

Jeżeli zmiana jest większa, możemy przygotować prototyp lub wizualizację przed rozpoczęciem developmentu. Dzięki temu klient może zobaczyć, jak będzie wyglądać nowa karta produktu, panel klienta, hero albo główna mechanika aplikacji, zanim powstanie pełna funkcja.

Zmniejsza to ryzyko sytuacji, w której pełna funkcja zostanie zaprogramowana, a dopiero później okaże się, że sposób jej prezentacji lub obsługi wymaga istotnych zmian.

12. Sprawdzamy efekt po wdrożeniu

Testy techniczne odpowiadają na pytanie, czy funkcja działa. Przy większych zmianach ważne jest również pytanie, czy rozwiązała problem, dla którego została stworzona.

Jeżeli celem była naprawa błędu technicznego, sprawdzamy, czy problem nie występuje ponownie.

Jeżeli celem było zwiększenie sprzedaży lub wartości koszyka, efekt możemy analizować wspólnie z klientem, który obserwuje dane biznesowe. Możemy również analizować zachowanie użytkowników, np. sposób korzystania z karty produktu, i na tej podstawie planować kolejne zmiany.

Ma to znaczenie, ponieważ samo wdrożenie funkcji nie oznacza jeszcze osiągnięcia celu biznesowego. Funkcja może działać poprawnie technicznie, ale nie przynieść oczekiwanej zmiany w zachowaniu klientów.

Nie każda mała zmiana wymaga osobnego pomiaru efektu. Przy większych zmianach warto jednak sprawdzić nie tylko to, czy funkcja została wdrożona, ale również czy przyniosła zakładany efekt.

13. Monitorujemy działanie projektu

Rozwój istniejącego systemu obejmuje również reagowanie na problemy, które pojawiają się już po wdrożeniu.

Sopchy może monitorować dostępność serwisu niezależnie od technologii, na której został zbudowany.

Jeżeli monitoring wykryje niedostępność strony, powiadomienie może zostać wysłane jednocześnie do klienta i zespołu Sopchy. Po przywróceniu działania wysyłane jest kolejne powiadomienie informujące, że serwis ponownie działa.

Monitoring pozwala rozpocząć reakcję bez konieczności czekania, aż klient lub jego użytkownik zauważy problem. W przypadku sklepu internetowego ma to bezpośrednie znaczenie dla dostępności sprzedaży.

Przykładowo, jeśli sklep zaczyna zwracać błąd 500, monitoring informuje o problemie. Sprawdzamy logi, identyfikujemy element powodujący błąd, a jeśli to możliwe, przywracamy działanie sklepu, np. wyłączając problematyczny moduł. Następnie sprawdzamy, co należy naprawić, aby rozwiązanie mogło bezpiecznie wrócić do działania.

Jeżeli problem utrzymuje się dłużej, kontaktujemy się z klientem i potwierdzamy, czy po jego stronie nie są prowadzone prace lub zmiany. Jeśli klient od razu prosi o rozpoczęcie działań, przystępujemy do weryfikacji.

14. Reagujemy szybko, ale nie składamy nierealnych obietnic

Problemy techniczne nie zawsze można rozwiązać w kilka minut. Można jednak rozpocząć ich weryfikację od razu.

Jeżeli sprawa jest pilna, nie obiecujemy klientowi konkretnego czasu rozwiązania, którego nie możemy zagwarantować. Zaczynamy natomiast sprawdzać problem możliwie szybko i informujemy klienta, co robimy oraz kiedy możemy przekazać kolejne informacje.

Takie podejście pozwala połączyć szybkość reakcji z realistycznym określaniem terminów. Klient wie, że problem został zauważony i kiedy może oczekiwać kolejnej informacji, ale nie otrzymuje obietnicy czasu rozwiązania, którego nie da się jeszcze określić.

W standardowej pracy nowe zadania zwykle rozpoczynamy w ciągu 1-3 dni. Pilne problemy traktujemy priorytetowo.

W godzinach pracy klient może skontaktować się z nami telefonicznie. Na wiadomości e-mail odpowiadamy zwykle w ciągu kilku minut, a jeśli sprawa wymaga dłuższej analizy, informujemy, kiedy wrócimy z odpowiedzią.

15. Aktualizujemy technologię i reagujemy na zmiany bezpieczeństwa

Starszy projekt może wymagać aktualizacji platformy, frameworka, biblioteki lub innych elementów technologicznych.

Sopchy monitoruje informacje o dostępnych łatkach bezpieczeństwa dla systemów open source, dzięki czemu możemy informować klientów o potrzebnych aktualizacjach i podejmować decyzję o ich wdrożeniu bez czekania na wystąpienie infekcji lub awarii.

Regularne aktualizacje mają znaczenie nie tylko ze względu na bezpieczeństwo. Mogą również wpływać na kompatybilność z serwerem, modułami, integracjami i kolejnymi wersjami platformy.

Przed większą aktualizacją sprawdzamy stan projektu i zależności między jego elementami. Jeżeli aktualizacja może powodować problemy z istniejącymi modułami lub integracjami, uwzględniamy to w planie prac.

Dzięki temu firma może wcześniej zaplanować ryzykowną zmianę, zamiast reagować dopiero wtedy, gdy stara wersja przestanie działać lub pojawi się problem bezpieczeństwa.

W niektórych przypadkach dalsza aktualizacja istniejącego rozwiązania nie jest technicznie lub ekonomicznie uzasadniona. Wtedy porównujemy ją z możliwością przebudowy lub migracji do innego rozwiązania.

16. Przejmujemy istniejące projekty

Sopchy może rozpocząć rozwój projektu, który wcześniej tworzył inny software house lub programista.

Nie wymagamy, aby istniejący projekt miał kompletną dokumentację. Jeśli dokumentacja jest dostępna, analizujemy ją, ponieważ może przyspieszyć poznanie systemu. Jeżeli jej brakuje, poznajemy projekt poprzez rzeczywiste zadania.

Jest to istotne dla firm, które chcą zmienić wykonawcę, ale obawiają się, że brak dokumentacji uniemożliwi dalszy rozwój. Brak kompletnej dokumentacji nie musi być przeszkodą w rozpoczęciu współpracy.

Przy prostych zmianach możemy szybko wejść w konkretny problem. Przy dedykowanych rozwiązaniach analiza istniejącej dokumentacji, kodu i sposobu działania systemu może być ważnym elementem przygotowania do dalszych prac.

Jeżeli klient potrzebuje pełnego obrazu stanu technicznego projektu, możemy przeprowadzić osobny audyt. Nie jest on jednak wymagany w każdym przypadku.

Wspólnie z klientem ustalamy również, które problemy i ryzyka wymagają działania. Jeśli podczas pracy zauważymy element, który może utrudnić dalszy rozwój, informujemy o tym i ustalamy, czy klient chce, abyśmy się nim zajęli.

17. Prowadzimy bieżącą dokumentację zmian

W rozwijanym projekcie informacje o zmianach muszą pozostać aktualne.

Specyfikacja projektu może być aktualizowana wraz z kolejnymi zmianami. W przypadku większych zmian opisujemy nowe funkcje, zależności i sposób działania rozwiązania.

Zachowujemy również wcześniejsze wersje dokumentacji, aby można było sprawdzić, jak projekt wyglądał pierwotnie i jakie zmiany zostały wprowadzone później.

Ma to znaczenie szczególnie przy projektach rozwijanych przez wiele lat lub przez kilka osób. Aktualna dokumentacja ogranicza ryzyko podejmowania decyzji na podstawie nieaktualnych informacji, a historia zmian pozwala zrozumieć, dlaczego określone rozwiązania znalazły się w systemie.

Nie każda drobna poprawka wymaga aktualizacji całej specyfikacji. Zakres dokumentacji dopasowujemy do znaczenia zmiany.

Do porządkowania informacji możemy wykorzystywać również AI. Przykładowo, jeśli zespół ma informacje o funkcjach systemu i rolach użytkowników, AI może pomóc przekształcić je w uporządkowane ścieżki użytkowników lub przygotować pierwszy opis mechanizmu. Materiał nadal jest weryfikowany przez zespół.

18. Środowisko deweloperskie i wdrożenie

Większe zmiany wykonujemy na środowisku deweloperskim lub testowym, a nie bezpośrednio na produkcji.

Jest to szczególnie ważne w przypadku sklepów i systemów, które są używane przez klientów, pracowników lub obsługują płatności. Błąd wprowadzony bezpośrednio na produkcję może wpłynąć na sprzedaż lub działanie istniejących funkcji.

Jeżeli klient nie ma odpowiedniego środowiska, pomagamy w jego przygotowaniu. Klient może sprawdzić rozwiązanie, przejść przez przygotowane funkcje i przekazać uwagi przed wdrożeniem produkcyjnym.

Po akceptacji ustalamy termin wdrożenia.

Przy większych zmianach w sklepach internetowych uwzględniamy również okresy sprzedażowe. Migracji, zmian technologicznych i innych ryzykownych prac nie planujemy bez uwzględnienia kampanii, sezonowości i znaczenia sklepu dla sprzedaży klienta.

Dzięki temu termin techniczny jest ustalany również z uwzględnieniem sytuacji biznesowej firmy, a nie wyłącznie dostępności programisty.

19. Testujemy zmiany przed wdrożeniem

Zmiana przechodzi przez testy odpowiednie do jej zakresu.

Programista sprawdza własną pracę, a przy większych zmianach rozwiązanie może zostać dodatkowo zweryfikowane przez inną osobę z zespołu lub podczas testów QA.

Nie sprawdzamy wyłącznie nowej funkcji. Przy istotnych zmianach testujemy również jej wpływ na elementy, które mogą zostać przez nią dotknięte.

W sklepie internetowym może to oznaczać sprawdzenie koszyka, checkoutu, płatności, logowania, składania zamówienia, obsługi dostawy czy innych elementów zależnych od wprowadzonej zmiany.

Jest to ważne, ponieważ modyfikacja jednego elementu istniejącego systemu może wpłynąć na inne funkcje. Sprawdzenie zależności ogranicza ryzyko, że nowa funkcja będzie działać poprawnie, ale przy okazji przestanie działać część wcześniej działającego sklepu.

Klient weryfikuje przede wszystkim działanie biznesowe rozwiązania. Nie musi samodzielnie diagnozować kodu ani ustalać technicznej przyczyny problemu.

20. Pracujemy w sposób, który pozwala klientowi wiedzieć, co dzieje się z projektem

Przy większych projektach pracujemy w sprintach i regularnie omawiamy postęp prac, najczęściej podczas spotkań odbywających się raz w tygodniu.

Klient ma stałego PM-a i może komentować zadania w panelu Sopchy. Przy zadaniach widoczny jest ich status, osoba odpowiedzialna, komentarze i czas pracy.

Dzięki temu klient nie musi pytać osobno o każdą zmianę. Może sprawdzić, co zostało zgłoszone, czym aktualnie zajmuje się zespół i jaki jest status konkretnego zadania.

Przy pojedynczych lub sporadycznych zmianach nie ma potrzeby organizowania regularnych spotkań. Wtedy komunikacja odbywa się wokół konkretnych zadań.

Klient powinien wiedzieć, czy zgłoszenie zostało zauważone, kto się nim zajmuje, jaki jest jego status i kiedy może spodziewać się kolejnej informacji.

21. Rozliczamy zarówno małe zadania, jak i większy rozwój

Wsparcie i rozwój projektu rozliczamy godzinowo.

Klient może zgłosić pojedynczą małą zmianę, jeśli nie potrzebuje stałego zakresu prac. Może również zlecić większy etap rozwoju, jeśli projekt wymaga większej liczby zmian.

Nie wymagamy stałego abonamentu, jeśli klient nie ma takiej potrzeby. Abonament jest jedną z dostępnych form współpracy, ale w praktyce często pracujemy w modelu, w którym klient zgłasza zadania wtedy, gdy rzeczywiście ich potrzebuje.

Taki model pozwala dopasować zakres prac do aktualnych potrzeb firmy. Klient może zlecić pojedynczą poprawkę, kilka zmian przed konkretną kampanią albo większy etap rozwoju bez konieczności utrzymywania stałego zakresu prac, którego w danym momencie nie potrzebuje.

Dzięki temu współpraca może obejmować zarówno pojedyncze poprawki, jak i wielomiesięczny rozwój projektu.

22. Rozwój projektu może trwać latami

Dobrze działający projekt nie musi być zastępowany nowym tylko dlatego, że firma się rozwija. Może być stopniowo dostosowywany do nowych potrzeb.

Wraz ze wzrostem firmy może pojawić się potrzeba nowych funkcji, większej automatyzacji, kolejnych integracji, zmian UX, rebrandingu, nowych kanałów sprzedaży, obsługi kolejnych rynków lub przebudowy procesów wewnętrznych.

Sopchy rozwija projekty przez wiele lat. Przykładem jest Luxtrade, dla którego od ponad 4 lat realizujemy prace rozwojowe, głównie w środowisku PrestaShop. Zakres obejmował między innymi dedykowane moduły, integracje, rebranding oraz mini-aplikacje odpowiadające na bieżące potrzeby firmy.

Ponad 90% klientów, dla których tworzymy projekty, pozostaje z nami również przy dalszym wsparciu i rozwoju. Współpraca z częścią klientów trwa 5-6 lat lub dłużej.

Rozwój projektu oznacza więc nie tylko dodawanie kolejnych funkcji. To proces dostosowywania technologii do tego, jak zmienia się firma, jej klienci, procesy i sposób sprzedaży.

Co daje taki sposób rozwoju projektu?

Rozwój powinien prowadzić do konkretnej zmiany w działaniu firmy. W zależności od projektu może to oznaczać zwiększenie sprzedaży, podniesienie wartości koszyka, ograniczenie pracy ręcznej, automatyzację procesów, poprawę UX, obsługę nowego rynku, integrację kolejnych systemów, ograniczenie błędów albo przygotowanie technologii na dalszy wzrost.

Dlatego przed rozpoczęciem zmiany wracamy do jej celu. Jeżeli klient chce zwiększyć wartość koszyka, szukamy rozwiązania, które może wspierać ten cel. Jeżeli chce wejść na nowy rynek, analizujemy wymagane zmiany w systemie. Jeżeli zgłasza błąd, szukamy jego przyczyny zamiast zakładać z góry, co trzeba zmienić.

Taki sposób pracy pozwala rozwijać istniejący system zgodnie z rzeczywistymi potrzebami firmy, zamiast rozbudowywać go o funkcje, które nie rozwiązują konkretnego problemu.

Czym zajmujemy się najczęściej w ramach rozwoju projektu?

Rozwijamy sklepy oparte na PrestaShop, WooCommerce, Magento, Shopware i Shopify oraz dedykowane aplikacje webowe. Prace mogą obejmować dodawanie i modyfikowanie funkcji sklepu, wdrażanie rozwiązań B2B, zmianę procesu zakupowego, rozbudowę panelu administracyjnego, dodawanie gotowych modułów i wtyczek oraz tworzenie własnych, dedykowanych modułów PrestaShop i WooCommerce.

Realizujemy również integracje sklepów z zewnętrznymi systemami, między innymi ERP, BaseLinkerem, systemami magazynowymi, operatorami płatności, firmami kurierskimi, systemami fakturowania i marketplace'ami. Jeżeli system udostępnia API, możemy wykorzystać je do wymiany danych i automatyzacji procesów. W przypadku braku gotowej integracji tworzymy dedykowane rozwiązanie dopasowane do istniejącej architektury projektu.

Rozwijamy także warstwę wizualną i sposób korzystania ze sklepu. W ramach rebrandingu możemy wdrożyć nowy design istniejącego sklepu, a przy problemach z użytecznością przeprowadzić audyt UX i wdrożyć wynikające z niego zmiany. Zakres prac UX może obejmować między innymi uproszczenie procesu zakupowego, poprawę nawigacji, wyszukiwania produktów, kart produktu, koszyka i checkoutu oraz zmianę sposobu prezentowania informacji użytkownikowi.

Rozwój może dotyczyć zarówno pojedynczej funkcji, jak i większej przebudowy istniejącego sklepu. Możemy pracować nad projektem stworzonym wcześniej przez Sopchy albo przejąć rozwój istniejącego rozwiązania po innym software house'ie lub programiście.

Najważniejsze jest dla nas to, aby zakres rozwoju wynikał z rzeczywistego problemu lub celu firmy. Dzięki temu rozwijany system ma wspierać sprzedaż, obsługę klientów i procesy wewnętrzne, zamiast zwiększać liczbę funkcji bez konkretnego zastosowania.