Kolorowanie linii projektu (z Maikiem Stettnerem z EA Games)

Przeczytaj transkrypcję:

Próbujemy transkrybować nasze podcasty za pomocą programu komputerowego. Wybaczcie wszelkie literówki, ponieważ bot nie jest poprawny w 100% przypadków.

Ben Aston

Witamy w podcaście DPM, w którym wychodzimy poza teorię, aby udzielać ekspertom PM praktycznych porad dotyczących skuteczniejszego prowadzenia projektów cyfrowych. Dziękuję za dostrojenie się. Nazywam się Ben Aston i jestem założycielem The Digital Project Manager. Bądźmy szczerzy: czy jesteś gotowy realizować swoje projekty zgodnie z budżetem? I zgodnie z harmonogramem? Czy jesteś gotowy dostarczyć również zakres, który obiecałeś? Nie masz pewności? Jak więc możesz to wiedzieć i jak możesz to osiągnąć? Właśnie o tym jest dzisiejszy podcast. O kontroli projektu.

To po prostu linie, które wyznaczamy wokół naszych projektów, aby pomóc sobie zrozumieć parametry projektu. Wiedzieć, gdzie powinniśmy kolorować. I rozpoznawać, kiedy w naszym projekcie wychodzimy poza te linie.

Ten odcinek sponsoruje Resource Guru, narzędzie do planowania zasobów używane przez zespoły w firmach takich jak Apple, Ogilvy, Deloitte i Publicis. Słuchacze DPM mogą otrzymać 20% zniżki na cały okres korzystania z konta, używając kodu rabatowego DPM2018.

Dowiedz się więcej w Resource Guru

Dzisiaj rozmawiam z Maikiem Stettnerem. Maik został niedawno mianowany dyrektorem ds. rozwoju w EA Games; wcześniej pracował w FCV, gdzie zarządza zespołem. Jest także jednym z naszych wewnętrznych ekspertów DMP w szkole Digital Project Manager. Kiedy zarządzasz zespołem kierowników projektów, jedną z kwestii, do których naprawdę można nabrać pasji, jest kontrola projektu. Maik ma w tym duże doświadczenie. Naprawdę chcesz, aby Twój zespół realizował projekty zgodnie z budżetem. Naprawdę chcesz, aby dotrzymywał terminów i osiągał wyznaczone kamienie milowe, bo inaczej wszystko zaczyna się rozpadać i musisz się zaangażować. Dlatego porozmawiamy dziś o tym, jak możemy lepiej zarządzać projektami i jakie kontrole możemy wdrożyć. Po pierwsze, pozwalają nam wiedzieć, że jesteśmy na właściwym torze. Po drugie, dają nam pewne możliwości, gdy zaczynamy zbaczać z kursu.

Mam nadzieję, że brzmi to dobrze. Maik, witaj w programie.

Maik Stettner:

Hej, Ben. Dzięki za zaproszenie.

Ben Aston:

Dobrze znów Cię gościć. Maik, opowiedz nam trochę o tym, że właściwie przechodzisz teraz lub zmieniasz rolę: z FCV, gdzie kierowałeś zespołem kierowników projektów, na stanowisko dyrektora ds. rozwoju w EA Games. Czy wiesz już, co to oznacza?

Maik Stettner:

Wkrótce się dowiem. Nadal skupiam się na zarządzaniu projektami. Oczywiście przechodzę ze środowiska agencji do branży gier w Electronic Arts, ale w swojej karierze pracowałem już wcześniej w różnych branżach, więc gry nie są dla mnie całkowitą nowością. Cieszę się, że znów będę mógł się w nie zagłębić. Z perspektywy zarządzania projektami jest to dość złożone. To bardzo wymagające i dynamiczne środowisko, więc prawdopodobnie również tam wykorzystam całą tę koncepcję kontroli projektu.

Ben Aston:

Świetnie. A kiedy myślisz o przejściu do nowej roli i poznawaniu różnych narzędzi oraz sposobów pracy, czy jest coś, co ostatnio odkryłeś lub czego ostatnio używałeś i pomyślałeś: „Tak, zdecydowanie chcę zabrać to ze sobą do nowej roli”? Jakieś nowe narzędzia lub podejścia?

Maik Stettner:

