Przekazuj swoim współpracownikom lepsze informacje zwrotne (z Ryanem Schaeferem z Viget)

Przeczytaj transkrypcję:

Testujemy transkrypcję naszych podcastów za pomocą programu komputerowego. Prosimy o wyrozumiałość w przypadku literówek, ponieważ bot nie zawsze poprawnie rozpoznaje tekst.

Ben Aston:

Witamy w podcaście DPM, w którym wykraczamy poza teorię, aby przekazywać praktyczne porady dotyczące prowadzenia lepszych projektów cyfrowych. Dziękuję za dołączenie. Nazywam się Ben Aston, jestem założycielem The Digital Project Manager.

Jak radzisz sobie z przekazywaniem informacji zwrotnych osobom w swoim zespole? Podchodzisz do tego bez obaw, bo w końcu jesteś kierownikiem projektu i masz rację, czy unikasz tego, bo martwisz się, że nie zostaniesz potraktowany poważnie? Być może otrzymujesz informacje zwrotne i masz wrażenie, że nikt tak naprawdę nie rozumie tego, co powiedziałeś, a może nawet tego nie usłyszał. Jako kierownicy projektów odpowiadamy jednak za osiąganie sukcesu, a jest to trudne, gdy nasze zespoły tak często zdają się podążać w niewłaściwym kierunku.

W dzisiejszym podcaście poznasz kilka prostych sposobów przekazywania informacji zwrotnych, które pomogą Twoim zespołom tworzyć lepszą pracę i utrzymywać projekty na właściwym torze.

Dziś rozmawiam z Ryanem Schaeferem. Ryan przeszedł od projektowania i tworzenia stron internetowych do zarządzania ich rozwojem. Pracuje w Waszyngtonie w agencji Viget. Cześć, Ryan.

Ryan Schaefer:

Cześć, Ben. Dzięki za zaproszenie.

Ben Aston:

Świetnie. Ryan, opowiedz nam trochę o swojej obecnej roli. Szczególnie interesuje mnie, jak przeszedłeś od projektowania i programowania do zarządzania projektami. To pytanie często się pojawia. Czym zajmujesz się teraz? Czy jest to wyłącznie zarządzanie projektami, czy nadal angażujesz się również w szczegóły?

Ryan Schaefer:

Powiedziałbym, że jest to głównie zarządzanie projektami, ale z pewnością jedną z rzeczy, które ułatwiły mi przejście od pracy w szczegółach i realizowania projektów projektowych oraz programistycznych do zarządzania projektami, było zrozumienie wszystkich założeń i procesów związanych z projektowaniem i programowaniem.

Dzięki temu mogę rozmawiać z bardzo utalentowanymi projektantami i programistami tutaj, na względnie równym poziomie. Nie muszę pytać, co oznaczają skróty, jakich używają narzędzi i tak dalej.

Myślę, że moje doświadczenie w poprzedniej firmie public relations, gdzie pełniłem podwójną rolę związaną zarówno z obsługą klientów, jak i realizacją projektów, również pomogło mi przygotować się do przekazywania informacji klientom oraz współpracy z innymi członkami zespołu. Na szczęście przejście do zarządzania projektami na pełną skalę było dla mnie dość naturalne.

Ben Aston:

Ale jak do tego doszło? Jaki był moment, w którym powiedziałeś: „Dobrze, to właśnie tym będę się zajmować — zostanę kierownikiem projektu”?

Ryan Schaefer:

Częściowo chodziło o chęć zarządzania rzeczami z perspektywy 30 tysięcy stóp, zamiast wykonywania pracy w izolacji. Głównym powodem było jednak pragnienie dołączenia do firmy, w której wszyscy pasjonowali się światem cyfrowym, byli nastawieni na przyszłość i rozumieli, że technologia zmienia sposób, w jaki żyjemy jako cywilizacja, a z pewnością także jako kraj. Chciałem być otoczony ludźmi, którzy to dostrzegają i cenią, a także są bardzo kompetentni w swoich dziedzinach związanych z technologią cyfrową. Ostatecznie miało mi to pomóc w rozwoju zawodowym.

