Zarządzanie 2-tygodniowym projektem (z Jenną Trunzo z Globant)

Przeczytaj transkrypcję:

Testujemy transkrypcję naszych podcastów 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 wykraczamy poza teorię, aby dostarczać ekspertom PM porad dotyczących prowadzenia lepszych projektów cyfrowych. Dziękuję za dostrojenie się. Nazywam się Ben Aston, jestem założycielem The Digital Project Manager. Na cyfrowym Dzikim Zachodzie, który nazywamy domem, nie jest niczym szczególnie zaskakującym, gdy trafia do nas projekt z niewielkim budżetem, dość niejasnym zakresem i napiętym harmonogramem. Ale co zrobić, jeśli ten krótki harmonogram obejmuje zaledwie dwa tygodnie? W dzisiejszym podcaście omówimy, jak skutecznie zaplanować i zrealizować projekt, gdy, szczerze mówiąc, nie ma wystarczająco dużo czasu, aby zrobić to właściwie. Słuchaj dalej, jeśli chcesz dowiedzieć się, z czego możesz zrezygnować i jakie skróty doprowadzą twój projekt do porażki.

Ben Aston:

Dziś dołącza do mnie Jenna Trunzo. Jenna jest certyfikowaną Scrum Masterką, a także certyfikowaną właścicielką produktu i kierowniczką projektu w firmie Globant — przynajmniej tak mi się wydaje, że tak to się wymawia. To firma z Raleigh w Karolinie Północnej. Porozmawiamy trochę o jej drodze do zostania kierowniczką projektu, którą opisuje jako szczęśliwy przypadek. Dowiemy się, czym był ten przypadek. Obecnie wykorzystuje swoje umiejętności, aby wspierać zespoły w tej agencji, która dużo mówi o Agile. O tym również chcę porozmawiać. Cześć, Jenna. Miło gościć cię dzisiaj w programie.

Jenna Trunzo:

Cześć, Ben, bardzo dziękuję za zaproszenie. I dobra robota — wymówiłeś to poprawnie. To Globant.

Ben Aston:

Globant. Czy wiesz, czym jest Globant? To po prostu nazwa kojarząca się z globalnością czy coś w tym rodzaju?

Jenna Trunzo:

Chciałabym wymyślić jakąś ciekawą historię, żeby zabrzmiało to interesująco, ale szczerze mówiąc, nie wiem.

Ben Aston:

Kiedyś pracowałem w agencji o nazwie FCV i ludzie zawsze chcieli wiedzieć, co oznacza FCV.

Jenna Trunzo:

Właśnie.

Ben Aston:

Rzeczywistość była taka, że nie oznaczało niczego. Kiedyś skrót rozwijał się jako False Creek Ventures, ale to nie brzmi… Po pierwsze, nie brzmi dobrze, a po drugie, nie brzmi jak agencja.

Jenna Trunzo:

Czyli po prostu wymyślałeś historie?

Ben Aston:

FCV — tak było. No cóż, niestety kiedy wypowiadasz FCV przez telefon, może to zabrzmieć jak różne rzeczy, w tym jak STD.

Jenna Trunzo:

Racja, a to nie jest przyjemne.

Ben Aston:

Tak, trzeba uważać.

Jenna Trunzo:

Oczywiście.

Ben Aston:

W każdym razie wystarczy o nazwach. Opowiedz nam trochę o tym, czym zajmujesz się w Globant.

Jenna Trunzo:

Jestem kierowniczką projektu w Globant. Zajmujemy się wszystkim — od migracji danych po sztuczną inteligencję. Wszystko opiera się na projektach i naprawdę zależy od sytuacji. Realizowałam zarówno bardzo małe projekty, jak i obecny, który jest dość duży. Zakres projektów jest tutaj bardzo różny. W całej firmie mamy około 8000 osób. Pracuję w Raleigh, gdzie w tym biurze jest około 150 osób.

Ben Aston:

