ZARZĄDZANIEPROJEKTEMPróba zapanowania nad chaosem

Wykład z kursu Digital Frontier – digitalfrontier.pl

Bo to bardzo długi wykład będzie.

Zakres wykładu

O czym opowiem

Zespół Definiowanie

zakresu Planowanie Metodyki

zarządzania: Tradycyjny

wodospad Metodyki zwinne

Wykonanie: Przedstawienie planu Realizacja planu Śledzenie postępów Raportowanie

Zarządzanie ryzykiem

Postmortemy Narzędzia

100% praktyki

To są moje przemyślenia po 20+ latach tworzenia gier w różnych środowiskach

Nie jestem wyszkolonym project managerem. Zaliczyłem kurs metodyki Scrum. Sporo samokształcenia – lubię wzmacniać swoje

doświadczenie wiedzę teoretyczną, choć najczęściej po fakcie.

Pamiętajcie, YMMV.

Dziwko!

Zespół

Mały zespół, mały problem

W zespołach 2-3 osobowych praktycznie nie istnieje koncepcja zarządzania projektem.

Plan mieści się na kartce (serwetce), komunikacja jest łatwa, a pełną wiedzę o stanie projektu ma każdy.

Wystarczą pewne wspólnie zaakceptowane ustalenia, minimalistyczny plan i wzajemnie obserwowania postępów pracy, aby projekt toczył się w dobrym kierunku.

Rośnie zespół, więcej problemów

Rośnie skala projektów. Pojawia się wiele zależności. Zwiększa się rozwarstwienie doświadczenia i

umiejętności. Trudno planować i zarządzać kolektywnie w

dużej grupie. Pojawiają się problemy komunikacyjne. Rośnie koszt, ryzyko i stres.

Planowanie to praca zespołowa

Nie da się stworzyć dobrego planu samodzielnie, bez udziału ludzi, którzy będą go realizować.

Nie ma takiego zadania, którego nie da się szybko wykonać – dla kogoś, kto nie będzie go wykonywał.

Plan stworzony „zaocznie” jest nic nie wart. Dobry plan to wiarygodny plan, czyli taki, w

który przede wszystkim uwierzą wykonawcy.

Dobry plan tworzy zespół

Planować powinien zespół, a producent/PM ma to zadanie ułatwić.

Idealnie, gdy każdy członek zespołu planuje swoje zadania.

Nie zawsze mamy zespół w momencie planowania, ale musimy mieć do dyspozycji przynajmniej kluczowych członków zespołu.

Planująca ekipa

Producent Głównego projektanta (lead designera); Głównego programistę (lead

programmer/technical director); Głównego artystę (art director/lead artist); Niektóre z funkcji można łączyć, szczególnie w

małych projektach.

Zespół

Nie musimy czekać z planowaniem aż skompletujemy zespół – kluczowi przedstawiciele pozwolą stworzyć niezły wstępny plan.

Plan musi uwzględniać ryzyka związane z pozyskaniem ludzi – bufory i plany awaryjne.

Znaczną część pracy można zaplanować dla ludzi, których w zespole już mamy, co da nam czas nie pozyskanie kolejnych.

Wiarygodny plan

Plan, w którego stworzenie zaangażowany jest zespół ma szansę być planem wiarygodnym.

Nie oznacza, że będzie to plan perfekcyjny, ale ominie nas spora przeszkoda w jego realizacji, czyli brak wiary w realizowalność po stronie tych, którzy będą musieli go realizować.

Taki plan będzie nam o wiele łatwiej prezentować i wykonywać.

Specyfikacja produktu

Definiowanie zakresu

Definicja produktu

Nie da się zaplanować produktu, który nie jest dobrze zdefiniowany.

Nie da się sensownie odpowiedzieć na pytanie: „chciałbym grę w stylu takiej to, a takiej, ile to będzie kosztować i kiedy będzie gotowe?”

Jakość planowania w olbrzymim stopniu zależy od precyzji zdefiniowania produktu – gry. Potrzebna jest dobra specyfikacja projektu.

Wstępna specyfikacja

Bardzo często na początku prac projektowych mamy bardzo ogólną specyfikację gry.

Projekt gry zostaje uszczegółowiony podczas prac designerskich.

Z w.w. powodów musimy ostrożnie planować oraz aktualizować swoje wstępne założenia wielokrotnie podczas polepszania się naszej wiedzy na temat definicji produktu.

Nawet wtedy może powstać wstępny plan.

Od góry lub od dołu

Możemy planować na podstawie specyfikacji – podejście od dołu.

Możemy planować na podstawie czasowych i/lub finansowych założeń – podejście od góry.

Niezależnie od podejścia, w pewnym momencie musimy dobrze zgrać specyfikację gry (co chcemy osiągnąć) z możliwościami – czasem i pieniędzmi.

Gry to twory dynamiczne

Niezależnie od podejścia musimy pamiętać o dynamicznym charakterze tworzenia gier.

Wstępna, nawet szczegółowa specyfikacja gry ulegnie zmianie podczas jej tworzenia – plan musi to uwzględniać.

I odwrotnie, pan nie jest z gumy, więc nierzadko trzeba będzie zmienić pierwotną specyfikację, aby zmieścić trzymać się planu.

Plany i specyfikacje muszą być elastyczne.

Co jest niezbędne

Jakiekolwiek wstępne założenia, które pozwalają ocenić, co chcemy zrobić (jaki jest zakres).