Ben Aston:

Świetnie. Opowiedz nam trochę o tym, czym zajmujesz się teraz. Jak wygląda rola kierownika projektu w Viget?

Ryan Schaefer:

Najpierw wyjaśnię, że chodzi o Viget. Często spotykamy się z błędną wymową.

Ben Aston:

Vid-get? Vig-et?

Ryan Schaefer:

Viget, tak.

Ben Aston:

Wszedłem nawet na stronę internetową i kliknąłem kota, który mówi, że to Viget.

Ryan Schaefer:

Tak, jest tam przycisk „przywitaj się”. To właśnie Viget.

Ben Aston:

Tak to jest, gdy ma się zabawną nazwę. Co ona właściwie oznacza?

Ryan Schaefer:

„Wspólnie rozkwitamy” po łacinie.

Ben Aston:

Ach, oczywiście.

Ryan Schaefer:

Coś w tym rodzaju.

Ben Aston:

Moja mama byłaby ze mnie rozczarowana. Mamo, przepraszam. Jest nauczycielką łaciny, więc powinienem wiedzieć takie rzeczy.

Ryan Schaefer:

Łacina była moim najmniej ulubionym przedmiotem w szkole średniej. Musieliśmy się jej uczyć. Nie mogę uwierzyć, że musieliśmy ją mieć, ale tak było.

Ben Aston:

Cóż, dzięki temu jesteś teraz tak dobrze przygotowany do posługiwania się wszystkimi językami, które znasz, prawda?

Ryan Schaefer:

Tak, dokładnie. Moja rola w Viget jako kierownika projektu obejmuje wiele różnych rzeczy. Oczywiście są podstawowe obowiązki kierownika projektu, takie jak harmonogram, budżet, planowanie, obsada i alokacja zasobów. Zajmujemy się też zadaniami bardziej typowymi dla zarządzania produktem. Nie mamy tutaj osobnych kierowników produktu, więc kierownicy projektów odpowiadają za wiele ścieżek użytkownika, definiowanie funkcji, testowanie jakości, a także dokładne rozumienie firm, z którymi pracujemy, i produktów, które tworzymy.

Ben Aston:

Czyli zajmujesz się zarządzaniem zarówno projektami, jak i produktami?

Ryan Schaefer:

Tak, to połączenie obu tych obszarów.

Ben Aston:

Opowiedz nam trochę o projektach, nad którymi obecnie pracujesz.

Ryan Schaefer:

Kilka tygodni temu przeszedłem do pracy w pełnym wymiarze godzin nad jednym projektem. To pierwszy raz, kiedy mi się to zdarzyło. Pracuję nad dużą stroną marketingową oraz swego rodzaju portalem dla różnych grup odbiorców, które mogą się logować i otrzymywać odmienne dane.

W praktyce przebudowujemy cały ekosystem, odświeżamy projekt wszystkich cyfrowych materiałów skierowanych do odbiorców i tworzymy plan rozwoju przyszłych produktów, na przykład aplikacji. Projekt jest bardzo angażujący i cieszę się, że mogę się w niego zagłębić, dobrze go poznać i więcej się o nim dowiedzieć.

Ben Aston:

Wiem, że podczas nadchodzącego DPM Summit poprowadzisz krótką prezentację na temat zarządzania tworzeniem aplikacji natywnej. Czy możesz przedstawić skróconą wersję swojego wystąpienia? Czego dowiedziałeś się o tworzeniu aplikacji natywnych?

Ryan Schaefer:

Moje wystąpienie będzie oparte na doświadczeniach z największego projektu, nad którym pracowałem w tej firmie — projekcie projektowania i tworzenia aplikacji na Androida.

