Moskwa nam pomoże

Branża e-commerce charakteryzuje się częstymi zmianami. Sprzedawca, którego sklep internetowy nie jest atrakcyjny dla klientów, nie tworzy przewagi nad swoją konkurencją. Nasuwa się zatem pytanie: Co mam zrobić, aby mój sklep wyróżniał się na tak konkurencyjnym rynku? Odpowiedź wydaje się dziecinnie prosta – zapewnić ponad przeciętną jakość obsługi klienta.

Chcąc być krok przed konkurencją, należy stale udoskonalać proces obsługi klienta oraz zapewnić sobie możliwość szybkiego wdrażania wszelkich usprawnień. Im bardziej jesteśmy wyczuleni na nowe potrzeby klientów i szybciej zareagujemy od strony funkcjonalnej, tym większe są nasze szanse na utrzymanie wysokiej pozycji sprzedażowej. Tylko jak zapewnić sobie możliwość szybkich, częstych zmian, dostosowania sklepu do wymagań rynku i klientów już na etapie podjęcia decyzji o wdrożeniu rozwiązania e-commerce?

Popłynąć czy wypłynąć?

Jedną z kluczowych decyzji, jaką należy podjąć przed przystąpieniem do realizacji projektu e-commerce, jest wybór metodyki, w jakiej ten projekt będzie zarządzany. Obecnie są dwa dominujące podejścia: klasyczne (Waterfall) oraz zwinne (Agile). Różnice pomiędzy podejściem zwinnym a tradycyjnym można rozpatrywać w kilku kategoriach począwszy od kultury pracy, a skończywszy na sposobach planowania terminów i szacowania kosztów. Obie metodyki różnią się na wielu płaszczyznach, szczególnie zaś swoim przeznaczeniem.

Waterfall to podejście nadająca się idealnie do projektów mających bardzo niskie prawdopodobieństwo zmiany zakresu wymagań w trakcie trwania projektu. Mam tutaj na myśli proces tworzenie oprogramowania dla programów bazujących na regulacjach prawnych (np. programy księgowe), oraz aplikacji, gdzie muszą byś spełnione wysokie wymagania bezpieczeństwa. Niestety, w projektach e-commerce, model ten ma niewielkie szanse na to, aby projekt zakończył się sukcesem. Z naszych doświadczeń wynika, że firmy najczęściej nie mają dobrze sprecyzowanych wymagań. Dlatego są one rozwijane, doprecyzowane, modyfikowane, usuwane, dodawane kolejne, w trakcie trwania projektu. Z czego to wynika? Otóż z szybko zmieniających się realiów otoczenia biznesowego naszych klientów. Specyfika projektów e-commerce wymusza niejako konieczność ciągłego modyfikowania zakresu projektu, a to stoi w sprzeczności z założeniami Waterfall.

Jeśli modyfikacje nie zostałyby wprowadzone, finalnie wdrożone rozwiązanie będzie miało niską wartość biznesową. Decydując się jednak na modyfikacje przy podejściu klasycznym, cofamy się w najgorszym wypadku do fazy “Planowanie”, narażając się tym samym na znaczący wzrost kosztów oraz wydłużenie czasu realizacji. W Waterfall zmiany nie są pożądane. Zdecydowanie odradzamy naszym klientom klasyczne podejście do realizacji projektów e-commerce. Zupełnym przeciwieństwem Waterfall jest podejście zwinne (Agile), określane mianem zwinnego podejścia projektowego. Tutaj zmiany są pożądane – im więcej tym lepiej.

Aby dobrze zrozumieć różnice między podejściem klasycznym a zwinnym na płaszczyźnie wymagań projektowych, musimy rozróżnić w obu podejściach wartości stałe od zmiennych. Najlepiej odzwierciedla to diagram. Co prawda jest on zaczerpnięty z metody Dynamic Systems Development Method, należącej do grupy metod zwinnych (Agile), jednak według mnie jest on właściwy we wszystkich metodach zwinnych. W metodach Agile jedyna wartość, która jest zmienna, to zakres wymagań projektowych. Koszt, czas realizacji i jakość to stałe zgodne z przyjętymi założeniami przed rozpoczęciem projektu.