Design Document – opisujący co chcemy zrobić – to nieocenione źródło niezbędnej wiedzy.

Rzadko występujący w przyrodzie Technical Design Document – opisujący jak i co konkretnie chcemy zrobić – to źródło najlepsze.

Musimy radzić sobie z tym, co mamy i zdobyć jak najwięcej informacji w czasie planowania.

Zakres

Mają specyfikację, musimy przetworzyć ją na zakres, co w praktyce oznacza zamianę opisu gry na listy produkcyjne: Listy funkcjonalnych elementów gry (feature

lists/backlog) Listy elementów składowych (asset lists)

Tak przetworzone listy będzie można potem próbować przekształcić w listy zadań do wykonania, oszacować ich czasochłonność i ułożyć w plan.

Planowanie

Plan od góry

Pozwala na planowanie bez ścisłej specyfikacji. Nie angażuje wielu ludzi. Jest bardzo niedokładny. Narzuca dużo:

Ogranicza kreatywność i rozwijanie jakości. Ma tendencję do wciskania zbyt dużej ilości prac w

ramy czasowe. Musi jak najszybciej zostać przekształcony w

plan od dołu.

Plan od dołu

Opiera się na w miarę dokładnej specyfikacji, a właściwie na listach produkcyjnych.

Jest często bardzo trudny i czasochłonny (bywa, że produkcja sobie, a tworzenie planu sobie).

Angażuje ludzi odpowiedzialnych z konkretne zadania (przynajmniej leadów).

Prowadzi do lepszych planów, bardziej zgodnych z rzeczywistością i bardziej wiarygodnych.

Listy

Listy produkcyjne pozwalają nam szacować czas niezbędny do ich realizacji i układać plan.

Produkcja elementów graficznych oraz audio (assetów) odbywa się na bazie dość dobrze ustalonych procesów.

Projektowanie gry, tworzenia fabuły i dialogów, programowanie technologii oraz rozgrywki to procesy przeważnie słabiej zdefiniowane (dynamiczne).

Procesy ustalone

Listy assetów stosunkowo łatwo przekształcić w konkretne listy: Liczbę lokacji. Liczbę postaci – ludzi, przeciwników, stworów, maszyn. Liczbę animacji dla każdej postaci. Liczbę przerywników filmowych. Liczbę elementów, które wymagają udźwiękowienia. Liczbę efektów specjalnych.

W większości przypadków są to bezpośrednio listy zadań do wykonania.

Procesy dynamiczne

Przewidywane prace w zakresie prac dynamicznych dzielimy na maksymalnie rozdzielne elementy funkcjonalne (features).

Listy elementów funkcjonalnych sortujemy pod względem priorytetów ważności dla jakości gry i jej unikalności, oraz ryzyka (ryzykowne na początek).

Tak zaplanowaną kolejność prac ograniczamy ramami czasowymi zgodnymi z ogólnymi założeniami projektu (time boxing). Czego nie zrobimy na czas, tego w grze po prostu nie będzie.

Procesy dynamiczne

Bardzo często więcej, nie oznacza lepiej i gra może wręcz zyskać na mniejszej liczbie funkcjonalności, które są lepiej dopracowane. Nie boimy się ciąć!

Dobrze jest prace ograniczać czasowo wielokrotnie w czasie projektu, aby móc modyfikować listę i zmieniać priorytety. Wiedza na temat gry rośnie wraz z jej rozwojem, więc oryginalna kolejność po jakimś czasie może nie mieć sensu i warto ją zmienić.

Procesy dynamiczne

Niezależnie od planowania metodą ram czasowych, warto przeanalizować, czy w ogóle planowane najważniejsze rzeczy zmieszczą się w ramach – nie zakładajmy, że samo wyznaczenie deadline sprawi, że coś się na to deadline pojawi.

Realizacja pewnych funkcjonalności musi potrwać pewien minimalny czas i nałożenie sobie zbyt krótkich ram czasowych nie przyniesie nam żadnych rezultatów.

Procesy dynamiczne

Część z elementów dynamicznych musi pojawić się choćby w szczątkowej formie wszędzie tam, gdzie są spodziewane (np. dźwięki). Tutaj zasada mniej, ale lepiej nie działa – musimy mieć komplet dźwięków tam, gdzie każdy ich brak zauważy.

W takim wypadku najlepiej zaplanować pracę przebiegami. W pierwszym przebiegu wykonujemy normy ilościowe, a kolejnych poprawiamy jakość, powtarzając ten proces dopóki trwa projekt.

Plan – oczekiwania

Nie każdy projekt wymaga szczegółowego planu i budżetu.

Bywają projekty ograniczone głównie czasowo. Bywają projekty z elastycznym budżetem. Planowanie jest trudne i powinno odpowiadać

potrzebom projektu. Warto wystrzegać się planowania dla sztuki

(znam projekty, których plan powstawał tak długo jak one same).

Przygotowania

Mamy określoną (przynajmniej zgrubnie) specyfikację, z której wynika planowany zakres prac.

Wiemy jakim dysponujemy zespołem – aktualnie lub docelowo.

Możemy przystąpić do planowania.

Szacowanie czasu pracy

Podstawą budowy wiarygodnego planu jest oszacowanie czasu wykonywania poszczególnych zadań.

Dobrze oszacować można jedynie dobrze zdefiniowane zadania.

Im większe zadanie – bardziej złożone albo gorzej zdefiniowane – tym gorsze będą oszacowania.