Świetnie. Opowiedz nam najpierw trochę o swojej historii. Opisujesz ją jako szczęśliwy przypadek. Na czym polegał ten przypadek? Byłaś projektantką graficzną, potem kierowniczką marketingu, a następnie kierowniczką projektu. Co się wydarzyło?

Jenna Trunzo:

Jestem pewna, że są osoby, które na początku kariery pracują w branżach kreatywnych. Kiedy ja się tym zajmowałam, wiele pracy zlecano na zewnątrz i nie było zbyt wielu ofert zatrudnienia. Pochodzę z Pittsburgha w Pensylwanii i właśnie tam pracowałam w tej branży. Możliwości było naprawdę niewiele. Kiedy przeprowadziłam się do Karoliny Północnej, podjęłam pracę jako kierowniczka marketingu w zespole zajmującym się nieruchomościami i spędziłam tam większą część dziesięciu lat. Bardzo mi się to podobało, ale w praktyce zajmowałam się zarządzaniem projektami — po prostu tak tego nie nazywaliśmy.

Ben Aston:

Właśnie.

Jenna Trunzo:

Znałam kilka osób pracujących w tej firmie i powiedziałam im, że jestem wtedy dość niezadowolona ze swojej sytuacji. Powiedzieli: „Naprawdę powinnaś zainteresować się tą firmą. Obecnie zatrudniamy kierowników projektów. Brzmi to bardzo podobnie do tego, czym się zajmujesz”. Odpowiedziałam: „Nie mam doświadczenia w świecie technologii. Nie wiem, nie wiem”. Odkładałam to przez jakiś czas, ale w końcu mnie przekonali i złożyłam aplikację. To była jedna z najlepszych decyzji w moim życiu, więc rzeczywiście był to szczęśliwy przypadek.

Ben Aston:

Świetnie. Mówiłaś, że wcześniej w praktyce zajmowałaś się zarządzaniem projektami, ale kiedy trafiłaś do Globant, co odkryłaś? Jakie były najważniejsze rzeczy, do których musiałaś się przyzwyczaić lub dostosować, jeśli chodzi o sposób pracy w dużej agencji?

Jenna Trunzo:

Na najbardziej podstawowym poziomie wcześniej pracowałam z domu, zdalnie. W tej pracy zaczęłam przychodzić do biura, co również było świetne, ale musiałam dostosować się do wielu nowych procesów i innego rodzaju pracy z klientami. Zmienił się również charakter wymagań, które próbowałam spełniać. Przejście z nieruchomości do technologii zdecydowanie było dużą zmianą. Co ciekawe, istnieją pewne podobieństwa, ale pojawiło się też wiele nowej terminologii, nowych procesów i nowych sposobów prowadzenia projektu. To była spora transformacja, ale bardzo dobra.

Ben Aston:

Tak. Sprawdziłem stronę Globant i dużo mówi się tam o zespołach Agile. Wiele osób mówi o Agile i próbuje wdrażać je na różne sposoby. Zespoły są jednym z rozwiązań, które wydają się działać. Opowiedz nam, jak to wygląda. W jakim zespole pracujesz i jak to działa? Jak zarządzasz swoim zespołem?

Jenna Trunzo:

Na bardzo ogólnym poziomie Globant działa w ramach kilku różnych rodzajów zespołów. Na przykład może to być zespół realizacyjny albo strategiczny. Wydaje mi się, że łącznie jest ich pięć. Na potrzeby tej rozmowy pracuję w zespole hybrydowym. W praktyce polega to na znalezieniu odpowiednich osób do każdej roli, dopasowanych do projektu, nad którym pracujesz, a następnie utworzeniu na tej podstawie zespołu. To właściwie zespół projektowy, ale różnica polega na tym, że stale oceniamy własne cele i odpowiedzialność. Na tej podstawie tworzymy własne metody i wskaźniki ich osiągania. W miarę dojrzewania zespołu najlepsi członkowie, którzy dobrze realizowali te założenia, mają tworzyć kolejne zespoły dla następnych projektów. To oni prowadzą następny zespół.