W podejściu klasycznym jedyną niezmienną (znaną od początku) wartością jest zakres wymagań projektowych. Koszt, czas realizacji, jak i jakość jest zmienna – nawet jeśli nie zostanie wprowadzona żadna modyfikacja do zakresu wymagań. Dlaczego? Ponieważ w metodzie tej estymację wykonuje osoba, która nie będzie później wdrażać rozwiązania. Od tego jest zespół deweloperski. Skutkuje to tym, że ustalenie przez wspomniany zespół deweloperski dokładnego czasu realizacji zadań, których wykonanie nastąpi za miesiąc, dwa, czy za rok jest niewykonalne. Nie ma przecież możliwości zidentyfikowania wszystkich utrudnień, jakie deweloperzy napotkają podczas procesu wdrożeniowego. Mało tego, praca programisty to praca twórcza, która nie może być wykonywana ciągle z taką samą wydajnością. W efekcie przekroczony zostaje zaplanowany czas realizacji, co automatycznie podnosi koszty. W końcu przez cały czas trzeba płacić zespołowi projektowemu. Jednocześnie widocznie spada jakość. Dlaczego? Ponieważ zespół przekraczając ustalony czas realizacji będzie dążył do możliwie najszybszego oddania projektu. Oznacza to najczęściej, że tworzone przez programistów rozwiązania nie będą przechodzić wystarczająco dokładnych testów, które pozwalają wyeliminować potencjalne błędy w działaniu aplikacji.

Moskwa moim przyjacielem!

Spokojnie, nie będę pisać o Moskwie, choć to piękne miasto. Aby lepiej zaplanować proces dostarczenia produktu o wysokiej wartości biznesowej, należy użyć metody, która pozwoli efektywnie zarządzać priorytetami wymagań. Szczególnie dobrze do tego celu nadaje się metoda MoSCoW, której pomysłodawcą jest Dai Clegg. Mimo, że została zaadoptowana do metodyki Dynamic Systems DevelopmentMethod (DSDM) można ją zastosować w ramach innych metod. Nazwa MoSCoW jest akronimem i powstała od pierwszych liter poziomów wymagań Must have, Should have, Could have, Won’t this time. Literka „o” pełni tylko rolę łącznika, dzięki czemu stworzono słowo łatwe do wymówienia.

MoSCoW jest prosty w użyciu i bardzo czytelny. Każda postronna osoba, bez zbędnych wyjaśnień jest w stanie stwierdzić, które elementy będą stanowiły nasze MVP i jakie wymagania będą jego rozwinięciem.

Czy wszystkie wymagania w projekcie mają poziom must have?

Wśród klientów panuje często przeświadczenie, że cały zakres projektu ma najwyższy priorytet (Must have). Jak wiadomo – nigdy tak nie jest. W każdym projekcie istnieje znaczna część wymagań, które
nie muszą być wdrożone w pierwszej wersji. Te, które są wdrażane nie muszą mieć ostatecznego/zaplanowanego kształtu. Mogą przyjąć uproszczoną formę, składającą się na biznesowo wartościowy produkt (nasze MVP). Dzięki takiemu podejściu szybciej udostępnimy produkt użytkownikom końcowym i otrzymamy informację zwrotną. Aby uniknąć sytuacji w której nagle wszystkie wymagania w projekcie mają poziom Must have wprowadzono zasadę. Mówi ona, że wymagania Must have mogą stanowić maksymalnie 60% wszystkich wymagań. Pierwsze, co przychodzi na myśl, to podział wymagań według ilości zadań. Jest to błędne założenie. Podziału należy dokonać w odniesieniu do złożoności i pracochłonności realizacji zadań. Najlepiej aby wycenę tą robić w jednostkach oderwanych od czasu realizacji np. w Story Points.

Podsumowanie

Rozpoczynając projekt e-commerce kluczowym jest, aby jak najszybciej doprowadzić do powstania produktu w wersji MVP, który zweryfikuje, jak bardzo nasz projekt jest atrakcyjny w oczach przyszłych klientów. Zasada ta nie powinna być stosowana tylko do nowych projektów. Takie samo założenie można zastosować modyfikując funkcjonalności w już istniejących rozwiązaniach e-commerce. MoSCoW jest metodą upraszczającą podział wymagań, które mają być zrealizowane w ramach projektu e-commerce. Wszystkie wymagania przypisane do priorytetu Must have stanowią produkt w wersji MVP. Nie jest sztuką zrealizować projekt. Sztuką jest zrealizować projekt, którego wynikiem będzie produkt zaakceptowany przez klientów.