Jak wygląda proces tworzenia projektu w Sopchy

Analiza potrzeb i poznanie firmy

Tworzenie projektu rozpoczynamy od poznania firmy i sposobu, w jaki działa. Na pierwszych rozmowach chcemy zrozumieć, czym zajmuje się klient, kim są jego klienci, jak pracują poszczególne zespoły i z jakich rozwiązań korzystają obecnie. Pytamy również o problemy, które firma chce rozwiązać, najbardziej czasochłonne zadania oraz procesy, które wymagają usprawnienia lub automatyzacji.

Te informacje wpływają bezpośrednio na sposób zaprojektowania projektu. Funkcje, uprawnienia, ścieżki użytkowników, integracje i sposób działania systemu wynikają z rzeczywistych potrzeb firmy, a nie z założenia, że każdy projekt powinien działać według tego samego schematu.

Klient nie musi na tym etapie wiedzieć, jaka technologia ani jakie konkretne rozwiązanie będzie najlepsze. Najpierw określamy potrzebę i oczekiwany efekt, a następnie dobieramy sposób jej realizacji. Wiedza klienta o jego firmie, procesach i użytkownikach jest równie istotna jak wiedza techniczna zespołu. Połączenie tych dwóch perspektyw pozwala zaprojektować rozwiązanie dopasowane do rzeczywistego sposobu działania firmy.

Jeżeli pracujemy nad istniejącym rozwiązaniem, analizujemy jego aktualny stan. Sprawdzamy, co działa prawidłowo, które elementy klient chce zachować, a z których chce zrezygnować. Weryfikujemy zastosowane technologie, istniejące integracje oraz dostępną dokumentację techniczną. Jeżeli dokumentacji brakuje, poznajemy rozwiązanie od strony technicznej, aby określić zakres niezbędnych prac.

Nie zawsze oznacza to przeprowadzanie pełnego audytu przed rozpoczęciem współpracy. W przypadku prostszych zmian możemy poznać system podczas realizacji konkretnego zadania. Przy większych lub bardziej ryzykownych pracach zakres analizy zwiększamy odpowiednio do sytuacji. Takie podejście pozwala nie ponosić kosztu szerokiej analizy tam, gdzie nie jest ona potrzebna, a jednocześnie ograniczyć ryzyko rozpoczęcia dużych prac bez sprawdzenia istotnych zależności.

1. Specyfikacja

Kolejnym etapem jest przygotowanie specyfikacji projektu. Klient może przekazać nam własną dokumentację, ale często otrzymujemy jedynie ogólny brief. Traktujemy go jako punkt wyjścia i uzupełniamy o informacje potrzebne do zaprojektowania oraz wdrożenia rozwiązania.

Specyfikacja przekłada potrzeby biznesowe na konkretne działanie systemu. Opisujemy w niej ścieżki użytkowników, funkcje systemu, role i uprawnienia oraz zakres dostępu poszczególnych użytkowników. Określamy, kto może wykonywać konkretne działania, jakie informacje widzi i jak powinny przebiegać poszczególne procesy.

Dokładnie opisujemy również integracje. Ustalamy, z jakimi systemami projekt będzie się komunikował, jakie dane będą przesyłane, w którym kierunku będzie odbywała się wymiana danych oraz gdzie poszczególne informacje będą zarządzane.

W przypadku projektu e-commerce może to oznaczać zaplanowanie komunikacji pomiędzy sklepem a systemem ERP, BaseLinkerem, systemem magazynowym, operatorem płatności, firmą kurierską, systemem fakturowania czy marketplace'em. Zakres integracji ustalamy na podstawie sposobu działania konkretnej firmy, a nie wyłącznie na podstawie dostępnych technicznie połączeń.

Na tym etapie ustalamy również priorytety. Określamy, które funkcje są niezbędne do uruchomienia pierwszej wersji projektu, czyli MVP, a które mogą zostać zrealizowane później i trafić do backlogu.

Takie rozdzielenie funkcji jest istotne szczególnie wtedy, gdy projekt ma być uruchomiony w określonym terminie lub budżecie. Pozwala rozpocząć pracę z zakresem potrzebnym do działania projektu, zamiast odkładać uruchomienie do momentu wykonania wszystkich planowanych funkcji.

Specyfikacja pozwala również wcześniej znaleźć brakujące informacje, zależności między funkcjami oraz elementy, które mogą wpłynąć na czas i koszt realizacji. Zmiana założeń na etapie dokumentacji jest zazwyczaj prostsza niż zmiana rozwiązania po rozpoczęciu programowania, zmianach w bazie danych czy przygotowaniu integracji.

