Jak pracujemy

Wygląd witryny e-commerce

Po wspólnym ustaleniu wymagań projektowych przystępujemy do prac nad wyglądem sklepu. W pierwszej kolejności tworzymy listę widoków, które powstaną w projekcie. Większość z nich jest standardowa, jak widok kategorii, czy konta użytkownika, ale w zależności od zawartości wymagań projektowych może pojawić się potrzeba stworzenia nowych. Lista widoków obejmuje również wytyczne co do ogólnego kształtu widoków. To znaczy, jakie elementy mają się na niej pojawić – wszystko w oparciu o ustalenia wymagań projektowych. Na bazie listy widoków nasz grafik tworzy zestaw grafik przedstawiających sklep tak, jak widzi go internauta.

Warto również zwrócić uwagę, że w przypadku, gdy klient dostarcza nam własną szatę graficzną, nasz grafik i tak musi narysować ją od nowa. Robimy to dlatego, żeby uniknąć nieporozumień i rozbieżności jakie mogą się pojawić przy realizowaniu projektu. Jeśli strona internetowa ma być w 100% zgodna z pierwotnym projektem graficznym, to musimy się upewnić, czy jest on wykonalny”. Poniżej przykładowe powody, dla których projekt graficzny może być niewykonalny:

• jest w nieprawidłowym formacie plików graficznych (najczęściej .ai zamiast .psd)
• rozmiary czcionek są sztucznie rozciągnięte (do wartości ułamkowej – na stronie internetowej można wprowadzić tylko wartości całkowite)
• poszczególne elementy powtarzalne rozmieszczone są nierówno, przez co nie ma możliwości odzwierciedlenia ich układu na stronie w zgodzie z zasadami RWD
• brakuje części elementów graficznych, które reprezentują potrzebne funkcje sklepu internetowego

Inna rzecz, że bardzo  często projekty przygotowane przez grafików zewnętrznych nie są kompletne – nie zawierają wszystkich widoków i wszystkich wariantów poszczególnych stron.

Trzeba także pamiętać o tym, że nie zawsze własny projekt oznacza mniejszy całkowity koszt wykonania projektu. Wynika to z faktu, że grafiki tworzone przez nas opierają się na strukturze aktualnej wersji PrestaShop, na której będzie budowany sklep. Jeśli grafik tworząc design nie brał pod uwagę oprogramowania, z którym będzie on zintegrowany, prace nad pocięciem grafiki i jej wdrożeniem będą trwały dużo dłużej, niż zazwyczaj. Żeby tego uniknąć proponujemy konsultacje przygotowanej grafiki przed rozpoczęciem prac, ponieważ czasem drobne kosmetyczne zmiany w grafice prowadzą do dużej oszczędności czasu i co za tym idzie, pieniędzy.

Estetyka i funkcjonalność sklepu internetowego

