Używaj opisów zakresu projektu, aby ratować swoją skórę (z Robyn Birkedal)

Przeczytaj transkrypcję:

Testujemy transkrypcję naszych podcastów za pomocą programu komputerowego. Wybaczcie wszelkie literówki, ponieważ bot nie jest poprawny przez 100% czasu.

Ben Aston:

Trzymasz telefon w zimnym uścisku, cały się pocisz. Klient jest wściekły. Dzwoni i grozi, że zakończy projekt oraz nie zapłaci za wykonaną pracę. A do tej pory wszystko szło tak dobrze. Klient był całkowicie spokojny i Ty również. Chciał, aby jego strona została przeprojektowana. Brzmiało prosto. Nie zawracałeś sobie głowy zapisywaniem czegokolwiek, ponieważ cóż, wydawało się, że wszyscy rozumieją sytuację. Wszyscy byli spokojni, a teraz już nie są. Okazuje się, że klient sądził, iż otrzyma również rebranding, oprócz tej przeprojektowanej strony internetowej. Teraz ściska Cię w żołądku, bo wiesz, że wszystko zepsułeś. Niczego nie zapisano, a jego słowo stoi przeciwko Twojemu. Już samo mówienie o tym mnie stresuje. Jeśli więc chcesz ograniczyć stres, słuchaj dalej tego podcastu, aby dowiedzieć się, dlaczego opisy zakresu są tak ważne, jak je pisać i wykorzystywać w projekcie.

Dziękuję za wysłuchanie. Nazywam się Ben Aston i jestem założycielem The Digital Project Manager. Witajcie w podcaście DPM. Naszą misją jest pomaganie kierownikom projektów w osiąganiu sukcesów oraz osobom zarządzającym projektami w lepszym dostarczaniu rezultatów. Pomagamy wynieść zarządzanie projektami na wyższy poziom. Odwiedź thedigitalprojectmanager.com, aby dowiedzieć się więcej o szkoleniach i zasobach oferowanych w ramach członkostwa. Ten podcast powstał dzięki firmie Clarizen, liderowi w dziedzinie oprogramowania do zarządzania projektami i portfelem projektów dla przedsiębiorstw. Odwiedź Clarizen.com, aby dowiedzieć się więcej.

Dziś dołącza do mnie Robyn. Robyn jest jedną z naszych ekspertek DPM. Dogodnie mieszka niedaleko miejsca, w którym obecnie przebywam. Lubi emotikony, tworzenie list i szczenięta. Jest szefową kuchni, która została kierowniczką projektów, i ma ponad 10 lat doświadczenia w zarządzaniu projektami w agencjach oraz startupach. Wkrótce będzie też bardziej dostępna, aby podejmować pracę kontraktową. Jeśli więc szukasz kierownika projektu na kontrakt, znajdź ją na LinkedIn. Robyn, dziękuję, że do nas dziś dołączasz.

Robyn Birkedal:

Cześć, Ben. Zawsze miło z Tobą rozmawiać.

Ben Aston:

Chcę zacząć od powrotu do tworzenia list i szczeniąt. Czy masz dziś przygotowaną listę?

Robyn Birkedal:

Tak. Właściwie jestem pod tym względem niezłą dziwaczką. Mam jedną listę najważniejszych celów na dziś, jedną listę w terminarzu, a do tego Kalendarz Google. Najwyraźniej w każdej chwili potrzebuję trzech różnych list. A tego, czego nie widać za moimi plecami, to moja ściana z karteczek samoprzylepnych.

Ben Aston:

To archiwum wszystkich list.

Robyn Birkedal:

Rzeczy podzielone na różne kategorie, które próbuję osiągnąć osobiście i zawodowo, a także różne pomysły na treści dla Ciebie.

Ben Aston:

Masz przy sobie również szczeniaka?

Robyn Birkedal:

Mam ośmioletniego psa. Oczywiście kocham psy znacznie bardziej niż koty i wszyscy mogą się ze mną nie zgadzać. Ostatnio emotikony wydają mi się mniej entuzjastyczne. Ale chyba właśnie tak wyglądała ta emotikona.

Ben Aston:

W zeszłym roku też taki byłem.

Robyn Birkedal:

Nie wiem.

Ben Aston:

Skoro listy są dla Ciebie tak ważne, to najwyraźniej Cię inspirują. Ciekawi mnie jednak, skąd czerpiesz inspirację. Co czytasz i czego obecnie słuchasz, aby się inspirować?