Na podstawie specyfikacji określamy również przewidywany czas potrzebny na realizację poszczególnych elementów. Estymacja odnosi się do opisanego zakresu, dlatego im dokładniej określone są wymagania, tym łatwiej określić nakład pracy.

Dla klienta oznacza to większą przewidywalność przed rozpoczęciem developmentu. Wiadomo, co ma zostać wykonane, jak powinno działać, jakie systemy będą ze sobą połączone i które funkcje mają zostać zrealizowane w pierwszej kolejności.

2. Dobór technologii

Technologię i sposób realizacji dobieramy po poznaniu wymagań projektu. Nie zakładamy z góry, że każdy projekt powinien zostać wykonany na tej samej platformie.

Jeżeli gotowe rozwiązanie odpowiada wymaganiom, możemy je wykorzystać i rozszerzyć o potrzebne funkcje. Jeżeli nie spełnia wymagań projektu, możemy stworzyć dedykowane rozwiązanie.

W zależności od potrzeb możemy pracować na istniejącym systemie, rozbudować platformę open source, stworzyć dedykowany moduł lub zbudować rozwiązanie od podstaw. Przy wyborze sposobu realizacji bierzemy pod uwagę między innymi zakres funkcji, możliwości dalszego rozwoju, wymagane integracje, sposób utrzymania oraz przewidywany nakład prac.

Dobór technologii ma znaczenie również dla dalszego rozwoju projektu. Rozwiązanie, które spełnia wymagania pierwszej wersji, ale utrudnia późniejsze zmiany, może generować dodatkowe koszty przy kolejnych etapach. Dlatego przy wyborze sposobu realizacji uwzględniamy nie tylko obecne wymagania, ale również planowany kierunek rozwoju.

Przykładem jest projekt dla Trend Glass, w którym sklep B2B został przeniesiony z rozwiązania SaaS na platformę open source. W ramach projektu odtworzyliśmy kluczowe procesy i funkcje po stronie administracyjnej, integracje z zewnętrznymi systemami oraz funkcje dostępne dla klientów.

W tym przypadku zmiana platformy wynikała z potrzeb projektu i zakresu funkcji, które miały zostać zachowane oraz rozwijane. Pokazuje to, że wybór technologii jest elementem procesu projektowego, a nie decyzją podejmowaną niezależnie od potrzeb firmy.

3. Prototypy, UX i design

Dla najważniejszych lub bardziej złożonych funkcji przygotowujemy prototypy i makiety. Pozwalają one zobaczyć sposób działania procesu jeszcze przed rozpoczęciem programowania. Możemy dzięki temu sprawdzić kolejne kroki użytkownika, sposób prezentowania informacji oraz dostępne działania.

Prototyp pozwala również wcześniej zweryfikować pomysł. Jeżeli okaże się, że dana ścieżka jest nieczytelna, wymaga zbyt wielu kroków albo nie odpowiada potrzebom użytkowników, możemy zmienić ją na etapie projektowym, bez ingerowania w gotowy kod.

W przygotowywaniu prototypów wykorzystujemy również narzędzia oparte na AI. W niektórych przypadkach pozwalają one szybciej przygotować i zweryfikować pierwsze warianty rozwiązania przy mniejszym nakładzie pracy. AI traktujemy jako narzędzie wspierające proces projektowy, a nie zastępujące analizę potrzeb, wiedzę projektową czy decyzje dotyczące funkcjonowania systemu.

Śledzimy rozwój narzędzi AI i wykorzystujemy je tam, gdzie mogą realnie przyspieszyć pracę lub ograniczyć jej koszt, szczególnie na etapie przygotowywania koncepcji, porządkowania informacji i tworzenia pierwszych prototypów.

Jeżeli w ramach projektu odpowiadamy za design, przygotowujemy również wstępny standard wizualny i kierunek projektowania interfejsu. Na jego podstawie powstają kolejne widoki projektu.

Kluczowe elementy projektu są zatwierdzane przed rozpoczęciem ich implementacji. Dzięki temu sposób działania funkcji, ścieżkę użytkownika czy wygląd interfejsu można zmienić na etapie specyfikacji lub prototypu, zanim zmiana będzie wymagała modyfikacji kodu, bazy danych lub integracji.

Tworzenie projektu traktujemy jako współpracę dwóch stron. Sopchy wnosi wiedzę o technologiach, możliwościach realizacji i konsekwencjach poszczególnych decyzji, a klient wiedzę o swojej firmie, użytkownikach i procesach. Na tej podstawie wspólnie ustalamy sposób działania projektu. Klient zatwierdza kluczowe założenia, wygląd i funkcjonalności przed rozpoczęciem prac programistycznych.

