Przygotowanie dokumentacji dla projektu eCommerce przed rozmową z agencją wdrożeniową to kluczowy krok, który może zaoszczędzić czas, zmniejszyć ryzyko nieporozumień i obniżyć koszty projektu. Dzięki dobrze opracowanej specyfikacji będziesz lepiej przygotowany do oceny ofert, lepiej zrozumiesz różnice między technologiami, a co najważniejsze — zapewnisz sobie bardziej precyzyjną wycenę.

Każda agencja nieważne czy pracująca w modelu Time and Materials czy Fixed Price wycenia funkcjonalności eCommerce na podstawie dokumentacji projektu. Czy to przesłanej przez klienta i dodatkowych rozmów, które z nimi prowadzi, czy to stworzonej wewnętrznie przez agencje na kanwie rozmów z klientem. 

Głównym kosztem projektu są właśnie funkcjonalności, które chcemy wdrożyć. To właśnie od liczby i poziomu skomplikowania funkcjonalności (a także technologii dobranej pod projekt) będzie zależeć koszt wdrożenia projektu.

Jednak pamiętaj, że jako klient nie masz obowiązku jej tworzyć – profesjonalna agencja eCommerce powinna po odpowiedniej kwalifikacji klienta przejść  przez ten proces, jednak przygotowanie się do rozmów z agencją na podstawie odpowiednio spisanej dokumentacji niesie za sobą wiele benefitów, które znacząco ułatwiają rozmowy, otrzymanie korzystnej oferty, oraz porównanie technologii. 

Spis treści

Korzyści płynące z przygotowania dokumentacji przez klienta

  • Agencje eCommerce są doskonałe w technologiach, które wdrażają, ale niekoniecznie muszą być ekspertami w Twojej konkretnej dziedzinie biznesowej. Największą przeszkodą podczas dyskusji jest zrównoważenie wiedzy między stronami: klientem, który rozumie, jak działa technologia, i agencją, która rozumie, jak działa biznes klienta. Przygotowując dokumentację i wymieniając wszystkie wymagania na papierze, znacznie usprawniasz ten proces dla agencji i zapewniasz, że Twoje potrzeby zostaną lepiej zrozumiane i odzwierciedlone w oszacowaniu projektu.
  • Technologie, które porównują klienci, często znacząco różnią się pod względem sposobu implementacji konkretnych funkcjonalności. Na przykład w jednej technologii implementacja funkcji może zająć 60 godzin; w innej gotowa wtyczka może być dostępna; a w trzeciej implementacja pełnej funkcjonalności może nie być możliwa. Dlatego też posiadanie dobrze przygotowanej dokumentacji projektu i opartego na niej kosztorysu pozwoli Ci lepiej porównywać różne technologie.
  • W zależności od strategii zakupowej klienta, przygotowanie dokumentacji pozwoli zaoszczędzić czas na długich spotkaniach i na wyjaśnianiu agencji, jak wszystko powinno działać. Niektóre firmy wysyłają nawet briefy do wielu agencji, prosząc o wstępne szacunki projektu, a następnie spotykają się tylko z wybranymi agencjami.
  • Mniej oczywistą korzyścią jest to, że klient może lepiej uporządkować własne myśli na temat tego, czego potrzebuje. Agencje często spotykają się z sytuacjami, w których nawet początkowe wymagania projektu nie są dobrze zdefiniowane w umyśle kupującego. W wielu przypadkach wczesne wewnętrzne dyskusje zespołowe i ustalenie wstępnej wersji funkcjonalności i operacji platformy pomogą lepiej określić potrzeby projektu.

Teraz, gdy rozumiemy już znaczenie tworzenia początkowej dokumentacji projektu, możemy zająć się tym, jak powinniśmy podejść do jej tworzenia.

Disclaimer