Fajnie założyć jakąś minimalną gradację czasu szacowania (np. 1 dzień/1 tydzień) w zależności od dokładności planu.

Szacowanie czasu pracy

Szacują wykonawcy danych prac: I tak będą niedoszacowywać, szczególnie młodzi i

niedoświadczeni. Przełożeni będą szacować według swoich umiejętności,

a nie wykonawcy. Przełożeni mają tendencję do wywierania presji na

szybsze terminy – bo więcej, lepiej i fajniej. Przełożeni znają ograniczenia zewnętrzne projektu

(planowane czasy i budżety) i chcą jak najwięcej „wycisnąć” w ramach ograniczeń.

Szacowanie jest bardzo trudne.

Szacowanie - formuły

The Game Producer’s Handbook: Best Case: 10 Worst Case: 25 Likely Case: 15 (2 * BC + 3 * WC + LC) / 6 (2 * 10 + 3 * 25 + 15) / 6 = 18

Szacowanie - formuły

PERT (Program Evaluation and Review Technique): Best Case: 10 Worst Case: 25 Likely Case: 15 (BC + 4 * LC + WC) / 6 (10 + 4 * 15 + 25) / 6 = 16

Szacowanie - formuły

„Na ostrożnego producenta”: Best Case: 10 Worst Case: 25 Likely Case: 15 LC * 1.25 (25% rezerwy czasowej) 15 * 1.25 = 19

Narzędzia

Microsoft Excel (lub inny arkusz kalkulacyjny) Microsoft Project Funkcjonalnie podobne systemy online Pomaga:

Możliwość definiowania zależności. Automatycznie balansowanie zasobów. Weryfikacja obłożenia pracą. Uwzględnianie kalendarza (święta, wolne dni).

Arkusz kalkulacyjny

Doskonałe narzędzie do tworzenia planów zgrubnych.

Łatwy w obsłudze. Nie ma wielu funkcji wspierających – cały plan

trzeba modyfikować ręcznie. Lepszy jednak nawet prosty plan niż żaden. Spisuje się też doskonale w prostszych

projektach, gdzie ma wiele zależności.

Narzędzie specjalizowane

Bardzo dużo funkcjonalności wspierające proces planowania.

Pozwala uniknąć wielu błędów – nadmiernego lub niedostatecznego obciążenia wykonawców (tzw. zasobów), nieuwzględnienia zależności.

Łatwo wprowadzać zmiany, które natychmiast modyfikują cały plan – proces całkowicie automatyczny.

Narzędzie specjalizowane

Można narzucić wiele ograniczeń, które będą uwzględniane podczas planowania.

Łatwiej określać zależności pomiędzy zadaniami.

Wyraźnie widać ścieżkę krytyczną projektu. Kusi do „optymalizowania” planu, aby osiągnąć

zamierzony rezultat – co owocuje tworzeniem planów fikcyjnych.

Zależności

Pewne zadania można wykonać tylko wtedy, gdy wcześniej zostaną wykonane inne zadania.

Zadania mogą mieć proste zależności – jedynie od jednego poprzedniego, albo złożone – od wielu zadań.

Zadania i zależności pomiędzy nimi wytyczają ścieżkę krytyczną projektu.

Produkcja gier często obfituje w bardzo skomplikowany system zależności, co utrudnia planowanie.

Zależności

Planowanie

Lista zadań i procesów ograniczanych czasowo. Zadania pogrupowane według upodobań. Lista wykonawców (zespół). Każdemu z wykonawców przypisujemy kolejno

zadania z puli. Zadania powiązane ustawiamy we właściwiej

kolejności. Uwzględniamy zadania wieloprzebiegowe –

iteracyjne.

Planowanie

Plan musi uwzględnić podstawowe cykle produkcyjne: projektowanie, prototypowanie, produkcję właściwą i proces post-produkcji.

W planie musimy uwzględnić błędy oraz konieczność ich naprawienia. Nie wszystkie błędy mogą i powinny czekać do końca.

Ludzie to nie roboty – chorują, mają urlopy, mają gorsze dni, są weekendy i święta.

Leadzi nie mają 100% wydajności, bo mają podwładnych na głowie.

Planowanie

Nie zaklinaj rzeczywistości – jeśli z planu wynika, że termin nie zostanie dotrzymany, to odrobina „kombinacji” z planem nie zmieni rzeczywistości.

Zaplanuj bufory. Jeśli nie będziesz mógł manipulować zakresem lub jakością, to produkcja będzie musiała się przedłużyć.

Rozsądny bufor to 30% lub więcej całości. Im krótszy projekt, tym większy bufor.

Bufor nie musi być częścią planu pracy – ważny jest w budżetowaniu.

Sytuacja zmienną jest

Plany się dezaktualizują. Szybko. Trzeba plany często modyfikować. Trzeba śledzić faktyczne postępy prac i

porównywać je z planem. Planowanie i śledzenia prac w projekcie

wymaga producentów lub project managerów. Nie w każdym projekcie jest to możliwe.

Przykładowe planowanie

Excel Gantter.com

Ale jak nad tym wszystkim zapanować?

Plan planem

Prosta metodyka zarządzania niewielkimi projektami

Mała skala

Mały projekt – prosty plan

Prosty plan lepszy niż żaden. Zbyt skomplikowany plan zajmie za dużo czasu. Managerowie przeważnie są częścią

wykonawców, więc nie mogą zajmować się wyłącznie skomplikowanym planowanie.