Opowiem o tym, czego się nauczyłem, a przede wszystkim o różnicach między zarządzaniem tworzeniem aplikacji natywnej a częściej spotykanym tworzeniem stron internetowych oraz o najlepszych praktykach w tym zakresie. Chcę też omówić konkretne wymagania techniczne, które kierownik projektu powinien znać.

Jednym z przykładów jest wysoki koszt błędu w przypadku aplikacji. Aplikacja może się całkowicie zawiesić, podczas gdy w przypadku strony internetowej błąd zwykle można naprawić przez ponowne załadowanie strony. Języki używane do tworzenia aplikacji natywnych różnią się też od JavaScriptu stosowanego w aplikacjach internetowych. W przypadku aplikacji natywnej trzeba samodzielnie opracować znacznie większą część rozwiązania problemu.

Istnieją również ograniczenia systemowe, w tym działanie bez połączenia z internetem. Trzeba wiedzieć, jak aplikacja działa offline, jak przyciski menu telefonu współpracują z aplikacją i dokąd prowadzą użytkownika.

Ben Aston:

Masz doświadczenie zarówno z aplikacjami internetowymi, jak i natywnymi. Wydawało mi się, że wszyscy tworzą aplikacje internetowe, bo są łatwiejsze i szybsze w budowie. Jak oceniasz kierunek rozwoju aplikacji internetowych i natywnych?

Ryan Schaefer:

Jedną z interesujących rzeczy, które obserwujemy i z którymi mierzymy się jako firma, jest popularność narzędzi takich jak Squarespace, Beams w WordPressie czy Weebly. Są to bardzo praktyczne usługi, które pozwalają osobom z ograniczoną wiedzą techniczną szybko stworzyć dobrze wyglądającą stronę internetową.

Z powodu niskiego kosztu i dostępności tych rozwiązań trudniej znaleźć tradycyjne projekty stron marketingowych. W świecie aplikacji natywnych nie ma jeszcze podobnych rozwiązań, dlatego dostrzegamy tam duży potencjał. Poza tym miło jest móc powiedzieć: „Mamy aplikację”.

Ben Aston:

Jakie narzędzia znajdują się w Twoim zestawie kierownika projektu? Jak zarządzasz produktami i projektami? Co zawsze konfigurujesz na początku projektu?

Ryan Schaefer:

Ważne jest, aby dobrze rozpocząć projekt. Lubię organizować skoncentrowane dyskusje podczas spotkań otwierających projekt z klientem. Bardzo pomocna jest rozmowa o wizji, podczas której omawiamy, czym obecnie zajmuje się organizacja, co robi lub czego nie robi jej produkt oraz dokąd chce dojść. Organizuję również warsztaty dotyczące problemów, celów i założeń, a także wywiady z interesariuszami.

Wiele z tych informacji trudno wydobyć w procesie sprzedaży, niezależnie od tego, jak szczegółowo go zaplanujesz. Gdy już dobrze zrozumiesz wszystkie te kwestie — co warto uwzględnić w zakresie projektu, ponieważ może to zająć kilka tygodni lub dłużej — możesz rozpocząć pracę z wiedzą, która pozwoli działać szybciej, wydajniej i ostatecznie dostarczyć lepszy produkt.

Narzędzia używane do uporządkowania tych informacji mogą być bardzo różne. Airtable jest dobrym rozwiązaniem, podobnie jak GitHub Projects, ZenHub używany z GitHubem czy Trello. Korzystaliśmy ze wszystkich tych narzędzi, zależnie od preferencji klientów i naszych rekomendacji.

Ben Aston:

Czy są jakieś konkretne narzędzia do zarządzania projektami, które ostatnio ułatwiają Ci życie? Jakieś dobre triki, skróty lub funkcje, które niedawno odkryłeś?

Ryan Schaefer:

Powiedziałbym, że dwie rzeczy. Po pierwsze, poświęciłem trochę czasu na poznanie skrótów klawiaturowych, ponieważ jest ich bardzo dużo. Dzięki temu oszczędzam sekundy setki razy dziennie.

Po drugie, nowym narzędziem, którego używam i które bardzo wiele mi otworzyło, jest Notion. To coś w rodzaju aplikacji będącej przestrzenią roboczą. Można używać jej do sporządzania notatek i współpracy, działa offline, ma przejrzysty interfejs, pozwala osadzać treści, tworzyć przełączniki i bez końca zagnieżdżać strony. Dostępna jest również w wersji internetowej i mobilnej, więc można korzystać z niej wszędzie. Jest bardzo elastyczna.

Dzięki temu, gdy jestem na rozmowie, mogę szybko ją uruchomić, zapisać potrzebną informację, a później z łatwością uporządkować ją i nadać jej estetyczny wygląd.

Ben Aston:

Co uważasz za najtrudniejsze w pracy nad wszystkimi tymi projektami i narzędziami? Jakie są codzienne wyzwania? Co jest obecnie najtrudniejszą częścią Twojej pracy?

Ryan Schaefer:

Jest wiele takich rzeczy. Jedną z nich jest brak czasu, ale najtrudniejsze wydaje mi się przełączanie kontekstu.

Zwykle kierownik projektu pracuje nad kilkoma projektami, a jego kalendarz jest pełen spotkań. Często przechodzisz z jednego spotkania na drugie i musisz w ciągu minuty odtworzyć cały kontekst projektu. Uważam to za bardzo trudne. Radzę sobie z tym, robiąc dokładne notatki, do których mogę od razu wrócić. Przygotowuję również agendy do każdego spotkania. Na początku dnia lubię poświęcić trochę czasu, aby przy kawie zastanowić się nad statusem każdego projektu, nad tym, gdzie się znajduje i gdzie powinien znaleźć się pod koniec dnia.

Drugim wyzwaniem jest znalezienie dobrego sposobu na ułatwienie współpracy podczas przekazywania pracy od projektantów programistom. Otrzymujesz piękny projekt przygotowany przez projektanta we współpracy z osobą zajmującą się doświadczeniem użytkownika, a następnie chcesz, aby programista go przejrzał i zaakceptował, zanim pokażesz go klientowi. Na podstawie statycznego projektu często trudno jest udokumentować i zdefiniować wszystkie funkcje interfejsu oraz sposób zarządzania nimi w panelu administracyjnym.

Eksperymentujemy więc z Airtable i podobnymi rozwiązaniami, aby uporządkować treści w sposób, który pozwala powiązać każdy element projektu z odpowiednim opisem. Dzięki temu programista może określić, jak wszystko będzie działać, ile czasu zajmie realizacja i czy zmieścimy się w terminie oraz budżecie.

Może to być dość pracochłonny proces i nadal go dopracowujemy, ale mam nadzieję, że przyniesie dobre rezultaty.

Ben Aston:

Porozmawiajmy o tym, ponieważ Airtable to zasadniczo połączenie arkusza kalkulacyjnego i bazy danych.

Ryan Schaefer:

Tak.

Ben Aston:

Czy Airtable integruje się z InVision, Sketch lub innym narzędziem używanym do tworzenia makiet?

Ryan Schaefer:

Ma integracje, ale głównie korzystamy z Figmy. Nie sądzę, aby miała z nią integrację.

Próbowaliśmy kilku różnych rozwiązań, między innymi arkusza Google z linkami. Nie wiem, czy jesteśmy już na etapie, na którym integracja z narzędziem miałaby sens. Największą zaletą Airtable jest to, że jest relacyjną bazą danych. Bardzo łatwo można łączyć ze sobą informacje, rozwiązanie dobrze się skaluje, a dane są czytelne i mają przejrzysty interfejs.

Ben Aston:

Dla osób, które nigdy nie korzystały z Airtable — jak organizujecie w nim pracę?

Ryan Schaefer:

Jeśli zaczynamy od eksploracji interfejsu, dokumentujemy miejsce docelowe każdego elementu nawigacji, korzystając z mapy strony. Następnie tworzymy kolejne widoki, które wyglądają jak karty, i porównujemy bieżącą wersję, odwołując się do informacji w innym widoku. Dodajemy nowe obszary i oznaczamy je tagami, kategoriami lub różnymi blokami z określonymi nagłówkami i kolorami.

Dzięki temu powstaje przejrzysty materiał, który każdy może łatwo zrozumieć w trakcie projektu i który pełni funkcję głównego źródła informacji.

Ben Aston:

To świetny pomysł. Przejście od projektu doświadczenia użytkownika do programowania przy jednoczesnym zachowaniu wymagań jest dużym wyzwaniem. Airtable pozwala odwoływać się do tych samych elementów zamiast kopiować je w wielu miejscach, więc zmiana w jednym miejscu aktualizuje wspólne dane.

Porozmawiajmy teraz o Twoim artykule. Dotyczy on przekazywania informacji zwrotnych w sposób, który przynosi korzyści projektowi i prowadzi do stworzenia lepszego produktu.

Dlaczego Twoim zdaniem kierownicy projektów powstrzymują się przed przekazywaniem informacji zwrotnych i czego się obawiają?

Ryan Schaefer:

Myślę, że są dwa powody. Pierwszy jest czysto ludzki: nie chcemy urazić członków zespołu ani umniejszać ich pracy. Drugi polega na tym, że możemy nie czuć się wystarczająco pewnie, wyrażając opinię wobec ekspertów — projektantów i programistów.

To uzasadnione obawy, ale kierownik projektu jest zwykle najbliżej klienta i ma świeższe spojrzenie niż osoba, która przez długi czas pracowała nad szczegółami. Możesz najlepiej odtworzyć perspektywę użytkownika końcowego. Wnosisz więc do pracy inną perspektywę niż osoba, która ją wykonuje.

Powinieneś czuć się pewnie w tej dziedzinie i korzystać ze swojego punktu widzenia, aby przekazywać informacje zwrotne: „Widzę to po raz pierwszy jako kierownik projektu. Użytkownik również zobaczy to po raz pierwszy. Czy jasno pokazuje to, czym zajmuje się organizacja? Czy odpowiada jej odbiorcom? Czy oczywiste jest, że to menu rozwijane?”. Taka reakcja pomaga zespołowi odnieść rozwiązanie do oczekiwanego zachowania użytkownika i celów biznesowych.

Ben Aston:

Podoba mi się perspektywa kierownika projektu jako strażnika sukcesu i doświadczenia użytkownika, który zapewnia świeże spojrzenie.

W artykule podajesz dziesięć wskazówek dotyczących przekazywania dobrych informacji zwrotnych. Pierwsza mówi o przygotowaniu się i zdobyciu odpowiedniej wiedzy z perspektywy sukcesu biznesowego. Jak poznajesz, że masz wystarczającą wiedzę?

Ryan Schaefer:

Nigdy nie można mieć pewności, że wie się absolutnie wszystko, i to jest w porządku.

Dobrym początkiem są rozmowy o wizji, ponieważ pozwalają zrozumieć, jak firma postrzega siebie i dokąd chce zmierzać. Rozmowy z kadrą kierowniczą pokazują, jak organizacja chce realizować swoje plany. Spotkanie otwierające projekt z osobami bezpośrednio zaangażowanymi pozwala zrozumieć, jak projekt łączy się z działaniami kierownictwa i wyższymi celami biznesowymi.

Wszystko to powinno być widoczne w tym, co próbujesz osiągnąć. Jeśli rozumiesz, dokąd klient chce dojść, stajesz się osobą pomagającą mu tam dotrzeć — poprzez poprawę komunikacji, odświeżenie wyglądu marki, zmianę przekazu albo rekomendację rozszerzenia produktu i stworzenia aplikacji.