Ben Aston:

Ile osób liczy taki zespół?

Jenna Trunzo:

To się zmienia. Może liczyć od 3 do 20 osób. W moim obecnym zespole jest ich osiem.

Ben Aston:

Jak taki zespół otrzymuje zasoby? Pojawia się projekt i zostaje przypisany do zespołu, który następnie ustala, kiedy go dostarczy, czy wygląda to inaczej?

Jenna Trunzo:

To projekt określa, kiedy i co dostarczamy. Zespół jest tworzony na potrzeby danego projektu, chyba że działa tak skutecznie, że przechodzi bezpośrednio z jednego projektu lub klienta do kolejnego. Nie zawsze tak to wygląda, ale w idealnym świecie właśnie tak by było. Pozostawałbyś w swoim zespole do momentu jego dojrzenia i podziału, a następnie przechodziłbyś z projektu do projektu.

Ben Aston:

Czyli zespoły stale się zmieniają.

Jenna Trunzo:

Tak.

Ben Aston:

Wspomniałaś, że pracujesz w zespole hybrydowym. Zazwyczaj w Agile, a szczególnie w Scrumie, kierownik projektu nie jest osobną rolą.

Jenna Trunzo:

Zgadza się.

Ben Aston:

Opowiedz, jaka jest twoja rola w tym zespole i jakie pełnisz funkcje.

Jenna Trunzo:

Wykonuję wiele tradycyjnych zadań związanych z zarządzaniem projektami. Myślę, że termin Agile bywa czasami używany dość luźno.

Ben Aston:

Tak.

Jenna Trunzo:

Zajmuję się budżetem, zakresem, rezultatami i podobnymi sprawami. W kontekście zespołów chodzi jednak bardziej o kondycję zespołu i projektu oraz o odpowiedzialność za utrzymanie zespołu, jego oceny, dojrzałość i podobne kwestie.

Ben Aston:

Opowiedz o ocenach i dojrzałości. Czy ludzie zdają jakieś testy?

Jenna Trunzo:

Niekoniecznie są to testy. To raczej proces współpracy, podczas którego spotykamy się i dyskutujemy: „Czy osiągnęliśmy cele, które wyznaczyliśmy sobie na początku istnienia tego zespołu?”. Kiedy jako grupa i zespół tworzymy konstytucję, co trzy do sześciu miesięcy oceniamy, czy jej przestrzegamy, czy robimy to we właściwy sposób i czy musimy coś dostosować. Dodam tylko, że jest to dla nas stosunkowo nowa koncepcja, ponieważ nie tak dawno zostaliśmy przejęci przez Globant i przechodzimy na ich sposób pracy.

Ben Aston:

Czekają was zatem ekscytujące czasy.

Jenna Trunzo:

Tak.

Ben Aston:

Zawsze pytam ludzi, z jakich narzędzi korzystają, ponieważ kierownicy projektów są zwykle zainteresowani nowymi i ciekawymi narzędziami. Co znajduje się w twoim zestawie narzędzi kierownika projektu, który szczególnie cenisz?

Jenna Trunzo:

Advil, zdecydowanie Advil. Tylko żartuję. Mam szczęście pracować w bardzo współpracującym środowisku. Tak naprawdę moi współpracownicy są moim najważniejszym narzędziem. Stale konsultujemy ze sobą różne sytuacje i pracę nad projektami, prosząc o drugą opinię. „Czy to zadziałało w twoim projekcie? A to zadziałało u ciebie?” Jeśli chodzi o konkretne narzędzia, korzystamy głównie z Jiry i Confluence. Google Drive jest naszym głównym centrum, a poza tym korzystamy z różnych dodatkowych narzędzi, które projektanci przesyłają nam lub z którymi musimy pracować. Te trzy są jednak naszymi podstawowymi rozwiązaniami.

Ben Aston:

Klasyka.