Bazowy plan trzeba przełożyć na listę zadań: Bezpośrednio w przypadku zadań o ustalonym

procesie produkcyjnym. W ramach jakiegoś limitu czasowego w pozostałych

kategoriach.

Prosty plan

Lista zadań jest dobrym zasobem w dalszym zarządzaniu niewielkim projektem.

Lista zawsze musi być posortowania względem priorytetów i ryzyka – niezbędne elementy oraz te obarczone największym ryzykiem (ale wykonalne w rozsądnym czasie) muszą być na początku listy.

Plan trzeba będzie modyfikować w miarę postępu prac nad projektem.

Prosty plan

Zadania przypisuje się według zaplanowanej kolejności wykonawcom.

Przypisania obejmują tylko najbliższy okres. Wykonawcy oznaczają zadania wykonane. Ocena stanu projektu jest prowadzona na

bieżąco – zrobione/do zrobienia.

Prosty plan

Jako narzędzia wystarczą proste listy zadań do zrobienia (to do) albo systemy ticketowe. Mnogość narzędzi komputerowych, w tym online.

Można stosować systemy analogowe – tablice i karteczki.

Jasny przekaz dla wykonawców, prosta informacja zwrotna.

Prostota plany ułatwia modyfikacje i zmiany – proces zarządzania nie zajmuje wiele czasu i daje się pogodzić z innymi zajęciami.

Prosty plan - problemy

Ocena wielkości pozostałej pracy odbywa się „na oko”. Trudna odpowiedź na pytanie „kiedy?”

Przy prostych narzędziach (czy analogowych) trudno post factum zebrać informację o czasach wykonywania zadań.

Nie uwzględnia się zależności pomiędzy zadaniami.

Wymaga zarządzającego listami/zadaniami.

Z siłą wodospadu.

Duża skala

Zarządzanie na wyższym poziomie

Dużo ludzi, spore pieniądze, dziesiątki tysięcy zadań, akcjonariusza, zarządy.

Olbrzymia skala projektu rodzi problemy w wykładniczym tempie.

Rośnie liczba zależności, które mogą przyczyniać się do opóźnień.

Opóźnienia często generują koszty, które byłby niezłymi budżetami mniejszych gier.

Wkracza korporacyjny styl

Oczekuje się planów, odpowiedzi na pytania kiedy i za ile, wzorowej organizacji pracy.

Często wymogi kierownictwa nie mają wiele wspólnego z rzeczywistością.

Duże naciski na dokonywanie cudów (reality distortion field), spory nacisk na „no co, nie damy rady?”

Brak zrozumienia dla niedokładnie zdefiniowanej natury produkcji gier.

Siła przyzwyczajeń

Nacisk na używanie standardowych narzędzi i standardowych metodyk planowania i zarządzania projektami.

Projekty to zestawy zadań, a ludzie to „zasoby”. Plan ma uwzględniać wszystko, definiować

wszystkie zadania, optymalizować użycie zasobów.

Jeśli coś jest zaplanowane, to zawsze można to przecież „lepiej zaplanować”.

Wierz, ale sprawdzaj

Zasobami trzeba zarządzać – hierarchia i struktura.

Nad wszystkim mają czuwać managerowie i muszą wszystkim kierować.

Zasoby trzeba kontrolować. Zasoby muszą pracować na 120%. Jeśli coś się dzieje nie tak, to nie trzeba wyciągać

wniosków, ale można jeszcze bardziej przycisnąć śrubę.

Z siłą wodospadu

Metodyka planowania, pracy i zarządzania – wodospad (waterfall)

Wodospad

Produkcja jest podzielona na etapy. Kolejny etap zaczyna się po zaliczeniu

poprzedniego. Etapy najczęściej są swoimi małymi wodospadami. Jest wiele wodospadów równoległych. Problemy na dowolnym etapie przesuwają

wszystkie następujące po nim. Poprzez system zależności, przesunięcia w jednym

wodospadzie przesuwają też wodospady równoległe.

Planowanie wodospadu

Tworzenie dobrych planów jest bardzo trudne. Liczba zadań w dużych projektach jest

gigantyczna. Liczba zależności jest bardzo duża. Zaplanowanie wszystkiego z dużą dokładnością

jest bardzo trudne. Bywa, że tworzenie dobrego planu ciągnie się

niemalże przez całą produkcję.

Komunikacja

Nawet dobrze sporządzony plan jest bardzo trudny do przedstawienia wykonawcom.

Wykres Gantta jest nieczytelny dla większości ludzi zajmujących się tworzeniem gier.

Widoki dodatkowe (np. kalendarza) też nie są za czytelne.

Przekazanie informacji wszystkim w zakresie ich zadań jest bardzo trudne – filtrowanie po zasobach, zakresach czasowych itp.

Komunikacja

Plan powstaje u managerów, praca odbywa się w zespole – brakuje narzędzi dobrej, dwukierunkowej komunikacji.

Wykonawcy muszą najczęściej uciekać się do dodatkowych narzędzi informowania o przebiegu prac.

Śledzenie postępów i aktualizacja planu staje się projektem samym w sobie – często powstaje do tego osobny zespół.

Wodospad - problemy

Zakłada zakończenie poprzedzających faz przed rozpoczęciem kolejnych.

Dynamiczny charakter projektu powoduje, że założenia nieustannie się zmieniają, co wymaga nieustannego aktualizowania i poprawiania planu.