Na potrzeby tego artykułu skupimy się wyłącznie na projektach typu greenfield. Projekty typu greenfield to takie, w których budujemy coś od podstaw. Na przykład firma, która sprzedawała swoje produkty tylko w sklepach stacjonarnych, teraz chce zacząć sprzedawać online, budując platformę eCommerce. Projekty te oferują możliwość stworzenia nowej obecności cyfrowej bez ograniczeń istniejących systemów lub procesów.

Organizacje, które już działają w eCommerce i mają zbudowaną wiedzę, zazwyczaj rozumieją, dlaczego chcą zmienić swoją technologię eCommerce. Wiedzą, co działa źle, a co dobrze w ich obecnej konfiguracji. Dlatego agencje rzadko spotykają się z sytuacjami, w których firmy migrujące swoje platformy eCommerce nie mają przygotowanej dokumentacji dla nowego projektu.

Ponadto w artykule tym opisano wyłącznie właściwy sposób prezentacji założeń biznesowych, nie omawiając szczegółowo samego procesu, czyli tego, jak z perspektywy biznesowej określić, jakie funkcjonalności są potrzebne w projekcie.

W jaki sposób agencje wdrażające szacują koszty projektów eCommerce?

Przede wszystkim, kluczowe jest zrozumienie, jak większość agencji podchodzi do wyceny projektów internetowych. Mówiąc prościej, cena danego projektu będzie zależeć od liczby i złożoności funkcjonalności, front-endu sklepu oraz technologii/platformy użytej do wdrożenia projektu.

Koszt projektu eCommerce różni się znacząco w zależności od jego złożoności i zakresu. Na dolnym końcu spektrum cenowego znajdują się proste sklepy oparte na szablonach, sprzedające lokalnie kilka produktów, które są stosunkowo niedrogie. W miarę zwiększania złożoności koszty rosną. Sklep z dużym asortymentem (powiedzmy 10 000 produktów) sprzedający na arenie międzynarodowej będzie droższy ze względu na skalę i dodatkowe funkcje wymagane do sprzedaży globalnej. Platformy eCommerce B2B często kosztują więcej niż sklepy B2C ze względu na ich specjalistyczne funkcje i złożone struktury cenowe. Na górnym końcu spektrum cenowego znajdują się projekty rynkowe, które obejmują wielu sprzedawców i różne interakcje, co czyni je ogólnie najdroższymi w opracowaniu i utrzymaniu.

Aby znacznie uprościć tę kwestię, im bardziej złożony jest sklep, tym więcej linii kodu trzeba napisać lub tym więcej wtyczek/rozszerzeń danej platformy trzeba użyć. Aby oszacować „ile linii kodu” trzeba napisać, aby cały sklep odzwierciedlał wizję klienta, projekt należy rozbić na tzw. funkcjonalności. Te funkcjonalności mogą odnosić się do tego, co widzimy jako użytkownicy (na froncie sklepu) – takie jak banery, galerie zdjęć, odpowiedni projekt strony lub to, co dzieje się za kulisami (na zapleczu) – na przykład logika promocji, integracja z systemami zewnętrznymi, takimi jak PIM, ERP itp.

Naturalnie, jest to tylko uproszczenie tego, jak działa ten proces. Inne elementy, które należy wziąć pod uwagę, to na przykład wybór technologii/platformy, podejście agencji do ustalania cen, model rozliczeniowy z agencją, licencje, optymalizacje platformy, wybrana architektura aplikacji itd.

Warto być świadomym kosztów projektu eCommerce, gdyż pozwoli nam to lepiej analizować oferty i dobrać odpowiednią technologię i agencję, co znacząco przyczyni się do sukcesu naszego biznesu.

Czym jest funkcjonalność i jak można ją prawidłowo udokumentować?

Mówiąc prościej, funkcjonalność to nic więcej niż dana funkcja eCommerce, która wykonuje określone zadanie. Aby lepiej to zrozumieć, weźmy przykład naszego klienta, Mytheresa:

mytheresa shop

