Dzisiaj zajmiemy się pytaniem dotyczącym samego funkcjonalnego podejścia do tego, jak podzielić etap tej tzw. analizy biznesowej. Czy na samym początku warto zainwestować więcej w analizę biznesową czy może wystarczy nam mniejsza analiza biznesowa, a większość rzeczy ustalimy w trakcie realizacji projektu?
Czy warto zainwestować więcej w analizę biznesową na początku projektu?
Co to jest analiza biznesowa?
Dwa podejścia do analizy biznesowej w świecie ecommerce
Które podejście jest dobre w przypadku ecommerce’u?
Analiza biznesowa w ecommerce – podsumowanie
Czy warto zainwestować więcej w analizę biznesową na początku projektu?
Jak zawsze na samym początku prosta odpowiedź na to trudne biznesowe pytanie.
Jeśli mówimy o projektach wdrożeniowych sklepów internetowych albo platform B2B na Magento, to biorąc pod uwagę obecne otoczenie gospodarcze, w którym dyrektorzy ecommerce i właściciele biznesów mierzą się z większą niepewnością, powinniśmy zrobić zdecydowanie większą analizę biznesową na samym początku, aby zwiększyć swoje bezpieczeństwo finansowe.
To jest prosta odpowiedź na to trudne pytanie biznesowe. Zachęcam wszystkich do czytania dalej, aby pogłębić wiedzę.
PS. Czasami analiza biznesowa jest nazywana fazą discovery. W tym artykule będę używał tych pojęć zamiennie.
Co to jest analiza biznesowa?
Analiza biznesowa to etap projektu, w którym dokładnie określamy, jak ma wyglądać docelowy system, jak ma działać i jak ma wyglądać.
Powiedziałbym, że jeśli chodzi o efekty tej analizy biznesowej, powinno być ich kilka.
- Pierwszym punktem jest stworzenie i opisanie architektury całego systemu.
Powinniśmy wiedzieć jakie narzędzie, aplikacje i rozwiązanie są odpowiedzialne za co, jak się łączą, jakiego rodzaju dane są przekazywane z jednego systemu do drugiego.
- Drugim punktem są wymagania biznesowe, które powinny być sformułowane i opisane w formie epic i user stories.
W skrócie są to opisy funkcjonalności i wymagań biznesowych, które powinny być zrozumiałe dla każdego na każdym poziomie doświadczenia i dla całego zespołu projektowego.
- Każdy user story powinien mieć kryteria akceptacyjne.
Powinniśmy wiedzieć, jak ma działać poszczególna funkcjonalność i jak ona powinna funkcjonować, abyśmy na koniec dnia mogli powiedzieć, że spełnia ona kryteria, które określiliśmy sobie na samym początku.
- Ostatnim punktem są projekty graficzne.
Wydaje mi się, że rozsądne minimum to, że te projekty graficzne powinny być przygotowane w co najmniej dwóch rozdzielczościach, czyli typowe pod mobile oraz pod desktop. Powiedzmy coś około 368 pikseli oraz coś około 1280.
Powinniśmy mieć stronę główną, listingi, wyniki wyszukiwania, kartę produktu, koszyk, checkout, stronę mojego konta, stronę podziękowania, szablon stron CMS oraz widoki, które powinny zabierać wszystkie potrzebne stany, takie jak hoovery, walidacje, puste wyniki filtrowania itd.
To są minimalne efekty tej analizy biznesowej.
Dwa podejścia do analizy biznesowej w świecie ecommerce
Teraz tutaj pojawia się pytanie i dwa obozy na całym rynku.
Podejście #1
Jedni mówią, że to, co wystarczy na samym początku, to w zasadzie podstawowa architektura i najważniejsze user stories. Wystarczą one do rozpoczęcia prac programistycznych. Następnie w trakcie kodowania będziemy doprecyzować założenia i tworzyć projekty graficzne.
Nie ma potrzeby tworzenia dużych dokumentacji, ponieważ system ecommerce w trakcie rozmów, współpracy i nabierania doświadczenia przez zespół pewnie się zmieni.
Poza tym cały rok okresu wdrożeniowego, to dosyć dużo w świecie ecommerce’u. Może wydarzyć się dużo nowych rzeczy, mogą pojawić się nowe funkcjonalności, które trzeba będzie gdzieś uwzględnić. Po co więc tworzyć całą dokumentację, skoro wizja w trakcie projektu i tak ulegnie zmianie?
To jest jedno podejście i ono ma dosyć dużo zalet. Jest słuszne w niektórych punktach.
Podejście #2
Drugie podejście wygląda trochę inaczej, mówi o tym, żebyśmy postarali się doprecyzować jak najwięcej rzeczy na samym początku.
Oprócz tego, żebyśmy wiedzieli jak ma wyglądać architektura systemu, jak wyglądają funkcjonalności i jakie są kryteria akceptacyjne poszczególnych funkcjonalności, powinniśmy stworzyć od razu projekty graficzne i przewidzieć jak najwięcej na samym początku.
Dzięki temu później w trakcie realizacji prac projektowych nie będziemy tracić czasu i unikniemy sytuacji, że na sam koniec dnia zakodowaliśmy coś co mija się z naszą początkową wizją.
Które podejście jest dobre w przypadku ecommerce’u?
- Mniejsza analiza biznesowa
Większość osób mówi, że takie podejście, gdzie mamy tylko ogólne założenia na samym początku i od razu rozpoczynamy pracę, jest zwinnym podejściem agile’owym.
W mojej ocenie, znajduje ono zastosowanie w przypadku projektów, w których wprowadzamy całkowicie nową usługę lub produkt na rynek.
Chcemy jak najszybciej wypuścić je na rynek, przetestować na prawdziwych użytkownikach. Na podstawie analizy używania aplikacji oraz feedbacku jakościowego kreować dalszy kierunek rozwoju systemu.
Gdybyśmy projektowali Ubera po raz pierwszy, bo wcześniej nie istniał, to te podejście byłoby świetne.
Mielibyśmy tylko główne założenia na samym początku, rozpoczęlibyśmy kodowanie, szybko testowalibyśmy to na prawdziwych użytkownikach, dokładalibyśmy kolejne funkcjonalności itd.
Wtedy byłoby to zasadne. Tym bardziej, że w przypadku start-up’ów tego typu pewnie kilka rożnych firm pracuje nad podobnym pomysłem i kto pierwszy wejdzie na rynek ten go wygrywa. Nie ma czasu na dokładne planowanie.
- Większa analiza biznesowa
Natomiast ecommerce nie jest już tak innowacyjnym rozwiązaniem, jakim był jeszcze 20 lub 15 lat temu. Procesy w ecommerce są podobne między biznesami.
Oczywiście, są różne funkcjonalności, które możemy dołączyć, ale ogólnie rzecz biorąc, ecommerce jest przewidywalny i znamy główne procesy.
W związku z tym, możemy przewidzieć więcej rzeczy na samym początku.
- Podsumowując…
Jestem gorącym zwolennikiem tego, w przypadku ecommerce wykonać pełną analizę biznesową. Zwłaszcza w obecnych czasach, kiedy mamy do czynienia z dużą niepewnością otoczenia gospodarczego i kiedy bardzo ważna jest przewidywalność finansowa projektu. Powinniśmy na początku przygotować wszystkie user stories, dokładnie opisać kryteria akceptacyjne, opisać architekturę i stworzyć wszystkie projekty graficzne. Dopiero po tym etapie zabierajmy się za kodowanie.
Jest opcja na przyspieszenie prac. Jeśli mamy zaakceptowaną fazę discovery dla głównych elementów wdrożenia (rodzaj wersji Magento, podstawowa konfiguracja) to możemy już rozpoczynać te pierwsze zadania kodowe. Można to zrobić już po akceptacji pierwszych stories i pierwszych kryteriów akceptacyjnych.
Dzięki temu, że więcej ustalimy na samym początku to budżet wdrożenia będzie pewniejszy i czas wdrożenia będzie krótszy (nie będziemy tracili czasu na kodowanie, poprawianie i ponowne kodowanie tego samego elementu).
Jeśli poświęcimy więcej czasu na wykonanie fazy discovery, to końcowy budżet wdrożenia w stosunku do naszej estymacji rozjedzie się o około 10%. Natomiast nie spotka nas smutna sytuacja, że po fazie discovery ktoś wyestymował wdrożenie na 600.000 PLN, ale po 14 miesiącach pracy budżet przekroczył granicę 2.ooo.ooo PLN i końca nie widać. Dodam, że jeżeli ustalenia doprecyzowane są w trakcie realizacji projektu to projekt magicznym sposobem ma tendencje do niekontrolowanego nabierania masy.
Właśnie dlatego zdecydowanie lepiej jest zrobić dokładniejszą (lepszą) analizę biznesową. W efekcie będziemy mieli większą kontrolę nad budżetem projektu i czasem wdrożenia.
W skrócie: dokładniejsza analiza biznesowa = większe bezpieczeństwo i przewidywalność finansową + krótszy czas realizacji wdrożenia.
Analiza biznesowa w ecommerce – podsumowanie
Mam nadzieję, że przy podejmowaniu decyzji dotyczących zakresu analizy biznesowej będziecie wyposażeni w większą wiedzę niż wcześniej.
Podsumowując, w mojej ocenie, jeśli zależy nam na większym bezpieczeństwie i przewidywalności, powinniśmy już na samym początku, wykonać rozbudowaną analizę biznesową, w czasie której powinniśmy ustalić:
- architekturę systemu
- epiki
- user stories
- kryteria akceptacyjne do user stories
- oraz wszystkie projekty graficzne
W mojej ocenie, w obecnych czasach, kiedy otoczenie gospodarcze jest niepewne, wszystkim zależy na finansowym bezpieczeństwie i przewidywalności, to podejście jest dużo bardziej rozsądne.
Na koniec jeszcze jedna ważna informacja – user stories i kryteria akceptacyjne tak czy inaczej będą musiały być przygotowane (albo na etapie analizy biznesowej albo na etapie kodowania), niezależnie od tego czy będzie to projekt sklepu B2C czy platformy B2B.
To pierwsze podejście daje nam większą kontrolę nad terminem wdrożenia i budżetem.
Jeśli zainteresował Cię temat analizy biznesowej to mam nadzieję, że temat kosztów wdrożenia Magento również przypadnie Ci do gustu i uzupełni zdobytą dzisiaj wiedzę!
Przy okazji – jeżeli jeszcze nie śledzisz mojego profilu LinkedIn, to nie wiesz co tracisz 😉 Piszę o nowościach ze świata Magento i ecommerce developmentu, których po prostu nie można przegapić!