Trudności w komunikacji i śledzeniu prowadzą do szybkich rozbieżności planu i stanu faktycznego.

Wodospad - problemy

Duży stopień skomplikowania i konieczność zapewnienie aktualizacji (zbieranie informacji) sprawia, że zarządzaniem musi zajmować się kilka osób.

Oferując kompleksowy widok całego projektu, kusi do dokonywania w nim nierealistycznych zmian w celu osiągnięcia określonego efektu – np. skrócenia terminów, czy zmniejszenia udziału zasobów.

Wodospad - zalety

Dobrze zaprojektowany pozwala udzielić precyzyjniejszej odpowiedzi na pytanie „kiedy?”.

Bardzo dobrze odpowiada na pytanie „na pewno na kiedy nie?”.

Pozwala odkryć ścieżkę krytyczną. Pozwala na prostsze badanie wariantów

produkcyjnych – zmiany ilości zasobów, zmniejszanie zakresie – w celu poznania alternatywnych dat zakończenia.

Dość wodospadu!

Nowe jest zwinne

Podkopywanie starego

Metodyka wodospadu jest sztywna, skostniała, mało podatna na dynamikę i zmiany.

Preferuje struktury, hierarchie, „zasoby”, kółka w maszynie, zarządzenia i sterowanie – to kłóci się z dynamicznymi i kreatywnymi zmianami.

Przywiązanie do schematu i inercja powoduje opóźnienia, a tym samym naciski na zespół, aby je nadrabiać (bo termin był ustalony roku temu!).

Kładzie się nacisk na plan, a nie na funkcjonalny produkt.

Więcej problemów

Wiele części zespołu pracuje według osobnych planów, w różnym tempie, bez testowania wzajemnie swoich prac.

Gra przez większość czasu produkcji nie działa. Szacunki w planach są przeważnie za

optymistyczne. Managerowie zajmują się setkami drobnych

problemów, komunikacją i próbują zorientować się jaka jest naprawdę sytuacja.

Efekty

Mniej innowacji, brak reakcji na zmiany, plan górą. Spadek jakości produktów. Spadek jakości życia – coraz gorsze warunki pracy. Pogłębianie się animozji pomiędzy managerami, a

resztą zespołu. Ubezwłasnowolnienie wykonawców, zabijanie

inicjatyw. Spadek satysfakcji z pracy, wypalenie, odejścia z

branży.

Podejście zwinne (Agile)

Częstsze dostarczanie nowej funkcjonalności - iteracje.

Efekty – działająca gra – jest widoczną miarą postępu prac.

Zmiany specyfikacji nie mają destrukcyjnego wpływu – szybka i regularna adaptacja.

Bezpośrednia komunikacja w zespole i poza nim.

Samozarządzalność zespołów. Członkowie zespołu przecież wiedzą, co robią.

Zwinny projekt

Tradycyjny cykl podzielony na iteracje, każdy z konkretny rezultatem:

Młyn?

Scrum

Metodyka Scrum

Grę tworzy zespół w iteracjach – sprintach (typowo: 2-4 tygodnie).

Gra opisana jest jako lista planowanych funkcjonalności – Product Backlog.

Dla każdego sprintu tworzy się osobny zestaw detalicznych zadań do wykonania – Sprint Backlog – pobranych z Product Backlogu.

Backlog to zawsze spriorytetyzowana lista.

Metodyka Scrum

Product Backlog jest w gestii Product Ownera, który decyduje o kształcie gry.

Scrum Master wspiera zespół w pracy i usuwa im wszystkie przeszkody.

Zespół sam decyduje kto i kiedy w ramach sprintu wykonuje swoje prace.

Codzienny Standup Meeting pozwala opowiedzieć o postępach i poinformować o problemach.

Zadania – karteczki na tablicy.

Metodyka Scrum

Każdy sprint daje w efekcie działającą grę wzbogaconą o nową funkcjonalność.

Sprint rozpoczyna się planowanie – zespół sam dobiera sobie tyle zadań, ile jest w stanie wykonać.

Sprint kończy się retrospekcją, czyli dyskusją nad tym, co się wydarzyło i wnioskami na przyszłość.

Bieżący postęp prac ilustruje zazwyczaj wykres spalania (burndown chart).

Metodyka Scrum

Metodyka Scrum

Scrum – efekty

Poprawa komunikacji – wewnątrz zespołu, dzięki wspólnemu planowaniu, codziennym spotkaniom, oraz na zewnątrz, dzięki obecności Scrum Mastera, tablicy zadań oraz wykresowi spalania.

Zmniejszenie managementu – zespół zarządza się sam.

Zwiększenie zaangażowanie poprzez wybór zadań, szacowanie, widoczne efekty.

Zauważalne efekty pracy, ciągle funkcjonujący produkt.

Scrum – efekty

Lepiej dobrany zakres prac dzięki lepszemu szacowaniu i poznaniu prędkości (velocity) zespołu.

Usprawnianie procesów produkcyjnych oraz szacowania, dzięki retrospekcjom.

Możliwość szybkiej reakcji na zmiany poprzez zmiany w backlogu i szybszą widoczność efektów.

Szybko widać błędy szacowania, co pozwala na lepsze przydzielania zadań i szacowanie czasu zakończenia pracy.

Scrum – wyzwania

Metodyka dla projektów programistycznych, która zakładała, że członkowie zespołu mogą podołać zamiennie większości zaplanowanych zadań.