Jenna Trunzo:

Tak, klasyka.

Ben Aston:

Porozmawiajmy o twoim artykule. Dla tych, którzy jeszcze go nie czytali: jak wspomniałem na początku, Jenna otrzymała projekt do zrealizowania w ciągu dwóch tygodni. Opowiedz najpierw, jak ten projekt do ciebie trafił, ponieważ większości osób informacja: „Musisz zrealizować ten projekt w dwa tygodnie” wystarczyłaby do wywołania lekkiego zawału. Jak projekt do ciebie trafił i dlaczego zamiast go odrzucić, podjęłaś się jego realizacji?

Jenna Trunzo:

Trochę jedno i drugie. Miałam wolne moce przerobowe, więc to było korzystne. Jeden z moich projektów właśnie się zakończył, więc byłam dostępna. Jednocześnie pracuję w firmie, w której szanuje się sytuację, gdy ktoś naprawdę nie chce pracować nad danym projektem — wtedy przekazują go komuś innemu. Ja jednak lubię projekty wymagające odrobiny kreatywności i stanowiące wyzwanie. Nie przeszkadzało mi to. Pomyślałam: „W dwa tygodnie chyba nie może pójść aż tak źle”.

Ben Aston:

Co mogłoby pójść nie tak?

Jenna Trunzo:

Co mogłoby pójść nie tak w ciągu dwóch tygodni? Właśnie.

Ben Aston:

Dlaczego harmonogram obejmował dwa tygodnie? W artykule wspominasz, że zaplanowano testy. Czy był to przypadkowy termin, czy naprawdę ważne było, aby projekt trwał tylko dwa tygodnie?

Jenna Trunzo:

Naprawdę ważne było, aby trwał tylko dwa tygodnie. Firma zaplanowała testy z użytkownikami, zakładając, że uda jej się przygotować wszystko, co było potrzebne do tego czasu. Termin testów był już ustalony, choć nie znam ich szczegółów. Nie byli jednak w stanie zrobić tego, co musieli. Potrzebowali nas, abyśmy w ciągu dwóch tygodni stworzyli klikalne prototypy, które zagwarantowałyby gotowość do zaplanowanych testów z użytkownikami.

Ben Aston:

Mieliście więc dwa tygodnie na stworzenie funkcjonalnego prototypu do testów z użytkownikami. Czy możesz powiedzieć coś więcej o tym, co prototypowaliście? Aby stworzyć naprawdę funkcjonalny prototyp, z którego można uzyskać wartościowe informacje podczas testów, trzeba go dość dokładnie opracować. Co budowaliście?

Jenna Trunzo:

Firma analizowała sposób prezentowania interfejsu użytkownika swojego urządzenia. Musieliśmy wziąć istniejący interfejs konkretnego urządzenia i stworzyć jego prototyp tak, aby odzwierciedlał sposób, w jaki konsument wchodziłby z nim w interakcję. Każdy prototyp odpowiadał całej ścieżce użytkownika. Każdy kliknięty przycisk prowadził użytkownika kolejno określoną ścieżką. Musieliśmy upewnić się, że prototypy rzeczywiście prowadzą go tą ścieżką.

Ben Aston:

Mówiąc o urządzeniu, nie masz na myśli oprogramowania, tylko na przykład piekarnik?

Jenna Trunzo:

Dokładnie, na przykład piekarnik konwekcyjny.

Ben Aston:

Tworzyliście więc obrazy wyświetlacza piekarnika?

Jenna Trunzo:

Mniej więcej. Uwzględnialiśmy wszystkie dostępne przyciski i ekrany wyświetlane podczas interakcji z nimi. Załóżmy, że chcę zautomatyzować działanie na podstawie rodzaju potrawy. Naciskam przycisk X, a wyświetlacz pokazuje A, B, C, D i E. Jeśli nacisnę przycisk Y, co pokaże wyświetlacz i czy odpowiada to potrzebom konsumenta?

