Z tego podcastu dowiesz się:
- Co to jest dokumentacja projektowa
- Ile zastosowań ma taka dokumentacja
- Które rzeczy dokumentować na pewno, a które niekoniecznie
- Jak wykorzystać kalendarz w służbie dokumentacji
- Kiedy dokumentacja uratuje tyłek project managerowi
- Na jakie korzyści możesz liczyć, prowadząc dokumentację
- Za co pokochają cię stakeholderzy i współpracownicy
- Czym jest RAID i jak może tobie pomóc
- Jakie są najlepsze praktyki prowadzenia dokumentacji
Podcast znajdziesz także na:
Transkrypcja podcastu
„Być jak manager” – podcast, epizod 21.
Dzień dobry. Po co nam dokumentacja biznesowa? To jest pytanie, które dziś i sobie i tobie, drogi słuchaczu, postawię. Pytanie, na które będziemy szukali sensownej odpowiedzi. Natomiast jeśli jesteś tu przypadkiem lub trafiłeś na ten podcast po raz pierwszy, to ja zawsze podkreślam, że ten podcast to pewnego rodzaju przestrzeń w polskim Internecie, którą wykreowałem głównie na subiektywnych i bardzo indywidualnych opiniach moich, ale także moich kolegów, o szeroko pojętej branży menadżerskiej, a dokładniej, branży menadżerskiej w branży IT. Więc najczęściej treści, które tutaj spotkasz dotyczą szeroko pojętego zarządzania produktem, zarządzania projektem, analityki biznesowej, czy np. bycia product ownerem lub scrum masterem. Zachęcam, żeby zostać na dłużej, zachęcam zawsze, żeby zapisać się na newsletter na moim blogu bycjakmanager.pl, nie dlatego że chcę spamować, bo to, co zawsze podkreślam to to, że, po pierwsze, nigdy nie spamuję, wysyłam informacje tylko o nowych epizodach lub różne przydatne triki, porady dotyczące zarządzania. Druga rzecz to to, że ja nigdy nie handluję czyimiś danymi, więc twoim imieniem i adresem mailowym na pewno nie będę handlował z osobami lub firmami trzecimi.
Dziś temat project-managerski. I jeżeli jednak, drogi słuchaczu, masz zacięcie do product managementu lub bycia scrum masterem lub product ownershipu, to gwarantuję ci, że mimo project-managerskiego contentu na pewno znajdziesz tutaj wartościowe treści także dla siebie. Zachęcam, żeby zostać na dłużej. Ale ja już wejdę od razu w mięcho, bo szkoda gadać.
To, co chcę podkreślić – i niech ta myśl towarzyszy nam już do końca naszego dzisiejszego spotkania – to to, że ja nie będę wchodził w takie mocne szczegóły, czyli nie będę jeszcze opowiadał o tym, jakie są dokładne typy dokumentacji projektowej, jakie się tworzy i po co. Po pierwsze, dlatego że to jest temat rzeka, po drugie, dlatego że schomikowałem sobie te takie bardziej dokładne mięcho na kolejne epizody swoich podcastów. A nie chciałem też opowiadać o typach dokumentów project-managerskich bez takiego wyjścia z progu w ten temat. I postanowiłem, że dzisiejszy epizod zadedykuję nie tylko project managerom, ale wszystkim osobom, które kiedykolwiek zadały sobie pytania: „Po co nam tak naprawdę dokumentacja projektowa? Dlaczego ona jest taka ważna?”.
Zacznijmy od ogółu, wejdźmy później w nieco głębsze szczegóły, ale bez – tak jak wspomniałem – bardzo dokładnych technikaliów. Ogólnie, dokumentacja projektowa, jeżeli mielibyśmy siebie zapytać, czym jest, to ona jest tworzona przez project managera, żeby adekwatnie zarządzać, kontrolować i – jak to się ładnie mówi – dostarczać projekt, który został managerowi zlecony do realizacji. Termin dokumentacji projektowej – nie wszyscy to wiedzą – nawiązuje do wszystkich dokumentów projektowych, które są tworzone w trakcie prac nad projektem. I to są te rzeczy, o których ja nie będę dzisiaj długo opowiadał, ale wspomnę tylko, że mogą to być m.in. plan projektu, kalendarz projektu, budżet, zdefiniowane aktywności, kamienie milowe projektu, roadmapa czy też ogólne wytyczne dla zespołu projektowego spisane w jednym miejscu. I taka dokumentacja projektowa, wbrew pozorom, ma wiele zastosowań, m.in. planowanie, zarządzanie kosztami czy chociażby zarządzanie ryzykiem, które pojawia się niemalże w każdym projekcie. I w dodatku – co chcę podkreślić – są pewne rodzaje dokumentów, które powinny zostać stworzone w odpowiednich fazach projektu, ponieważ te dokumenty wyznaczają np. kierunek kolejnych kroków, jakie musimy podjąć, żeby dojechać do celu, to mogą być opisane konkretne przypadki biznesowe, raporty ze statusami, które mówią o postępie prac czy chociażby wymagania projektowe, mogą to być nowe dodatkowe specyfikacje, które pojawiają się w trakcie implementacji oprogramowania. Chcę też powiedzieć – jeszcze tak na poziomie ogółu – że dojrzałe organizacje zazwyczaj dążą do tego, żeby tworzenie dokumentacji projektowej odbywało się według jednakowego procesu, żeby wszyscy w organizacji wiedzieli, po co robimy dokumentację i jak często i jakiego rodzaju i w jaki sposób. I wypracowanie pewnego standardu przez project managerów w organizacji może bardzo pomóc, bo z góry będzie wiadomo, gdzie, kiedy, jaką dokumentację spłodzić, żeby nic ważnego nam nie uciekło.
Wciąż operując na poziomie pewnego ogółu, dlaczego dokumentacja projektowa jest ważna? Odpowiedzmy sobie na to pytanie. Pytanie wydaje się łatwe, ale gdy zastanowimy się nad tym dłużej, już tak łatwo nie jest. Wiele organizacji wciąż ma swego rodzaju ambiwalentne uczucie do prowadzenia dokumentacji projektowej. Dla jednych to jest wciąż superważne – ale tylko w teorii – dla innych to superważne i w teorii i w praktyce. Część firm – powiedziałbym, nawet project managerów – kocha, ale także jednocześnie nienawidzi przepalania czasu – a co za tym idzie, także pieniędzy – właśnie na robienie dokumentacji. I teraz – żeby być precyzyjnym – nie mówimy tutaj o robieniu kilku dokumentów, ale o wprowadzeniu do firmy na stałe pewnego procesu, który będzie drogowskazem dla wszystkich, gdzie i jak musimy budować dokumentację projektową. Nie chodzi mi o jednostkowe otworzenie laptopa, klepnięcie kilku dokumentów, wypchanie je na jakiegoś drive’a, na jakąś chmurę i tyle. Nie, chodzi o dobrze złożony proces, żeby takowa dokumentacja powstawała, co w dłuższej perspektywie przełoży nam się na szereg benefitów. I ktoś może powiedzieć: „Dobra, to dawaj te benefity”, to daję – przede wszystkim, dobrze prowadzona dokumentacja projektowa poprawi transparentność tego co i dlaczego to robimy. Kolejno, odpowiednio prowadzona dokumentacja da tobie, jako project managerowi, możliwość śledzenia postępu tego, co dzieje się w projekcie, ale także inne osoby będą mogły to łatwo sprawdzić – znów pewna transparencja. Dzięki dobrze prowadzonej dokumentacji – jeśli ktoś ci zada podobne pytanie – możesz być pewien, że widzisz na bieżąco, które zadania zostały już ukończone, a które czekają jeszcze w kolejce. Możesz też niemal natychmiast zareagować, gdy widzisz, że projekt schodzi z obranego kursu, a działania zespołu zaczynają się trochę rozjeżdżać z pierwotnym planem. I jeśli miałbym podawać argumenty dalej, to dzięki odpowiednio prowadzonej dokumentacji jesteś w stanie łatwo sprawdzić, czy wszystkie wymagania projektowe zostały spełnione. Przecież tak naprawdę projekty prowadzi się w oparciu o pewne wymagania – klientów, inwestorów, stakeholderów itd. A jeśli nie jesteś w stanie tego sprawdzić, to przynajmniej wiesz, które rzeczy wymagają jeszcze opieki np. deweloperów.
Dokumentacja pomaga ocenić projekt, gdy już jest skończony. To też jest benefit, o którym nie każdy pamięta. Ponadto, ocenianie samego projektu na końcu daje możliwość zebrania feedbacku i opinii od osób zaangażowanych w projekt, tzw. kontrybutorów, to jest takie bardzo ładne słowo. A to z kolei może wskazać słabości w naszym procesie – takie zebranie feedbacku i tych opinii – i tutaj już po nitce do kłębka – jak znamy słabości naszego projektu, naszego zespołu, to będziemy w stanie je wyeliminować przy okazji kolejnego projektu.
Jakie są jeszcze korzyści? Wiem, że pokrótce o nich wspomniałem. Ale poza benefitami są jeszcze pewne korzyści. Widzisz, tego jest więcej niż bylibyśmy w stanie wymyślić na poczekaniu. Otóż, kolejne korzyści z dobrze prowadzonej dokumentacji to to, że definiujesz cele projektu. Sam proces w ogóle robienia tej dokumentacji zmusza cię do zdefiniowania celów projektu. I tworzenie dokumentacji, żeby ustalić i spisać jasne cele projektowe powoduje, że wszyscy interesariusze, razem z tobą, będą mieli takie same oczekiwania wobec projektu. To definiowanie celów to jest niezwykle fajne zadanie, bo, ponadto, mając jasno sprecyzowane cele projektu, cały twój zespół inżynieryjny, zespół projektowy zyskuje poczucie, że wszyscy idziecie w tym samym kierunku. To dlatego już definiowanie celów na początku tworzenia dokumentacji projektowej jest zadaniem arcyważnym.
Dokumentacja jest też dość mocnym wsparciem w tej początkowej fazie planowania projektu. Każdy dokument ma swoją określoną funkcję i rolę, jaką odkrywa w dokumentacji projektowej. PM-owie często używają dokumentów projektowych, żeby tworzyć dokładny podział prac w strukturach zespołów. I nie chodzi mi o to, że managerowie siadają i mówią każdemu, co ma robić. Tak to nie wygląda. Chodzi mi bardziej tutaj o budowanie struktur, które udźwigną projekt. Przykładowo, wiedząc z dokumentacji, jak będą mniej więcej wyglądały kolejne etapy projektu, managerowie mogą zgłosić, np. ty, jako project manager możesz zgłosić zapotrzebowanie w zespole HR-owym na odpowiednią liczbę specjalistów, bo przecież wakaty trzeba otworzyć stosunkowo wcześnie, ileś miesięcy wcześniej, żeby pozyskać odpowiednie kompetencje do odpowiedniego etapu realizacji projektu. Dlatego dokumentacja powinna jasno określać, z jakimi technologiami przyjdzie nam pracować, dzięki czemu wiemy, jakich kompetencji w zespole będziemy potrzebować.
Poza tym masz łatwy podgląd na cały projekt. Jeśli wszystkie dokumenty projektowe są na bieżąco realizowane – a do takiej sytuacji dążymy – to wszyscy interesariusze mają w każdej chwili wzgląd w status projektu, lub też nie interesariusze, ale np. inni managerowie, którzy wyczekują zakończenia tego projektu.
Ta metoda bywa szczególnie przydatna project managerom, którzy pracują zdalnie, lub po prostu zespołom pracującym zdalnie. Tym bardziej ja sobie osobiście nie wyobrażam prowadzić projektu bez analizowania dokumentacji na bieżąco, gdy pracujemy w różnych strefach czasowych, to się wydaje karkołomne, w sensie, nierobienie tego wydaje się karkołomne.
Kolejna korzyść z prowadzenia dokumentacji projektowej to lepsze zarządzanie ryzykiem i problemami. Jednym z dokumentów projektowych, który przygotowuje project manager jest tzw. RAID. To jest akronim angielskich słów Risks Actions Issues oraz Decisions. I już samo tworzenie i aktualizowanie tego dokumentu przygotowuje ciebie, jako PM-a, na potencjalne ryzyka albo problemy, które mogą się wydarzyć w trakcie realizacji projektu.
I ostatnia wartość dodana, którą chciałbym przypomnieć to fakt, że z dokumentacją projektową sam projekt staje się swego rodzaju mierzalny. Mając ładnie spisane fazy projektu, zadania, jak też wskazane obłożenie każdego z członków zespołu, ryzyka, deadline’y, zyskujesz tak naprawdę pełną transparentność na temat tego, co dzieje się w projekcie. I dzięki tej wiedzy łatwiej jest mierzyć siły na zamiary, czyli w skrócie, czy w ogóle tobie i twojemu zespołowi uda się dowieść projekt na czas.
Odpowiedzieliśmy już sobie na pytanie, dlaczego warto prowadzić dokumentację projektową. Dlaczego warto ją ustawić w swego rodzaju proces, który jest stały w firmie i który jest nieomijalny, który jest wymagany. Ale teraz warto sobie odpowiedzieć na pytanie, co warto dokumentować. Niezależnie od tego, jak kształtują się struktury w twojej organizacji, umiejętność zapisywania i dokumentowania wszystkich aspektów projektu to czasem klucz do sukcesu w zarządzaniu projektem. Raporty, wykresy, dane, liczby, dokumenty, wnioski czy chociażby aktualizacje statusów powinny być utrzymywane na bieżąco przez cały cykl życia projektu. Jeśli poskładasz wszystkie te elementy w całość, to te puzzle ułożą się w piękny finał dowiezionego na czas projektu, którego jesteś przecież kapitanem. Jednakże twój czas, jako PM-a, jest ograniczony, co wszyscy wiemy, podobnie jak cierpliwość wielu organizacji do żmudnej, monotonnej czynności utrzymywania dokumentacji na odpowiednim poziomie. W związku z tym chcę rozszerzyć pytanie, które zadałem – „Co warto dokumentować?” i zapytać: „Co więc na pewno dokumentować, jeśli nie chcesz wykolejenia projektu po drodze?”. Przede wszystkim, dokumentujemy wszystko to, co związane z klientem. Wyobraź sobie, że pracujecie nad jakąś aplikacją od kilkunastu tygodni. Niech to będzie aplikacja do monitorowania ruchu gołębi pocztowych. To jest oczywiście wymyślony case, nie bierz tego na poważnie. Klientem jest Poczta Polska, chociaż to nieco patologiczny przykład, bo i sama Poczta Polska jest spółką dość patologiczną, w sensie biznesowym oczywiście. Ale wyobraźmy sobie, że to właśnie twój klient. Gdy powoli dobiegają końca wasze prace nad wersją MVP tej aplikacji, to klient – czyli Poczta Polska – nagle przychodzi i zmienia zdanie. Mało tego, kwestionuje decyzje, jakie zostały podjęte w ciągu ostatnich kilku miesięcy. Klient, w tym naszym wyimaginowanym przykładzie Poczta Polska, zarzeka się, że uzgodniliście z nim pewien kierunek rozwoju aplikacji, ale w czasie developmentu, nie wiedzieć czemu, poszliście w inną stronę. No i dupa. Sytuacja jest patowa, bo teraz słowo klienta jest przeciwko twojemu słowu – ty mówisz, że poszliście w dobrym kierunku, w tym ustalonym kierunku, a klient z końcem projektu mówi: „Chwila, nie tego oczekiwaliśmy”. I w tym momencie jasno i rzetelnie prowadzona dokumentacja oraz notatki ze spotkań z klientem, a poza notatkami także czas, daty, nazwiska uczestników spotkań, pomogą ci w krótkim czasie rozjaśnić wszystkie wątpliwości klienta. Nazywajmy to jak chcemy – prowadzenie takiej dokumentacji to może być nachalna biurokracja, może to być przesadna pieczołowitość, nieważne, w takiej sytuacji to twój najlepszy dupochron przed ryzykiem skonfliktowania się z klientem i wywalaniem projektu do góry nogami.
Co jeszcze na pewno powinniśmy dokumentować? Otóż kwestie prawne, które mają wpływ na projekt. W niektórych projektach departamenty prawne w firmie muszą stale przyglądać się i oceniać dokumentację projektową. Być może projekt, jaki realizujesz z zespołem jest bowiem wynikiem wygranego przetargu publicznego. Firmy IT często startują w przetargach, żeby zdobyć kontrakt na owocną, intratną i nierzadko wieloletnią współpracę z instytucją publiczną. To może być jednak miecz obosieczny, pamiętajmy o tym. Bo projekty, na które pieniądze idą z kasy publicznej muszą być i są obwarowane z każdej strony solidnie prowadzoną dokumentacją. W takich przypadkach, jako project manager, powinieneś znać wszystkie wymagania co do prowadzenia odpowiedniej dokumentacji, jeszcze zanim takowy projekt wystartuje. Jakakolwiek improwizacja na polu projektów z kasy publicznej – zwłaszcza gdy w grę wchodzą tematy realizowane np. dla rządu – to może być ryzykowny pomysł. Mówię o tej improwizacji – nie improwizuj na tym polu, tu musi być wszystko solidnie dogadane i udokumentowane. Dokładność i sumienność to są dwie cechy, z którymi w tym kontekście naprawdę warto się zaprzyjaźnić.
Co jeszcze na pewno warto dokumentować? Właściwą ilość procesów. I teraz, co to znaczy właściwą ilość, co to znaczy procesów? Wiadomo, że nikt z nas nie chciałby się zakopać po szyję w dokumentowaniu procesów, a przez to nie mieć czasu na właściwe prowadzenie projektu. To, czego w rzeczywistości potrzebujesz to jasnych wytycznych wokół planu projektu i celów. Powiedzmy to sobie bez owijania w bawełnę – nie ma sensu dokumentować każdego jednego procesu, jeśli nie przekłada się dokumentowanie tego na konkretną wartość dla projektu. Ja zawsze pozwalam dać się ponieść strukturze organizacji i jakoby poprowadzić mnie w tym, ile tak naprawdę rzeczy powinienem dokumentować. Tutaj bardzo ciężko surowo to ocenić, bo bardzo ważny jest ten kontekst firmy, w której pracujesz. To ty, jako project manager, musisz odnaleźć już ten balans pomiędzy liczbą rzeczy, które udokumentujesz a których nie udokumentujesz. Dobra rada: jeśli nie jesteś pewien, czy coś powinno się znaleźć na papierze, to albo zapytaj, a jeśli wciąż nie uzyskasz odpowiedzi, to lepiej to zrób, lepiej udokumentuj. Natomiast gdy liczba dokumentów zacznie cię przytłaczać, to jest duże prawdopodobieństwo, że także inni zaczną się gubić w tej dokumentacji. Wtedy to jest jasny sygnał, żeby zacząć optymalizować dokumentację projektową, jaką prowadzisz.
Rzeczy, które jeszcze na pewno warto dokumentować w projekcie to są zmiany projektowe. Skrajny przykład: gdy zmienia się cel projektu, to nie mamy do czynienia z kosmetyczną zmianą, a ze zmianą strategii. I taką zmianę celu projektu nie tylko trzeba wykazać w dokumentacji, ale też jasno zakomunikować zespołowi. Bo, umówmy się, pracujecie nad czymś miesiąc, dwa, nagle zmienia się cel – to jest cholernie ważne. Tutaj już, bez owijania w bawełnę, trzeba coś z tym zrobić. Nie chcę się rozgadywać w tym punkcie, bo tutaj dużo zależy od twojego wyczucia projektu. Jeśli czujesz, że na którymś ze spotkań zapadła jakaś decyzja, która potencjalnie może wpłynąć bezpośrednio na dalszą część projektu, na jego estymację, czas trwania, na rezultat końcowy – zwłaszcza jeśli to projekt za hajs publiczny – to wrzuć to do dokumentacji projektowej i nawet wyszczególnij dla transparentności. Naprawdę, tobie się nic nie stanie, a będziesz z pewnością lepiej sypiał.
Nie chcę przechodzić na pewno przez najważniejsze rodzaje dokumentów, których może potrzebować projekt, tych najbardziej krytycznych dokumentów jest osiem, może dziewięć, z tego co pamiętam, zostawię to sobie na osobny podcast. Zahaczmy jednak na koniec właśnie o to, jak wyglądają te najlepsze praktyki w prowadzeniu dokumentacji. I nie chodzi tylko o to, żeby dokumentacja powstawała i miała się dobrze, ale żeby była dla nas swego rodzaju artefaktem, który zwiększy naszą efektywność i usprawni działanie projektu, działanie zespołów projektowych.
Na pewno warto – pierwsza dobra praktyka – dać sobie wystarczająco dużo czasu, do tego wykorzystuj swój kalendarz. Wiele osób myśli, że kalendarz to jest narzędzie tylko do umawiania spotkań. Nieprawda. Użyj swojego kalendarza i zarezerwuj sobie dwu-, trzygodzinne sloty każdego tygodnia, żeby zebrać do kupy wszystkie potrzebne dokumenty i je zaktualizować. I zamiast przepalać te kilka godzin na kolejny call albo spotkanie ze współpracownikiem schowaj się w samotni ze swoim laptopem, wyłącz powiadomienia na komunikatorze firmowym i daj sobie ten czas, żeby w skupieniu popracować indywidualnie nad dokumentacją. Ja mam takie bloki wbite niemal codziennie na stałe w kalendarz – jedne krótkie, 30-minutowe, inne dłuższe, nawet dwugodzinne, żeby móc skupić się na pracy indywidualnej. I podobnie możesz sobie także wrzucić stały blok czasowy, np. na każdy piątek, niech to będzie 10-15 minut luzem, żeby jedynie przejrzeć dokumentację i zobaczyć, czy coś nie wymaga uaktualnienia. Bo nie każda dokumentacja musi być z tygodnia na tydzień aktualizowana, nie wszystkie projekty posuwają się w tak dynamicznym tempie do przodu.
Druga dobra praktyka, którą chcę się z tobą podzielić to to, żeby ustalić sobie właściwy poziom szczegółowości takiej dokumentacji. Tworzenie dokumentacji projektowej dla inżynierów jest zupełnie czymś innym niż tworzenie dokumentacji projektowej dla zarządu albo wyższego kierownictwa. Inżynierowie – co wydaje mi się jasne – potrzebują więcej szczegółów, które tym im możesz dostarczyć, natomiast wyższy management nie ma czasu na to, żeby się taplać w szczegółach, technikaliach, jakichś kosmetycznych decyzjach. Obie strony, inżynierowie i wyższy management, chcą konkretów, ale o innym poziomie granulacji. Od ciebie zależy, jak dostosujesz skalę szczegółów do swoich odbiorców. Jeśli zrobisz to dobrze, uwierz mi, twoi odbiorcy na pewno będą ci za to bardzo wdzięczni.
Trzecia dobra praktyka to to, żeby korzystać ze sprawdzonych narzędzi do przechowywania dokumentacji. Twoja dokumentacja powinna być dla innych bardzo łatwa do namierzenia. Upewnij się zatem, że macie w firmie odpowiednie repozytorium do trzymania takiej dokumentacji. I z mojego doświadczenia dodam jedynie, że Dysk Google nie jest idealny – chociaż jest darmowy, dlatego wiele startupów korzysta z Dysku Google, bo jest taniej – w większości projektów, które ja prowadziłem w przeszłości mi idealnie sprawdzał się Confluence, obecnie również z niego korzystam jako product manager. Podobnych narzędzi na rynku jest sporo, tak że zachęcam, porozmawiaj ze swoimi przełożonymi, porozmawiaj ze współpracownikami i wynegocjujcie dla siebie takie repozytorium, z którego każdy będzie potrafił korzystać i będzie spełniać wymagania w waszej organizacji. Nigdy nie chomikuj dokumentacji projektowej u siebie na dysku lokalnym. Ktoś ci podwinie laptopa w restauracji i jest dupa. Nie można tak robić. Nigdy lokalnie, trzymamy dokumentację tam, gdzie jest także dostępna dla odpowiednich osób w organizacji.
I ostatnia, czwarta dobra praktyka na dziś to: warto udostępniać dokumentację innym i współtworzyć ją z nimi. Tam druga część tego zdania jest superważna – żeby współtworzyć ze współpracownikami właśnie takową dokumentację. Zdziwiłbyś się, ile osób czyta dokumentację biznesową, przepraszam, projektową, aczkolwiek biznesową także. Ja wielokrotnie byłem zdziwiony, że ktoś rzeczywiście sięgał po dokumenty, które tworzyłem. Oczywiście, wiele osób, wielu PM-ów, także wielu inżynierów nie lubi tworzyć dokumentacji projektowej, ale za to uwielbiamy otrzymywać paczki dokumentów, które są wręcz skrojone według naszych potrzeb. Ja uwielbiam, jak dołączam do nowej organizacji i pytam, czy macie jakąś dokumentację o tym projekcie, co mógłbym poczytać i dostaję paczkę skrojoną pode mnie, pod moją specjalizację. Czuję wtedy dość ogromną ekscytację tym, że ktoś naprawdę podjął ten trud i zrobił tak świetną dokumentację, z której ja mogę teraz czerpać garściami. Szczerze polecam jak najczęściej udostępniać tworzone dokumenty innym tak, żeby mogli je współtworzyć, albo chociaż zostawiać w nich swoje komentarze. I to jest ważne. Tę dokumentację tworzysz dla ludzi, nie dla siebie, więc warto zbierać feedback właśnie od tych ludzi, od innych osób jeszcze na etapie tworzenia tej dokumentacji. W moim zespole to się świetnie sprawdza, gdy czasem pracujemy w kilka osób na jednym drafcie, a po kilku dniach, przykładowo, mamy gotowy finalny dokument, który już wtedy możemy pokazać pozostałym osobom w zespole.
To wszystko na dziś. Nie ukrywam, że jestem jednocześnie zmęczony, bo ten temat już na etapie researchu i tego, co chciałem dziś opowiedzieć był dość wymagający, żeby zawrzeć jak najkrócej, w pigułce tylko te rzeczy, które w rzeczywistości przełożą się na wartość dla ciebie i twoich zespołów. Z drugiej strony wiem, że ja jedynie skubnąłem dziś temat, ja go jedynie musnąłem w policzek i na pewno będzie jeszcze kontynuacja dokumentacji projektowej. Ja będę rozbijał na czynniki pierwsze każdy z dokumentów, jaki project managerowie tworzą, żeby usprawniać, przyspieszać też efektywność i w ogóle działalność zespołów projektowych.
Super dzięki za odsłuch tego odcinka. Mam nadzieję, że mój bełkot nie zniechęci cię do wysłuchania kolejnego epizodu, który będzie już wkrótce. Jeśli mogę jeszcze jakoś pomóc, to zachęcam do konsultacji jeden na jeden, info znajdziesz na moim blogu bycjakmanager.pl, w zakładce „konsultacje”. Jeśli jest coś, co mogę poprawić w moich podcastach, zachęcam do podrzucenia mi feedbacku na moich mediach społecznościowych – LinkedIn, Instagram, Facebook, YouTube. Do usłyszenia wkrótce. Dbaj o siebie i innych. Cześć!
KONIEC
Źródła
https://www.projectmanager.com/blog/great-project-documentation
https://filestage.io/blog/project-documentation/
https://www.simplilearn.com/project-documentation-article
https://www.tacticalprojectmanager.com/essential-project-documents/