Rozbijając sekcję strony głównej, możemy zobaczyć (od prawej):

  • Funkcjonalność koszyka
  • Lista życzeń (dodaj produkt do ulubionych)
  • Opcja logowania
  • Zmiana języka: Polski / Angielski
  • Kategorie produktów
  • Baner na ekranie głównym strony głównej prowadzi do konkretnej kategorii produktów.

Załóżmy teraz scenariusz badawczy, w którym potrzebujemy szacunkowej ceny za wdrożenie konkretnej funkcji eCommerce. Bez dostarczenia graficznego makiety agencja może interpretować wymagania inaczej. Może to prowadzić do różnych interpretacji zakresu projektu, na przykład:

W jednym projekcie lista życzeń może wyglądać następująco:

Jak widać, ten przykład obejmuje standardową funkcjonalność listy życzeń, wraz z możliwością sortowania produktów na liście życzeń. Jednak w innym projekcie termin „lista życzeń” może być interpretowany inaczej, na przykład:

Innymi słowy, mamy tutaj opcje posiadania wielu list życzeń na jednej platformie handlu elektronicznego, możliwość eksportowania listy życzeń do pliku CSV, opcję zmiany liczby produktów na liście życzeń oraz działania zbiorcze, które umożliwiają nam wykonywanie różnych funkcji, jak wymieniono poniżej:

Dlatego definiując nasze wymagania, powinniśmy skupić się na opisaniu danej funkcjonalności tak precyzyjnie, jak to możliwe. Dobrą praktyką jest opisanie funkcjonalności na tyle szczegółowo, aby nawet mniej doświadczony członek zespołu mógł dokładnie odtworzyć to, co ma robić. Poniżej znajduje się kilka przykładów ilustrujących ten aspekt:

❌ Mój sklep internetowy powinien umożliwiać bezpieczne logowanie i gwarantować każdemu klientowi wygodne robienie zakupów na swoim koncie.

✅ Możliwość zalogowania się do sklepu za pośrednictwem kont Google, Apple i Facebook, z opcją dokończenia zamówienia na etapie realizacji transakcji bez konieczności logowania. Możliwość edycji danych osobowych i zgód marketingowych.

❌ Możliwość zarządzania produktami z poziomu panelu administracyjnego.

✅ Sklep umożliwia dodawanie, edycję i usuwanie produktów. Obsługuje różne kategorie produktów, biorąc pod uwagę wiele atrybutów, kodów, cen i poziomów zapasów.

❌ Obsługa wielu walut i języków.

✅ Sklep jest dostępny w języku angielskim, polskim, francuskim i szwedzkim. Waluty dostępne w sklepie to PLN, EUR i SEK. Język i lokalizacja sklepu są ustawiane automatycznie na podstawie ustawień przeglądarki użytkownika.

Funkcjonalności mogą również dotyczyć innych elementów zaplecza eCommerce:

❌ Nie chcę, aby każdy w zespole miał dostęp do wszystkich informacji w panelu administracyjnym.

✅ Możliwość przypisywania ról i dostępu do wybranych funkcji eCommerce. Chciałbym mieć możliwość przypisania roli superadministratora i utworzenia konta dla pracownika, gdzie będzie miał dostęp tylko do zamówień przychodzących do sklepu.

Chociaż omówione przez nas opisy są poprawne, nadal pozostawiałyby znaczne pole do interpretacji, gdyby zostały przekazane bezpośrednio deweloperowi do wdrożenia. Aby stworzyć naprawdę kompleksową specyfikację, musielibyśmy opisać każdą funkcjonalność jeszcze bardziej szczegółowo.

Ten bardziej precyzyjny opis powinien obejmować sposób, w jaki funkcjonalność powinna się pojawiać na froncie sklepu, sposób, w jaki powinna działać, kryteria akceptacji i szczegółowy opis ścieżki klienta przez funkcję. Jednak w celu oszacowania, ustalenia ceny i porównania technologii poziom opisu przedstawiony powyżej może być całkowicie wystarczający, a rola dalszych zadań wyjaśniających jest zazwyczaj podejmowana podczas dedykowanych warsztatów.

