Slajdy do 6-godzinnego wykładu w ramach kursu Digital Frontier.

1. ZARZĄDZANIE
PROJEKTEM
Próba zapanowania nad chaosem
Wykład z kursu Digital Frontier – digitalfrontier.pl

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

3. 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

4. 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.

5. Dziwko!
Zespół

6. 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.

7. 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.

8. 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.

9. 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.

10. 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.

11. 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.

12. 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ć.

13. Specyfikacja produktu
Definiowanie zakresu

14. 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.

15. 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.

16. 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.

17. 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.

18. 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.

19. 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.

20. Planowanie

21. 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.

22. 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.

23. 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).

24. 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.

25. 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.

26. 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ć.

27. 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.

28. 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.

29. 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).

30. 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.

31. 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.

32. 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.

33. 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

34. 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

35. 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

36. 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).

37. 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.

38. 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.

39. 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.

40. 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.

41. Zależności

42. 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.

43. 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.

44. 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.

45. 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.

46. Przykładowe planowanie
 Excel
 Gantter.com

47. Ale jak nad tym wszystkim zapanować?
Plan planem

48. Prosta metodyka zarządzania niewielkimi
projektami
Mała skala

49. 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.

50. 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.

51. 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.

52. 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.

53. 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.

54. Z siłą wodospadu.
Duża skala

55. 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.

56. 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.

57. Siła przyzwyczajeo
 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ć”.

58. 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ę.

59. Z siłą wodospadu
 Metodyka planowania, pracy i zarządzania –
wodospad (waterfall)

60. 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.

61. 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ę.

62. 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.

63. 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ół.

64. 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.

65. 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.

66. 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.

67. Dość wodospadu!
Nowe jest zwinne

68. 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.

69. 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.

70. 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.

71. 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ą.

72. Zwinny projekt
 Tradycyjny cykl podzielony na iteracje, każdy z
konkretny rezultatem:

73. Młyn?
Scrum

74. 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.

75. 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.

76. 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).

77. Metodyka Scrum

78. Metodyka Scrum

79. 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.

80. 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.

81. 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.

82. 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.

83. 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.

84. 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

85. Jedziemy z koksem
Wykonywanie

86. Podstawowy problem
Komunikacja

87. 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.

88. 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.

89. 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.

90. 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.

91. Jak poprawid 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).

92. Czego unikad 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.

93. 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ż.

94. Przedstawienie planu

95. 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.

96. 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.

97. 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.

98. Realizacja planu

99. 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.

100. 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.

101. Śledzenie postępów

102. 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.

103. Ś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.

104. 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ć.

105. Raportowanie

106. Smutna koniecznośd
 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ę.

107. Coś pójdzie źle, na pewno.
Zarządzanie ryzykiem

108. 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ć.

109. Zapoznaj się z trójkątem (ponownie)
JAKOŚĆ
CZAS KOSZT
Zakres
Ilość funkcji

110. Trójkąt w majtkowych kolorach

111. 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.

112. 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ą.

113. 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ć.

114. 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.

115. 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.

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

117. 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.

118. 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.

119. Narzędzia

120. #1
Narzędzie numer 1

121. 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

122. 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_spread
sheets

123. Człowiek to nie wszystko
Narzędzia do zarządzania

124. 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.

125. 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.

126. 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)

127. 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.

128. 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.

129. Inne narzędzia online
 Setki dostępnych rozwiązań:
 http://en.wikipedia.org/wiki/Comparison_of_proje
ct_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.

130. Też dają radę
Prostsze narzędzia

131. 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.

132. 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.

133. 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.