Mam wrażenie, że na każdym stanowisku, na którym pracowałem, zawsze uczyłem się nowych aspektów i perspektyw dotyczących rozwiązywania problemów. Zwłaszcza gdy pracujesz przy oprogramowaniu lub zarządzaniu projektami cyfrowymi, napotykasz podobne problemy, ale mogą istnieć alternatywne sposoby ich rozwiązywania. Można to robić za pomocą narzędzi do śledzenia problemów, które z czasem stają się coraz lepsze, albo narzędzi generujących analizy potrzebne do podejmowania doraźnych decyzji. Nie sądzę, żebym potrafił wskazać jedno konkretne narzędzie, poza zasadniczo tymi najbardziej oczywistymi. Z mojej perspektywy interesujące jest to, że wiele problemów — niezależnie od tego, czy tworzysz aplikację, oprogramowanie komputerowe, stronę internetową, grę czy cokolwiek innego — jest do siebie bardzo podobnych. Podejście do ich rozwiązywania również jest porównywalne.

Ben Aston:

Tak, jedną z interesujących rzeczy, które zauważyłem, odkąd zacząłem pracować jako kontraktor, jest to, że nawet gdy wydaje Ci się, że wiesz, jak należy coś robić — niezależnie od tego, czy chodzi o zasoby, gdzie możesz użyć narzędzia takiego jak Resource Guru, czy o inne dostępne narzędzia — jedno z nich, Harvest, ma narzędzie o nazwie Forecast. Wydaje Ci się, że wiesz, jak sterować statkiem i jak wszystko powinno działać, a potem próbujesz użyć nowego narzędzia albo zacząć korzystać z niego w taki sposób, w jaki używa go inna agencja, i odkrywasz, że to zupełnie inna bajka. To samo narzędzie można wykorzystywać na tak wiele sposobów, że czasami staje się to naprawdę trudne.

Myślę jednak, że to, o czym mówisz w kontekście danych i analiz, jest niezwykle ważne. Prowadzi to do artykułu, który napisałeś na temat kontroli projektu. Kiedy kierujemy zespołem kierowników projektów lub z nimi współpracujemy, chcemy mieć pewność, że nie polegamy cały czas wyłącznie na intuicji ani na tym, czy coś wydaje się być na właściwym torze lub czy projekt wydaje się przebiegać prawidłowo. Dane mają kluczowe znaczenie, prawda?

Maik Stettner:

Zdecydowanie. Zwłaszcza w moich rolach menedżera kierowników projektów nie zawsze mam pełny dostęp do szczegółów, które zna kierownik pracujący nad projektem. Dlatego w dużej mierze polegam na analizowaniu punktów danych i sprawdzaniu, jak wygląda realizacja budżetu, jaki jest wskaźnik wykorzystania środków i tak dalej. Zwykle pozwala mi to podejmować decyzje wspólnie na przykład z kierownikami projektów lub zespołem pracującym nad danym projektem.

Ben Aston:

Czyli to właśnie są nasze kontrole projektu, prawda? Kiedy myślimy o zarządzaniu programem lub zespołem kierowników projektów, patrzymy na te dane. Są to artefakty tworzone przez kierowników projektów w naszym zespole. Opowiedz nam o kontrolach projektu. Jak byś je zdefiniował lub rozumiał? To rzeczy, których używamy do kontrolowania projektów, ale czym właściwie są? Czym mogą być?

Maik Stettner:

To trochę onieśmielające określenie. Dla mnie kontrola projektu oznacza zasadniczo wszystkie narzędzia potrzebne do uzyskania właściwych informacji, aby móc podejmować świadome decyzje. Chodzi o wszelkie dane, które można zebrać, aby podejmować decyzje dotyczące kosztów, czasu, zakresu i tak dalej. Oczywiście łączy się to bezpośrednio z kontaktami z klientem i wszystkimi dynamicznymi decyzjami, które trzeba podejmować w projekcie. Czy zespół jest wystarczająco duży? Czy potrzebuję kogoś jeszcze? Czy jesteśmy na czas? Czy mieścimy się w budżecie? To po prostu ogólne ramy zarządzania projektami i podejmowania świadomych decyzji.

Ben Aston:

Jakie dokumenty uważasz za najbardziej przydatne? Możemy tworzyć całą gamę różnych dokumentów. Jeśli więc ograniczymy to do absolutnych podstaw, co Twoim zdaniem jest najbardziej użyteczne? Co jest najbardziej przydatne, gdy sam zarządzasz projektem, a może z perspektywy menedżera programu lub dyrektora ds. realizacji zarządzającego zespołami kierowników projektów?

Maik Stettner:

Najbardziej standardową rzeczą, którą polecam wszystkim, jest przygotowywanie rzetelnego raportu statusowego. To raport dotyczący projektu, zawierający wszystkie istotne dane związane z jego realizacją: całkowite koszty projektu, pozostały budżet, wskaźnik wykorzystania środków, osiągnięcia z ostatnich miesięcy oraz najważniejsze działania, ryzyka, blokady i decyzje. Zwykle w projektach, nad którymi pracowałem wraz z zespołami, tworzyliśmy raporty statusowe co tydzień. Upewnialiśmy się także, że klient zawsze ma do nich dostęp. Dzięki temu mógł podejmować decyzje na podstawie przejrzystego obrazu sytuacji projektu. To bardzo podstawowe i proste narzędzie, które pomaga kierownikowi projektu również w samokontroli.

Na przykład na początku tygodnia można utworzyć raport statusowy, sprawdzić, jak wyglądają dane, jaki jest stan budżetu i gdzie jesteśmy w harmonogramie, a następnie zebrać to na poziomie ogólnym. Można omówić raport z klientem i zaplanować cykliczne spotkania, które często nie muszą trwać dłużej niż pół godziny. Służą one jako regularne punkty kontrolne i pomagają budować relację z klientem. Nie muszą odbywać się zdalnie — mogą również odbywać się osobiście. Właściwie zawsze dobrze jest spotykać się osobiście, aby budować relację z klientem. W ten sposób tworzy się poziom zaufania i przejrzystości, dzięki któremu podczas regularnych spotkań omawiane są zarówno możliwości, jak i problemy czy blokady.

Ben Aston:

Tworzysz więc dokumentację, a następnie organizujesz regularne spotkania kontrolne z klientem. Podczas tych spotkań przygotowujecie raporty statusowe. Co jeszcze udostępniasz? Czym innym jest wewnętrzna próba kontrolowania projektów, a czym innym dzielenie się tymi danymi z klientem. Poza raportami statusowymi, jakie są dla Ciebie podstawowe elementy zarządzania i kontroli projektu z klientem?

Maik Stettner:

Jednym z podstawowych narzędzi utrzymywania ogólnej kontroli nad projektem może być wniosek o zmianę, a właściwie proces obsługi wniosków o zmianę wraz z formularzami. Za każdym razem, gdy zdefiniowany zakres ulega zmianie, trzeba na przykład poświęcić dodatkowy wysiłek lub zespół projektowy musi zmienić kierunek, aby spełnić oczekiwania dotyczące czasu, należy to udokumentować. W projektach wniosek o zmianę często jest zakazanym określeniem i obawiasz się go użyć, bo boisz się, że klient się zdenerwuje. To jednak całkowicie normalna rzecz.

Wnioski o zmianę nie muszą koniecznie mieć żadnego wpływu — mogą służyć wyłącznie dokumentowaniu sytuacji. Projekt może nadal mieścić się w budżecie i nie musi to mieć wpływu na harmonogram. Mimo wszystko zdecydowanie warto to udokumentować i przyzwyczaić klienta do tego, że istnieje proces obsługi zmian. Jeśli w pewnym momencie projektu zostanie podjęta decyzja mająca wpływ na budżet, dobrze jest dokładnie ją przeanalizować, udokumentować i uzyskać akceptację wszystkich stron dla takiego wniosku o zmianę.

Ben Aston:

Kolejnym dokumentem, o którym mówisz — kolejną kontrolą projektu — jest rejestr RAID. To również ważny element kontroli projektu. Gdybyś jednak miał wybrać tylko jeden dokument do kontrolowania projektów, czego byś użył?

Maik Stettner:

Najważniejszy jest dobry, solidny raport statusowy. Rejestr RAID wchodzi bardziej w szczegóły i w zależności od złożoności projektu może nie być potrzebny aż w takim stopniu. Raport statusowy powinien jednak obejmować niektóre z tych elementów. Jeśli masz ryzyka, blokady lub inne istotne kwestie, upewnij się, że raport statusowy zawiera na nie miejsce, aby wszyscy mieli je na uwadze. Regularne spotkania z klientem, udostępnianie mu kluczowych wskaźników efektywności i danych, a następnie przeprowadzenie go przez bieżący proces i postępy — to dla mnie najważniejszy wskaźnik.

Ben Aston:

To chyba kwestia równowagi. Ile kontroli faktycznie sobie zapewniamy i ile możemy stworzyć dzięki tej dokumentacji? W pewnym sensie wracamy do debaty na temat zwinności i tego, jak niektórzy mogą ją postrzegać. Nie chcemy ugrzęznąć w dokumentacji wymagań ani kontroli, bo mogłoby to ograniczyć projekt. Jak znaleźć równowagę między spędzaniem całego czasu na monitorowaniu budżetu, aktualizowaniu co tydzień raportu statusowego i organizowaniu spotkań? Tworzysz sobie w ten sposób mnóstwo pracy. Jak wyważyć, ile to za dużo, a ile wystarczy, aby utrzymać kontrolę nad projektem i informować klienta na bieżąco?

Maik Stettner:

Z mojej perspektywy, gdy zaczynam nowy projekt, podchodzę do niego dość egoistycznie — w tym sensie, że zaczynam od aktualizacji statusu projektu, jakkolwiek ją nazwiemy, która jest łatwa do przygotowania. Prawdopodobnie mogę ją wygenerować za pomocą istniejącego oprogramowania, na przykład oprogramowania do planowania zasobów takiego jak Resource Guru, oprogramowania do ewidencji czasu pracy lub dowolnego narzędzia używanego przez firmę. Pozwala mi to zebrać podstawowe dane. W zależności od sytuacji może to już wystarczyć na początek. Niektórzy klienci mogą potrzebować więcej i oczekiwać większej szczegółowości. Jednak dla kierownika projektu, który chce mieć obraz wewnętrznych danych i przedstawić coś klientowi, jest to bardzo dobry punkt wyjścia. Zebranie tego w cyklicznym procesie naprawdę nie zajmuje wiele czasu.

Ostatecznie nie chcesz tworzyć dla siebie zbyt dużo pracy, bo wtedy istnieje ryzyko, że po prostu przestaniesz to robić. Gdy zrobi się intensywnie lub projekt będzie wymagał całej Twojej uwagi, raportowanie w tle może zejść na dalszy plan.

Ben Aston:

To bardzo trafna uwaga na temat robienia tylko tyle, ile potrzeba do kontrolowania projektu. Prawdopodobnie jeszcze ważniejsza jest częstotliwość, z jaką to robimy. Można stworzyć ogromny raport statusowy i świetne mechanizmy kontroli projektu na samym początku projektu, ale jeśli przygotowanie danych i wypełnienie wszystkich pól zajmuje wiele godzin, to wszystko obraca się przeciwko Tobie. Raportowanie trwa zbyt długo, przestajesz je tworzyć i tracisz kontrolę nad projektami.

Maik Stettner:

Dokładnie. Trzeba też pamiętać, że działa to w obie strony. Z jednej strony Ty, jako kierownik projektu, musisz wiedzieć, co się dzieje, aby podejmować świadome decyzje. Klient chce wiedzieć, co się dzieje, ale wewnętrzny zespół również zasługuje na informacje. Jedną z decyzji, które musi podjąć kierownik projektu, jest sposób przekazywania tych informacji. Nie sądzę, żebym kiedykolwiek przeprowadzał swój zespół przez suchy raport statusowy. Zawsze znajdowałem inne sposoby na przedstawianie zespołowi ograniczeń budżetowych, terminów i tym podobnych kwestii. Ważne jest jednak, aby mieć wystarczającą wiedzę i dane, które pozwolą informować wszystkich, tak aby wszyscy pracowali nad tym samym projektem.

Ben Aston:

To świetna uwaga. Nie chodzi tylko o naszych klientów, ale również o zespoły. Dzięki temu zespoły rozumieją ograniczenia projektu. Jeśli projekt pochłania zbyt wiele zasobów i musimy jako zespół znaleźć bardziej efektywny sposób działania, posiadanie tych danych jest korzystne nie tylko dla klienta, ale również dla zespołu. Możemy powiedzieć: „Słuchajcie, musimy trochę zmienić kierunek. Być może nie skończymy wszystkiego w takim zakresie, na jaki liczyliśmy. Zbierzmy się więc i dostosujmy”.

Dane, o których mówisz, nie są po to, żeby kierownik projektu utrudniał wszystkim życie. Chodzi o to, aby powiedzieć: „Spójrzcie, oto raport statusowy. Pokazuje, że wykorzystujemy zasoby zbyt intensywnie. Ponownie poświęciliśmy zbyt dużo czasu na UX. Ponownie poświęciliśmy zbyt dużo czasu na projektowanie. Jeśli tego nie zakończymy, nie będziemy mieć wystarczającego budżetu, aby właściwie przeprowadzić zapewnienie jakości”. To naprawdę solidne podejście.