Jest to proces ciągły i wymaga dużej inwestycji na początku. Skupiamy się na fazach odkrywania, które mają odpowiadać na te pytania. To bardzo pomaga uporządkować proces i ostatecznie prowadzi do stworzenia lepszego produktu.

Ben Aston:

Aby być dobrze poinformowanym, trzeba rozumieć klienta, jego definicję sukcesu biznesowego oraz użytkowników i ich potrzeby. Wspomniałeś również o znajomości najlepszych praktyk i czerpaniu wiedzy z różnych dziedzin. Jak wygląda to w Twoim przypadku?

Ryan Schaefer:

Gdy zdobywasz większą wiedzę i chcesz przekazywać zespołowi bardziej szczegółowe informacje, rób to w sposób dyplomatyczny i obiektywny, a nie subiektywny.

Najlepszym sposobem jest rozmawianie z jak największą liczbą osób w zespole i otwarte przyznawanie się do luk w wiedzy. Jeśli ktoś wywodzi się z programowania i nie zna się dobrze na doświadczeniu użytkownika, nie powinien obawiać się obserwowania pracy projektanta UX i uczenia się od niego.

Warto również samodzielnie próbować różnych rzeczy. Dostępnych jest wiele materiałów do nauki programowania i projektowania. Można czerpać inspirację z projektów zespołu, obserwować trendy i czytać artykuły. Staram się poświęcać pięć godzin tygodniowo na projektowanie, podtrzymywanie umiejętności programistycznych i czytanie.

Ben Aston:

Z jakich stron korzystasz, aby być na bieżąco?

Ryan Schaefer:

Thedigitalprojectmanager.com to dobra strona.

Dobrym źródłem jest też A Girl’s Guide to Project Management. Adweek pomaga zorientować się, w jakim kierunku zmierza branża kreatywna. W programowaniu W3Schools nie jest serwisem informacyjnym, ale zawiera materiały pozwalające wypróbować różne rozwiązania w CSS, JavaScripcie i technologiach backendowych.

Ben Aston:

Warto rozwijać własne umiejętności poprzez projekty eksperymentalne i poboczne. Nawet podstawowe zrozumienie sposobu działania technologii pozwala prowadzić bardziej świadomą rozmowę z programistą.

Można stworzyć własną stronę portfolio albo spróbować zbudować coś od podstaw. Czytanie o czymś to jedno, a samodzielne wykonanie tego to coś zupełnie innego. Gdy samodzielnie spróbujesz zrealizować zadanie, lepiej zrozumiesz, ile pracy wymaga ono od projektanta.

Czy zdarzyło Ci się, że takie podejście obróciło się przeciwko Tobie? Jak radzisz sobie, gdy ktoś nie traktuje poważnie Twojej opinii, ponieważ jesteś tylko kierownikiem projektu?

Ryan Schaefer:

Na szczęście jeszcze mi się to nie zdarzyło. Częściowo wynika to ze świetnych ludzi, z którymi pracuję, ale również z tego, że koncentruję się na perspektywie klienta. Zespół szanuje tę perspektywę, szczególnie gdy pokazujesz, jak podjęte decyzje, zastosowana logika i stworzone systemy odnoszą się do celów ustalonych na początku etapu.

Nie chodzi więc o stwierdzenie: „Nie podoba mi się ten kolor”, lecz raczej: „Wiemy, że wytyczne marki wskazują ten kolor jako dodatkowy. Zajmuje on dużo miejsca. Czy może to negatywnie wpłynąć na odbiór projektu?”. Projektant prawdopodobnie już to przemyślał i będzie miał uzasadnienie. Jeśli będzie ono sensowne dla Ciebie, będzie też sensowne dla klienta.

Ben Aston:

Wspomniałeś również, że nie wszystko musi spoczywać na kierowniku projektu. Możesz zaprosić dyrektora kreatywnego do trudnej rozmowy i poprosić o dodatkową perspektywę. Nie musisz samodzielnie pełnić roli strażnika wszystkiego, co jest właściwe.

W artykule piszesz też o przygotowaniu się na różne reakcje zespołu. Jak znaleźć równowagę między wymagającą informacją zwrotną, motywowaniem i konstruktywną pochwałą, nie rozmywając przekazu?

Ryan Schaefer:

Nie ma na to jednej naukowej metody ani prostych kroków. Kierownik projektu powinien wykorzystywać inteligencję emocjonalną, aby obserwować, jak ludzie reagują na informacje zwrotne.

Najważniejsze jest bycie konkretnym. Nie należy opierać się na subiektywnych opiniach, lecz na obiektywnych decyzjach i ich związku z celami projektu.

Warto też subtelnie pokazywać, że wierzysz w zdolność danej osoby do wykonania zadania. Jest to zachęcające niezależnie od tego, czy ktoś osobiście przeżywa konstruktywną krytykę, czy traktuje ją jako materiał do rozwoju.

Ben Aston:

Jeśli ktoś słucha tego podcastu i myśli, że zespół UX lub projektant nigdy go nie wysłucha, bo postrzega go jedynie jako administratora, jaki byłby pierwszy krok lub najważniejsza rzecz do zapamiętania?

Ryan Schaefer:

Gdy po raz pierwszy widzisz coś, co wygląda niewłaściwie — prototyp, projekt lub cokolwiek innego — nie musisz od razu wyrażać opinii. Wróć do biurka, przyjrzyj się temu i zrób notatki. Zastanów się, gdzie projekt nie spełnia założeń, a przede wszystkim przygotuj propozycje ulepszeń.

Dzięki temu masz czas, aby przejść przez podobny proces myślowy jak osoba, która stworzyła projekt, i przygotować uzasadnienie swoich sugestii. Im więcej czasu poświęcisz na dokładną analizę, tym bardziej członek zespołu będzie szanował Twoją opinię i tym chętniej uwzględni ją w kolejnej wersji.

Ben Aston:

To bardzo rozsądna rada. Ludzie mogą zareagować defensywnie, gdy słyszą po prostu: „Nie podoba mi się to” albo „To chyba nie działa”. Warto poświęcić czas na zrozumienie, dlaczego coś wydaje się niewłaściwe, i przedstawić uzasadnienie związane z wymaganiami klienta. Możemy zadawać pytania osobie, która wykonała pracę, a potem zaproponować możliwe rozwiązania.

Warto szkicować pomysły na tablicy lub w notatniku. Wtedy nie przejmujesz projektu, tylko przedstawiasz możliwe kierunki. Może to pomóc zespołowi lepiej zrozumieć Twoje sugestie.

Ryan, bardzo dziękuję za udział w rozmowie.

Ryan Schaefer:

Bardzo dziękuję. Doceniam zaproszenie.

Ben Aston:

Ciekawi mnie, co o tym sądzisz. Czy próbowałeś kiedyś przekazywać informacje zwrotne? Jak na nie zareagował zespół? Czy był zły, czy raczej wdzięczny, że zwróciłeś uwagę na coś, czego wcześniej nie zauważył?

Napisz, co myślisz. Skomentuj artykuł i odwiedź stronę thedigitalprojectmanager.com, aby dołączyć do naszego zespołu na Slacku. Znajdziesz tam wiele interesujących rozmów na temat realizacji projektów.

Jeśli podobało Ci się to, czego dziś słuchałeś, zasubskrybuj podcast i poświęć kilka minut na pozostawienie szczerej opinii o podcaście DPM w Apple Podcasts. Bardzo cenimy oceny i recenzje, więc dziękujemy za ich pozostawienie.

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