Warsztaty eCommerce „Od wizji do planu”

Dowiedz się więcej

Mając za sobą przegląd funkcjonalności handlu elektronicznego, omówmy teraz, jak przygotować kompleksową dokumentację.

Co powinna zawierać dokumentacja projektu?

Na podstawie setek dokumentacji projektów i wniosków o propozycje, nad którymi pracowaliśmy, poniżej znajduje się ogólna struktura dokumentacji, która zazwyczaj umożliwia efektywny i skuteczny proces składania ofert ze sprzedawcą. Oto przykładowa struktura:

Wprowadzenie/Opis klienta

W tej sekcji warto krótko opisać, kim jesteśmy, jak wygląda nasz biznes lub jak planujemy, aby wyglądał. Chociaż może się to wydawać oczywiste i można to uznać za odpowiedzialność sprzedawcy, aby zbadać te informacje online lub przekazać je zespołowi po spotkaniu, ważne jest, aby pamiętać, że szacowanie projektu obejmuje nie tylko konsultanta obecnego na spotkaniu, ale całą gamę programistów i pracowników w firmie.

Często dokumentacja projektu jest przekazywana innej osobie w celu wyceny. Zapewniając tło w przygotowanym dokumencie, zapewniamy, że osoba wyceniająca projekt zrozumie tło firmy dokładnie tak, jak chcemy, aby zostało przedstawione. Ważne jest, aby uwzględnić kontekst istotny dla realizacji projektu i celów biznesowych, które chcemy osiągnąć zarówno w perspektywie długoterminowej, jak i krótkoterminowej.

Ważne jest, aby jasno zdefiniować, czego potrzebujemy od firmy. Na przykład termin „wdrożenie eCommerce” może obejmować:

  • Przygotowanie projektu sklepu
  • Wdrożenie technologii zaplecza
  • Implementacja front-endu sklepu
  • Konserwacja sklepu po uruchomieniu
  • Usługi SEO i SEM
  • Rekrutacja programistów dla konkretnej technologii po uruchomieniu
  • Wdrażanie systemów PIM, ERP i innych systemów związanych z eCommerce
  • Tworzenie mikrousług
  • i często o wiele więcej…

Dlatego jeśli mamy jakieś szczególne wymagania dotyczące współpracy, warto je tutaj przedstawić. Częstym wymaganiem jest model cenowy projektu. Niektóre firmy wolą pracować w modelu Time & Materials, podczas gdy inne wolą Fixed Price.

Termin składania ofert i przybliżony harmonogram realizacji projektu

Nie jest to obowiązkowy punkt, ale wskazując agencji nasze oczekiwania dotyczące terminu otrzymania szacunków i przedstawiając, jak planujemy rozbić harmonogram projektu, znacznie ułatwiamy pracę agencji przygotowującej szacunki, a także potencjalnie wpływamy na wybór technologii. Na przykład – jeśli potrzebujemy, aby złożony sklep został uruchomiony w ciągu 2 miesięcy, prawdopodobnie nie będziemy w stanie zrobić tego na Magento lub Sylius; zamiast tego będziemy szukać uproszczeń i skłaniać się ku bardziej gotowym rozwiązaniom.

Wymagania funkcjonalne

Kluczową częścią dokumentacji projektu jest opis wszystkich niezbędnych funkcjonalności. Poniżej zamieściliśmy kilka pytań, które początkowo pomogą przygotować listę funkcjonalności, jeśli nie są jeszcze dobrze zdefiniowane. Pamiętaj jednak, aby poprawnie sformułować funkcjonalności, jak wspomniano w poprzednim punkcie.

Model biznesowy

  • Jaki jest model biznesowy projektu? (B2B, B2C, itp.)
  • Jak wygląda model biznesowy sklepu?
  • Czy sprzedaż będzie prowadzona tylko na rynku lokalnym, czy również międzynarodowym? Jeśli międzynarodowym, to na jakie rynki będzie kierowana?
  • Jakie są preferencje dotyczące metod płatności na rynkach docelowych?
  • Czy projekt będzie standardowym rozwiązaniem eCommerce, czy też wielodostawczym rynkiem?
