Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.

Zarządzanie projektem

2.025 Aufrufe

Veröffentlicht am

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

  • Als Erste(r) kommentieren

Zarządzanie projektem

  1. 1. ZARZĄDZANIEPROJEKTEMPróba zapanowania nad chaosemWykład z kursu Digital Frontier – digitalfrontier.pl
  2. 2. Bo to bardzo długi wykład będzie.Zakres wykładu
  3. 3. O czym opowiem Zespół Definiowaniezakresu Planowanie Metodykizarządzania: Tradycyjnywodospad Metodyki zwinne Wykonanie: Przedstawienie planu Realizacja planu Śledzenie postępów Raportowanie Zarządzanieryzykiem Postmortemy Narzędzia
  4. 4. 100% praktyki To są moje przemyślenia po 20+ latachtworzenia gier w różnych środowiskach Nie jestem wyszkolonym project managerem. Zaliczyłem kurs metodyki Scrum. Sporo samokształcenia – lubię wzmacniać swojedoświadczenie wiedzę teoretyczną, choćnajczęściej po fakcie. Pamiętajcie, YMMV.
  5. 5. Dziwko!Zespół
  6. 6. Mały zespół, mały problem W zespołach 2-3 osobowych praktycznie nieistnieje koncepcja zarządzania projektem. Plan mieści się na kartce (serwetce),komunikacja jest łatwa, a pełną wiedzę o stanieprojektu ma każdy. Wystarczą pewne wspólnie zaakceptowaneustalenia, minimalistyczny plan i wzajemnieobserwowania postępów pracy, aby projekttoczył się w dobrym kierunku.
  7. 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 iumiejętności. Trudno planować i zarządzać kolektywnie wdużej grupie. Pojawiają się problemy komunikacyjne. Rośnie koszt, ryzyko i stres.
  8. 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 gowykonywał. Plan stworzony „zaocznie” jest nic nie wart. Dobry plan to wiarygodny plan, czyli taki, wktóry przede wszystkim uwierzą wykonawcy.
  9. 9. Dobry plan tworzy zespół Planować powinien zespół, a producent/PM mato zadanie ułatwić. Idealnie, gdy każdy członek zespołu planujeswoje zadania. Nie zawsze mamy zespół w momencieplanowania, ale musimy mieć do dyspozycjiprzynajmniej kluczowych członków zespołu.
  10. 10. Planująca ekipa Producent Głównego projektanta (lead designera); Głównego programistę (leadprogrammer/technical director); Głównego artystę (art director/lead artist); Niektóre z funkcji można łączyć, szczególnie wmałych projektach.
  11. 11. Zespół Nie musimy czekać z planowaniem ażskompletujemy zespół – kluczowiprzedstawiciele pozwolą stworzyć niezływstępny plan. Plan musi uwzględniać ryzyka związane zpozyskaniem ludzi – bufory i plany awaryjne. Znaczną część pracy można zaplanować dlaludzi, których w zespole już mamy, co da namczas nie pozyskanie kolejnych.
  12. 12. Wiarygodny plan Plan, w którego stworzenie zaangażowany jestzespół ma szansę być planem wiarygodnym. Nie oznacza, że będzie to plan perfekcyjny, aleominie nas spora przeszkoda w jego realizacji,czyli brak wiary w realizowalność po stronietych, którzy będą musieli go realizować. Taki plan będzie nam o wiele łatwiejprezentować i wykonywać.
  13. 13. Specyfikacja produktuDefiniowanie zakresu
  14. 14. Definicja produktu Nie da się zaplanować produktu, który nie jestdobrze zdefiniowany. Nie da się sensownie odpowiedzieć na pytanie:„chciałbym grę w stylu takiej to, a takiej, ile tobędzie kosztować i kiedy będzie gotowe?” Jakość planowania w olbrzymim stopniu zależyod precyzji zdefiniowania produktu – gry.Potrzebna jest dobra specyfikacja projektu.
  15. 15. Wstępna specyfikacja Bardzo często na początku prac projektowychmamy bardzo ogólną specyfikację gry. Projekt gry zostaje uszczegółowiony podczasprac designerskich. Z w.w. powodów musimy ostrożnie planowaćoraz aktualizować swoje wstępne założeniawielokrotnie podczas polepszania się naszejwiedzy na temat definicji produktu. Nawet wtedy może powstać wstępny plan.
  16. 16. Od góry lub od dołu Możemy planować na podstawie specyfikacji –podejście od dołu. Możemy planować na podstawie czasowychi/lub finansowych założeń – podejście od góry. Niezależnie od podejścia, w pewnym momenciemusimy dobrze zgrać specyfikację gry (cochcemy osiągnąć) z możliwościami – czasem ipieniędzmi.
  17. 17. Gry to twory dynamiczne Niezależnie od podejścia musimy pamiętać odynamicznym charakterze tworzenia gier. Wstępna, nawet szczegółowa specyfikacja gryulegnie zmianie podczas jej tworzenia – planmusi to uwzględniać. I odwrotnie, pan nie jest z gumy, więc nierzadkotrzeba będzie zmienić pierwotną specyfikację,aby zmieścić trzymać się planu. Plany i specyfikacje muszą być elastyczne.
  18. 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 TechnicalDesign Document – opisujący jak i co konkretniechcemy zrobić – to źródło najlepsze. Musimy radzić sobie z tym, co mamy i zdobyć jaknajwięcej informacji w czasie planowania.
  19. 19. Zakres Mają specyfikację, musimy przetworzyć ją nazakres, co w praktyce oznacza zamianę opisu gryna listy produkcyjne: Listy funkcjonalnych elementów gry (featurelists/backlog) Listy elementów składowych (asset lists) Tak przetworzone listy będzie można potempróbować przekształcić w listy zadań dowykonania, oszacować ich czasochłonność iułożyć w plan.
  20. 20. Planowanie
  21. 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 wramy czasowe. Musi jak najszybciej zostać przekształcony wplan od dołu.
  22. 22. Plan od dołu Opiera się na w miarę dokładnej specyfikacji, awł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 konkretnezadania (przynajmniej leadów). Prowadzi do lepszych planów, bardziej zgodnychz rzeczywistością i bardziej wiarygodnych.
  23. 23. Listy Listy produkcyjne pozwalają nam szacować czasniezbędny do ich realizacji i układać plan. Produkcja elementów graficznych oraz audio(assetów) odbywa się na bazie dość dobrzeustalonych procesów. Projektowanie gry, tworzenia fabuły i dialogów,programowanie technologii oraz rozgrywki toprocesy przeważnie słabiej zdefiniowane(dynamiczne).
  24. 24. Procesy ustalone Listy assetów stosunkowo łatwo przekształcić wkonkretne 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 listyzadań do wykonania.
  25. 25. Procesy dynamiczne Przewidywane prace w zakresie prac dynamicznychdzielimy na maksymalnie rozdzielne elementyfunkcjonalne (features). Listy elementów funkcjonalnych sortujemy podwzględem priorytetów ważności dla jakości gry ijej unikalności, oraz ryzyka (ryzykowne napoczątek). Tak zaplanowaną kolejność prac ograniczamyramami czasowymi zgodnymi z ogólnymizałożeniami projektu (time boxing). Czego niezrobimy na czas, tego w grze po prostu nie będzie.
  26. 26. Procesy dynamiczne Bardzo często więcej, nie oznacza lepiej i gramoże wręcz zyskać na mniejszej liczbiefunkcjonalności, które są lepiej dopracowane.Nie boimy się ciąć! Dobrze jest prace ograniczać czasowowielokrotnie w czasie projektu, aby mócmodyfikować listę i zmieniać priorytety. Wiedzana temat gry rośnie wraz z jej rozwojem, więcoryginalna kolejność po jakimś czasie może niemieć sensu i warto ją zmienić.
  27. 27. Procesy dynamiczne Niezależnie od planowania metodą ramczasowych, warto przeanalizować, czy w ogóleplanowane najważniejsze rzeczy zmieszczą sięw ramach – nie zakładajmy, że samowyznaczenie deadline sprawi, że coś się na todeadline pojawi. Realizacja pewnych funkcjonalności musipotrwać pewien minimalny czas i nałożeniesobie zbyt krótkich ram czasowych nieprzyniesie nam żadnych rezultatów.
  28. 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). Tutajzasada mniej, ale lepiej nie działa – musimy miećkomplet dźwięków tam, gdzie każdy ich brakzauważy. W takim wypadku najlepiej zaplanować pracęprzebiegami. W pierwszym przebieguwykonujemy normy ilościowe, a kolejnychpoprawiamy jakość, powtarzając ten procesdopóki trwa projekt.
  29. 29. Plan – oczekiwania Nie każdy projekt wymaga szczegółowego planui 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ł takdługo jak one same).
  30. 30. Przygotowania Mamy określoną (przynajmniej zgrubnie)specyfikację, z której wynika planowany zakresprac. Wiemy jakim dysponujemy zespołem –aktualnie lub docelowo. Możemy przystąpić do planowania.
  31. 31. Szacowanie czasu pracy Podstawą budowy wiarygodnego planu jestoszacowanie czasu wykonywania poszczególnychzadań. Dobrze oszacować można jedynie dobrzezdefiniowane zadania. Im większe zadanie – bardziej złożone albo gorzejzdefiniowane – tym gorsze będą oszacowania. Fajnie założyć jakąś minimalną gradację czasuszacowania (np. 1 dzień/1 tydzień) w zależności oddokładności planu.
  32. 32. Szacowanie czasu pracy Szacują wykonawcy danych prac: I tak będą niedoszacowywać, szczególnie młodzi iniedoświadczeni. Przełożeni będą szacować według swoichumiejętności, a nie wykonawcy. Przełożeni mają tendencję do wywierania presji naszybsze 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. 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. 34. Szacowanie - formuły PERT (Program Evaluation and ReviewTechnique): Best Case: 10 Worst Case: 25 Likely Case: 15 (BC + 4 * LC + WC) / 6 (10 + 4 * 15 + 25) / 6 = 16
  35. 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. 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. 37. Arkusz kalkulacyjny Doskonałe narzędzie do tworzenia planówzgrubnych. Łatwy w obsłudze. Nie ma wielu funkcji wspierających – cały plantrzeba modyfikować ręcznie. Lepszy jednak nawet prosty plan niż żaden. Spisuje się też doskonale w prostszychprojektach, gdzie ma wiele zależności.
  38. 38. Narzędzie specjalizowane Bardzo dużo funkcjonalności wspierające procesplanowania. Pozwala uniknąć wielu błędów – nadmiernegolub niedostatecznego obciążenia wykonawców(tzw. zasobów), nieuwzględnienia zależności. Łatwo wprowadzać zmiany, które natychmiastmodyfikują cały plan – proces całkowicieautomatyczny.
  39. 39. Narzędzie specjalizowane Można narzucić wiele ograniczeń, które będąuwzględniane podczas planowania. Łatwiej określać zależności pomiędzyzadaniami. Wyraźnie widać ścieżkę krytyczną projektu. Kusi do „optymalizowania” planu, aby osiągnąćzamierzony rezultat – co owocuje tworzeniemplanów fikcyjnych.
  40. 40. Zależności Pewne zadania można wykonać tylko wtedy, gdywcześniej zostaną wykonane inne zadania. Zadania mogą mieć proste zależności – jedynieod jednego poprzedniego, albo złożone – odwielu zadań. Zadania i zależności pomiędzy nimi wytyczająścieżkę krytyczną projektu. Produkcja gier często obfituje w bardzoskomplikowany system zależności, co utrudniaplanowanie.
  41. 41. Zależności
  42. 42. Planowanie Lista zadań i procesów ograniczanych czasowo. Zadania pogrupowane według upodobań. Lista wykonawców (zespół). Każdemu z wykonawców przypisujemy kolejnozadania z puli. Zadania powiązane ustawiamy we właściwiejkolejności. Uwzględniamy zadania wieloprzebiegowe –iteracyjne.
  43. 43. Planowanie Plan musi uwzględnić podstawowe cykleprodukcyjne: projektowanie, prototypowanie,produkcję właściwą i proces post-produkcji. W planie musimy uwzględnić błędy orazkonieczność ich naprawienia. Nie wszystkiebłę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. 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 produkcjabędzie musiała się przedłużyć. Rozsądny bufor to 30% lub więcej całości. Imkrótszy projekt, tym większy bufor. Bufor nie musi być częścią planu pracy – ważny jestw budżetowaniu.
  45. 45. Sytuacja zmienną jest Plany się dezaktualizują. Szybko. Trzeba plany często modyfikować. Trzeba śledzić faktyczne postępy prac iporównywać je z planem. Planowanie i śledzenia prac w projekcie wymagaproducentów lub project managerów. Nie wkażdym projekcie jest to możliwe.
  46. 46. Przykładowe planowanie Excel Gantter.com
  47. 47. Ale jak nad tym wszystkim zapanować?Plan planem
  48. 48. Prosta metodyka zarządzania niewielkimiprojektamiMała skala
  49. 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 ustalonymprocesie produkcyjnym. W ramach jakiegoś limitu czasowego w pozostałychkategoriach.
  50. 50. Prosty plan Lista zadań jest dobrym zasobem w dalszymzarządzaniu niewielkim projektem. Lista zawsze musi być posortowania względempriorytetów i ryzyka – niezbędne elementy orazte obarczone największym ryzykiem (alewykonalne w rozsądnym czasie) muszą być napoczątku listy. Plan trzeba będzie modyfikować w miarępostępu prac nad projektem.
  51. 51. Prosty plan Zadania przypisuje się według zaplanowanejkolejności wykonawcom. Przypisania obejmują tylko najbliższy okres. Wykonawcy oznaczają zadania wykonane. Ocena stanu projektu jest prowadzona nabieżąco – zrobione/do zrobienia.
  52. 52. Prosty plan Jako narzędzia wystarczą proste listy zadań dozrobienia (to do) albo systemy ticketowe. Mnogośćnarzędzi komputerowych, w tym online. Można stosować systemy analogowe – tablice ikarteczki. Jasny przekaz dla wykonawców, prosta informacjazwrotna. Prostota plany ułatwia modyfikacje i zmiany –proces zarządzania nie zajmuje wiele czasu i dajesię pogodzić z innymi zajęciami.
  53. 53. Prosty plan - problemy Ocena wielkości pozostałej pracy odbywa się „naoko”. Trudna odpowiedź na pytanie „kiedy?” Przy prostych narzędziach (czy analogowych)trudno post factum zebrać informację o czasachwykonywania zadań. Nie uwzględnia się zależności pomiędzyzadaniami. Wymaga zarządzającego listami/zadaniami.
  54. 54. Z siłą wodospadu.Duża skala
  55. 55. Zarządzanie na wyższym poziomie Dużo ludzi, spore pieniądze, dziesiątki tysięcyzadań, akcjonariusza, zarządy. Olbrzymia skala projektu rodzi problemy wwykł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łbyniezłymi budżetami mniejszych gier.
  56. 56. Wkracza korporacyjny styl Oczekuje się planów, odpowiedzi na pytaniakiedy i za ile, wzorowej organizacji pracy. Często wymogi kierownictwa nie mają wielewspólnego z rzeczywistością. Duże naciski na dokonywanie cudów (realitydistortion field), spory nacisk na „no co, niedamy rady?” Brak zrozumienia dla niedokładniezdefiniowanej natury produkcji gier.
  57. 57. Siła przyzwyczajeo Nacisk na używanie standardowych narzędzi istandardowych metodyk planowania izarządzania projektami. Projekty to zestawy zadań, a ludzie to „zasoby”. Plan ma uwzględniać wszystko, definiowaćwszystkie zadania, optymalizować użyciezasobów. Jeśli coś jest zaplanowane, to zawsze można toprzecież „lepiej zaplanować”.
  58. 58. Wierz, ale sprawdzaj Zasobami trzeba zarządzać – hierarchia istruktura. Nad wszystkim mają czuwać managerowie imuszą 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. 59. Z siłą wodospadu Metodyka planowania, pracy i zarządzania –wodospad (waterfall)
  60. 60. Wodospad Produkcja jest podzielona na etapy. Kolejny etap zaczyna się po zaliczeniupoprzedniego. 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 jednymwodospadzie przesuwają też wodospadyrównoległe.
  61. 61. Planowanie wodospadu Tworzenie dobrych planów jest bardzo trudne. Liczba zadań w dużych projektach jestgigantyczna. 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. 62. Komunikacja Nawet dobrze sporządzony plan jest bardzotrudny do przedstawienia wykonawcom. Wykres Gantta jest nieczytelny dla większościludzi zajmujących się tworzeniem gier. Widoki dodatkowe (np. kalendarza) też nie są zaczytelne. Przekazanie informacji wszystkim w zakresieich zadań jest bardzo trudne – filtrowanie pozasobach, zakresach czasowych itp.
  63. 63. Komunikacja Plan powstaje u managerów, praca odbywa się wzespole – brakuje narzędzi dobrej,dwukierunkowej komunikacji. Wykonawcy muszą najczęściej uciekać się dododatkowych narzędzi informowania oprzebiegu prac. Śledzenie postępów i aktualizacja planu staje sięprojektem samym w sobie – często powstaje dotego osobny zespół.
  64. 64. Wodospad - problemy Zakłada zakończenie poprzedzających faz przedrozpoczęciem kolejnych. Dynamiczny charakter projektu powoduje, żezałożenia nieustannie się zmieniają, co wymaganieustannego aktualizowania i poprawianiaplanu. Trudności w komunikacji i śledzeniu prowadządo szybkich rozbieżności planu i stanufaktycznego.
  65. 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 nierealistycznychzmian w celu osiągnięcia określonego efektu –np. skrócenia terminów, czy zmniejszeniaudziału zasobów.
  66. 66. Wodospad - zalety Dobrze zaprojektowany pozwala udzielićprecyzyjniejszej odpowiedzi na pytanie „kiedy?”. Bardzo dobrze odpowiada na pytanie „na pewnona kiedy nie?”. Pozwala odkryć ścieżkę krytyczną. Pozwala na prostsze badanie wariantówprodukcyjnych – zmiany ilości zasobów,zmniejszanie zakresie – w celu poznaniaalternatywnych dat zakończenia.
  67. 67. Dość wodospadu!Nowe jest zwinne
  68. 68. Podkopywanie starego Metodyka wodospadu jest sztywna, skostniała,mało podatna na dynamikę i zmiany. Preferuje struktury, hierarchie, „zasoby”, kółka wmaszynie, zarządzenia i sterowanie – to kłóci sięz dynamicznymi i kreatywnymi zmianami. Przywiązanie do schematu i inercja powodujeopóźnienia, a tym samym naciski na zespół, abyje nadrabiać (bo termin był ustalony rokutemu!). Kładzie się nacisk na plan, a nie na funkcjonalnyprodukt.
  69. 69. Więcej problemów Wiele części zespołu pracuje według osobnychplanów, w różnym tempie, bez testowaniawzajemnie swoich prac. Gra przez większość czasu produkcji nie działa. Szacunki w planach są przeważnie zaoptymistyczne. Managerowie zajmują się setkami drobnychproblemów, komunikacją i próbują zorientowaćsię jaka jest naprawdę sytuacja.
  70. 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, aresztą zespołu. Ubezwłasnowolnienie wykonawców, zabijanieinicjatyw. Spadek satysfakcji z pracy, wypalenie, odejścia zbranży.
  71. 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ą destrukcyjnegowpł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. 72. Zwinny projekt Tradycyjny cykl podzielony na iteracje, każdy zkonkretny rezultatem:
  73. 73. Młyn?Scrum
  74. 74. Metodyka Scrum Grę tworzy zespół w iteracjach – sprintach(typowo: 2-4 tygodnie). Gra opisana jest jako lista planowanychfunkcjonalności – Product Backlog. Dla każdego sprintu tworzy się osobny zestawdetalicznych zadań do wykonania – SprintBacklog – pobranych z Product Backlogu. Backlog to zawsze spriorytetyzowana lista.
  75. 75. Metodyka Scrum Product Backlog jest w gestii Product Ownera,który decyduje o kształcie gry. Scrum Master wspiera zespół w pracy i usuwaim wszystkie przeszkody. Zespół sam decyduje kto i kiedy w ramachsprintu wykonuje swoje prace. Codzienny Standup Meeting pozwalaopowiedzieć o postępach i poinformować oproblemach. Zadania – karteczki na tablicy.
  76. 76. Metodyka Scrum Każdy sprint daje w efekcie działającą gręwzbogaconą o nową funkcjonalność. Sprint rozpoczyna się planowanie – zespół samdobiera sobie tyle zadań, ile jest w staniewykonać. Sprint kończy się retrospekcją, czyli dyskusjąnad tym, co się wydarzyło i wnioskami naprzyszłość. Bieżący postęp prac ilustruje zazwyczaj wykresspalania (burndown chart).
  77. 77. Metodyka Scrum
  78. 78. Metodyka Scrum
  79. 79. Scrum – efekty Poprawa komunikacji – wewnątrz zespołu, dziękiwspó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ącyprodukt.
  80. 80. Scrum – efekty Lepiej dobrany zakres prac dzięki lepszemuszacowaniu i poznaniu prędkości (velocity) zespołu. Usprawnianie procesów produkcyjnych orazszacowania, dzięki retrospekcjom. Możliwość szybkiej reakcji na zmiany poprzezzmiany w backlogu i szybszą widoczność efektów. Szybko widać błędy szacowania, co pozwala nalepsze przydzielania zadań i szacowanie czasuzakończenia pracy.
  81. 81. Scrum – wyzwania Metodyka dla projektów programistycznych, którazakł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óżnespecjalizacje. Wiele procesów jest sekwencyjnych i nie możnawykonywać ich w dowolnej kolejności – opóźnieniamoże zaważyć na kolejnych zadaniach i całości.
  82. 82. Scrum – wyzwania Czasem trudno rozbić długie procesyprodukcyjne 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ć dlawielu irytujące.
  83. 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. Niepogryzą się! I liczy się efekt końcowy – gra.
  84. 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. 85. Jedziemy z koksemWykonywanie
  86. 86. Podstawowy problemKomunikacja
  87. 87. Komunikacja W kontekście zarządzania projektemkomunikacja to: Przekazanie podstawowych założeń projektowych. Komunikowanie terminów. Przekazywanie planów wykonawcom. Śledzenie postępów prac. Raportowanie stanu projektuprzełożonym/partnerom.
  88. 88. Dlaczego komunikacja to problem Zespoły składają się z szerokiego spektrumludzi: artyści, projektanci, pisarze, programiści. Praca według planu oraz koniecznośćraportowania stoi w sprzeczności z„artystycznym” charakterem wielu pracprodukcyjnych. Ogólna niechęć do wykonywania nudnych ipowtarzalnych czynności, które nie mająbezpośredniego wpływu na wykonywaniepowierzonych prac.
  89. 89. Dlaczego komunikacja to problem Nieumiejętność właściwego przedstawieniakonieczności właściwej komunikacji czyni tenwymóg „zachcianką”, a nie koniecznością. Brak powiązania mechanizmówkomunikacyjnych z przebiegiem projektów – niewiadomo, co właściwie daje raportowanie. Opory komunikacyjne to stoją głównie postronie zespołu.
  90. 90. Dlaczego komunikacja to problem Plany produkcyjne mają słabo przyswajalnąformę – ciężko je przedstawić (wydrukować) wformie „strawnej” dla np. artysty. W wielu działach jest spora niechęć do używanianarzędzi wykraczających poza zakres niezbędnydo bezpośrednio wykonywanej pracy.
  91. 91. Jak poprawid komunikację? Wyjaśnić po co faktycznie jest potrzebna. Dostarczać informację w czytelnej i zrozumiałejformie (nie wykres Gantta!). Zapewnić jak najlepsze narzędzia do zlecaniaprac i raportowania wykonania. Wdrożyć jakiś codzienny prosty rytuał związanyz raportowaniem. Gdy zawodzą narzędzie, użyć mechanizmówpersonalnych (człowieka).
  92. 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 – toniezbędna informacja dla ułatwienia pracywszystkim. Czasem to wymóg „onych” – wtedy wszysyc tego nielubimy, ale musimy Forsowania rozwiązań, których nikt nie chce.
  93. 93. Nie antagonizujmy! Zespół i managerowie jadą na tym samymwózku – mają ten sam cel, czyli doprowadzenieprojektu do końca, najlepiej w dobrej jakości. Raz rozpoczęty proces antagonizacji trudnozatrzymać: Prace toczą się niezgodnie z planem. Zarządzający nie znają faktycznego stanu projektu. Wrogość, niechęć, złośliwości, nawet sabotaż.
  94. 94. Przedstawienie planu
  95. 95. Jasny przekaz Zaangażowanie wykonawców w planowanieułatwia przekazywanie im planu – nie jest onzaskoczeniem. Pamiętajmy o tym, że nie każdy musi podzielaćnasze zdanie co do najlepszej formy planu. Dobrze przedstawiony plan jest dobrymkrokiem w kierunku dobrego wykonania. Z drugiej strony, nie wszyscy członkowie będązainteresowani wszystkimi detalami.
  96. 96. Komunikacja procesem ciągłym Nie wystarczy oznajmić – oto nasz plan izapomnieć o sprawie. Będzie się przecież zmieniał – trzebakomunikować zmiany. Tworzenie gry to proces długotrwały, wartowięc cały czas dbać, aby wszyscy wiedzieli jakiesą cele krótko i długoterminowe.
  97. 97. Wyznaczajmy sobie cele Wyznaczajmy sobie cele, które wspólnie chcemyosią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żącychznacząco zwiększa skupienie się zespołu naosiągnięcie określonych rezultatów.
  98. 98. Realizacja planu
  99. 99. Róbmy swoje Wybierzmy sobie jakikolwiek sposóbzarządzania projektem, choćby najprostsząmetodykę. Niech będzie wiadomo, co chcemy robić i jakbędziemy postępy prac śledzić. Nawet lista nakartce 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 ibrak decyzji czasem potrafią położyć projekt.
  100. 100. Główny cel Głównym celem jest zrobienie gry: W ogóle. Dobrej. Spory, budowanie pozycji w stadzie, maniawielkości, i temu podobne, nie służą głównemucelowi. Ambicje są fajne, dążenie do perfekcji też, alefeature creep zabił już nie jeden projekt.
  101. 101. Śledzenie postępów
  102. 102. To nie jest kontrola Każdy projekt będzie miał problemy – trzeba jeszybko wykrywać, aby móc je sprawnie usuwać. Brak wiedzy o stanie projektu nie pozwala naszybkie wykrywanie problemów. Często ktoś,kto ma problem może nawet o tym nie wiedzieć. Świadomość, że prace dobrze się toczą, dobrzewpływa na morale. Widać efekty.
  103. 103. Śledzenie postępów (lub ich braku) Dobrze, gdy stosowana metodyka i jej narzędziaułatwiają pokazywania postępów. Tu przewagi mają metodyki zwinne nastawionena krótkoterminowe cele oraz działające iteracjeproduktu (nie mówiąc o scrumowym wykresiespalania). W przypadku zhierarchizowanej struktury iklasycznego wodospadu śledzenie wymagasporo wysiłku i staje się procesem samym wsobie, często wymagającym osobnych ludzi.
  104. 104. Narzędzia pomagają Dobre narzędzia pozwalają wszystkim członkomzespołu łatwo prezentować własne postępy pracoraz 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 – raportymejlowe, raporty we wspólnych plikach. Róbmy wszystko, aby ten proces ułatwiać ioswajać.
  105. 105. Raportowanie
  106. 106. Smutna koniecznośd Nie zawsze jesteśmy sobie sterem i żeglarzem,czasem ktoś stoi nad nami. Znając stan projektu, łatwo nam takie raportysporządzać. Mając dobre narzędzia do śledzenia postępów,znamy dobrze stan i może go ładniezaraportować. Nie zdziwmy się, że ktoś będzie chciał wiedziećnp. jak wydajemy jego pieniądze. Raport czasemjest skromną ceną za sporą inwestycję.
  107. 107. Coś pójdzie źle, na pewno.Zarządzanie ryzykiem
  108. 108. Będą problemy Niezależnie od jakości planowania i metodykizarządzania projektem, pojawią się problemy. Pomysły się nie sprawdzają, ludzie zawodzą,ludzie odchodzą, ludzie chorują, partnerzybiznesowi upadają, pieniądze się kiedyś kończą. Wypadki się zdarzają (bus factor). Zawsze zaplanujemy więcej niż będziemy wstanie zrobić.
  109. 109. Zapoznaj się z trójkątem (ponownie)JAKOŚĆCZAS KOSZTZakresIlość funkcji
  110. 110. Trójkąt w majtkowych kolorach
  111. 111. Minimalizacja ryzyka Tak konstruujemy zakres gry, aby móc nimmanipulować (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ększympriorytetem.
  112. 112. Minimalizacja ryzyka Bardziej złożone elementy gry (np. fabułę) takżekonstruujemy tak, aby można było ją obcinać.Często cięcia w takiej dziedzinie skutkująsporymi redukacjami na innych listachprodukcyjnych. Zaplanuj bufory – bufory generalnie odnoszą siędo szacowania kosztów, gdyż przedłużenieprodukcji automatycznie oznacza zwiększeniekosztów. Cięcia są prostsze i skuteczniejsze niż zużywaniebuforów! Nic nie kosztują.
  113. 113. Minimalizacja ryzyka Trzeba pozbywać się niewiadomych –prototypować, uściślać specyfikację i listy. Najlepszych ludzi trzeba rzucać nanajtrudniejsze zadania. Ryzykiem też bywają ludzie – nie spełniająnaszych oczekiwań, nie dogadują się z innymi wzespole. Nie wszystko musimy zrobić wewnątrz zespołu– dobrzy partnerzy zewnętrzni (outsource)mogą nas uratować.
  114. 114. Minimalizacja ryzyka Warto wcześnie zidentyfikować możliwe ryzykai zdefiniować gotowe plany awaryjne. Trzeba być cały czas czujnym. Jeśli wszystko idzie dobrze, to na pewno cośprzeoczyliśmy.
  115. 115. To praca zespołowa Managerowie i zespół mają wspólny cel – to niesą przeciwnicy po przeciwnych stronach frontu. Nie oszukujmy zespołu (fałszywe deadline’y). Warto dzielić się problemami z zespołem iwspólnie zarządzać ryzykiem. Jeśli nie znamy rozwiązania problemu, bardzoprawdopodobne, że ktoś z zespołu może nampomóc.
  116. 116. Uczmy się na własnych błędach.Postmortemy
  117. 117. Postmortem Zwyczaj podsumowywania produkcji (lubetapy), gdy zespół tworzy listę np. 5 rzeczy,które się udały, oraz 5 rzeczy, które zawiodły. Ja preferuję postmortemy krytyczne, nierzadkoznacznie obszerniejsze. Warto je robić po zakończeniu istotnych etapówprodukcji, szczególnie wymagających znacznegowysiłku od zespołu: dema, vertical slice, ważnemilestone’y, gold master.
  118. 118. Postmortem Dobrze pozbierać postmortemy od różnychludzi/działów. Trzeba w nich wystrzegać się wskazywaniapalcami na konkretnych ludzi, a jedyniepokazywać problemy i sugestie ich rozwiązania. Celem postmortemu jest usunięcie problemów, anie antagonizowanie wzajemnie członkówzespołu. Ignorowanie raportowanych problemów raczejnie skończy się dobrze.
  119. 119. Narzędzia
  120. 120. #1Narzędzie numer 1
  121. 121. Arkusz kalkulacyjny Podstawowe narzędzie w rękach każdegoproducenta: Budżetowanie Proste harmonogramy Alokacje zasobów Listy produkcyjne Listy zadań Wszelkie inne listy
  122. 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 dlawszystkich, 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
  123. 123. Człowiek to nie wszystkoNarzędzia do zarządzania
  124. 124. Hansoft Jedyne znane mi narzędzie zbudowane specjaliedo zarządzania produkcją gier wideo. Wspiera zarówno tradycyjną metodykęwodospadu, jak i nowsze metodyki zwinne. Ułatwia komunikację pomiędzy zespołem, amanagerami. Ułatwia zarządzanie zasobami.
  125. 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 liczbyużytkowników.
  126. 126. Microsoft Project Podstawowe narzędzie do planowaniaprojektó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 zzasobami, czasem i finansami. Samodzielne narzędzie – brak komunikacji(Project Server coś ułatwia)
  127. 127. Narzędzia online Coraz popularniejsza kategoria narzędzi dozarządzania projektami – w formie aplikacjiwebowych. Najczęściej łączą ze sobą funkcjonalnośćplanowania i zarządzania projektami z bogatyminarzędziami ułatwiającymi współpracę wramach zespołu. Różny stopień skomplikowania, są narzędziadarmowe oraz komercyjne.
  128. 128. Gantter Przeglądarkowa alternatywa dla MS Projecta,oczywiście znacznie uproszczona. Umożliwia tworzenie harmonogramów, alokacjezasobów, automatyczne ustawianie zadań wzależności od dostępności zasobów,budżetowanie. Umożliwia dzielenie się przygotowanym planemoraz wspólną pracę nad nim przez grupęmenagerów.
  129. 129. 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 filozofiepracy: harmonogramy, listy zadań, tickety. Dodatkowo wspieranie śledzenia błędów,zarządzanie dokumentami, raportowanie ianaliza. Trudno znaleźć narzędzie dokładnieodpowiadające naszym potrzebom i procesom.
  130. 130. Też dają radęProstsze narzędzia
  131. 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 – wszyscykorzystają z tych samych list (mogą też miećdodatkowo swoje). Niekwestionowanym liderem w tej dziedziniejest Basecamp.
  132. 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órychumieszcza się „karteczki”. Karteczka to opis, komentarze, wewnętrzne listyzadań, dołączone dokumenty, przypisani ludzie. Sami określamy schematy prac w ramachkonkretnych tablic. Aktualnie mój #1 w projektach zwinnych.
  133. 133. Korzystajmy z narzędzi! Znajdźmy sobie narzędzie, które będziepasowało naszemu zespołowi i stosujmy je. Korzystajmy z możliwości techniki i ułatwiajmysobie życie. Niech narzędzie jednak nie przeszkadza nam wosiągnięciu celu – stworzeniu fajnej gry.

×