Kiedy rozważamy kwestie wyglądu sklepu internetowego, pamiętajmy o tym, że projekt graficzny musi brać pod uwagę nie tylko aspekty estetyczne, ale również funkcjonalne i finansowe. Proces sprzedaży w sklepach internetowych jest mocno sformalizowany i rządzi się pewnymi zasadami, do których przyszli klienci budowanego sklepu są od dawna przyzwyczajeni. Stworzenie sklepu, który nie uwzględnia tych zasad powoduje ryzyko, że klient będzie się czuł zagubiony, lub wręcz straci zaufanie do strony, co zaowocuje porzuceniem koszyka i brakiem sprzedaży. Nasz zespół tworzy makietę zgodną z zasadami User Experience (UX), umieszczając poszczególne elementy tak, żeby zakupy były możliwe najbardziej przyjazne dla użytkownika. Niestety, w niektórych sytuacjach pojawia się konflikt pomiędzy oczekiwaniami inwestora a koncepcjami naszego zespołu. Warto jednak pamiętać, że  rozpoczynając współprace z nami, kupuje się nie tylko nasz czas, ale także naszą wiedzę. Warto zaufać nam w kwestiach dotyczących organizacji strony, ponieważ niektóre funkcje, które na pierwszy rzut oka wydają się niepotrzebne, mogą utrudnić rozwój strony w przyszłości. Z drugiej strony staramy się zawsze dostosować system do potrzeb inwestora, ale każdą rozbieżność musimy wspólnie omówić, żeby mieć pewność, że wprowadzenie zmian wynika ze specyfiki danego biznesu i jej wprowadzenie jest warte kosztu, jaki będzie związany z jej wprowadzeniem. Tu dochodzimy do drugiego zagadnienia, czyli aspektu finansowego. Dokonując wyceny projektu przyjmujemy uśrednioną czasochłonność wykonania poszczególnych elementów sklepu internetowego, w oparciu o nasze doświadczenia z realizacji poprzednich projektów. Dzieje się tak, ponieważ do dokonania precyzyjnej wyceny godzinowej czasochłonności projektu potrzebujemy kompletnego projektu funkcjonalnego i makiety. Te dwa elementy stanowią natomiast integralną część naszych prac, więc stworzenie ich ma miejsce dopiero po podpisaniu umowy. Zatem projekt i stworzona makieta muszą brać pod uwagę budżet, jaki przyjęliśmy na początku. Oczywiście, założony budżet pozwala na stworzenie pełnowymiarowego sklepu internetowego pozostawia margines na wdrożenie funkcji nieprzewidzianych w wycenie, czy wymaganiach projektowych, jednak trzeba pamiętać, że nie możemy dowolnie rozszerzać zakresu prac ani przyjmować, że każdy widok graficzny jest możliwy do wdrożenia w ramach podpisanego budżetu.

Projekt funkcjonalny – co to jest i dlaczego w ogóle go tworzymy?

Projekt funkcjonalny zawiera kompletny opis działania i wyglądu sklepu internetowego. Jest on tworzony na bazie ustaleń zawartych w pytaniach do projektu funkcjonalnego oraz w oparciu o przygotowaną makietę. Przy tworzeniu sklepu internetowego wychodzimy z założenia, że im mniej nieporozumień i wynikających z nich poprawek na etapie odbioru, tym sprawniejszy i bardziej efektywny jest proces wdrażania witryny e-commerce. Dlatego w projekcie funkcjonalnym znajduje się opis wszystkich elementów strony internetowej oraz opis ich działania. Nawet standardowe funkcje PrestaShop mogą być wdrożone na kilka różnych sposobów (na przykład tunel zakupów może być wielokrokowy lub typu one page checkout), dlatego ich opis zabezpiecza obie strony przed sytuacją, gdy efekt końcowy odbiega od oczekiwań.

Na etapie projektu funkcjonalnego omawiamy również z inwestorem dokładny sposób funkcjonowania elementów ogólnie ujętych w wymaganiach projektowych. Każde rozwiązanie jest konsultowane z inwestorem, żeby upewnić się, że efekt będzie satysfakcjonujący. Przy przedstawianiu propozycji kierujemy się zasadą: „jak najlepsze rozwiązanie możliwie w ramach określonego budżetu”. Biorąc pod uwagę, że rozwiązania ogólnie opisane, po sprecyzowaniu mogą przekroczyć budżet przewidziany w początkowej wycenie, może się zdarzyć, że na etapie tworzenia projektu funkcjonalnego przedstawimy propozycję, która będzie wymagała prac dodatkowych i zwiększenia końcowej ceny projektu.