Przy produkcji gry zespoły są interdyscyplinarne, członkowie zespołu mają określone, różne specjalizacje.

Wiele procesów jest sekwencyjnych i nie można wykonywać ich w dowolnej kolejności – opóźnienia może zaważyć na kolejnych zadaniach i całości.

Scrum – wyzwania

Czasem trudno rozbić długie procesy produkcyjne na mniejsze części, które spełniają swoją rolę i mogą być częścią działającej gry.

Działa dobrze tylko w mniejszych zespołach. Scrum ma też swoje rytuały, które mogą być dla

wielu irytujące.

Nie wszystko stracone

Można zainwestować sporo w optymalizację Scruma i dostosowanie go do wymagań poszczególnych działów.

Można uprościć sobie Scruma i wybrać z niego „najciekawsze” elementy – Project Backlog, planowanie, sprinty, codzienne spotkania, konkretne cele realizowane przez działającą grę. Resztę traktuje się mnie ortodoksyjnie.

Można łączyć wodospad i metodyki zwinne. Nie pogryzą się! I liczy się efekt końcowy – gra.

Jeszcze zwinniej

Inne zwinne procesy i metody: Agile Modeling Agile Unified Process (AUP) Crystal Clear Dynamic Systems Development Method (DSDM) Extreme Programming (XP) Feature Driven Development (FDD) GSD Kanban (development) Lean software development Velocity tracking

Jedziemy z koksem

Wykonywanie

Podstawowy problem

Komunikacja

Komunikacja

W kontekście zarządzania projektem komunikacja to: Przekazanie podstawowych założeń projektowych. Komunikowanie terminów. Przekazywanie planów wykonawcom. Śledzenie postępów prac. Raportowanie stanu projektu

przełożonym/partnerom.

Dlaczego komunikacja to problem

Zespoły składają się z szerokiego spektrum ludzi: artyści, projektanci, pisarze, programiści.

Praca według planu oraz konieczność raportowania stoi w sprzeczności z „artystycznym” charakterem wielu prac produkcyjnych.

Ogólna niechęć do wykonywania nudnych i powtarzalnych czynności, które nie mają bezpośredniego wpływu na wykonywanie powierzonych prac.

Dlaczego komunikacja to problem

Nieumiejętność właściwego przedstawienia konieczności właściwej komunikacji czyni ten wymóg „zachcianką”, a nie koniecznością.

Brak powiązania mechanizmów komunikacyjnych z przebiegiem projektów – nie wiadomo, co właściwie daje raportowanie.

Opory komunikacyjne to stoją głównie po stronie zespołu.

Dlaczego komunikacja to problem

Plany produkcyjne mają słabo przyswajalną formę – ciężko je przedstawić (wydrukować) w formie „strawnej” dla np. artysty.

W wielu działach jest spora niechęć do używania narzędzi wykraczających poza zakres niezbędny do bezpośrednio wykonywanej pracy.

Jak poprawić komunikację?

Wyjaśnić po co faktycznie jest potrzebna. Dostarczać informację w czytelnej i zrozumiałej

formie (nie wykres Gantta!). Zapewnić jak najlepsze narzędzia do zlecania

prac i raportowania wykonania. Wdrożyć jakiś codzienny prosty rytuał związany

z raportowaniem. Gdy zawodzą narzędzie, użyć mechanizmów

personalnych (człowieka).

Czego unikać w tym procesie

Stawania po przeciwnych stronach barykady: Zarządzający projektem są częścią zespołu. Raportowanie to nie jest patrzenie na ręce – to

niezbędna informacja dla ułatwienia pracy wszystkim.

Czasem to wymóg „onych” – wtedy wszysyc tego nie lubimy, ale musimy

Forsowania rozwiązań, których nikt nie chce.

Nie antagonizujmy!

Zespół i managerowie jadą na tym samym wózku – mają ten sam cel, czyli doprowadzenie projektu do końca, najlepiej w dobrej jakości.

Raz rozpoczęty proces antagonizacji trudno zatrzymać: Prace toczą się niezgodnie z planem. Zarządzający nie znają faktycznego stanu projektu. Wrogość, niechęć, złośliwości, nawet sabotaż.

Przedstawienie planu

Jasny przekaz

Zaangażowanie wykonawców w planowanie ułatwia przekazywanie im planu – nie jest on zaskoczeniem.

Pamiętajmy o tym, że nie każdy musi podzielać nasze zdanie co do najlepszej formy planu.

Dobrze przedstawiony plan jest dobrym krokiem w kierunku dobrego wykonania.

Z drugiej strony, nie wszyscy członkowie będą zainteresowani wszystkimi detalami.

Komunikacja procesem ciągłym

Nie wystarczy oznajmić – oto nasz plan i zapomnieć o sprawie.

Będzie się przecież zmieniał – trzeba komunikować zmiany.

Tworzenie gry to proces długotrwały, warto więc cały czas dbać, aby wszyscy wiedzieli jakie są cele krótko i długoterminowe.

Wyznaczajmy sobie cele

Wyznaczajmy sobie cele, które wspólnie chcemy osiągnąć – regularne kamienie milowe projektu (milestones).

Wiele projektów wymaga ich także formalnie (np. z powodów kontraktowych)

Nawet jeśli stosujemy podejście zwinne, wyznaczanie sobie jasnych celów bieżących znacząco zwiększa skupienie się zespołu na osiągnięcie określonych rezultatów.

