proces produkcji ten square games

Proces dostarczania rozwiązań od wizji po produkcję. Jak to robi zespół Ten Square Games

Jako Agile Coach mam misję uzwinniania firmy pod względem produkcyjnym i produktowym poprzez współpracę z zespołami i liderami. Wspólnie testujemy różne podejścia, koncepcje i narzędzia tak, aby znaleźć zestaw, który rezonuje z danym produktem. Dziś chcę pokazać Wam naszą wizję rozwoju i produkcji gier, którą sukcesywnie wdrażamy w jednym z naszych produktów. Nie wszystko działa idealnie, ale wspólnymi siłami pokonujemy kolejne wyzwania.

lukasz szczepanski ten square games

Łukasz Szczepański. Agile Coach w Ten Square Games. Posiada 15-letnie doświadczenie w produkcji aplikacji i gier mobilnych. Pracował zarówno w małych studiach, jak i w dużych korporacjach. Swoją karierę pokierował w stronę zarządzania zespołami najpierw jako Project Manager a finalnie jako ekspert, który pomaga organizacjom przejść na pracę w Agile. Jak sam deklaruje – zawodowo pomaga zespołom projektowym tworzyć jeszcze lepsze produkty. Wielki fan zrównoważonych procesów i humanitarnego zarządzania bez nadgodzin.


Ten Square Games operuje jako Game as a Service, które jest growym odpowiednikiem SaaSa. Budujemy produkty/usługi, które w założeniu mają utrzymać się na rynku przez długi czas, ciągle dostarczając wrażeń (czy też wartości) naszym klientom. Większość naszego portfolio to gry, które są w fazie live, w której to podlegają ciągłym przemianom i ewolucji. Jest to faza ciągłego odkrywania produktu (Continuous Product Discovery), ponieważ również preferencje graczy podlegają ciągłym przemianom, a konkurencja nie śpi. 

W obecnych czasach może wydawać się to pewnym frazesem, ale bez podejścia zwinnego nie bylibyśmy w stanie rozwijać produktu równie dynamicznie i osiągać podobnych sukcesów jak teraz. Produkcje GaaS diametralnie różnią się od gier premium AAA (Wiedźmin, Assassin’s Creed, Elder Scrolls, etc.). Pracujemy na rynku, na którym naszymi bezpośrednimi konkurentami nie jest kilka czy kilkanaście produktów, a są ich dziesiątki – a w pewnych segmentach nawet tysiące. 

Dodatkowo oddajemy dużą część gry za darmo, co z jednej strony obniża próg wejścia nowych graczy, a z drugiej powoduje, że nie są z nami związani żadną lojalnością i mogą bardzo szybko zmienić naszą produkcję na konkurencyjną. Jeśli nie trafimy w preferencje graczy, to nie poświęcą nam czasu, a szansa na zarobek z dodatkowych usług maleje do zera. Jednocześnie musimy dobrać nasze strategie sprzedażowe do graczy tak, aby nie odstraszyć ich agresywnymi promocjami

Gry AAA sprzedają graczom pewną wizję doświadczeń, budują oczekiwanie na dostęp do produktu przez długi czas i zbierają fundusze za pomocą preorderów. Gracz po zakupie takiej gry zazwyczaj nie może jej zwrócić i czuje pewną wewnętrzną presję, aby korzystać z produktu, który zakupił. Niewątpliwie nawet w produkcjach AAA wykonywane są testy i iteracje, tak aby zminimalizować ryzyko ‘wpadki’, ale często ograniczone są one do testów wewnętrznych czy też Friends and Family. Przy tych ostatnich rośnie ryzyko przecieków i zniszczenia marketingowego wizerunku gry, a przy tych pierwszych testujemy grę na, cóż… grupie nerdów, która tworzy tę grę. Jeśli tworzymy grę dla innych nerdów, to trafiliśmy w dziesiątkę, jednakże masowy odbiorca różni się od typowego twórcy gier na kilku płaszczyznach.

Tymczasem w branży gier mobilnych dzięki zwinnemu podejściu oraz dynamice produktu jesteśmy w stanie testować hipotezy biznesowe, bezpośrednio na wybranej puli naszych klientów i badać ich zmiany zachowań, przez co możemy szybciej i taniej osiągnąć lepsze dopasowanie do naszych graczy.