W swoim artykule omówiłeś proces inicjowania kontroli projektu, a następnie sposób wykorzystywania ich do kontrolowania projektów. Mówiłeś o ocenianiu, planowaniu, reagowaniu i łączeniu. Czy możesz przeprowadzić nas przez ten proces i wyjaśnić, jak go wdrażasz?

Maik Stettner:

Oczywiście. Jako kierownik projektu zawsze musisz wiedzieć, na jakim etapie znajdują się poszczególne kwestie, aby podejmować świadome decyzje. Na tym opiera się tych kilka kroków. Zasadniczo zaczynasz od oceny. Musisz wiedzieć, na jakim etapie jest projekt i gdzie znajduje się w planie projektu. Czy jesteś na właściwym torze, aby osiągnąć oczekiwany rezultat? Czy zrealizujesz cel? Nie chodzi tylko o perspektywę kluczowych wskaźników efektywności. Jako kierownik projektu musisz zajrzeć pod maskę, zadawać pytania i rozumieć, co robi zespół. Musisz stać się ekspertem na wysokim poziomie w zakresie pracy różnych osób, z którymi współpracujesz: UX, projektowania, programowania i zapewniania jakości. Dzięki temu możesz ocenić, czy w niektórych obszarach projektu można pójść na skróty. Tego dowiesz się tylko wtedy, gdy naprawdę zagłębisz się w temat, zaczniesz rozmawiać z ludźmi i zrozumiesz, co trzeba zrobić bardziej szczegółowo i na bardziej szczegółowym poziomie. Następnie podejmujesz decyzje na tej podstawie.

To prowadzi do drugiego kroku, czyli planowania. Jak wiemy, często musimy ponownie zebrać informacje i pojawiają się kwestie wymagające zmian: zmieniają się terminy, zakres i tak dalej. Trzeba to zaplanować oraz zaplanować kolejne kroki z zespołem na podstawie posiadanej wiedzy. Jako kierownik projektu otrzymujesz informacje z obu stron: masz perspektywę klienta oraz wewnętrzną wiedzę zespołu. Na tej podstawie tworzysz główny plan doprowadzenia projektu do końca.

Na tej podstawie kolejnym krokiem jest reagowanie. Wdrażasz zmiany zgodnie z planem. Obejmuje to poinformowanie klienta, zapewnienie zmiany procesu, jeśli jest potrzebna, aktualizację dokumentacji i systemów śledzenia problemów, takich jak Jira, a także aktualizację harmonogramów i dopilnowanie wszystkich korekt.

Ostatnim krokiem, który wyodrębniłem, jest łączenie. Jako kierownik projektu jesteś spoiwem, które łączy zespół. Najlepiej, aby każdy wiedział na poziomie ogólnym to, co wiesz Ty. Dlatego przekazuj swoją wiedzę zespołowi, aby każdy miał pełny obraz sytuacji. Klient musi być na bieżąco, zespół musi być na bieżąco. Następnie zarządzasz tymi zmianami, aby móc je rzeczywiście zrealizować.

Ben Aston:

Słyszę tu właściwie dwa różne elementy. Z perspektywy zarządzania projektami dane są naprawdę ważne. Te punkty danych pozwalają nam ocenić, na jakim etapie znajdują się projekty. Bardzo szybko i na wysokim poziomie dają nam możliwość kontrolowania projektów: możemy ustalić, jak priorytetyzować zasoby i projekty, aby je realizować. Dane dają nam ten ogólny obraz.

Podoba mi się jednak to, co mówisz o innych aspektach kontroli projektu. Nie chodzi tylko o dane ani o samo zbieranie informacji. Chodzi o rozpoczęcie rozmowy i włączenie zespołów do dyskusji oraz debaty na temat kontrolowania projektu, omawiania najlepszego sposobu realizacji zadań i bardziej zwinnego podejścia do realizacji projektów, w którym dostosowujemy się w trakcie pracy i kierujemy intuicją. Zamiast wszystko z góry ustalać, przygotowywać raporty statusowe, stwierdzać przekroczenie budżetu i na tym poprzestawać, warto uczynić z tego rozmowę.