Realizacja planu

Róbmy swoje

Wybierzmy sobie jakikolwiek sposób zarządzania projektem, choćby najprostszą metodykę.

Niech będzie wiadomo, co chcemy robić i jak będziemy postępy prac śledzić. Nawet lista na kartce ze skreślaniem jest lepsza niż nic.

Skupmy się na postępach, nie stójmy w miejscu. Jeśli coś idzie nie tak, lepiej szybko podjąć jakąś decyzję i pchnąć projekt do przodu. Zacięcia i brak decyzji czasem potrafią położyć projekt.

Główny cel

Głównym celem jest zrobienie gry: W ogóle. Dobrej.

Spory, budowanie pozycji w stadzie, mania wielkości, i temu podobne, nie służą głównemu celowi.

Ambicje są fajne, dążenie do perfekcji też, ale feature creep zabił już nie jeden projekt.

Śledzenie postępów

To nie jest kontrola

Każdy projekt będzie miał problemy – trzeba je szybko wykrywać, aby móc je sprawnie usuwać.

Brak wiedzy o stanie projektu nie pozwala na szybkie wykrywanie problemów. Często ktoś, kto ma problem może nawet o tym nie wiedzieć.

Świadomość, że prace dobrze się toczą, dobrze wpływa na morale. Widać efekty.

Śledzenie postępów (lub ich braku)

Dobrze, gdy stosowana metodyka i jej narzędzia ułatwiają pokazywania postępów.

Tu przewagi mają metodyki zwinne nastawione na krótkoterminowe cele oraz działające iteracje produktu (nie mówiąc o scrumowym wykresie spalania).

W przypadku zhierarchizowanej struktury i klasycznego wodospadu śledzenie wymaga sporo wysiłku i staje się procesem samym w sobie, często wymagającym osobnych ludzi.

Narzędzia pomagają

Dobre narzędzia pozwalają wszystkim członkom zespołu łatwo prezentować własne postępy prac oraz równie łatwo obserwować postępy innych.

Jeśli nie ma dobrych narzędzi, trzeba opierać się o inne, najczęściej mniej lubiane metody: Przepytywanie – kojarzy się z brakiem zaufania. Wprowadzanie uciążliwych rytuałów – raporty

mejlowe, raporty we wspólnych plikach. Róbmy wszystko, aby ten proces ułatwiać i

oswajać.

Raportowanie

Smutna konieczność

Nie zawsze jesteśmy sobie sterem i żeglarzem, czasem ktoś stoi nad nami.

Znając stan projektu, łatwo nam takie raporty sporządzać.

Mając dobre narzędzia do śledzenia postępów, znamy dobrze stan i może go ładnie zaraportować.

Nie zdziwmy się, że ktoś będzie chciał wiedzieć np. jak wydajemy jego pieniądze. Raport czasem jest skromną ceną za sporą inwestycję.

Coś pójdzie źle, na pewno.

Zarządzanie ryzykiem

Będą problemy

Niezależnie od jakości planowania i metodyki zarządzania projektem, pojawią się problemy.

Pomysły się nie sprawdzają, ludzie zawodzą, ludzie odchodzą, ludzie chorują, partnerzy biznesowi upadają, pieniądze się kiedyś kończą.

Wypadki się zdarzają (bus factor). Zawsze zaplanujemy więcej niż będziemy w

stanie zrobić.

Zapoznaj się z trójkątem (ponownie)

JAKOŚĆ

CZAS KOSZT

ZakresIlość funkcji

Trójkąt w majtkowych kolorach

Minimalizacja ryzyka

Tak konstruujemy zakres gry, aby móc nim manipulować (czytaj – zmniejszać).

Cała zaplanowana funkcjonalność musi mieć priorytety, przynajmniej 3: Musi być (krytyczne dla jakości gry) Może być (podnosi jakość, ale nie jest krytyczne) Fajnie byłoby mieć (upiększające detale)

Na początek realizujemy rzeczy z największym priorytetem.

Minimalizacja ryzyka

Bardziej złożone elementy gry (np. fabułę) także konstruujemy tak, aby można było ją obcinać. Często cięcia w takiej dziedzinie skutkują sporymi redukacjami na innych listach produkcyjnych.

Zaplanuj bufory – bufory generalnie odnoszą się do szacowania kosztów, gdyż przedłużenie produkcji automatycznie oznacza zwiększenie kosztów.

Cięcia są prostsze i skuteczniejsze niż zużywanie buforów! Nic nie kosztują.

Minimalizacja ryzyka

Trzeba pozbywać się niewiadomych – prototypować, uściślać specyfikację i listy.

Najlepszych ludzi trzeba rzucać na najtrudniejsze zadania.

Ryzykiem też bywają ludzie – nie spełniają naszych oczekiwań, nie dogadują się z innymi w zespole.

Nie wszystko musimy zrobić wewnątrz zespołu – dobrzy partnerzy zewnętrzni (outsource) mogą nas uratować.

Minimalizacja ryzyka

Warto wcześnie zidentyfikować możliwe ryzyka i zdefiniować gotowe plany awaryjne.

Trzeba być cały czas czujnym. Jeśli wszystko idzie dobrze, to na pewno coś

przeoczyliśmy.

To praca zespołowa

Managerowie i zespół mają wspólny cel – to nie są przeciwnicy po przeciwnych stronach frontu.

Nie oszukujmy zespołu (fałszywe deadline’y). Warto dzielić się problemami z zespołem i