Po tym wstępie możemy przejść do meritum, czyli tego, jak wygląda nasz proces rozwoju i dostarczania gry. Będę opowiadał o nim w kontekście gry, która jest już na rynku i nadal się rozwija – rozwój i utrzymanie produktu będzie zapewne bliskie większości czytelników.

Wizja

Wszystko zaczyna się od wizji. Jest ona ostatecznym stanem docelowym, w którym chcemy się znaleźć. Wizja jest ambitna, dalekosiężna, ukierunkowana.

Niech za przykład posłuży nam wizja Google, która brzmi: “Zorganizować całą informację na świecie tak, aby była łatwo dostępna i użyteczna.

Wizją produktu może być również “Budujemy największą wędkarską społeczność poprzez absorbujące wydarzenia i turnieje.”

Jeśli wizją Twojego produktu jest “Chcemy zwiększyć przychody o 12% rok-do-roku” to być może potrzebujesz trochę się nad nią zastanowić. Taka definicja jest raczej celem, który jest powiązany z jednym, konkretnym wskaźnikiem. Zbudowanie ‘wizji’ w taki sposób nie wyznacza kierunku, za którym może podążać zespół. Można by sparafrazować tę definicję jako “w przyszłym roku ma być więcej tego samego”. Nasi współpracownicy nie będą w stanie zainspirować się taką wizją, a rozwój produktu zwróci się w stronę chaosu, gdzie każdy element produktowej układanki ciągnie w swoją stronę, byle by tylko podnieść wskaźnik.

Wizja jednoczy zespół i ukierunkowuje działanie. Jest także pewną… barierką, która nie pozwoli nam odjechać za daleko. W dużym skrócie – wizja mówi nam, czy budujemy statek, czy samolot.

Są organizacje, gdzie ten krok się pomija. Tam buduje się silnik i inne części, a potem zastanawia się, czy istnieją pojazdy, do których można je zastosować. Może brzmi to wtórnie, ale wszyscy byli bardzo produktywni i bardzo zajęci, mamy dużo fajnych części!

Strategia

Mając wizję, możemy budować strategię osiągnięcia tej wizji. Strategia jest pewnym zestawem zasad, których będziemy się trzymać w drodze do osiągnięcia wizji. Można myśleć o niej także jako o zbiorze problemów, które chcemy rozwiązać.

Na przykład: “Naszą strategią przeprowadzenia Czerwonego Kapturka do domku babci jest możliwie jak największe ominięcie lasu, aby zniwelować ryzyko spotkania wilka. Ominiemy także moczary, aby nie pobrudzić bucików. Aby zapewnić dostarczenie koszyka w czasie, w którym jego zawartość pozostanie świeża zainwestujemy 3 punkty w chodzenie na szczudłach, aby przejść wąwóz i 5 punktów w szybkie bieganie, aby nadrobić omijanie lasu.

Wiemy więc, co chcemy zrobić, ale w tej strategii wyczytać możemy także to, czego nie zrobimy. Nie ma tu walki ani ucieczki przed wilkiem, umiejętności przeżycia w lesie czy też wspinaczki po skałach. 

Budując podróż Kapturka nasz zespół będzie mógł zapytać “Po co nam kalosze jeśli nie wchodzimy na moczary i czy można w nich szybko biegać?”. To z kolei pozwoli naszemu Product Managerowi zastanowić się czy nie zagalopował się w lokalnych optymalizacjach produktu.

Z powyższego już wiecie, że w TSG zespół ma wpływ na produkt i pomaga osobom zarządzającym produktem podejmować trudne decyzje i pilnować zgodności kierunku rozwoju z założoną wizją. Budowanie doświadczeń to sport zespołowy!

Mapa Drogowa (zwana również “roadmapą”)

Ze strategii wiemy jakie podejście chcemy zastosować. Na kolejnym poziomie planowania rozmawiamy o tym, co konkretnie chcemy osiągnąć. Środowisko IT jest mocno podzielone w kwestii tego czym taka mapa drogowa powinna być. Istnieją dwa główne obozy: jedni chcą widzieć kolorowe paseczki na linii czasu, a nich wszystkie możliwe detale, a po przeciwnej stronie są tacy jak ja, którzy chcą wiedzieć jakich efektów spodziewamy się w konkretnym czasie.

Moja mapa mogłaby wyglądać tak:

mapa oparta o efekty

