Blog

Projekt grywalizacyjny okiem analityka

21.04.2017

C hcemy angażującej koncepcji grywalizacyjnej. Koniecznie z rankingiem, który można udostępniać – przecież musimy mieć rywalizację i element viralowy. Mniej więcej tyle wiadomo na etapie wstępnych rozmów z klientem. Później do projektu włączają się programiści, projektanci UX, testerzy, graficy. Chcą wiedzieć, “jak to dokładnie ma działać”. Czy możliwe, żeby ktoś był w stanie mówić jednocześnie językiem klienta, osób technicznych i pozostałych specjalistów stojących za grywalizacją? Poznajcie etapy projektu grywalizacyjnego i dowiedzcie się, jaka jest rola analityka na każdym z nich.

Jak wygląda projekt grywalizacyjny?

Realizacja projektu grywalizacyjnego to sztafeta, w której specjaliści z różnych dziedzin chcą jak najszybciej dobiec do mety i dostarczyć klientowi jak najlepsze rozwiązanie. Każda drużyna potrzebuje osoby, która spojrzy na działania poszczególnych członków zespołu z dystansu. W przypadku projektów grywalizacyjnych nad sprawnością procesów na każdym etapie projektu czuwa analityk biznesowy.

 Etapy projektu grywalizacyjnego

1. Przetarg

Najlepsi przyjaciele analityka: klient, przedstawiciel handlowy, dział kreatywny, grywalizator

To etap, na którym przedstawiciel handlowy składa klientowi ofertę zawierającą zarys koncepcji kreatywnej oraz wycenę. Prosto? Tak! I właśnie takie powinno być dla klienta. Jednak wstępną ofertę poprzedza skrupulatnie przeprowadzona analiza. Etap przetargu wiąże się z poniższymi działaniami:

  1. Zebranie od klienta wymagań – najczęściej podczas warsztatów, na których wspólnie określamy cele projektu i budujemy wizję rozwiązania.
  2. Zdefiniowanie mechanizmów grywalizacyjnych – jakie funkcjonalności pomogą nam w realizacji celu?
  3. Stworzenie opowieści - bez dobrego storytellingu trudno o dobrą grywalizację - wzbogacamy koncepcję o postacie, misje, zadania i narrację.
  4. Zaprezentowanie zarysu grafik – pokazujemy klientowi, jak to mniej więcej widzimy.

Na koniec tego etapu mamy przygotowaną wstępną wersję dokumentacji. Na jej podstawie oceniana jest kosztochłonność przez programistów, grafików i specjalistów UX.

 

 2. Planowanie projektu

Najlepsi przyjaciele analityka: Project Manager, liderzy zespołów programistycznych

Klient zdecydował się na projekt! Czas zrealizować to, co zaproponowaliśmy w ofercie i podczas spotkań z klientem. U jakiego źródła lider techniczny lub programista najszybciej może uzyskać informacje, jeśli nie chce zakopać się w dokumentacji? Właśnie u analityka, który w krótkim czasie może opisać mu najważniejsze założenia projektu. W końcu odpowiada za dokumentację i zna ją jak własną kieszeń.

Dział kreacji, grywalizator i analitycy przekazują liderom zespołów oraz Project Managerowi cel projektu, wizję rozwiązania oraz wymagania klienta. Przy wsparciu analityka liderzy tworzą zadania techniczne. Analityk musi zadbać o to, żeby produkt odpowiadał oczekiwaniom klienta zawartym w umowie.

 

3. Realizacja projektu

Najlepsi przyjaciele analityka: liderzy zespołów programistycznych, testerzy, PM

Jeśli nie ma wielu nieprzewidzianych sytuacji, projekt powinien przebiegać płynnie. Analityk rozwiązuje problemy, wyjaśnia szczegóły w dokumentacji, wprowadza do niej konieczne zmiany i jest czujny podczas spotkań z klientem.

Bardzo ważna jest dobra współpraca na linii analityk - tester. Testerzy są w stanie najlepiej sprawdzić, czy dany przypadek użycia jest realizowany przez aplikację. Jeśli w fazie testów pojawią się jakiekolwiek wątpliwości, znowu analityk i przygotowana przez niego dokumentacja to najlepszy adres, pod którym warto szukać odpowiedzi. Przypadki użycia zawarte w dokumentacji odpowiadają na pytanie: “ale co ja mam testować?”.

 

4. Wsparcie / modyfikacje

Produkt został oddany do klienta. Działa i wszyscy są szczęśliwi. To jednak nie koniec. Rynek ciągle się zmienia, tak samo strategie biznesowe i wymagania klienta. Za miesiąc albo za rok konieczne będą nowe funkcjonalności lub ich modyfikacje. Analityk powinien być wtedy na miejscu, aby dowiedzieć się, jaki efekt ma zostać osiągnięty. Przygotowuje rozwiązanie – w końcu doskonale zna wdrożenie, możliwości modyfikacji i sytuację klienta.

 

Czy analityk rzeczywiście jest konieczny w projekcie? Czy dodatkowe man-days i związane z nimi koszty się zwrócą? W mikro i małych projektach raczej nie. Zakres działań w takim przypadku można ustalić w kilku mailach, a podstawową dokumentację mogą zrobić sami programiści.

Zupełnie inaczej jest w projektach średnich i dużych. Analityk wnosi wartość przy oszacowaniu kosztów projektu oraz usprawnia pracę programistów. Nie wspominając o tym, że jest gwarancją, iż rozwiązanie będzie lepiej dostosowane do potrzeb klienta. Jak zauważył Barry Boehm, każda zmiana w późnym etapie produkcji jest dużo większym kosztem niż zmiana na etapie analizy czy projektowania rozwiązania.

 

Karol Witek

Business Analyst

Biznesową stronę dużych projektów zna z różnych punktów widzenia. Doświadczenie zdobywał jako Project Manager i Product Owner. Wierzy w liczby i diagramy, dlatego został analitykiem biznesowym. W projektach grywalizacyjnych nic nie dzieje się poza jego wiedzą. Prywatnie fan planszówek i kuchni indyjskiej.

Zobacz również