Przy tym punkcie chciałbym zatrzymać się na dłużej, ponieważ wielu inwestorów zwraca uwagę na możliwość zwiększenia ceny w trakcie przygotowania projektu funkcjonalnego. Trzeba zwrócić uwagę, że na etapie ustalania zakresu prac, znaczna większość elementów jest opisana dość ogólnie, bez dokładnej specyfikacji obejmującej dokładne funkcjonowanie i wygląd. Stworzenie tak precyzyjnego opisu byłoby niemożliwe.Choćby dlatego, że na tym etapie nie istnieje projekt graficzny, jednocześnie inwestor na etapie wymagań projektowych nie ma jasnego obrazu mechanizmów działania, a jedynie efekt, jaki chce osiągnąć. Generalnie rzecz ujmując, brief klienta i wycena zawiera wytyczne, a nie specyfikację. Żeby osiągnąć cel określony przez te wytyczne, możemy wdrożyć różne rozwiązania – jedne tanie, ale mniej wygodne, inne idealnie dopasowane do potrzeb, ale wymagające większego nakładu pracy. W naszej pracy zawsze kierujemy się zasadą najtańszego akceptowalnego rozwiązania, oznacza to, że przedstawiamy sposób wdrożenia danej funkcjonalności, który będzie inwestora kosztował najmniej. Jeśli ten sposób nie jest satysfakcjonujący proponujemy następne, bardziej dopasowane, ale związane z dodatkowymi kosztami, tak długo, aż inwestor uzna, że otrzyma dokładnie to, czego potrzebuje. Dzięki takiemu podejściu, inwestor nigdy nie przepłaci za funkcje, których tak naprawdę nie potrzebuje. Kolejną zaletą  jest to, że inwestor nie musi wszystkiego ustalać przed podpisaniem umowy, co znacznie skraca czas realizacji projektu.  Poszczególne funkcje są doprecyzowane już na etapie tworzenia szaty graficznej i projektu funkcjonalnego.

W projekcie funkcjonalnym znajduje się też opis funkcji panelu administracyjnego sklepu, ale tylko takich, które są tworzone lub modyfikowane na zlecenie klienta. Dla pozostałych funkcji obowiązującym opisem jest standardowy panel administracyjny PrestaShop.

Co jeśli chcesz wdrożyć funkcję lub grafikę nieprzewidzianą w wymaganiach projektowych, a
wykraczającą poza budżet przyjęty w umowie?

Na etapie tworzenia grafiki i projektu funkcjonalnego dodawanie kolejnych funkcji, czy zmiany w grafice są stosunkowo proste. Pamiętać należy o tym, że w niektórych przypadkach będzie się to wiązało ze zwiększeniem całkowitego kosztu sklepu. Od strony formalnej wygląda to tak:

1.  Zestaw wytycznych (graficznych lub funkcjonalnych) stanowi osobną wycenę.
2. Po jej zaakceptowaniu tworzymy aneks do umowy (określający wartość prac dodatkowych oraz wskazujący dokument, który opisuje zakres prac) oraz aktualizujemy wymagania projektowe o nowe elementy.

Faza tworzenia dokumentacji jest najlepszym momentem do precyzowania poszczególnych funkcji i widoków oraz dopracowania szczegółów. Na początkowym etapie (wymagania projektowe, wycena) niemożliwe jest osiągnięcie pełnej precyzji jak chodzi o zakres prac, więc zarówno wycena jak i wartość są do pewnego stopnia uogólnieniem.

Co jeśli na etapie wdrożenia chcę zmienić projekt funkcjonalny i wprowadzić do niego nowe
funkcje?

Wprowadzanie zmian w projekcie w trakcie wdrożenia, lub wręcz po jego zakończeniu jest niestety często spotykane, ale jest to bardzo niebezpieczna droga dopracowywania projektu. Gorąco odradzamy zmiany polegające na tym, że nieukończony projekt jest przedmiotem zmian i są one wdrażane zanim wersja oryginalna projektu znajdzie się na serwerach roboczych. Jest kilka powodów, dla których to nie jest dobre rozwiązanie:

1. Znacząco zwiększa koszt realizacji projektu. Każda zmiana wymaga analizy pod kątem interakcji z elementami już wdrożonymi w projekcie. Oznacza to, że nawet jeśli mówimy o jednej zmianie, to musimy de facto przejrzeć cały projekt, żeby mieć pewność, że nie będzie konfliktu z istniejącymi funkcjami. To samo dotyczy grafiki – nawet tak banalna zmiana w makiecie, jak rozmiar czcionki w jednym miejscu, wymaga analizy – style czcionek są globalne i zmiana rozmiaru może spowodować zmiany w innych miejscach.
2. Znacząco zwiększa czas realizacji projektu. Jeśli dochodzi do zmiany w projekcie, to musimy wstrzymać wszelkie działania i wycenić prace dodatkowe. Równoległe realizowanie projektu i wprowadzanie do niego zmian jest niemożliwe ze względu na interakcję pomiędzy poszczególnymi częściami strony. Zatem potrzebujemy czasu na analizę wykonalności i wycenę prac dodatkowych, załatwienie formalności, zmianę makiety graficznej i projektu funkcjonalnego. Jeśli zakładamy, że przeciętny projekt jest wdrażany przez trzy miesiące, to nawet drobna zmiana może wydłużyć cały proces o miesiąc.
3. Nie widzimy globalnego wpływu zmiany na całość projektu. Pamiętajmy o tym, że zawartość projektu funkcjonalnego i graficznego to efekt analizy i wizji inwestora, która ma swój początek wiele miesięcy przed rozpoczęciem prac. Zmiany natomiast są często impulsywne, powodowane emocjami lub chwilową zmianą podejścia do swojego biznesu pod wpływem na przykład obejrzenia strony konkurencji. W Jash Technologie wychodzimy z założenia, że pośpiech jest złym doradcą. Lepiej jest skonfrontować naszą wizję z klientem, posłuchać go (poprzez analizę) i rozwijać działający sklep, niż opóźniać premierę i wprowadzać zmiany, które nie mają oparcia w reakcji klienta.