Jest to przykład Mapy Opartej o Efekty (Outcome Based Roadmap), o której mówiłem na tegorocznej konferencji Digital Dragons. W tym formacie skupiamy się na osiągnięciu pewnego efektu lub zmiany w pewnym określonym czasie, zamiast koncentrować się na aktywnościach do wykonania. 

Taka mapa pozwala na zwinność w planowaniu działań, ponieważ nie zakłada silnych zależności pomiędzy elementami, a zmiana Dnia Trzeciego po odkryciu nowych rzeczy w Dniu Drugim nie powoduje konieczności ponownego zaplanowania dziesiątek aktywności. Kolejnym atutem tej mapy jest to, iż koncentruje się na efekcie końcowym a nie sposobie osiągnięcia tegoż, co powoduje, że zespół może wykazać się kreatywnością i odpowiedzialnością za produkt (Ownership). Dzięki jasnemu celowi jesteśmy w stanie skupić nasze wysiłki na jednym kierunku.

Ważne: Powyższy przykład mapy mówi o ‘Dniach’, aby było to spójne z podróżą Kapturka, w rzeczywistym świecie każdy z tych ‘Dni’ na mapie byłby okresem od 1 do 3 miesięcy. Mapa drogowa służy do planowania w średnim terminie.

Plan Wydania

Wreszcie dotarliśmy do miejsca, gdzie możemy rozbić pracę na ‘namacalne’ aktywności. Zdobycie 5 punktów zwinności to niemały wyczyn. W każdej dyscyplinie można zdobyć tylko po jednym punkcie. Kapturek będzie musiał ćwiczyć:

  • Gimnastykę
  • Jazdę na rolkach
  • Bieganie
  • Skok o tyczce
  • Piłkę Ręczną

Do każdej z tych dyscyplin potrzebować będziemy specjalistycznego sprzętu, który dostarczy drugi z naszych zespołów. Celowo zaczynamy od gimnastyki, gdzie nie potrzeba sprzętu, tak aby dać drugiemu zespołowi czas na dostarczenie wymaganych przedmiotów. Tutaj, na poziomie zespołów możemy zaplanować, ile będzie trwał każdy z treningów i na kiedy orientacyjnie potrzebujemy konkretnych narzędzi. 

Czy to jeszcze zwinność?

Czekaj, czekaj Łukasz! Przecież taki plan chyba niespecjalnie jest już edżajl? Nie wygląda Ci to na taki waterfall? Wszystko zaplanowane, rozłożone w czasie, zidentyfikowane zależności, gdzie tu zwinność?

W manifeście zwinnego tworzenia oprogramowania czytamy Odpowiedź na zmiany ponad podążanie za planem. Nie jest tam zapisane Zmiany zamiast planu. Błędne jest założenie, że w podejściu zwinnym nie ma planów. Jest ich wręcz bardzo dużo. Są konstruowane w taki sposób, aby można było łatwo je modyfikować na podstawie nowych informacji i doświadczeń z procesu produkcji. Dzięki temu jesteśmy w stanie zacząć zarządzać oczekiwaniami odpowiednio wcześnie i zmieniać zakres prac tak, aby pasował do nowo odkrytej rzeczywistości.

W naszym przypadku celem pierwszej iteracji mogłoby być zdobycie punktu zwinności dla pierwszego zespołu i dostarczenie sprzętu do jazdy na rolkach dla drugiego zespołu.

Tak! Iteracje mają swoje cele! Nie, celem iteracji nie może być wykonanie wszystkich zaplanowanych zadań. Tutaj jest miejsce na zapewne kolejny artykuł.

Wracając do naszych zespołów – jeśli okazałoby się, że nie jesteśmy w stanie dostarczyć rolek w pierwszej iteracji, to logiczne będzie ćwiczenie biegania w drugiej iteracji, bo tam również nie potrzebujemy specjalistycznego sprzętu, kupując zespołowi drugiemu chwilę czasu na dokończenie ich pracy. Oczywiście, te problemy powinny być wyłapane wcześniej – w czasie codziennych spotkań – nie na koniec iteracji.

Naszym założeniem jest to, że na koniec każdej iteracji dostarczymy coś skończonego, namacalnego i działającego. Jednocześnie obserwujemy otoczenie i użyteczność tego, co dostarczyliśmy. Wyciągając wnioski z tych obserwacji, modyfikujemy plan na przyszłość. 

Zapraszamy do dyskusji

Patronujemy

 
 
More Stories
blockchain prawda i mity
Blockchain – fakty i mity o pracy w tej branży