4. Harmonogram i realizacja

Po zatwierdzeniu zakresu, sposobu działania i wyglądu projektu przygotowujemy harmonogram. Określamy kolejność realizacji etapów, planowany czas prac oraz osoby odpowiedzialne za poszczególne zadania.

Uwzględniamy również zadania, które muszą zostać wykonane po stronie klienta lub innych podmiotów zaangażowanych w projekt. Mogą to być na przykład przygotowanie tłumaczeń, treści, materiałów prawnych, grafik, danych produktowych czy danych wymaganych do integracji.

Uwzględnienie tych zależności jest istotne, ponieważ część prac programistycznych nie może zostać zakończona bez danych lub decyzji znajdujących się po stronie klienta albo zewnętrznego dostawcy. Wczesne wskazanie takich elementów pozwala lepiej zaplanować kolejność prac i ograniczyć przestoje.

Następnie poszczególne etapy dzielimy na konkretne zadania i rozpoczynamy prace programistyczne. Większe projekty realizujemy w sprintach, a efekty kolejnych etapów prezentujemy klientowi podczas regularnych spotkań.

Klient zatwierdza sposób działania i zakres projektu przed rozpoczęciem developmentu. Po wykonaniu poszczególnych funkcji może natomiast zweryfikować, czy zostały zrealizowane zgodnie ze wcześniej zatwierdzoną specyfikacją.

Podział projektu na konkretne zadania pozwala monitorować postęp prac i szybciej zauważyć, jeżeli realizacja któregoś elementu wymaga dodatkowych ustaleń, danych lub decyzji.

5. Zmiany w trakcie realizacji

Założenia projektu mogą zmienić się również w trakcie prac. Może to wynikać ze zmiany potrzeb firmy, pojawienia się nowej informacji albo decyzji o dodaniu funkcji, która wcześniej nie była częścią zakresu.

Jeżeli klient chce dodać nową funkcję lub zmodyfikować wcześniej ustalony element, określamy przewidywany czas potrzebny na realizację zmiany oraz jej wpływ na pozostałe prace i harmonogram.

Klient decyduje wtedy, czy zmiana jest potrzebna w bieżącym etapie, czy może zostać przeniesiona do kolejnego etapu rozwoju i backlogu.

Takie podejście pozwala podejmować decyzje dotyczące zmian na podstawie ich rzeczywistego wpływu na projekt. Klient zna przewidywany dodatkowy nakład pracy i może zdecydować, czy chce przeznaczyć na zmianę czas i budżet zaplanowany na bieżący etap, czy zrealizować ją później.

Dzięki temu nowe zadania nie są po prostu dodawane do projektu bez uwzględnienia ich wpływu na wcześniej ustalony zakres. Zmiana pozostaje częścią świadomie zarządzanego zakresu projektu.

6. Testowanie i wdrożenie

Przed uruchomieniem projekt jest testowany wewnętrznie. Developerzy sprawdzają przygotowane funkcje, a prace są weryfikowane przez innych członków zespołu. W zależności od projektu wykonywane są również testy funkcjonalne i manualne przez QA.

Testujemy nie tylko nową funkcję, ale również jej wpływ na elementy, z którymi jest połączona. W sklepie internetowym może to oznaczać sprawdzenie między innymi koszyka, procesu składania zamówienia, płatności, dostawy, logowania czy innych funkcji zależnych od wprowadzonej zmiany.

Jest to istotne, ponieważ poprawnie działająca pojedyncza funkcja może jednocześnie wpływać na inne elementy systemu. Testowanie pozwala wykryć takie zależności przed publikacją zmiany dla użytkowników.

Klient nie odpowiada za techniczne testowanie implementacji. Jego rolą jest przede wszystkim sprawdzenie, czy gotowa funkcja działa zgodnie ze specyfikacją i ustalonym sposobem działania oraz czy odpowiada potrzebom biznesowym.

Prace prowadzimy na środowisku deweloperskim. W zależności od potrzeb projektu przygotowujemy również środowisko stagingowe, na którym rozwiązanie można sprawdzić przed publikacją produkcyjną.

Rozdzielenie środowiska deweloperskiego, stagingowego i produkcyjnego pozwala testować zmiany przed ich publikacją dla użytkowników końcowych. Ma to szczególne znaczenie w sklepach i systemach wykorzystywanych przez klientów lub pracowników, gdzie niezweryfikowana zmiana może wpłynąć na sprzedaż albo bieżącą pracę firmy.