Robyn Birkedal:

To świetne pytanie. Mogłabym teraz mówić o tym przez około 30 minut. Oczywiście The Digital Project Manager jest stałym źródłem inspiracji. Zrobiłam sobie krótką przerwę od tak intensywnego angażowania się w społeczność na Slacku i teraz, kiedy wróciłam, bardzo brakowało mi wielu znajomych. To była ogromna radość. Inspirują mnie również moi lokalni znajomi i moja społeczność. Chcę jednak wspomnieć o jednej z naprawdę świetnych grup społecznościowych w Portland, w które przez lata się angażowałam. Nazywa się PDXWIT, czyli Portland Women in Technology. Bardzo cenię tę społeczność, która dobrze organizuje wydarzenia związane z rozwijaniem umiejętności, mentoringiem i dostępem do pracy. Nauczyli mnie również bardzo dużo o różnorodności i inkluzji. Gorąco zachęcam Was do stworzenia czegoś podobnego albo odwiedzenia strony pdxwit.org.

Ben Aston:

To ciekawe. Nad czym próbujesz jeszcze pracować? Wszyscy mamy obecnie trochę więcej czasu. Mam wrażenie, że zasypują mnie kursy mistrzowskie, ćwiczenia i najróżniejsze inne rzeczy. Co Cię inspiruje? Co chciałabyś zrobić? Pracujesz nad nowym hobby, uczysz się języka programowania albo zagłębiasz się w jakiś temat?

Robyn Birkedal:

Ostatnio wróciłam do Drupala, z którym nie pracowałam od około siedmiu lat, więc nadrabiam zaległości. Poza tym myślę o zdobyciu różnych certyfikatów. To niemal sekret, którym dzielę się z Tobą na głos. Rozważam zdobycie PMP albo certyfikatu z podejścia SAFe. Chcę sprawdzić, czy jest to coś, co chciałabym robić w przyszłości, i lepiej poznać te metodyki, zamiast pozostawać przy tym, co już znam.

Ben Aston:

Powodzenia. Czy odkryłaś ostatnio coś jeszcze, co sprawia, że Twoje życie jest lepsze? Co wywołuje uśmiech albo daje Ci chwilę radości?

Robyn Birkedal:

To również trochę krępujące. Nie wiem, dlaczego jestem dziś tak zdenerwowana, ale bardzo podoba mi się praca z domu. W tle włączam jedną stację w YouTube TV, którą subskrybuję. To kanał w całości poświęcony surfingowi. Mieszkam w Portland, więc dotarcie na plażę zajmuje mi półtorej godziny. Nie surfuję i nic nie wiem o surfingu, ale bardzo lubię oglądać zawody surfingowe w tle. Teraz interesuję się wieloma osobami, między innymi Andym Ironsem i Kellym Slaterem. Nauczyłam się z tego naprawdę dużo, co jest chyba najdziwniejszą rzeczą, która ostatnio uczyniła moje życie lepszym.

Ben Aston:

Kto jest Twoim ulubionym surferem?

Robyn Birkedal:

Zdecydowanie Kelly Slater.

Ben Aston:

Wiesz, Kelly był tutaj. To dobry początek, jeśli chodzi o ratowanie sytuacji. Moją ciekawostką jest to, że surfowałem z Kellym Slaterem na Hawajach.

Robyn Birkedal:

Nie możesz po prostu tak powiedzieć. To nie działa.

Ben Aston:

Wychodziliśmy z wody, a on wchodził do niej ze swoją dziewczyną. Minęliśmy się i powiedziałem: „Cześć, Kelly”. Więc surfowaliśmy z nim. Prawda?

Robyn Birkedal:

Tak, byliście w wodzie w tym samym czasie.

Ben Aston:

No właśnie.

Robyn Birkedal:

Brzmi jednak tak, jakbyś był pod wielkimi falami, skoro byłeś tam z Kellym.

Ben Aston:

Tak. Dlatego właśnie to moja ciekawostka. Przejdźmy jednak do poważnego tematu i od plaży wróćmy do opisów zakresu. Zacznijmy od tego, dlaczego są ważne. Na początku próbowałem zarysować, dlaczego powinniśmy się nimi przejmować. Projekty się psują, dochodzi do nieporozumień, a opisy zakresu mogą uratować nam skórę. Czy masz jakieś historie z pracy nad projektami bez opisów zakresu? Dlaczego tak Cię one fascynują?

Robyn Birkedal:

Zdecydowanie. Już podczas słuchania Twojego wstępu poczułam, jak wraca do mnie trauma, która prawdopodobnie zawsze będzie wracać. Opisy zakresu są niezwykle ważne, ponieważ pozwalają upewnić się, że zespół i klient jasno rozumieją ogólne wymagania. Ostatecznie definiują również sposób, w jaki projekt może ponieść porażkę. Chcemy uniknąć konfliktu z klientem i zespołem wewnętrznym, a także uzgodnić wspólne rozumienie projektu i zapobiec sporom prawnym.

Ben Aston:

Próbujemy więc maksymalnie doprecyzować i ujednolicić rozumienie projektu. Opisy zakresu świetnie nadają się do zapisania tego wspólnego rozumienia. Czasami myślimy: „Wszyscy jesteśmy zgodni, jesteśmy przyjaciółmi”. W rzeczywistości bywa gorzej, gdy jesteśmy przyjaciółmi, bo każdy zakłada, że pozostali rozumieją się nawzajem. Słowa takie jak „aktualizacja” czy „odświeżenie” mogą być bardzo niejednoznaczne. Opisy zakresu zmniejszają tę niejednoznaczność i sprawiają, że szare obszary stają się znacznie bardziej jednoznaczne.

Robyn Birkedal:

Zdecydowanie. Nawet w ciągu dziesięciu lat pracy w tej branży terminologia zmienia się praktycznie co kwartał. Zanim porozmawiamy o tym, czym są opisy zakresu i jak je tworzyć, chcę podkreślić, że ich pisanie jest w tej roli bardzo niedoceniane. To najbardziej suche zadanie w całej pracy i zwykle najtrudniejszy element rozpoczęcia projektu. Nikt nie chce brać za nie odpowiedzialności. A ja osobiście je uwielbiam, ponieważ poświęcenie czasu na początku projektu zapewnia mu znacznie sprawniejszą realizację w przyszłości.

Ben Aston:

Porozmawiajmy więc o podstawach. Czym jest opis zakresu projektu?

Robyn Birkedal:

Możemy używać wielu różnych terminów, na przykład „odświeżenie” i „przeprojektowanie”. Opis zakresu to po prostu sposób opisania pracy, którą zobowiązujesz się dostarczyć. Na najbardziej podstawowym poziomie opisuje ograniczenia projektu. Mówimy o tym, co zostanie dostarczone, czego nie dostarczymy, jakie przyjmujemy założenia oraz jakie są dodatkowe wyjaśnienia.

Ben Aston:

Opis zakresu służy do opisania i zapisania pracy. Mówimy: „To zrobimy, a tego nie zrobimy”. Jeśli nie możemy dokładnie określić, co wykonamy, możemy przynajmniej opisać proces, który zastosujemy. Czasami ludzie pytają, czy potrzebują zakresu prac albo jak wygląda zakres prac w podejściu zwinnym. Nadal musimy określić, co robimy, a czego nie robimy. Zamiast definiować rezultaty, możemy określić cel, do którego zmierzamy, oraz proces, który pomoże nam go osiągnąć.

Robyn Birkedal:

Istnieją podstawowe zasady, których warto przestrzegać, ale nie ma jednego szablonu dla każdego kierownika projektu cyfrowego. Nie można po prostu skopiować i wkleić jednego dokumentu. Każda firma, projekt i program są inne. Chodzi o zachowanie spójności i ochronę siebie, zespołu oraz inicjatywy biznesowej.

Ben Aston:

Czy masz historie pokazujące, co się dzieje, gdy zakres nie zostanie zdefiniowany wystarczająco dokładnie?

Robyn Birkedal:

W poprzednich rolach doradzano mi, aby nie umieszczać zbyt wielu szczegółów, ponieważ mogłoby to zwiększyć ryzyko prawne. Jednak największe sukcesy osiągałam wtedy, gdy umieszczałam w opisie możliwie dużo szczegółów. Niezależnie od tego, czy projekt jest realizowany kaskadowo, czy zwinnie, warto zdefiniować wszystko w opisie i sprawdzić to z klientem. Nie zawsze uda się zrobić to idealnie, a klient może inaczej zinterpretować pewne elementy. Chodzi o to, by jak najlepiej przeanalizować sytuację i poświęcić odpowiednio dużo czasu na początku.

Ben Aston:

Pracowaliśmy kiedyś z dużym klientem z branży elektroniki użytkowej, tworząc dla niego niestandardowe animacje. Klient chciał mieć pewność, że kupiliśmy prawa do animacji, więc nabyliśmy licencję na pięć lat. Zakładaliśmy, że będziemy jej potrzebować najwyżej przez rok, ale chcieliśmy mieć możliwość ponownego wykorzystania jej w kolejnym roku. Później klient wrócił i powiedział: „Chwileczkę, prosiłem o zakup praw do tej animacji”. Odpowiedzieliśmy, że tak zrobiliśmy, ale klient chciał praw wieczystych, do wykorzystania w dowolnych mediach i formatach. My kupiliśmy prawa tylko na pięć lat. Stało się to ogromnym problemem, ponieważ studio animacji wiedziało, że może zażądać od nas dowolnej kwoty. Ostatecznie relacja z klientem rozpadła się z powodu jednego niedokładnie zdefiniowanego elementu opisu zakresu: okresu obowiązywania praw do animacji od podmiotu zewnętrznego. Małe nieporozumienie może mieć ogromne konsekwencje.

Traktujmy to poważnie, ponieważ opisy zakresu mogą zatopić nie tylko projekt, ale również całą relację z klientem. Jak wygląda proces ich pisania? Jak decydujesz, co powinno się w nich znaleźć?

Robyn Birkedal:

Zanim odpowiem, trzy kwestie. Po pierwsze, nie jestem prawniczką i nie udzielam formalnych porad prawnych. Mówię wyłącznie o własnych doświadczeniach, głównie z kariery w reklamie. Po drugie, bardzo współczuję Ci w związku z tą sytuacją dotyczącą praw wieczystych. Różnica między jednym rokiem, pięcioma latami a wieczystym okresem obowiązywania jest ogromna. Po trzecie, w różnych środowiskach opisy zakresu mogą przyjmować różne formy. Możemy nazywać je kosztorysem, zakresem prac, umową albo ofertą. Są elementem większego zestawu dokumentów. Nie są jednak tym samym co umowa o zachowaniu poufności, umowa ramowa, umowa z niezależnym wykonawcą czy umowa o gwarantowanym poziomie usług. To tylko jeden z elementów współpracy z klientem.

Ben Aston:

Zdecydowanie.

Robyn Birkedal:

Wracając do pytania: zwykle korzystałam z szablonów dostarczanych przez zespoły wewnętrzne. Zachowuję również poprzednie wersje zakresów prac w osobnym folderze, aby sprawdzać, jak opisywałam projekty związane z marką, projekty cyfrowe, odświeżenia czy przeprojektowania. The Digital Project Manager także jest świetnym źródłem informacji. Napisałeś bardzo dobry artykuł o tworzeniu zakresu prac, który zawiera również szablon.

Ben Aston:

Ważne jest stworzenie własnego banku opisów zakresu, które można ograniczać, ponownie wykorzystywać i dostosowywać. Parametry projektów często się powtarzają: liczba tworzonych koncepcji, liczba rund poprawek, sposób przekazywania informacji zwrotnych, końcowe rezultaty. Jeśli powtarzamy ten sam proces i tworzymy podobne rezultaty, opisy zakresu można łatwo ponownie wykorzystać.

Na stronie thedigitalprojectmanager.com/project-scope-statement znajdziesz wiele opisów zakresu. Niektóre są ogólne i można je dostosować do własnych projektów, zmieniając nazwy. Inne są bardziej szczegółowe. Możemy na przykład określić, kto płaci za licencje na obrazy i filmy, kto odpowiada za ich zakup, ile czasu klient ma na zatwierdzenie pracy, kiedy powinien przekazać skonsolidowane uwagi oraz ile rund zatwierdzania przewidziano.

Porozmawiajmy o dobrych i złych opisach zakresu. Można podejść do tego jako do kontinuum: od luźnego opisu zakresu do bardzo szczegółowego. Co sprawia, że opis zakresu jest dobry albo zły?

Robyn Birkedal:

To duże pytanie. Najważniejsze jest korzystanie z wcześniejszych opisów zakresu oraz proszenie współpracowników i znajomych o przykłady skutecznych dokumentów, aby nie zaczynać za każdym razem od zera. Społeczność DPM również może być pomocna. Mogę jednak podać pięć sposobów na ochronę własnej skóry.