Dla osób, które nigdy nie myślały o przygotowywaniu właściwych raportów statusowych dla klientów lub projektów: przedstawiłeś ten proces. Jaki jest jednak pierwszy krok do odzyskania kontroli nad projektami? Co powinni zrobić ludzie, nawet jeśli nie doprowadzą sprawy do utworzenia raportu statusowego ani jednego z tych mechanizmów kontroli projektu? O czym kierownicy projektów powinni pomyśleć w pierwszej kolejności, gdy zastanawiają się, jak uporządkować realizację i kontrolować projekty? Czy polecasz jakiś dobry punkt wyjścia?

Maik Stettner:

Dla mnie najważniejsze jest uzyskanie dobrego obrazu tego, co trzeba zrobić, aby doprowadzić projekt do realizacji. Zarówno z perspektywy klienta, jak i wewnętrznej. Część zadań może być bardzo prostą logistyką. Jakie są oczekiwania klienta? Czy istnieją jakieś czynniki napędzające projekt? Czy jest wyznaczona data zakończenia, ponieważ trwa kampania albo odbywa się prezentacja dla kadry kierowniczej, a osoba kontaktowa musi mieć gotowy materiał do tego czasu? Następnie należy spojrzeć na kwestie wewnętrzne: uzyskać jasny obraz potrzebnego zespołu i sposobu jego pracy. Przynajmniej na poziomie ogólnym trzeba zrozumieć, jak wszystkie te elementy się połączą. Dzięki doświadczeniu kierownik projektu może ocenić na wysokim poziomie, jaki będzie plan i jakie przybliżone punkty kontrolne trzeba uwzględnić w procesie.

Ostatecznie raport statusowy pomaga przede wszystkim Tobie samemu utrzymać właściwy kierunek i nie zapomnieć o tych punktach kontrolnych. Myślę, że to kluczowa kwestia. Potrzebujesz połączenia kluczowych wskaźników efektywności, umiejętności miękkich i ogólnego zachowania trzeźwego obrazu projektu, aby mieć pewność, że dokładnie rozumiesz, gdzie jesteś, nawet gdy projekt staje się bardziej złożony. Następnie musisz podejmować świadome decyzje i znaleźć narzędzia, które Ci w tym pomogą.

Ben Aston:

Podoba mi się to, o czym mówisz. Dane nie mają znaczenia, jeśli nie możemy ich z czymś porównać. Możemy przygotowywać raporty statusowe, ale jeśli nie mamy planu projektu, z którym można je porównać, dane są właściwie pozbawione znaczenia. Upewnij się więc, że masz właściwy plan, a potem mierz wyniki względem niego. Rozmawiając z kierownikami projektów z innych agencji, zauważyłem także, że często brakuje ewidencji czasu pracy i dokładnego śledzenia czasu poświęconego na różne zadania w ramach projektu. Chociaż śledzenie czasu jest jedną z najbardziej uciążliwych rzeczy, o które można poprosić, warto je wdrożyć, jeśli dotąd go nie było. Upewnij się, że masz plan projektu, a następnie śledź czas względem tego planu. Daje Ci to pewną kontrolę nad projektem. To naprawdę solidna rada. Dziękuję, Maik. Wspaniale było gościć Cię w naszym programie.

Maik Stettner:

Dzięki, Ben.

Ben Aston:

Jako jeden z naszych ekspertów DPM, Maik pojawi się także w naszym nadchodzącym kursie, który rozpoczyna się we wrześniu. Nazywa się on Mistrzostwo w zarządzaniu projektami cyfrowymi. To siedmiotygodniowy intensywny kurs zarządzania projektami cyfrowymi. Nauczysz się skutecznie zarządzać złożonymi projektami cyfrowymi. Kurs obejmuje lekcje wideo, zadania, dyskusje grupowe oraz możliwość udziału w sesjach coachingowych. Odwiedź stronę thedpmschool.com i zapisz się. Zostało jeszcze kilka miejsc, ale kurs rozpoczyna się 10 września. Jeśli chcesz włączyć się do rozmowy na temat kontroli projektu — jak możemy lepiej kontrolować projekty i jakiej dokumentacji używamy — przejdź do sekcji zasobów na stronie thedigitalprojectmanager.com i dołącz do naszego zespołu na Slacku, gdzie toczy się wiele interesujących rozmów. Skomentuj wpis, porozmawiaj o tym na Slacku i zastanówmy się wspólnie, jak możemy lepiej kontrolować nasze projekty.

Do usłyszenia następnym razem. Dziękuję za uwagę.