Większość projektów eCommerce, które przekraczają budżet lub miną się z terminem, nie kuleje z powodu problemów technicznych. Kod działa, integracje są budowane, a zespół dostarcza to, o co został poproszony. Prawdziwe straty - te, które narastają miesiącami i są bardzo kosztowne do naprawienia - mają zwykle jedno źródło, które rzadko trafia do projektowych podsumowań: klient nie podejmuje decyzji na czas.
To nie jest wygodna obserwacja i nie jest wymierzona w żadnego konkretnego klienta. To wzorzec, który pojawia się regularnie i który większość doświadczonych zespołów projektowych zna doskonale. Technologia radzi sobie z dużą złożonością. Z czym sobie nie radzi, to brak decyzji tam, gdzie powinny zapadać.
Czym tak naprawdę jest brak decyzyjności w projekcie
Warto tu rozróżnić kilka rzeczy, bo ten problem jest często mylnie interpretowany. Klient, który ma trudności z podejmowaniem decyzji, niekoniecznie jest trudnym lub zdezorganizowanym partnerem. W większości przypadków przyczyna jest strukturalna, a nie personalna: nie ma jednej osoby, która podejmuje kluczowe decyzje, odpowiedzialność jest rozproszona między kilkoma osobami lub działami, a wszystko, co wymaga wyboru, jest po cichu odkładane na później.
Efektem rzadko kiedy jest to, że decyzje są podejmowane źle. Częściej po prostu nie są podejmowane wcale, albo pojawiają się tak późno, że projekt zdążył już pójść dalej i musi się cofnąć żeby je uwzględnić.
Co ważne, nie chodzi tu o złe intencje. Wielu klientów, którzy odkładają decyzje, nie robi tego, żeby utrudniać projekt. Po prostu utknęli w wewnętrznych procesach i innych priorytetach firmy. Ten kontekst nie sprawia, że opóźnienia są mniej kosztowne, ale zmienia to, jak należy podejść do rozwiązania problemu.
Cztery etapy, w których brak decyzyjności jest najbardziej szkodliwy
Większość projektów eCommerce przechodzi przez te same fazy: Discovery, Projektowanie/Design, Development i Testy. Brak decyzji wpływa na każdą z nich trochę inaczej. Niektóre etapy mogą „wchłonąć” opóźnienie i wrócić na właściwy tor bez większych konsekwencji, inne nie - a koszt niepodjętej decyzji przenosi się bezpośrednio na kolejną fazę.
1. Discovery
Na etapie Discovery klient nie tylko odpowiada na pytania i potwierdza ogólne założenia projektu. Opisuje on też, jak działa jego biznes, wymienia potrzebne funkcjonalności, tłumaczy procesy firmowe i często dzieli się szerszą wizją projektu. To dużo materiału do omówienia, a działa to tylko wtedy, gdy ktoś po stronie klienta ma faktyczne upoważnienie do zamykania tematów w trakcie rozmowy.
Warsztaty są właśnie po to, żeby zdefiniować zakres projektu, zanim ruszy development. Gdy kręcą się w kółko, to zazwyczaj pierwszy wyraźny sygnał, że nikt po stronie klienta nie ma autorytetu, żeby powiedzieć: „Skupmy się na budowaniu X i potem przejdziemy do Y".
2. UX i architektura
Projektowanie to nie tylko estetyka - ma bezpośredni wpływ na to, jak klienci korzystają z platformy i jak ją odbierają. Właśnie dlatego decyzje projektowe nie mogą czekać w nieskończoność. Kierunek wybrany zbyt późno, pod presją, przy połowie ludzi wciąż niezgodnych, rzadko kiedy daje spójny efekt, który był celem od początku.
To samo dotyczy decyzji związanych z architekturą. Gdy wybór między dwoma podejściami technicznymi jest ciągle przekładany, zespół deweloperski albo czeka, albo podejmuje decyzję sam. Żaden z tych scenariuszy nie jest dobry i oba generują ryzyko, które ujawnia się później w projekcie.
3. Development
W trakcie fazy developmentu normalne jest dokładne przemyślenie wdrażanych funkcjonalności i integracji. Problemy zaczynają się wtedy, gdy raz podjęte decyzje są regularnie cofane. Funkcjonalność potwierdzona w drugim tygodniu jest kwestionowana w szóstym, bo ktoś, kto nie był na pierwotnym spotkaniu, ma inne zdanie. Praca wykonana na podstawie pierwotnej decyzji jest częściowo lub całkowicie zmarnowana, a zespół zaczyna od nowa.
Tego rodzaju przeróbki są jedną z najkosztowniejszych rzeczy, które mogą przydarzyć się w projekcie - nie dlatego, że każda pojedyncza zmiana jest dramatyczna, ale dlatego, że się kumulują. Podważają też zaufanie zespołu do stabilności tego, co buduje, co przekłada się na tempo pracy i morale po obu stronach.
4. Testy i feedback
Końcowe etapy projektu są miejscem, gdzie opóźnione decyzje stają się najbardziej widoczne. Przed rozpoczęciem testów obie strony muszą uzgodnić, co oznacza „gotowe" - co przechodzi, co nie i co wykracza poza zakres bieżącego wydania.
Opóźniony feedback dodatkowo to komplikuje, bo mogą pojawić się uwagi, które otwierają na nowo funkcjonalności odebrane miesiące wcześniej, zamieniając prawie ukończony projekt w trwające negocjacje. Release się blokuje nie dlatego, że praca nie została wykonana, ale dlatego, że kryteria jej przyjęcia nigdy nie zostały właściwie ustalone.
Najczęstsze przyczyny braku decyzyjności
Jak już wspomnieliśmy, najczęstsza przyczyna jest prosta. Po stronie klienta nie ma jednej wyznaczonej osoby odpowiedzialnej za decyzje nt. projektu. Bez niej każda ważna decyzja staje się zadaniem grupowym. Grupy działają wolno i mają tendencję do szukania kompromisu zamiast decydowania, co zazwyczaj prowadzi do wymagań, które próbują objąć zbyt wiele naraz.
Do tego dochodzi sytuacja, gdy każdy dział - sprzedaż, IT, marketing - ma coś do powiedzenia, ale żaden głos nie ma decydującego zdania. Projekt wchłania napięcia między nimi. Strach przed podjęciem złej decyzji prowadzi do odkładania jej na później, szczególnie w organizacjach, gdzie błędy są traktowane jak porażki, a nie jako naturalny element procesu decyzyjnego. A powszechny cel zadowolenia wszystkich zaangażowanych rozszerza wymagania zamiast je precyzować.
Jak rozpoznać problem na wczesnym etapie
Sygnały ostrzegawcze pojawiają się na długo przed tym, zanim projekt znajdzie się w poważnych tarapatach - w wielu przypadkach widać je już w trakcie rozmów sprzedażowych. Potencjalny klient, który nie potrafi wskazać jednej osoby odpowiedzialnej za projekt, który daje różne odpowiedzi w zależności od tego, kto jest na spotkaniu, albo który na bezpośrednie pytania konsekwentnie odpowiada „musimy to wewnętrznie uzgodnić" - pokazuje dokładnie, jak będzie wyglądał projekt.
Inne sygnały to trudności z priorytetyzacją wymagań. Podejście typu „wszystko jest tak samo ważne" to z pewnością nie najlepszy sposób prowadzenia projektu. Warto też zwrócić uwagę na zakres, który rozszerza się za każdym razem, gdy decyzja jest blisko podjęcia, albo na wzorzec zgadzania się na spotkaniach i powracania z innymi poglądami po wewnętrznych dyskusjach. To nie są oznaki złego partnera. To sygnały, że wewnętrzna struktura decyzyjna klienta wymaga uporządkowania, zanim projekt się rozpocznie.
Konsekwencje braku decyzyjności w projekcie eCommerce
Najbardziej widoczną konsekwencją jest opóźnienie, choć nie jest ono najpoważniejsze. Przesunięcie harmonogramu można przynajmniej zobaczyć i zakomunikować. Wzrost kosztów, który za nim idzie, jest już trudniejszy do uchwycenia i jeszcze trudniejszy do powiązania z konkretnym źródłem. Decyzje podejmowane na siłę pod koniec projektu - bo były odkładane zbyt długo i nie mogą już czekać - są prawie zawsze gorszej jakości niż te podejmowane z czasem i pełną informacją. Zespół jest pod presją, opcje się zawęziły, a efekt to odzwierciedla.
Poza liczbami, projekt, który znacząco przekracza czas i budżet z powodu opóźnionych decyzji, zwykle kończy się frustracją po obu stronach, nawet gdy strona techniczna była solidna. Klient czuje, że projekt kosztował więcej niż się spodziewał. Agencja czuje, że wykonała go dobrze, ale jest obwiniana o okoliczności, na które nie miała wpływu. Z takiej dynamiki trudno się podnieść, a jest ona w pełni do uniknięcia.
Dlaczego brak decyzyjności boli bardziej w eCommerce B2B
Projekty eCommerce B2B są z natury bardziej złożone niż B2C, co sprawia, że każda opóźniona decyzja ma tu większą wagę. Więcej działów, więcej konkurujących priorytetów i więcej niestandardowych scenariuszy, które nie mieszczą się w standardowym zachowaniu platformy. Proces, który działa dla jednego segmentu klientów, może wymagać zupełnie innego podejścia dla kolejnego.
Do tego dochodzi zależność od systemów zewnętrznych. Logika cenowa, stany magazynowe i zarządzanie zamówieniami często „żyją" w systemie ERP, co oznacza, że decyzja o tym, jak platforma ma obsługiwać konkretny proces, nie może zapaść bez zrozumienia, jak ten system jest skonfigurowany. Gdy takie pytanie pozostaje bez odpowiedzi, nie opóźnia tylko jednego zadania czy modułu. Opóźnia wszystko, co jest z nim powiązane, a w platformie B2B większość rzeczy jest ze sobą powiązana.
Jak stworzyć warunki do sprawnego podejmowania decyzji
Z naszego doświadczenia wynika, że najskuteczniejsze działania można podzielić na trzy obszary - po stronie klienta, po stronie agencji i na poziomie samego procesu.
Po stronie klienta
Najbardziej skuteczna zmiana strukturalna to wyznaczenie jednej osoby jako właściciela projektu z realną możliwością podejmowania decyzji. Ta osoba nie musi być wysoko postawiona, ale musi mieć uprawnienia do zamykania kwestii bez konieczności eskalowania każdej sprawy wyżej.
Jedną z najskuteczniejszych rzeczy, które klient może zrobić przed rozpoczęciem współpracy z agencją, jest przeprowadzenie wewnętrznego warsztatu, żeby uzgodnić priorytety w swoim zespole i uzgodnić, kto jest odpowiedzialny za konkretne decyzje. Dzięki temu pierwsze spotkanie z zespołem deweloperskim dotyczy budowania, a nie rozwiązywania wewnętrznych nieporozumień.
Po stronie agencji
Cierpliwość z pewnością nie jest właściwą odpowiedzią na brak decyzyjności. Wyznaczenie konkretnego terminu, po którym zespół przechodzi do realizacji z udokumentowaną rekomendacją, utrzymuje projekt w ruchu i sprawia, że koszt opóźnienia staje się precyzyjny.
Zamiast przedstawiać otwarte opcje i czekać, aż klient wybierze, doświadczone zespoły rekomendują kierunek i wyjaśniają rozumowanie stojące za tym wyborem. To jest bardziej użyteczne dla klienta, który ma trudności z podjęciem decyzji, niż lista równoważnych alternatyw bez wyjaśnienia, która jest lepsza i dlaczego. Dokumentowanie każdej decyzji - kto ją podjął, kiedy i na jakiej podstawie - chroni obie strony, gdy decyzja jest później kwestionowana.
Na poziomie procesu
Pomocna jest tu ustrukturyzowana metoda, na przykład MoSCoW (Must-have, Should-have, Could-have, Won't-have). Gdy każde wymaganie musi zostać przypisane do konkretnej kategorii, rozmowa przesuwa się od „wszystko jest ważne" do „co faktycznie potrzebujemy, żeby wystartować". Kompromisy stają się widoczne, a ich unikanie trudniejsze.
Iteracyjne podejście do developmentu jest również bardzo ważne. Zamiast próbować zdefiniować i zbudować wszystko naraz, zaczynanie od najbardziej krytycznych funkcjonalności i podsumowywanie ich w krótkich cyklach daje klientowi coś konkretnego, na co może reagować. Znacznie łatwiej jest podjąć decyzję, mając przed sobą działający prototyp, niż zatwierdzać pełny projekt wyłącznie na podstawie dokumentacji.
Podsumowanie
Warto pamiętać, że projekty eCommerce rzadko upadają przez złą decyzję. Błędny wybór, zwłaszcza na wczesnym etapie, można skorygować - większość doświadczonych zespołów wie, jak to zrobić bez dużych kosztów.
Czego nie można skorygować, to decyzja, która nigdy nie została podjęta. Ta nieobecność cicho narasta - zamienia się w założenia, założenia w zależności, a zależności w problemy, których naprawienie kosztuje znacznie więcej niż podjęcie pierwotnej decyzji.
Brak decyzji jest sam w sobie decyzją - i konsekwentnie jest tą najdroższą z dostępnych.
<div class="rtb-text-box is-blue-50">Nasze warsztaty eCommerce pomagają uporządkować wizję projektu, określić realny zakres MVP i lepiej zrozumieć potrzeby biznesowe jeszcze przed rozpoczęciem wdrożenia. Dzięki doświadczeniu zespołu BitBag wspólnie analizujemy cele, procesy i wyzwania, aby zaplanować rozwiązanie dopasowane do specyfiki Twojego biznesu. To także przestrzeń, w której pomagamy rozwiać wątpliwości związane z wyborem technologii, funkcjonalności czy dalszego kierunku rozwoju platformy. Jeśli Twój projekt jest jeszcze na etapie planowania lub potrzebujesz wsparcia w podjęciu kluczowych decyzji, nasze warsztaty będą dobrym pierwszym krokiem.</div>
{{cta-service-workshop="/pl/comp/cta"}}