Z punktu widzenia inwestora to najnudniejszy etap tworzenia sklepu internetowego. Nasz zespół programistów wdraża sklep zgodnie z wytycznymi ustalonymi i zatwierdzonymi wcześniej. Zasadą jest stuprocentowa zgodność z projektem graficznym i funkcjonalnym, więc to czysto techniczna robota, w której nikt poza zespołem programistów nie bierze udziału. Na co warto zwrócić uwagę, to fakt, że unikamy prezentowania inwestorowi częściowych efektów prac na naszym serwerze testowym. Mówiąc wprost, budowany sklep wygląda bardzo brzydko i częściowe prezentacje mogłyby niepotrzebnie zaniepokoić inwestora, co do końcowego efektu.

Kontrola jakości i testy

Kontrola jakości odbywa się dwuetapowo. Pierwszą fazą jest kontrola wewnętrzna. Obejmuje ona część wizualną i funkcjonalną. Jest ona przeprowadzana przez osobę, która dotychczas nie miała kontaktu z projektem – o wiele trudniej jest znaleźć własne błędy, dlatego świeże spojrzenie na projekt pozwala na skuteczniejsze wskazanie ewentualnych błędów.

Należy zwrócić uwagę, że na tym etapie nie wszystkie elementy mogą podlegać przetestowaniu. Najlepszym przykładem są moduły płatności, które do prawidłowego funkcjonowania mogą wymagać wskazania adresu URL strony, co sprawia, że dopiero po ostatecznej instalacji na serwerze produkcyjnym inwestora będzie możliwa ich weryfikacja. Z drugiej strony, trzeba pamiętać, że chodzi o standardowe moduły, których kontrola jakości jest raczej formalnością.

Drugi etap kontroli jakości, to odbiór przez inwestora. Odbywa się on na naszym serwerze testowym, gdzie udostępniamy możliwość sprawdzenia efektu naszych prac zarówno od strony front-endu jak i panelu administratora. Wszelkie poprawki, jakie ewentualnie mogą się pojawić, wdrażamy natychmiast.

Instalacja i szkolenie

Ostatnim etapem naszych prac przy tworzeniu sklepu internetowego jest instalacja na serwerze docelowym oraz szkolenie w zakresie obsługi oprogramowania. Instalacja na serwerze wskazanym przez inwestora jest połączona z konfiguracją i przetestowaniem modułów, których nie można było przetestować przedtem (wspomniane moduły płatności). Dodatkowo, na etapie instalacji przeprowadzamy (jeśli jest objęta zakresem prac) migrację danych z poprzedniej wersji sklepu, żeby zachować ciągłość danych pod kątem zamówień i klientów na nowej witrynie. W takim przypadku wymagane będzie wyłącznie istniejącego sklepu na czas nie dłuższy niż osiem godzin. Oczywiście moduł migracji jest przetestowany przed instalacją, żeby uniknąć wszelkich problemów.

Szkolenie, zależnie od ustaleń w trakcie wyceny może być przeprowadzone na miejscu w siedzibie firmy inwestora lub zdalnie przez Skype. Obejmuje ono opis standardowych funkcji PrestaShop oraz funkcji specyficznych, wdrożonych dla konkretnego projektu.