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.

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:

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łędnym 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 logicznym 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ść.

Spojrzenie całościowe

Tak pokrótce wygląda cały proces produktowy. Definiujemy stan docelowy, wybieramy sposób dojścia do niego, następnie budujemy konkretną drogę i planujemy mniejsze kroki.

Produkcja

Powoli dochodzimy do sedna tego artykułu, czyli jak konkretnie chcemy pracować przy wytwarzaniu kolejnych wersji gier.

Pomiędzy Mapą Drogową a Planem Wydania celowo pominąłem jeden z kroków, aby wpleść go właśnie tutaj. Tym krokiem jest szeroko pojęty Design, czyli zmiana wizji i definicji wyzwania/problemu w pewien wytwór, który pomoże osiągnąć nam wyznaczony efekt. W tym miejscu po prostu tworzymy kształt Ficzerów.

Zobaczmy jak może wyglądać organizacja takiej pracy.

Taka tam, standardowa tablica Kanbanowa. Wiadomka, też mamy taką w Jirze!Tu małe sprostowanie, w Jirze nie da się w łatwy sposób zaimplementować właściwego Kanbana. Ale jak to? Przecież mamy kolumny i rozpisany cały proces!

Kanban

Aby Kanban był Kanbanem powinien być systemem PULL a nie PUSH. System PUSH to taki, gdzie gdy skończymy pracę to przerzucamy ją do kolejnej fazy procesu. Ktokolwiek się tam znajduje musi się spieszyć z własną pracą, bo jeśli zaśpi to za chwilę będzie miał ogromną górkę do nadrobienia, a nowa praca będzie nadal spływała. Tak w skrócie działa standardowy ‘Kanban’ w Jirze.

W sposób dokładnie odwrotny działa system PULL. Każda kolumna ma ograniczenie Pracy W Toku (Work In Progress, WIP), które widoczne jest na powyższej tablicy w kwadratowych nawiasach. Ograniczenie to mówi nam jak wiele elementów może znajdować się jednocześnie w danej fazie procesu. Limit Pracy W Toku jest wprost skorelowany z ilością członków zespołu, którzy są w stanie obsłużyć daną fazę procesu.

Gdy w danej kolumnie limit nie jest osiągnięty i mamy wolne moce przerobowe, możemy pobrać karteczkę z poprzedniej fazy procesu. Co będzie oznaczało, że poprzednia faza procesu również będzie mogła rozpocząć nową pracę. Cały system sterowany jest od końca przez najwolniejsze ogniwo.

System PULL wymaga, by w jasny sposób oddzielić pracę ukończoną w danej kolumnie od tej, która jest w toku. Tutaj Jira niestety nie oferuje zbyt wielu wygodnych rozwiązań. Zarówno “praca w toku”, jak i ta “ukończona” wlicza się do limitu Pracy W Toku.

Spójrzmy na przykład – na tablicy powyżej nie możemy rozpocząć procesu uszczegóławiania pomysłu (Refinement), ponieważ limit [1] został osiągnięty poprzez wykonanie uszczegółowienia zielonej karteczki. Nie możemy jej jednak pobrać do procesu projektowania (Design), ponieważ tam również został osiągnięty limit a praca czeka na informację zwrotną. Dopiero gdy jedna z żółtych karteczek z kolumny Feedback przejdzie do Done, wtedy będzie można pobrać (do Feedbacku) nową kartkę z kolumny Design->Done, co z kolei będzie oznaczało, że możemy zacząć pracę nad Designem zielonej karteczki pobranej z kolumny Refinement->Done, co finalnie oznacza, że będziemy mogli pobrać nowy pomysł do uszczegółowienia z puli pomysłów (Idea).

W ten sposób otrzymujemy proces, który dostarcza ‘wyroby’ w ciągły i stały sposób, skorelowany z najwolniejszym stadium procesu, lub – w skrócie – działa tak szybko jak to jest możliwe. 

Łukasz, co Ty dajesz, w ogóle! Przecież ci ludzie w pierwszych dwóch kolumnach nic nie robią, przepalają piniendze!

Rzeczywiście, nie przetwarzają karteczek, ale jednocześnie nie produkują ‘górki’, którą tzw. ktoś będzie musiał się zająć, przetestować, zintegrować. Rodzi się oczywiste pytanie – co robić jeśli osiągniemy limit pracy w toku? Pomagamy. Mając tzw. “Wolny czas” możemy przyjrzeć się gdzie utknął proces, podjąć się analizy problemu, pomóc rozładować bottleneck, tak aby reszta procesu mogła znów ruszyć. Poprzez refleksję nad rozwiązanymi problemami zespół zbuduje nowy, lepszy proces. Pamiętajmy, że proces jest czymś, co zespół buduje dla siebie, a nie czymś, co jest mu narzucone i niezmienne.