Po zakończeniu prac i testów wdrażamy projekt na środowisko produkcyjne. W przypadku większych wdrożeń ustalamy termin publikacji z uwzględnieniem działania firmy, kampanii sprzedażowych, sezonowości oraz znaczenia danej zmiany dla użytkowników.

W razie potrzeby pomagamy również w przygotowaniu środowiska potrzebnego do uruchomienia projektu.

Po wdrożeniu szkolimy zespół klienta i przekazujemy niezbędne dostępy. W razie potrzeby przygotowujemy również instrukcje PDF lub video, które mogą być wykorzystywane przy wdrażaniu kolejnych osób.

Dla jakich firm realizujemy projekty?

Sopchy realizuje projekty głównie dla średnich firm, dla których rozwiązania cyfrowe i e-commerce mają bezpośrednie znaczenie dla działalności firmy.

Wśród klientów znajdują się firmy osiągające ponad 1,2 mln zł rocznego przychodu netto, w których sklep internetowy jest ważnym lub głównym kanałem sprzedaży. Najczęściej są to firmy realizujące od kilkuset do kilku tysięcy transakcji miesięcznie.

Przy takiej skali sklep internetowy nie jest tylko stroną prezentującą produkty. Jego działanie wpływa na sprzedaż, obsługę klientów, pracę zespołów, realizację zamówień, gospodarkę magazynową i komunikację z innymi systemami.

Dlatego projekty realizowane dla takich firm często obejmują nie tylko stworzenie lub zmianę samego sklepu, ale również integracje, automatyzację procesów, rozwój funkcji B2B, przebudowę procesów zakupowych, migrację platformy lub dalszy rozwój istniejącego rozwiązania.

Przykłady realizowanych projektów

Trend Glass

Dla Trend Glass realizowaliśmy projekt obejmujący sklep B2B oraz sklep B2C. Sklep B2B został przeniesiony z rozwiązania SaaS na platformę open source. W ramach prac odtworzyliśmy kluczowe procesy i funkcje po stronie administracyjnej, integracje z zewnętrznymi systemami oraz funkcje dostępne dla klientów.

Dla sklepu B2C przygotowaliśmy również dedykowany design. Po pewnym czasie sklep B2C został dodatkowo objęty rebrandingiem.

Sopchy zapewnia wsparcie techniczne dla projektów Trend Glass od ponad 3 lat.

Browar PINTA

Dla Browaru PINTA stworzyliśmy stronę internetową pełniącą funkcję katalogu produktów, która jest na bieżąco rozwijana i aktualizowana. Przygotowaliśmy również sklep internetowy, który pozwolił rozszerzyć sprzedaż o kanał B2C.

Sopchy zapewnia wsparcie techniczne dla projektów PINTA od ponad 5 lat.

Luxtrade

Dla Luxtrade przejęliśmy bieżące wsparcie i rozwój istniejącego sklepu, prowadząc te prace od ponad 4 lat. Działaliśmy głównie w obrębie platformy PrestaShop.

W ramach współpracy realizowaliśmy między innymi dedykowane moduły, integracje, rebranding oraz mini-aplikacje tworzone w odpowiedzi na aktualne potrzeby firmy i prowadzone projekty biznesowe.

Ten przykład pokazuje również, że projekt nie musi kończyć się na pierwszym wdrożeniu. Istniejący sklep może być przez kolejne lata rozwijany wraz ze zmianami potrzeb firmy, procesów sprzedażowych i technologii.

Podsumowanie

Proces tworzenia projektu ma ograniczyć ryzyko kosztownych zmian i niejasności w trakcie realizacji. Najpierw poznajemy firmę i jej sposób działania, następnie przekładamy potrzeby biznesowe na konkretną specyfikację, dobieramy sposób realizacji, przygotowujemy prototypy i dopiero wtedy rozpoczynamy programowanie.

Każdy etap ma konkretny cel. Analiza pozwala zrozumieć problem i zależności, specyfikacja porządkuje zakres, funkcje i integracje, dobór technologii pozwala wybrać sposób realizacji odpowiedni dla projektu, prototypy umożliwiają wcześniejszą weryfikację pomysłu, a testy ograniczają ryzyko problemów po wdrożeniu.

Dla klienta oznacza to możliwość podejmowania decyzji na podstawie konkretnych informacji jeszcze przed wykonaniem pełnego zakresu prac. Wiadomo, co ma zostać zrealizowane, jakie są zależności, które elementy są priorytetowe i gdzie mogą pojawić się dodatkowe wymagania.

Proces tworzenia projektu kończy się uruchomieniem rozwiązania. Dalszy rozwój, aktualizacje, optymalizacja i bieżące wsparcie mogą być prowadzone w ramach osobnych procesów współpracy.