Po pierwsze, określ cel projektu. Lubię nazywać tę część „przeglądem”, ponieważ brzmi bardziej formalnie. To pierwsza sekcja, w której opisujesz pracę, powód istnienia projektu lub programu, przyczynę jego realizacji i oczekiwane rezultaty. Nie trzeba opisywać wszystkiego. Wystarczy krótka i zwięzła deklaracja wartości, która wyjaśnia, dlaczego wykonujemy tę pracę i dlaczego jest ważna.

Ben Aston:

Rozpoczęcie od „dlaczego” jest niezwykle ważne. Jeśli wszystko inne zawiedzie, cel jest naszym zabezpieczeniem. Jeśli możemy wykazać, że dostarczony rezultat realizuje pierwotny zamiar, mamy wspólną podstawę. Klient może nie lubić sposobu wykonania, ale jeśli rezultat zwiększa liczbę subskrybentów, osiągamy wspólnie ustalony cel.

Robyn Birkedal:

Druga wskazówka to opisanie procesu zatwierdzania. Warto określić, kiedy klient ma przekazać uwagi, kto je przekazuje i w jaki sposób powinny być dostarczone. Najlepiej omówić ten proces z klientem ustnie, a następnie zapisać ustalenia w dokumencie.

Trzecia wskazówka: dokładnie określ, co zostanie dostarczone. Zwykle jest to największa część opisu zakresu. W projekcie kaskadowym może być bardzo szczegółowa i rozbudowana, natomiast w podejściu zwinnym może bardziej koncentrować się na procesie. Powinna określać, co klient otrzyma, kiedy to otrzyma i w jaki sposób.

Ben Aston:

Jeśli możemy coś zdefiniować, zdefiniujmy to. Jeśli nie wiemy dokładnie, co dostarczymy, zastosujmy podejście polegające na pozostawieniu bezpiecznego marginesu. Określmy minimum, które na pewno dostarczymy. Jeśli sądzimy, że stworzymy cztery koncepcje, zobowiążmy się do dwóch. Jeśli przewidujemy maksymalnie pięć komponentów, uzgodnijmy pięć, nawet jeśli ostatecznie powstanie sześć lub siedem. W ten sposób nie składamy nadmiernych obietnic.

Robyn Birkedal:

To rzeczywiście może pomóc również w zarządzaniu pracą zespołu. Projektant, deweloper albo strateg może mieć własne wyobrażenia o zakresie pracy. Wczesne rozmowy pomagają ograniczyć wewnętrzne rozbieżności, a nie tylko nieporozumienia z klientem.

Czwarta wskazówka to określenie, co jest zawarte w zakresie, a co nie. Zwykle umieszczam tę informację w osobnej sekcji. Po wskazaniu rezultatów tworzę wyczerpującą listę granic projektu. Warto uwzględnić zależności i założenia, na przykład sposób przekazywania informacji zwrotnych, dodatkowe wdrożenia albo zmianę terminu wdrożenia. Jeśli klient przesunie wdrożenie, może być konieczne wystawienie zlecenia zmiany, ponieważ zespół będzie potrzebował dodatkowego czasu i przeorganizowania zasobów.

Lubię również sekcję „Wyłączenia” albo „Poza zakresem”. Należy w niej wymienić wszystko, o co klient może poprosić, ale czego nie dostarczamy. Mogą to być dodatkowe materiały szkoleniowe, hosting, opłaty za czcionki, cyfrowe przewodniki po stylu albo prawa do obrazu obowiązujące bezterminowo. Chodzi o jasne określenie, za co nie ponosimy odpowiedzialności.

Ben Aston:

To właśnie w tym miejscu pojawiają się nieporozumienia. Klient może powiedzieć, że chce odświeżyć stronę i przeprowadzić rebranding, ale później okazuje się, że budżet nie obejmuje pełnego rebrandingu. Warto więc zapisać, że rebranding nie jest częścią projektu. Dzięki temu można później wrócić do dokumentu i pokazać, że ten element został wyraźnie wyłączony z zakresu.

Robyn Birkedal:

Nie ma jednego właściwego sposobu. Trzeba zaufać intuicji i zastanowić się, co może pójść źle. Mapowanie potencjalnych problemów oraz ich zwięzłe podsumowanie pomaga ograniczyć ryzyko już na początku projektu.

Piąta i ostatnia wskazówka jest nieco kontrowersyjna: twórz macierz opisów zakresu. W przeszłości spędzałam wiele godzin na przeglądaniu historii wersji dokumentów, plików, Slacka, wiadomości e-mail, plików projektowych, a czasem nawet kodu, aby ustalić, co dokładnie zostało uzgodnione. Teraz wykonuję tę pracę na początku i śledzę rezultaty, aby wszyscy rozumieli, jak realizujemy ustalenia.