Aby pogłębić to zagadnienie polecam powieść E. Goldratta – “Cel I” (“The Goal”). Wprowadzi ona was w tajniki teorii ograniczeń w systemach produkcyjnych i pokaże jak radzić sobie i znajdować prawdziwe bottlenecki (wąskie gardła procesu). 

Design

W ten sposób pomysły przekuwane są w konkretne funkcjonalności, które będziemy chcieli zaimplementować. Pomysły z kolei tworzone są w podobnym, aczkolwiek uproszczonym schemacie. Wkładem do nich jest oczywiście mapa drogowa, ale także informacja zwrotna od graczy, analityka danych i liczne badania, które robimy z rynkiem w celu lepszego dopasowania produktu do upodobań graczy. 

Tu warto zaznaczyć, że nasze tablice mają jeszcze tzw. Backlog. Jest to miejsce, gdzie gromadzimy różne pomysły, które priorytetyzujemy i wybieramy najciekawsze aby przenieść je do kolejnej fazy (To Do), gdzie oczekują na przetworzenie.

Dzięki temu dwustopniowemu procesowi unikamy poczucia chaosu i przytłoczenia przez zespół, jednocześnie dając przestrzeń na kreatywne działania innej części zespołu. Osoby, które zajmują się kolejnymi fazami mają przed sobą ograniczoną liczbę zadań i są w stanie planować do przodu bez poczucia przytłoczenia.

Mając cegiełkę Designu, w której zazwyczaj zawierają się również wstępne makiety możemy przejść do kolejnej fazy.

Dekompozycja

Wiedząc już co jest do wytworzenia, możemy zdekomponować to sobie na pojedyncze elementy do wytworzenia. Dzielimy nasz design na historie użytkownika (user stories), które są małymi – acz działającymi – elementami większej całości. Inwentaryzujemy także grafikę, która potrzebna będzie aby dana funkcjonalność wyglądała atrakcyjnie.

Dosyć często zachodzi potrzeba doprecyzowania wizji czy wymagań konkretnych elementów. Proces kanbanowy w strumieniu graficznym zakłada, iż wszystkie elementy doń trafiające są należycie przygotowane i mogą zostać wykonane bez dalszych rozmów. Stąd, w strumieniu graficznym istnieje wcześniejsza faza, tzw. “Upstream kanban” podobny do fazy designu, aczkolwiek dedykowany pracy artystycznej. Na wyjściu tego procesu znajdziemy zadania, które mogą zostać przekazane bezpośrednio artystom.

Elementy te staną się wkładem do kolejnej fazy i wyprzedzają ją o 1-4 tygodni.

Integracja

W fazie integracji zespół developerski korzystając ze specyfikacji oraz gotowych grafik buduje nową część naszej gry. W przeciwieństwie do poprzednich faz tutaj pracujemy w dwutygodniowych iteracjach, które mają do osiągnięcia cel, który wyznaczany jest w czasie planowania sprintu. Na koniec iteracji otrzymamy nową część (inkrement) produktu, który będziemy mogli wydać na rynek i zebrać informację zwrotną na temat jego wydajności oraz sposobu, w jaki użytkownicy z niego korzystają. Takie wydanie robimy raz na dwa tygodnie.

Te informacje zamykają naszą pętlę zwrotną i zasilają proces rozwoju produktu. Dzięki tym właśnie wnioskom jesteśmy w stanie tworzyć lepsze i ciekawsze gry, które są szyte na miarę pod naszych graczy, którzy dwa razy w miesiącu otrzymują nową wersję aplikacji z usprawnieniami budującymi jeszcze większą wartość produktu.

Podsumowanie

Rozwijając produkt wychodzimy od jego wizji – długoterminowego stanu docelowego. Następnie tworzymy strategię, która umożliwi nam wprowadzenie w życie tej wizji. W kolejnym kroku budujemy mapę drogową, dzięki której wiemy jakie hipotezy chcemy przebadać oraz jakich konkretnie wyników oczekujemy. Następnie szukamy najbliższych kroków, definiujemy je i planujemy w czasie.

W fazie produkcji – całkiem podobnie – wychodzimy od wizji kolejnego inkrementu, dekomponujemy ją i przygotowujemy materiały wsadowe, tak aby całość była gotowa do wykonania jak tylko znajdzie się na to przestrzeń. Finalnie, integrujemy wszystkie pozyskane wcześniej elementy, dbamy o jakość i przekazujemy nową wersję gry klientom, wyciągając wnioski z ich zachowań i ulepszając wizję kolejnych iteracji.

Łukasz Szczepański, Agile Coach z 15 letnim stażem pracy 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. Gamedev to jego świadomy wybór, bo sam jest graczem, ale wychodzenie poza tą branżę pozwoliło mu zebrać bogate doświadczenie, które wykorzystuje w swojej pracy. Koncentruje się na dostarczaniu wartości i zrozumieniu szerszego „dlaczego?”.

Artykuł pochodzi z portalu justgeek.it, gdzie został opublikowany 18 października 2021 r..