Analiza przedwdrożeniowa – z czego się składa? cz. II

Przygotowanie analizy przed wdrożeniem dużego projektu e-commerce to nie lada wyzwanie, zarówno dla agencji, jak i przedsiębiorstwa. Czy to konieczność oraz jakie firmy powinny zdecydować się na analizę pisaliśmy tutaj, natomiast tutaj znajduje się pierwsza część artykułu nt. elementów analizy. Temat szeroki, ale zdecydowanie warto go zgłębić. 

 

Procesy biznesowe

Zebranie procesów biznesowych zachodzących w firmie oraz dokładne ich opisanie to pierwszy najważniejszy etap analizy przedwdrożeniowej. Przykładami takich procesów są: ofertowanie, realizowanie zamówień, realizowanie dostaw itp.

Bardzo często jest tak, że dana organizacja działając od wielu lat na rynku ma świetnie wypracowane metody działania, natomiast nie są one w żaden sposób spisane. Każdy w organizacji zna swoje zadania i obowiązki, a przepływ informacji odbywa się właściwie.
Aby jednak firma wdrażająca e-commerce mogła odwzorować procesy w systemie do sprzedaży on-line, konieczne jest opisanie ich oraz usystematyzowanie w jednym dokumencie.

W zależności od opisywanego procesu należy przeprowadzić wiele rozmów i spotkań z osobami w dany proces zaangażowanymi i “wyciagnąć” od nich informacje dla nich oczywiste, a dla projektantów e-commerce kluczowe tj. detale dotyczące ich codziennej pracy oraz wykonywania określonych czynności.

Musimy wiedzieć kto w poszczególnych procesach bierze udział, jak długo one trwają, jaka jest droga przepływu danej informacji, na których etapach uczestniczy w procesie Klient docelowy oraz co dostaje itd. Dopiero posiadając te informacje wdrożeniowcy mogą prawidłowo zaprojektować działanie e-commerce w firmie, czyli odwzorować procesy lub zaprojektować je na nowo zgodnie z celem.

Wymagania funkcjonalne

Wymagania funkcjonalne to wymagania dotyczące istnienia lub braku danej funkcji. Zebrane zostają tu funkcje, które mają się pojawić w systemie, jak również te, których na pewno ma nie być (one pojawiają się także w części pt. Ograniczenia).
Określenie czego ma nie być w systemie jest tak samo ważne, jak określenie co musi się w nim znaleźć.
Znając wszystkie wymagania funkcjonalne możliwe jest określenie ich kosztów oraz podjęcie decyzji czy będą ostatecznie zrealizowane czy nie oraz na którym etapie.

Wymagania jakościowe

Określają jakość wykonania danej funkcji oraz sposób jej realizacji. Przykładem takiego wymagania jakościowego może być szybkość ładowania strony lub jej waga.

Wymagania funkcjonalne są bardziej techniczne i “twarde”, natomiast jakościowe są zdecydowanie bardziej “miękkie” i elastyczne.

Wymagania jakościowe są zależne od funkcjonalnych i na odwrót, muszą współgrać z nimi np. wymaganiem jakościowym jest grafika nawiązująca do wybranego motywu. Wiele firm może wykonać bardzo zaawansowaną grafikę, dodać odpowiednie widgety i w ten sposób spełnić to wymaganie, jednak w momencie, gdy część treści nie będzie widoczna dla Google, wtedy nie będzie spełnione wymaganie funkcjonalne SEO lub będzie sprzeczne z innym wymaganiem jakościowym, np. strona będzie się wczytywała w 20 sekund.
Warto także umieścić informację na temat braku wymagań jakościowych w stosunku do danych wymagań funkcjonalnych, po to, aby było to jasne dla obu stron.

Interfejsy użytkownika

Interfejsy Użytkowników określają jak system łączy się ze swoimi Użytkownikami. Każda grupa Użytkowników ma inne wymagania i potrzeby, w związku z czym system posiada wiele interfejsów, dostosowanych do potrzeb danej grupy.

W tej części analizy określamy jakie uprawnienia i funkcjonalności będą posiadały poszczególne interfejsy, a także przygotowywane są wizualizacje i prototypy każdego z nich, np. strona towaru, strona producenta, strona kategorii.

Przygotowując interfejsy Użytkowników na etapie analizy jesteśmy w stanie zachować spójność z wymaganiach funkcjonalnymi i jakościowymi. Grafik włącza się do komunikacji w projekcie w momencie, gdy wszystkie wymagania są ustalone i zebrane, dzięki czemu dokładnie wiemy jak dany interfejs ma wyglądać, zarówno frontend, jak i backend tj. panel administracyjny.

Interfejsy programowe

Interfejsami programowymi są wszystkie integracje tj. sposób w jaki platforma e-commerce (np. Extreme Commerce) przeprowadza komunikację jedno lub dwustronną z zewnętrznymi aplikacjami np. programami księgowymi, magazynowymi, produkcyjnymi, ale także z programami wspierającymi e-commerce np. Google Analitycs, live chaty czy porównywarki cenowe.