Jeśli jest to Multi-Vendor Marketplace:
  • Kto będzie pełnił rolę sprzedawcy?
  • Ilu dostawców przewidujemy łącznie?
  • Jaki jest model rozliczeń pomiędzy sprzedawcą a administratorem: stała opłata abonamentowa czy prowizja?
  • Jakie funkcjonalności powinien zawierać panel administracyjny dostawcy?

Pytania ogólne

  • Jakie informacje są wymagane przy rejestracji konta przez klienta?
  • W jakich walutach będzie można dokonywać zakupów?
  • W ilu językach ma być dostępny sklep?
  • Ile kanałów sprzedaży będzie obecnych w sklepie?
  • Czy witryna powinna zawierać wyszukiwarkę? Jeśli tak, jak powinna działać i według jakich kryteriów powinna sugerować produkty?
  • Ile osób będzie miało dostęp do panelu administratora i jakie role będą im przypisane?
  • Jakie strony statyczne będą dostępne w sklepie?
  • Jak powinna wyglądać struktura i menu witryny?
  • Czy planujemy wprowadzić w sklepie promocje i programy lojalnościowe?
  • Czy produkty subskrypcyjne będą dostępne w sklepie?
  • Czy w panelu administracyjnym powinna być dostępna opcja podziału użytkowników na role z określonymi uprawnieniami?

Produkty

  • Jakiego rodzaju produkty będą oferowane: fizyczne czy cyfrowe?
  • W jaki sposób planuje się kategorie produktów?
  • Jaka jest liczba produktów i ich wariantów?
  • Czy produkty wymagają personalizacji? Jeśli tak, jakie opcje personalizacji są potrzebne?
  • Gdzie będą przechowywane produkty i w jaki sposób zostaną podłączone do systemu?
  • Gdzie będą przechowywane informacje o zapasach?
  • Jak należy filtrować produkty (np. Elasticsearch)?
  • Czy sklep będzie oferował listę życzeń?
  • Czy przewidujemy cross-selling czy up-selling? Jeśli tak, gdzie powinno się to pojawić?
  • Czy w sklepie będą dostępne pakiety produktów?
  • Czy chcemy mieć „szybki przegląd” produktu po najechaniu kursorem?

Metody Płatności 

  • Czy sklep ma umowę z jakąś bramką płatności?
  • Które bramki płatności są brane pod uwagę?

Logistyka

  • Jak wygląda proces logistyczny i wysyłka produktu w sklepie?
  • Czy są planowane jakieś lokalizacje sklepów stacjonarnych?
  • Jakie opcje dostawy będą dostępne (np. dostawa standardowa, ekspresowa, tego samego dnia)?
  • Czy klienci będą mogli śledzić swoje przesyłki?
  • Jakie są limity dostawy, np. darmowa dostawa powyżej określonej kwoty?

Zamówienia 

  • Jak wygląda cały proces zakupu?
  • Czy przewidujemy możliwość dokonywania zakupów bez logowania?
  • Czy proces zakupu powinien być wieloetapowy czy przyjąć formę realizacji zamówienia na jednej stronie?
  • Czy klienci będą mogli zapisać swój koszyk na później?
  • Czy planujemy przypomnienia o porzuconych koszykach?
  • Czy będzie można edytować zamówienia po ich złożeniu (np. zmieniać adresy, dodawać/usuwać produkty)?

Integracje zewnętrzne

  • Z jakimi narzędziami sklep powinien się zintegrować (CRM, CMS, ERP, PIM, Marketing automation itp.)?
  • Jakie dane będą wymieniane w ramach integracji?
  • Jakie są powody integracji z konkretnymi narzędziami? Jakie potrzeby powinny spełniać te integracje?
  • Czy planujemy integrację z platformami społecznościowymi (np. logowanie za pośrednictwem Facebooka lub Google)?
  • Czy planujemy integrację ze stronami porównującymi ceny (np. Ceneo, Google Shopping)?