Ben Aston:

Dzięki temu zakres prac nie jest dokumentem używanym tylko raz. Umieszczenie rezultatów w macierzy pozwala je śledzić, przypominać klientowi i interesariuszom, że traktujemy dokument poważnie, oraz wykorzystywać go przez cały czas trwania projektu.

Robyn Birkedal:

Nie zawsze udostępniam taką macierz klientowi. Czasami przechowuję ją wyłącznie w strukturze plików projektu. Mogę jednak wykorzystać ją, gdy pojawi się spór, ponieważ wszystkie potrzebne informacje mam wtedy od razu pod ręką.

Ben Aston:

Czy to oznacza, że jeśli zastosujemy te wskazówki, wszystko pójdzie gładko? Jakie są największe wyzwania?

Robyn Birkedal:

Nie chodzi o ślepe przestrzeganie zasad. Trzeba elastycznie podchodzić do każdego projektu. Wcześniej zdarzało mi się traktować szablon jako coś, czego zawsze należy przestrzegać. Z czasem zrozumiałam, że klienci mają różne poziomy gotowości i różne sposoby pracy. Trzeba być elastycznym w podejściu do projektu, ale jednocześnie bardziej stanowczym w kwestii tego, do czego faktycznie się zobowiązujemy.

Ben Aston:

Jednym z największych wyzwań jest określenie, jak szczegółowy powinien być opis zakresu. Gdy zaczynamy projekt i nie wiemy jeszcze dokładnie, co dostarczymy, łatwo obiecać zbyt wiele. Po fazie odkrywania może się okazać, że część projektu jest zbędna albo zbyt droga. Warto więc brać pod uwagę horyzont planowania i dzielić zakres na realistyczne części. Jeśli rozpoczynamy fazę odkrywania, opiszmy najpierw jej zakres, a później zdefiniujmy zakres kolejnej fazy. Największym problemem może być nadmierne wybieganie w przyszłość.

Robyn Birkedal:

Kolejnym wyzwaniem jest uzyskanie akceptacji klienta, który nie zaangażował wszystkich interesariuszy. Może to poważnie zaszkodzić projektowi. Dlatego pomocne jest ustne przejście przez dokument i zorganizowanie sesji uzgodnieniowej.

Ben Aston:

Ważne jest właśnie ustne omówienie dokumentu. Nie chcemy, aby klient podpisał coś, czego nie przeczytał i nie zrozumiał. Opis zakresu nie powinien być przede wszystkim dokumentem prawnym. Ma ułatwiać rozmowę i uzgodnienie oczekiwań. Nie próbujemy klienta oszukać ani wykorzystać jego niewiedzy. Chcemy ustalić wspólne rozumienie, aby po dostarczeniu rezultatów klient był zadowolony z wyniku projektu. Jeśli sprawa trafia do sądu, wszyscy prawdopodobnie tracą pieniądze i klienta. Najważniejsze jest uzgodnienie oczekiwań i wspólne zrozumienie sposobu realizacji pracy.

Robyn Birkedal:

Nie ma nic lepszego niż świadomość, że opis zakresu można skopiować do prawnie wiążącego dokumentu, ponieważ wszystkie strony są ze sobą zgodne.

Ben Aston:

Zadbajmy więc o zgodność. Robyn, bardzo dziękuję za dzisiejsze spotkanie.

Robyn Birkedal:

Dziękuję za zaproszenie.

Ben Aston:

Chciałbym wiedzieć, jakie są Wasze wskazówki i triki dotyczące opisów zakresu i zakresów prac. Gdzie je przechowujecie? Jak je tworzycie? Co działa, a co nie? Opowiedzcie nam w komentarzach o swoich porażkach i zwycięstwach. Jeśli chcecie rozwijać się zawodowo, dołączcie do naszej społeczności DPM Membership. Odwiedźcie thedigitalprojectmanager.com/membership, aby uzyskać dostęp do naszego zespołu na Slacku, grup mastermind, mentoringu, szablonów, warsztatów, konsultacji, sesji pytań i odpowiedzi, e-booków oraz wielu innych materiałów. Jeśli podobał Wam się dzisiejszy odcinek, zasubskrybujcie podcast i zostańcie z nami na thedigitalprojectmanager.com. Do usłyszenia następnym razem. Dziękuję za uwagę.