Jest to zarówno opisywane, jak i wizualizowane w formie czytelnych diagramów np. schemat generowania etykiet na produkcji.

 

Interfejsy sprzętowe

W tej części określamy w jaki sposób platforma e-commerce komunikuje się bezpośrednio z jakimś sprzętem np. ze skanerem (urządzenie wejścia) lub z drukarką etykiet (urządzenie wyjścia).

Ograniczenia

Tutaj umieszczamy, wspomniane przy okazji wymagań funkcjonalnych i jakościowych, elementy, które nie pojawią się w projektowanej platformie e-commerce. Istnienie pewnych funkcjonalności w systemie może wydawać się oczywiste dla Klientów, tak jak brak niektórych z nich, stąd konieczność jasnego wypunktowania funkcjonalności, które nie zostaną wdrożone.
Np. brak dostępności aplikacji na smarwatch`ach, brak wersji językowych, brak rejestracji dla Klientów przed dokonaniem zakupów.

Ograniczenia mogą być jednocześnie ułatwieniami w realizacji projektu, gdyż często brak określonych funkcjonalności będzie powodować większą elastyczność systemu, realizacja będzie mniej skomplikowana i dzięki temu także tańsza, np.

  • wyłączenie monitorowania zmian w cennikach, które wykonywane są z dużą częstotliwością. Dzięki temu system nie jest obciążony, działa szybciej.
  • ograniczenia dostępności serwisu do 95%, co także pozwala wprowadzić znaczące oszczędności.

Szukanie oszczędności odbywać się wspólnie z Klientem, gdyż to on najlepiej zna firmę, jej otoczenie i potrzeby związane z działalnością.

Testy

Testy realizowane są na poziomie całego projektu oraz na poziomie poszczególnych zadań. Opisanie planowanych testów daje Klientowi pewność, że system projektowany jest z dużą dbałością o szczegóły i utrzymanie wysokiej jakości.

  • Testy wydajnościowe wykonywane są na ogół na końcu projektu, gdy wtedy mamy gotowy, działający system ze wszystkimi jego funkcjonalnościami i możliwe jest całościowe spojrzenie na system, zależności zachodzące między poszczególnymi jego elementami. Wykonując testy wcześniej, konieczne byłoby oparcie się jedynie o prototypy i przyjęte założenia.
  • Testy jednostkowe – wykonywane są praktycznie przez cały czas realizacji projektu przez programistów. Ich celem jest sprawdzenie czy podstawowe elementy danego modułu działają prawidłowo. Dopisywane są one do poszczególnych funkcji systemu, np. w module koszyka muszą być przetestowane pewne stałe elementy, jak choćby nierealizowanie zamówienia przy wartości 0. Testy wykonywane są za każdym razem, przy wprowadzeniu każdej kolejnej zmiany. Są one zautomatyzowane i pozwalają na zachowanie spójności pomiędzy poszczególnymi modułami.
  • Testy akceptacyjne – ich celem jest sprawdzenie czy to co zamawiał Klient zostało zrealizowane. Mogą być realizowane zarówno przez nas, jak i przez Klienta. Polegają na ponownym “przejściu” wymagania po wymaganiu i określeniu czy zostały one zrealizowane czy nie. Wykonanie wymagań funkcjonalnych określane jest zero-jedynkowo.
    Możliwe jest także wykonanie testów akceptacyjnych przez Klienta. Wtedy należy uzgodnić z nim przebieg testów, abyśmy przed oddaniem aplikacji, testowali ją dokładnie w ten sam sposób, w jaki zrobi to Klient.
    Trzecią opcją jest włączenie Klienta w testy wykonywane przez nas, tj. Klient ma wgląd w pracę testera na każdym etapie.
  • Dodatkowo w ramach testów tworzone są checklisty. Działają one podobnie do testów jednostkowych, tyle, że te realizowane są przez programistę, natomiast checklisty przez testera. Ustalana jest lista funkcji, która jest testowana przy każdej, nawet najprostszej, zmianie wprowadzanej do systemu. Pomaga to eliminować błędy na bieżąco. Dzięki temu Klient wie, że strategiczne dla niego funkcjonalności zawsze działają prawidłowo. Do podstawowej checklisty, stworzonej na początku projektu, w miarę rozwoju projektu dodawane są kolejne istotne punkty, gdyż np. pojawiają się błędy, których nie byliśmy w stanie przewidzieć. Przeprowadzenie testów zgodnie z checklistą trwa, natomiast z drugiej strony daje pewność i bezpieczeństwo prac nad projektem.

Podsumowanie projektu

Analiza powinna zawierać także podsumowanie projektu tzn. opis zawierający jego cel, narzędzia, które zostaną użyte, kluczowe funkcjonalności, które znajdą się w systemie oraz, ramowy harmonogram działań.
Dzięki podsumowaniu wszyscy obecni, ale także przyszli Użytkownicy aplikacji mogą zapoznać się z podstawowymi informacjami na temat wdrożenia, a w razie konieczności mają możliwość poszerzyć wiedzę zapoznając się z wybranym fragmentem lub całością analizy.

 

 

 

 

best.net