Ben Aston:

Projektowanie doświadczenia użytkownika dla piekarnika.

Jenna Trunzo:

Tak.

Ben Aston:

Czy końcowym prototypem były klikalne makiety, czy co dokładnie dostarczyliście po dwóch tygodniach?

Jenna Trunzo:

Były to zasadniczo klikalne makiety, z nieco bardziej szczegółowymi wytycznymi projektowymi zgodnie z oczekiwaniami klienta. Uwzględniały dokładne kroje pisma, odstępy i parametry projektu, które miał wykorzystywać rzeczywisty sprzęt. Tak, zasadniczo były to klikalne makiety.

Ben Aston:

Czy powstały w Envision?

Jenna Trunzo:

Wydaje mi się, że zostały stworzone w Envision.

Ben Aston:

Nie zaczynaliście całkowicie od zera, ponieważ interfejs piekarnika już istniał.

Jenna Trunzo:

Zgadza się.

Ben Aston:

W ciągu dwóch tygodni opracowywaliście różne ścieżki, aby sprawdzić, czy korzystanie z piekarnika jest dla ludzi zrozumiałe?

Jenna Trunzo:

Tak. Jednym z wyzwań było to, że zespół projektowy klienta przekazał nam na początku niewłaściwe specyfikacje. To problem, gdy masz tylko dwa tygodnie na realizację i tworzysz coś niezgodnego z ich oczekiwaniami. Była to niemała przeszkoda.

Ben Aston:

Kiedy zorientowaliście się, że specyfikacje były błędne?

Jenna Trunzo:

W artykule wspominam, że przy tak krótkim projekcie kluczowe są codzienne spotkania i prezentacje. Dokładnie tak pracowaliśmy, ponieważ chcieliśmy jak najszybciej dowiedzieć się, jeśli coś było nie w porządku. W tej sytuacji właśnie tak się stało. Codziennie kontaktowaliśmy się z klientem i przekazywaliśmy aktualizacje dotyczące postępów. Większość spotkań była prezentacjami lub wizualnymi przeglądami. Bardzo szybko stało się jasne, że otrzymaliśmy niewłaściwe informacje. Na szczęście mogliśmy je od razu skorygować, ale nie byłoby to możliwe bez tak częstego kontaktu.

Ben Aston:

Harmonogram i budżet były stałe, ale zastanawiam się, jaką elastyczność mieliście w zakresie projektu. Testy z użytkownikami miały się odbyć, a klient chciał opracowania określonych ścieżek. Czy mogliście zmienić liczbę ekranów i ścieżek?

Jenna Trunzo:

Niewielką. Poproszono nas o przygotowanie, o ile dobrze pamiętam, sześciu ścieżek i sześciu pełnych prototypów. Problem polegał na tym, że jeśli nie stworzylibyśmy wszystkich, wpłynęłoby to na testy, ponieważ jedna ścieżka była powiązana z kolejną. Zmiana zakresu oznaczałaby zmianę całego doświadczenia użytkownika.

Ben Aston:

Stały zakres i stały harmonogram. Jak to zaplanowaliście? Po pierwszym dniu zorientowaliście się, że projekt był błędny, a mieliście sześć ścieżek do przygotowania w dziesięć dni.

Jenna Trunzo:

Na tyle, na ile można coś takiego zaplanować. Dużo wcześniej współpracowaliśmy z całym zespołem. W takich sytuacjach kierownik projektu musi sprawdzić, czy potrafi się dostosować i odejść od tradycyjnego schematu. Jako kierownicy projektów często zamykamy się w procesie, z którym czujemy się komfortowo. Tutaj wszystko zostaje wywrócone do góry nogami. Z konieczności trzeba znaleźć sposoby na zwiększenie efektywności, co staje się bardzo dobrym doświadczeniem. Podstawowy plan powstał na podstawie analizy materiałów klienta, oczekiwanego rezultatu i kalendarza. Uznaliśmy, że średnio możemy realizować jedną ścieżkę w ciągu dwóch dni. Po uśrednieniu wszystko się zgadzało, ponieważ niektóre ścieżki były krótsze, a inne dłuższe.