Design i UI/UX

  • Kto będzie odpowiedzialny za projekt sklepu?
  • Czy rozważamy wdrożenie headless commerce?
  • Czy sklep powinien działać w modelu PWA (Progressive Web App)?
  • Jakie technologie front-endowe zaleca dostawca?

Marketing i SEO

  • Z jakich narzędzi marketingowych chcemy korzystać (np. automatyczne raporty)?
  • Czy sklep powinien mieć rozbudowane funkcje SEO (np. automatyczne generowanie tagów, przyjazne dla SEO adresy URL)?
  • Czy przewidujemy mechanizmy retargetingu (np. reklamy przypominające o porzuconych koszykach)?
  • Jakie wskaźniki i KPI są kluczowe (np. konwersje, porzucone koszyki)?
  • Czy planujemy funkcjonalność automatycznych raportów sprzedaży?

CMS (Zarządzanie treścią)

  • Czy planujemy elementy dynamiczne na stronie (np. obracające się banery)?
  • Czy przewidujemy możliwość zarządzania treścią przez wielu użytkowników jednocześnie (np. treści w wielu językach)?

Bezpieczeństwo 

  • Jakie są wymogi bezpieczeństwa danych (np. zgodność z RODO)?
  • Czy bierzemy pod uwagę mechanizmy monitorowania podejrzanych działań (np. ochrona przed botami)?

Dodatkowe funkcjonalności 

  • Czy w sklepie będą okienka pop-up?
  • Czy przewidujemy wysyłkę newsletterów?
  • Czy planujemy wdrożenie chatbota?
  • Czy sklep powinien mieć funkcjonalność offline (dla PWA)?
  • Czy przewidujemy API dla aplikacji zewnętrznych?
  • Jakie są wymagania dotyczące skalowalności projektu – ilu użytkowników jednocześnie przewidujemy na początku i w przyszłości?

Na potrzeby tego artykułu przygotowaliśmy również przykład dokumentacji funkcjonalności eCommerce. Pamiętaj, że tylko przykład – Twoja dokumentacja może być mniej lub bardziej obszerna.

Podsumowanie

Przygotowanie dokumentacji funkcjonalnej przed spotkaniem z agencją wdrożeniową to kluczowy krok, który przynosi wiele korzyści. Poprzez prawidłowe wyszczególnienie funkcjonalności eCommerce, które planujesz wdrożyć, zapewniasz:

  • Lepsze zrozumienie swoich potrzeb — proces spisywania wymagań pomaga uporządkować myśli i lepiej określić cele projektu.
  • Dokładniejsza wycena – Dzięki precyzyjnie opisanym funkcjonalnościom agencje mogą dokładniej oszacować czas i koszty wdrożenia.
  • Możliwość porównywania ofert i technologii – Posiadanie jednolitej dokumentacji ułatwia porównywanie różnych ofert i podejść technologicznych.
  • Mniejsze ryzyko nieporozumień — przejrzysta dokumentacja pozwala uniknąć niejasności między Tobą a agencją, co przyspiesza proces wdrażania projektu.
  • Oszczędność czasu — dokumentacja eliminuje potrzebę wielokrotnego wyjaśniania wymagań agencji i pozwala na szybsze przejście do fazy wdrożenia.

Dokumentacja funkcjonalna jest również kluczowa w kontekście bardziej złożonych projektów, takich jak marketplace’y lub sklepy B2B, gdzie precyzyjne opisy funkcjonalności mają kluczowe znaczenie. Dzięki odpowiedniemu przygotowaniu i szczegółowemu opisowi możesz stworzyć fundament, który pomoże nie tylko w ustalaniu cen, ale także w przyszłym sukcesie Twojego przedsięwzięcia eCommerce.

Jeśli szukasz firmy zajmującej się rozwojem handlu elektronicznego, sprawdź nasze usługi eComemrce >>