wspólnie zarządzać ryzykiem. Jeśli nie znamy rozwiązania problemu, bardzo

prawdopodobne, że ktoś z zespołu może nam pomóc.

Uczmy się na własnych błędach.

Postmortemy

Postmortem

Zwyczaj podsumowywania produkcji (lub etapy), gdy zespół tworzy listę np. 5 rzeczy, które się udały, oraz 5 rzeczy, które zawiodły.

Ja preferuję postmortemy krytyczne, nierzadko znacznie obszerniejsze.

Warto je robić po zakończeniu istotnych etapów produkcji, szczególnie wymagających znacznego wysiłku od zespołu: dema, vertical slice, ważne milestone’y, gold master.

Postmortem

Dobrze pozbierać postmortemy od różnych ludzi/działów.

Trzeba w nich wystrzegać się wskazywania palcami na konkretnych ludzi, a jedynie pokazywać problemy i sugestie ich rozwiązania.

Celem postmortemu jest usunięcie problemów, a nie antagonizowanie wzajemnie członków zespołu.

Ignorowanie raportowanych problemów raczej nie skończy się dobrze.

Narzędzia

#1

Narzędzie numer 1

Arkusz kalkulacyjny

Podstawowe narzędzie w rękach każdego producenta: Budżetowanie Proste harmonogramy Alokacje zasobów Listy produkcyjne Listy zadań Wszelkie inne listy

Arkusz kalkulacyjny

Wzorem jest Microsoft Office Excel Niezłe są darmowe alternatywy – LibreOffice Calc Niezbędna funkcjonalność – filtrowanie Najwygodniejsze są arkusze online – umożliwiają

współpracę i dzielenie się dokumentem (dostęp dla wszystkich, możliwości wspólnej edycji).

Google Docs są znakomite, ale można też śledzić alternatywne rozwiązania: http://en.wikipedia.org/wiki/List_of_online_spreadsheets

Człowiek to nie wszystko

Narzędzia do zarządzania

Hansoft

Jedyne znane mi narzędzie zbudowane specjalie do zarządzania produkcją gier wideo.

Wspiera zarówno tradycyjną metodykę wodospadu, jak i nowsze metodyki zwinne.

Ułatwia komunikację pomiędzy zespołem, a managerami.

Ułatwia zarządzanie zasobami.

Hansoft

Wspiera procesy produkcyjne (workflows). Daje dostęp wszystkim do całości projektu. Wspiera planowanie indywidualnych zadań. Pełni funkcję bazy błędów. Pozwala na zarządzanie dokumentami. Dość kosztowny – comiesięczne opłaty od liczby

użytkowników.

Microsoft Project

Podstawowe narzędzie do planowania projektów zarządzanych metodyką waterfall.

Pozwala na tworzenie, edycję oraz kontrolę harmonogramów.

Umożliwia śledzenie postępów prac. Pozwala na budżetowanie. Automatycznie identyfikuje problemy z

zasobami, czasem i finansami. Samodzielne narzędzie – brak komunikacji

(Project Server coś ułatwia)

Narzędzia online

Coraz popularniejsza kategoria narzędzi do zarządzania projektami – w formie aplikacji webowych.

Najczęściej łączą ze sobą funkcjonalność planowania i zarządzania projektami z bogatymi narzędziami ułatwiającymi współpracę w ramach zespołu.

Różny stopień skomplikowania, są narzędzia darmowe oraz komercyjne.

Gantter

Przeglądarkowa alternatywa dla MS Projecta, oczywiście znacznie uproszczona.

Umożliwia tworzenie harmonogramów, alokacje zasobów, automatyczne ustawianie zadań w zależności od dostępności zasobów, budżetowanie.

Umożliwia dzielenie się przygotowanym planem oraz wspólną pracę nad nim przez grupę menagerów.

Inne narzędzia online

Setki dostępnych rozwiązań: http://

en.wikipedia.org/wiki/Comparison_of_project_management_software

Różny stopień skomplikowana, różne filozofie pracy: harmonogramy, listy zadań, tickety.

Dodatkowo wspieranie śledzenia błędów, zarządzanie dokumentami, raportowanie i analiza.

Trudno znaleźć narzędzie dokładnie odpowiadające naszym potrzebom i procesom.

Też dają radę

Prostsze narzędzia

Listy to-do

Nie ma sensu rozważać narzędzi klienckich (instalowanych na komputerach zespołu) – narzędzia online są znacznie wygodniejsze.

Najważniejsza jest współpraca – wszyscy korzystają z tych samych list (mogą też mieć dodatkowo swoje).

Niekwestionowanym liderem w tej dziedzinie jest Basecamp.

Tablica Trello

Nowatorskie narzędzie do tworzenia list zadań, bazy błędów, systemów zarządzania procesami.

Tablicę dzieli się na zestaw list, na których umieszcza się „karteczki”.

Karteczka to opis, komentarze, wewnętrzne listy zadań, dołączone dokumenty, przypisani ludzie.

Sami określamy schematy prac w ramach konkretnych tablic.

Aktualnie mój #1 w projektach zwinnych.

Korzystajmy z narzędzi!

Znajdźmy sobie narzędzie, które będzie pasowało naszemu zespołowi i stosujmy je.

Korzystajmy z możliwości techniki i ułatwiajmy sobie życie.

Niech narzędzie jednak nie przeszkadza nam w osiągnięciu celu – stworzeniu fajnej gry.