Ben Aston:

Czyli mieliście wykonać określone zadanie i niewiele było miejsca na zmiany.

Jenna Trunzo:

Dokładnie.

Ben Aston:

Mieliście dziesięć dni, choć realizacja zajęłaby dwanaście. Podzieliliście więc pracę na odcinki czasowe, przeznaczając około dwóch dni na każdą ścieżkę. Czy uwzględniliście fakt, że pierwsze ścieżki zajmą więcej czasu, a później zespół przyspieszy?

Jenna Trunzo:

Wiedzieliśmy, że gdy uporamy się z podstawami, kolejne elementy powstaną szybciej. Po pierwszej naprawdę dobrej prezentacji dla klienta wiedzieliśmy, jakiego rodzaju informacji zwrotnych się spodziewać i mogliśmy odpowiednio się dostosować. Znaliśmy również tempo pracy naszych programistów oraz liczbę dostępnych godzin. To na pewno było ryzyko, ale taka jest natura tak krótkiego projektu.

Ben Aston:

Nie tworzyli więc tylko makiet, ale również coś budowali?

Jenna Trunzo:

Programiści sprawiali, że makiety były w pełni klikalne, ale nie powstała pełna wersja produktu.

Ben Aston:

Po pierwszym dniu zorientowaliście się, że macie niewłaściwe specyfikacje. Straciliście przez to dzień albo przynajmniej część zaplanowanego czasu. Jak zmodyfikowaliście plan?

Jenna Trunzo:

Mieliśmy pewien margines budżetowy. Mogliśmy zaangażować dodatkowego programistę na dzień lub dwa, aby pomógł tam, gdzie było to potrzebne. Zadziałało to idealnie. Nie zwiększyliśmy znacząco kosztów i nadal dostarczyliśmy projekt w terminie.

Ben Aston:

Czy plan się sprawdził?

Jenna Trunzo:

Tak.

Ben Aston:

Czy był wystarczająco szczegółowy?

Jenna Trunzo:

Był wystarczający, ponieważ nie mieliśmy dużego pola manewru. Projekt został ukończony prawidłowo, a na końcu mieliśmy bardzo dobrą relację z klientem. Patrząc wstecz, spróbowałabym wcześniej lepiej zrozumieć od lidera technicznego, które ścieżki będą wymagały więcej czasu. Mogłabym wtedy pomóc zespołowi lepiej rozłożyć pracę. On odpowiadał za programistów i bardzo dobrze znał ich tempo pracy, więc mu ufałam. To również jest część tej pracy — zaufanie do zespołu.

Ben Aston:

Które elementy planu nie zadziałały? Czy plan w którymś momencie się rozpadł?

Jenna Trunzo:

Muszę powiedzieć, że jestem bardzo zadowolona z liczby rzeczy, które mogły pójść źle, ale nie poszły. Myślę jednak, że na początku bardziej rozliczałabym klienta i upewniłabym się, że mamy dokładnie to, czego potrzebujemy, zanim zaczniemy pracę. Wydawało się, że tak jest, ale gdybym mogła zrobić to ponownie, poprosiłabym klienta o podwójne, a nawet potrójne sprawdzenie materiałów. To mogło zaoszczędzić cały dzień projektu.

Ben Aston:

Jakie wnioski wyciągnęłaś z tego projektu? Czy następnym razem zaplanowałabyś go inaczej?

Jenna Trunzo:

Wykonaliśmy wiele dobrych ruchów, ale są też konkretne wady i rzeczy, z których trzeba zrezygnować. Próbuję sobie przypomnieć, czy jest coś, co naprawdę zrobiłabym inaczej.

Ben Aston:

Czy były jakieś skróty, które próbowaliście zastosować, a potem i tak musieliście wrócić do pominiętych elementów? Przy napiętym harmonogramie łatwo pomyśleć: „Nie mamy czasu na porządny opis projektu, więc po prostu zbierzmy zespół i porozmawiajmy”.

Jenna Trunzo:

Właśnie.

Ben Aston:

A dwie godziny później zespół wraca i mówi: „Czy możesz przygotować opis projektu?”.

Jenna Trunzo:

Dokładnie.

Ben Aston:

Czasem mówimy: „Nie będziemy organizować codziennych spotkań Scrum, bo nie mamy na to czasu”, a potem okazuje się, że i tak odbywamy je codziennie. Czy były jakieś skróty, które próbowaliście zastosować, ale ostatecznie musieliście wykonać pominiętą pracę?

Jenna Trunzo:

Nie mieliśmy formalnego spotkania rozpoczynającego projekt. Nie odbyła się również rozmowa dotycząca jasnego podziału ról. Nie jestem pewna, czy było to absolutnie konieczne, ale myślę, że bardziej uporządkowany sposób pracy zespołu, zamiast swobodnego podejścia opartego na tym, kto najszybciej coś zrobi, byłby pomocny. Nie chodzi mi koniecznie o spotkanie rozpoczynające, ale o sesję wyjaśniającą role. Coś bardzo podstawowego. To był element, z którego zrezygnowaliśmy, a który mógłby nam się przydać.

Ben Aston:

Kiedy pracujesz nad projektem z bardzo napiętym harmonogramem, każda minuta ma znaczenie.

Jenna Trunzo:

Zgadza się.

Ben Aston:

Szczególnie pierwszego ranka łatwo pomyśleć: „Mamy dwa tygodnie, więc po prostu zaczynajmy”. Trudność polega na zapewnieniu zespołowi wystarczającej jasności, aby wiedział, dokąd zmierza i jakie kroki podejmie, bez zagłębiania się w najmniejsze szczegóły. Zespół musi naprawdę dobrze rozumieć, co trzeba zrobić, dlaczego i co będzie oznaczało sukces.

Jenna Trunzo:

I kto to zrobi.

Ben Aston:

Tak, i kto.

Jenna Trunzo:

Dokładnie.

Ben Aston:

To może ogromnie wpłynąć na skuteczność zespołu przez resztę projektu. Często myślimy: „Skoro my to rozumiemy, zespół również na pewno rozumie, bo przecież nie jest to skomplikowane”.

Jenna Trunzo:

Dokładnie. Trzeba też uważać na to w relacji z klientem, ponieważ nie wszyscy klienci znają te same zagadnienia co my. Mogą sądzić, że doskonale rozumieją, co będziemy robić, a kiedy im to dostarczymy, powiedzą: „Chwileczkę, w ogóle tego nie rozumiem”. W tym przypadku być może mogliśmy poświęcić nawet godzinę na lepsze zdefiniowanie wszystkiego.

Ben Aston:

Jenna, bardzo dziękuję za udział w programie. Wspaniale było cię gościć.

Jenna Trunzo:

Bardzo dziękuję. Naprawdę doceniam tę rozmowę.

Ben Aston:

Zastanawiam się, co o tym sądzisz. Czy kiedykolwiek prowadziłeś projekt z szalonym harmonogramem? Jak poszło? Opowiedz nam, co o tym myślisz, jak nim zarządzałeś, z jakich skrótów skorzystałeś i które próby ich zastosowania nie zadziałały. Następnie odwiedź TheDigitalProjectManager.com i dołącz do naszego zespołu na Slacku. Znajdziesz tam wiele interesujących rozmów na temat zarządzania projektami cyfrowymi. Jeśli podobało ci się to, co usłyszałeś, zasubskrybuj program i poświęć kilka minut na pozostawienie szczerej opinii. Czytamy wszystkie opinie i bardzo pomagają nam dopasowywać program oraz go ulepszać. Bardzo to doceniamy. Do następnego razu — dziękuję za słuchanie.