Z tego podcastu dowiesz się:
- Czym jest dokumentacja projektowa
- Z jakich etapów często składa się projekt
- Jak zarządzać procesem tworzenia dokumentacji
- Które narzędzia wybierać (Excel, Word, a może Power Point?)
- Czy Project Manager musi tworzyć wszystkie dokumenty
- Czym są tzw. „Minutki„
- Po co tworzyć streszczenie projektu
- Jak ustalać zakres prac
- Kiedy cel jest SMART
- Co należy zrobić zanim projekt wystartuje
Szablony do pobrania
- Minutki
- Streszczenie Projektu
- Zakres Prac
- Plan Zasobów
- Cele SMART
- Dziennik Decyzji
- Dokumentacja Projektowa
Transkrypcja podcastu
Być Jak Manager. Podcast epizod 29.
Dzień dobry. Powoli wiosna zagląda mi przez okna, a nagrywam to w drugiej połowie kwietnia 2023 r. Nie ukrywam, że kwiecień, taki jaki ja pamiętam z dzieciństwa, wyglądał zupełnie, zupełnie inaczej; w sensie takim, że na śmigusa-dyngusa biegaliśmy już w szortach i T-shirtach lejąc wodą przypadkowo napotkane dziewczyny. W obecnych czasach ciężko jest sobie wyobrazić śmigus-dyngus z zimnych kubłem wody na głowie z uwagi na niskie temperatury jakie mamy w tym miesiącu, natomiast my tu gadu-gadu o pogodzie.
Dla ciebie drogi słuchaczu, jeżeli jesteś tutaj przypadkiem lub po raz pierwszy przypomnę, że mój podcast kieruję do szeroko pojętej branży menadżerskiej w IT: product owner’ów, analityków biznesowych, project managerów i tutaj moja najbliższa specjalizacja – product managerów.
Dziś poopowiadamy sobie trochę więcej o dokumentacji projektowej, ale z innej strony. Powiem oczywiście dlaczego tak ważna jest dokumentacja w projekcie, ale powiem o tym w dużym uproszczeniu i wielkim skrócie, bo o tym jest już osobny podcast – podcast nr. 21 pod tytułem „Po co nam dokumentacja w projekcie?” Jeśli jeszcze, drogi słuchaczu, nie słyszałeś tamtego epizodu to serdecznie zachęcam, żeby go odsłuchać.
Ja postanowiłem w jednym miejscu opisać i udostępnić 7 szablonów dokumentów. 7 szablonów, które według mnie mogą pomóc tobie, wszystkim tak naprawdę, project managerom. Także dziś temat naprawdę dotyczący zarządzania projektem, nie produktem, chociaż też pewnie będziemy skubać różnych aspektów szeroko pojętego zarządzania w IT. I co teraz nastąpi? Ja zaraz opowiem kolejno o każdym z siedmiu szablonów pomocnych w kierowaniu projektem. Szablony będę opisywał w taki sposób, że nie musisz ich widzieć, ani na nie patrzeć, żeby zrozumieć jaką wartość do twojej pracy mogą wnieść te dokumenty. Także jeśli słuchasz tego podcastu np. jeżdżąc na rowerze, czy jadąc samochodem, albo ćwicząc na siłowni no to uspokajam – nie musisz oglądać wideo, sam dźwięk w zupełności wystarczy. Wszystkie szablony z dzisiejszego podcastu znajdziesz na moim blogu bycjakmanager.pl pod epizodem nr. 29. Tak, to dzisiejszy epizod. Pamiętajmy, że rodzajów dokumentacji projektowej jest od groma. Naprawdę liczba jest ogromna. Dzisiaj dotkniemy jedynie skrawka tej materii, a już to, z których szablonów dokumentów zechcesz skorzystać w przyszłości wynikać będzie na pewno ze specyfiki i twojego projektu, ale także będzie to zależeć od twoich osobistych preferencji. Lecimy zatem z tematem, a gdyby zaszła taka potrzeba to przypomnę, że jestem do twojej dyspozycji w ramach moich konsultacji 1:1, na które możesz zapisać się przez wspomnianą stronę bycjakmanager.pl i zachęcam gorąco do zapisania się na newsletter. Moi stali słuchacze już to wiedzą, że nie handluję czyimiś adresami mailowymi, ani imieniem. Wysyłam tylko i wyłącznie update’y dotyczące podcastów.
Czym jest dokumentacja projektowa? Jeszcze zanim zaczniemy rozmawiać o tych szablonach, jakie dla ciebie przygotowałem. Opowiedzmy sobie o tym w dwóch zdaniach, chociaż odpowiedź na to pytanie może być dla wielu osób oczywista. Gdybym miał stworzyć taką uniwersalną, wręcz encyklopedyczną definicję dokumentacji projektowej to powiedziałbym, że to jest każdy stworzony dokument, który w szczegółach opisuje pewne kroki podejmowane w trakcie cyklu życia projektu lub po prostu pewne etapy, przez które przechodzimy w czasie realizowania projektu. Jeśli zgodzilibyśmy się z taką definicją to takimi etapami w projekcie mogą być na przykład: ustalenie zakresu całego projektu, zebranie i opisanie wymagań technicznych oraz biznesowych, planowanie, development lub po prostu implementacja, zarządzanie zmianami w projekcie, ocena nazywana też szacowaniem oraz, przykładowo, zamknięcie projektu i podsumowanie go w raportach.
A teraz wyobraź sobie, że przez poszczególne etapy mielibyśmy przechodzić bez dokumentowania zmian i jakichkolwiek ustaleń. Zdradzę pewien fakt ze swojej przeszłości zawodowej. Kiedyś próbowałem sił z przyjaciółmi, z którymi rozwijałem startup bez prowadzenia odpowiedniej dokumentacji. Powiem tak: dziś tego startupu już nie ma, co też wiele tłumaczy. Nie twierdzę, że brak dokumentacji był główną przyczyną naszej porażki, ale na pewno byłoby to dużo łatwiejsze i profesjonalne gdybyśmy taką dokumentację wtedy tworzyli od samego początku. Dobrze prowadzona dokumentacja pomaga w kolaboracji, poprawia ogólną, wspólną współpracę z zespołem, zarządem, kierownictwem czy klientami. Głownie dlatego, że ty oraz inne decyzyjne osoby w projekcie zawsze macie jedno oficjalne źródło prawdy, do którego można zajrzeć, gdy czujesz jakby, że potrzebujesz dodatkowych informacji przed podjęciem jakiejś ważnej decyzji w projekcie. Nie chcę za bardzo rozwijać się przy tym punkcie, bo tak jak wspomniałem, na moim blogu pojawiały się już wcześniej tematy związane z dokumentacją i zawsze można sobie tam te treści wyklikać. Uznajmy więc w tym miejscu, że ja i ty rozumiemy i zgadzamy się, że dokumentacja w projekcie jest po prostu zajebiście ważna. Dziękuję i tyle.
Zanim przejdziemy do mięsa to chcę jeszcze wspomnieć o tym, o czym dotychczas nie mówiłem, mianowicie jak zarządzać tym całym procesem tworzenia dokumentacji. Nawet najlepsze szablony do prowadzenia dokumentacji pójdą do kosza, jeśli ty i pozostali członkowie twojego zespołu nie będziecie potrafili taką dokumentacją zarządzać. Także zapamiętaj proszę 4 proste zasady; 4 zasady, które pomogą tobie zbudować odpowiedni proces zarządzania dokumentacją projektową.
Zasada nr. 1 – twórz dokumenty z wyprzedzeniem. Jeśli mówimy o idealnym świecie, a do takiego dążymy, nawet jeśli wydaje się nieosiągalne, to idealną sytuacją jest, gdy zawsze masz oko na to, gdzie obecnie ty i twój zespół jesteście z projektem. Podobnie idealną sytuacją byłoby, gdyby odpowiednie dokumenty były gotowe z wyprzedzeniem. To mogą być dokumenty napisane z użyciem różnych narzędzi dostępnych na rynku. To może być Word, może być Excel, dokumenty Google, czy nawet PowerPoint. Wybierz taki dokument, taki typ dokumentu, który najlepiej pasuje do konkretnego procesu, albo wydarzenia jakie chcesz opisać, np. jeśli w projekcie pojawia się ryzyko to bardzo często najlepszym sposobem zobrazowania ryzyka będzie tabelka, a skoro tabelka to Excel zrobiłby tutaj potencjalnie dobrą robotę, albo ten Excel googlowski, też na pewno znasz. Gdy przygotowujesz dokumenty odpowiednio wcześniej to oczywiście to wymaga pewnej dyscypliny, ale gdy przygotujesz te dokumenty odpowiednio wcześnie to nie musisz pospieszać procesu tworzenia tej dokumentacji później. W sensie nie musisz tego robić na ostatnią chwilę i nie czujesz takiego ścisku, gdy dzieją się już istotne rzeczy w projekcie. Ja jestem ogromnym fanem tego, żeby inwestować odpowiednią ilość czasu w lepszą organizację pracy swojej, ale też pracy całego zespołu. Nie bój się tego i daj sobie tyle przestrzeni, ile potrzebujesz, żeby tworzyć dokumenty odpowiednie do kontekstu biznesowego oraz takie, które spełniają najwyższe standardy.
Zasada nr. 2 – zasada druga to ustanowienie tworzenia dokumentacji stałym elementem procesu waszej pracy. To nie może być dodatek, to nie jest wisienka na torcie. Utrzymywanie i aktualizacja dokumentacji w projekcie wymaga pewnej systematyczności. Po co komu dokumentacja, która jest przestarzała, albo nieaktualna? To, co ja robię, żeby pamiętać o aktualizowaniu dokumentów to ustawiam sobie zawsze w kalendarzu cykliczne przypomnienia. Niektóre dokumenty aktualizuję raz na tydzień, niektóre raz w miesiącu – to zależy od kontekstu. Dzięki temu mam pewność, że przynajmniej te najważniejsze rzeczy dla projektu są w miarę regularnie opisywane w dedykowanych do tego miejscach.
Zasada nr. 3 – zasada ta mówi o tym, żeby tworzoną dokumentację udostępniać innym, innym osobom, współpracownikom, żeby ją ocenić a następnie zaakceptować jako grupa. Niezależnie od tego jaki szablon dokumentów wybierzesz, korzystaj z niego w jak najbardziej elastyczny sposób, żeby dokument pomógł tobie i zespołowi np. zgromadzić w jednym miejscu wymagania biznesowe. A co to znaczy w elastyczny sposób? A no w taki, gdzie nie narzucasz pozostałym osobom sztywnych reguł jak podchodzić do tworzenia tego lub innego dokumentu. Ja sam zawsze staram się rozpocząć jedynie tworzenie dokumentu, ale już to co finalnie powstanie to staram się, aby to była wspólna praca moja i osób, które zaprosiłem do rozmów. Staram się jakby aktywizować ludzi wokół mnie, żeby pomogli mi stworzyć pewien dokument. Wtedy wychodzą naprawdę bardzo fajne warsztaty, bardzo fajne sesje i bardzo fajne dyskusje, gdy próbujemy razem taki dokument stworzyć. Zachęcam, żeby pierwszą wersję dokumentu zawsze udostępniać innym z możliwością zostawiania komentarzy, a nawet czasem z możliwością edycji i w ten sposób już samo tworzenie dokumentacji może być naprawdę bardzo fajnym warsztatem dla waszego zespołu projektowego. Także ty jako PM często rozpoczynasz proces tworzenia tego lub innego dokumentu, ale już dalsze prace najczęściej spoczywają na barkach waszego zespołu. O tym też sobie powiemy. Oczywiście w ramach dobrej organizacji pracy powinieneś także dbać o to, aby utrzymywać taką dokumentację, jeśli projekt lub produkt może na tym zyskać.
I zasada 4 – zasada 4 mówi o tym, żeby zapisać, ale też zarchiwizować dokumentację projektową. Niektóre projekty mają swój początek i koniec. W sumie to wszystko ma swój początek i koniec, ale w różnych odstępach czasu, nie? Jeśli coś w twoim projekcie się kończy, żeby coś innego mogło się rozpocząć to pamiętaj, żeby zawsze zapisać i, co najważniejsze, zarchiwizować dokumentację tak, żeby w przyszłości zawsze można było do niej wrócić. Ponadto archiwizując dokumentację dla danego projektu spinasz wtedy wszystko ładnie klamrą i przygotowujesz siebie, ale też zespół na kolejne wyzwania. Dlaczego ta zasada jest taka ważna, że ująłem ją w tej mojej wielkiej czwórce? Ponieważ pozostawienie dokumentacji w miejscu, w którym wkrótce pojawi się nowa, inna dokumentacja może powodować śmietnik. Nie warto trzymać bieżącej dokumentacji w jednym koszyku z archiwalnymi dokumentami, bo wtedy zwiększamy skalę chaosu tudzież takiego projektowego bałaganu i ty albo PM, który przyjdzie po tobie będzie musiał to ogarniać.
No dobra, a teraz już po tym, gdy znasz te 4 złote zasady zarządzania dokumentacją przejdźmy do szablonów, które dziś dla ciebie przygotowałem. Omówię każdy z nich, czyli co zawiera i gdzie potencjalnie moglibyśmy go wykorzystać. Szablony, co przypominam raz jeszcze, dostępne są do pobrania za darmo na moim blogu bycjakmanager.pl przy wpisie z dzisiejszym podcastem i coś co może się okazać przydatne, ale nie musi to to, że każdy szablon przygotowałem dla ciebie w dwóch wersjach – w wersji polskiej oraz w wersji angielskiej. To też odpowiedź na potencjalne pytania od moich słuchaczy jakie dostaję, czyli dlaczego trzeba tak długo czasem czekać na niektóre podcasty – bo ja to staram się robić pieczołowicie i zawsze dać taką jakąś wartość ekstra, której nie musiałbym dowozić, ale jednak staram się. Mam nadzieję, że to zostanie prędzej czy później docenione. Chociaż część z was już naprawdę bardzo to docenia. Zachęcam do korzystania oczywiście z angielskiej wersji, aczkolwiek jak pracujesz w zespole tylko polskojęzycznym to polskie wersje tych szablonów mogą przynieść tobie być może nawet więcej pożytku.
Pierwszy szablon przyda się nie tylko kierownikom projektu, ale każdej osobie, która z racji pełnionej roli w firmie często organizuje spotkania. Notatki ze spotkania – czyli tzw. minutki. Ja będę się odnosił tutaj do polskich wersji tych szablonów, więc niektóre nazwy, chociaż brzmią śmiesznie, żeby nie powiedzieć idiotycznie w języku polskim, no to jednak tutaj na potrzeby myślę po polsku, żyję po polsku i swój podcast prowadzę po polsku, więc staram się to tłumaczyć, ale też zawsze podkreślam, że jestem jednak większym fanem pracy w języku angielskim i komunikowania się ze współpracownikami właśnie w tymże języku, ponieważ angielski, chociaż nikt tego nigdy nie napisał i nie powiedział oficjalnie, jest pewnym takim umownym, globalnym językiem całej branży IT. Minutki – w spotkaniach, chociaż mogłoby się wydawać inaczej, nie chodzi tylko to, żeby się spotkać, miło porozmawiać i przepalić czas na pogawędkę bez ustalenia konkretnych rzeczy i ewentualnych działań, jakie trzeba podjąć w zespole. Niestety wciąż, mówię niestety, zdarzają się takie spotkania, w czasie których uczestnicy pogadają, pogadają, a następnie wrócą do swoich zajęć i tyle. Po jakimś czasie znów się spotykają i rozmawiają o tym co udało się osiągnąć w ostatnim czasie i tu pojawia się problem, bo mało kto pamięta kto co tak naprawdę miał zrobić. Dochodzi czasem do nieporozumień, bo jeden członek zespołu twierdzi, że to jego kolega z teamu miał coś sprawdzić, z kolei ten kolega nie przypomina sobie, że coś zostało mu oddelegowane i tak sobie można rozmawiać i rozmawiać, a robota się sama nie zrobi. Dobrą praktyką jest prowadzenie notatek ze spotkań. Chodzi o krótki zapis tego co, z kim i kiedy ustalono. Niby proste, ale żeby jeszcze bardziej ułatwić sobie życie to często spisuje się tzw. minutki. Najlepiej na początku spotkania wyznaczyć osobę, która sporządzi taki krótki dokument. Nierzadko tą osobą jest właśnie organizator spotkania lub jakiś kierownik projektu, albo lider zespołu, który wyręcza w tym organizatora spotkania. Na moim szablonie minutek umieściłem następujące pola: sekcja ogólna, w której wpisujesz datę oraz miejsce spotkania. Najczęstszym miejscem są ostatnio video konferencje, także możesz po prostu wpisać spotkania online. Ponadto warto wpisać nazwę spotkania oraz organizatora spotkania. W osobnej kolumnie warto wypisać osoby zaproszone na spotkanie z podziałem na tych, którzy byli obecni oraz na tych, którzy nie dotarli. Nie wnikajmy w szczegóły nieobecności, bo to nie ma większego znaczenia – nieobecni to nieobecni i tyle nam wystarczy. Często poważnym błędem komunikacyjno-organizacyjnym jest brak agendy dla organizowanych spotkań. Warto zawsze w kilku punktach stworzyć taką agendę na potrzeby spotkania. Wtedy dajesz sobie oraz innym poczucie dobrej organizacji, dobrego prowadzenia projektu, a przy okazji, mówiąc językiem sejmowym, pilnujesz porządku obrad. Także w moim szablonie minutek również znajdziesz miejsce na agendę. Poza agendą dodałem też osobną tabelę, żeby wypisać w krótkich punktach jakie rzeczy omówiliście w czasie spotkania. To co polecam tobie robić, gdy będziesz tworzył minutki to to, żeby tworzyć je na bieżąco w czasie spotkania. Możesz nawet udostępnić ekran pozostałym uczestnikom spotkania i robić notatki tak, żeby inni mogli je komentować i podpowiadać tobie co warto w nich wpisać. Umieściłem również osobne pole, pojedyncze dla wniosku ze spotkania, jednego wniosku i to pole nie jest jakoś superważne, ale jeśli spotkanie dotyczyło np. jednego konkretnego tematu to może warto również podsumować całość jednym zdaniem. Ostatnia sekcja, czyli tzw. action pointy. po polsku zatytułowałem te sekcje „do zrobienia” i tak jak wszystkie poprzednie pola można śmiało pominąć, tak tutaj polecam zwrócić szczególną uwagę na to kto i jakie zadania, czynności powinien podjąć, żeby zadziało się to, co wspólnie ustaliliście na spotkaniu. Formuła przepisywania zadań jest bardzo prosta. Piszesz krótko co jest do zrobienia, a następnie decydujecie w waszym gronie kto podejmie się realizacji tego zadania i przypisujecie nazwisko osoby właśnie przy tym zadaniu i tyle.
Kolejny szablon, jaki dla ciebie przygotowałem, na pewno przyda ci się w zebraniu wszystkich najważniejszych rzeczy o projekcie w jednym miejscu. Ja lubię taką organizację, lubię sam siebie dyscyplinować, żeby gdzieś tam nawet na boku tylko wewnętrznie dla siebie notować wszystko co dzieje się w projekcie. Chodzi bowiem o streszczenie projektu, czyli tzw. brief. Tutaj krótko i na temat, bo właśnie tak ma wyglądać ten dokument. Chodzi o to, aby project manager zawsze miał pod ręką dokument, w którym jak najbardziej skrótowo opisane są najważniejsze rzeczy dotyczące projektu. W związku z tym w szablonie znajdziesz 6 następujących akapitów: „nazwa projektu”, „o projekcie”, „cele projektu”, „o zespole”, „zakres prac” oraz „oś czasu”. Przejdźmy sobie pokrótce przez każdy z tych punktów – „nazwa projektu” – tutaj nic wyjaśniać nie trzeba. Akapit „o projekcie” dosłownie w jednym lub dwóch zdaniach napisz kto zainicjował projekt, czego ten projekt dotyczy i dlaczego właśnie ten projekt został zainicjowany. Cele projektu – w tym paragrafie wypisz chociaż jedno lub dwa najważniejsze cele jakie chcecie zrealizować w ramach tego projektu. Jeśli uznasz to za superważne to możesz tych celów wypisać więcej, ale nie za dużo, chociaż możesz je nawet rozbić na jakieś mniejsze kamienie milowe. Pamiętaj tylko tym, że to ma być streszczenie, a nie epopeja o zarządzaniu projektem. Akapit „o zespole” natomiast, jak sama nazwa wskazuje, jest o zespole. Super, jeśli zgadłeś. Przedstaw w tym miejscu jakby ogólny zarys zespołu, który jest albo będzie zaangażowany w projekt. Opisz dotychczasowe poszczególne kompetencje w tym zespole, specjalizacje zespołu oraz to, co ten zespół chce osiągnąć w ramach projektu. Warto wypisać także zakres odpowiedzialności zespołów w projekcie, czyli za co ten konkretny zespół będzie odpowiadał. Upewnij się, to ci pomoże, że wskazałaś lidera, albo osobę kontaktową, do której można adresować pytania w czasie trwania prac nad projektem. Tyle jeśli chodzi o brief, czyli streszczenie projektu. Przejdźmy teraz to bardziej „mięsistej” partii ciała kierowniczego jakim jest udokumentowanie zakresu prac w projekcie. Zakres prac w projekcie, tzw. SOW, S-O-W to z angielskiego Scope of Work, czyli zakres prac. To jest cholernie ważny dokument. W sumie nie tyle sam dokument co czynność jaka się za nim kryje. Otóż bardzo wiele nieporozumień w trakcie trwania projektu, ale też przy oddawaniu wytworzonych dóbr klientowi rozbija się o to co tak naprawdę wchodziło w zakres prac. Nierzadko bowiem okazuje się, że po kilku miesiącach, kiedy kończy się projekt, to któryś z interesariuszy, albo klientów nagle podnosi rękę i mówi „ale chwila, to to i tamto nie zostało zrobione” i nagle zapada martwa cisza. Okazuje się, że na ten sam projekt zespół developerów oraz klient patrzyli w nieco inny sposób. Przypadków takich nieporozumień można mnożyć, ale w skrócie chodzi o to, że klient spodziewał się więcej, a rzekomo dostał mniej. I teraz ty, jako PM, musisz zawsze dokumentować najważniejsze ustalenia pomiędzy twoim zespołem, a osobą, dla której realizujecie projekt. Jednym z takich kluczowych ustaleń jest właśnie zakres prac, czyli Scope of Work. Dokumentowanie takich ustaleń może przybierać oczywiście różne formy. Najprostszą z nich jest bodajże nagranie spotkania z klientem, jeżeli jest to spotkanie online lub wysłanie notatki na mailu po takim spotkaniu z listą rzeczy jakie ustaliliście. Aczkolwiek szablon, który dla ciebie przygotowałem pomoże ci uniknąć nieporozumień i niemalże poprowadzi cię za rączkę w czasie ustalania zakresu pracy klientem. Templatkę otwiera tabelka, w której wpisujesz standardowe informacje przy tego typu dokumentach, tj. nazwa projektu, nazwa firmy, która zleca projekt, miejsce realizacji projektu, imię, telefon, e-mail osoby kontaktowej po stronie klienta, a w polu „manager” wpisujesz prawdopodobnie siebie jako kierownika tego projektu. Na końcu data sporządzenia dokumentu. W pierwszym oknie zaraz pod informacjami ogólnymi, tak jak mówiłem, nie musisz widzieć tego dokumentu, to nie jest teraz istotne, natomiast warto opisać także zaraz poniżej w kilku zdaniach ogólny zakres prac, które podejmie twój zespół albo zespoły, którymi zarządzasz w ramach projektu. Jeśli nie wiesz od czego zacząć opisywanie zakresu prac to możesz zacząć czymś w rodzaju „realizacja projektu przyniesie klientowi …” albo „niniejszy projekt realizowany jest, aby …” i dalej wypisujesz co ma przynieść ten projekt. Skup się na tym co najważniejsze, nie wypisuj jeszcze dokładnych rzeczy jakie dowieziecie w ramach projektu, bo na to jest osobna dedykowana przestrzeń także w tym samym szablonie, a ta przestrzeń to kolejna tabelka naszej templatki, gdzie należy opisać w punktach wyniki prac. W angielskim szablonie lepiej się to nazywa, bo to jest outcome, albo deliverables, czyli, no dobra, to jest nieprzetłumaczalne, to są rzeczy, które dowieziecie. Chodzi tutaj o wypunktowanie produktów albo usług, które zostaną dostarczone w ramach projektu. Przykładowo – jeśli pracujecie nad jakąś aplikacją do składania zamówień w sklepie internetowym to warto w punktach wypisać co zostanie zrealizowane, np. aplikacja mobilna na system Android zawierająca funkcjonalności opisane w załączniku nr. 1 do umowy z klientem. Dokumentacja techniczna zawierająca dokładny opis całej architektury aplikacji, projekty oraz inne materiały interaktywne takie jak materiały wideo lub klikalne prototypy jakie powstały w trakcie tworzenia aplikacji, itd., itd. Nie ukrywam, że im dokładniej opiszesz rzeczy, które powinniście dowieźć jako zespół, tym lepiej zabezpieczysz siebie i firmę przed ewentualnymi nieścisłościami w późniejszych etapach prac, ale też nie pisz elaboratu. Uczulam na to. Jeśli coś wymaga rozwinięcia lepiej stworzyć do tego załącznik i tam to opisać, a w tym ogólnym dokumencie o zakresie prac jedynie odesłać do odpowiedniego załącznika. Dodałem też do szablonu tabelek, gdzie możesz wypisać co na pewno nie wchodzi w zakres projektu. Czasem klient naciska na pewną rzecz, żeby ją upchać w ramach projektu. Ja mówię „w ramach projektu”, ale klient myśli sobie „w ramach tego samego budżetu”, ale wasz zespół wie, że nie będzie tego w stanie zrealizować w ustalonym czasie i za ustalone pieniądze. Warto już na etapie ustalania szczegółów projektu wyraźnie zaznaczyć to co znajduje się poza zakresem prac. Masz do tego wyznaczone miejsce w szablonie tak, żeby nie zapomnieć. Inną, myślę, że równie ważną sekcją w dokumentowaniu zakresu projektu jest zdefiniowanie pewnych kamieni milowych. Kamienie milowe są o tyle ważne, że pomagają rozbić tego kloca, ten monolit zwany projektem, na pewne mniejsze etapy. Nie zapominajmy tutaj o interesariuszach i sponsorach projektu, którzy lubią być i najczęściej chcą być informowani na bieżąco o postępach prac w projekcie. I kamienie milowe to jest taki idealny pretekst do tego, żeby co jakiś czas odtrąbić sukces na spotkaniu z klientem i pochwalić się, że zespołowi udało się właśnie osiągnąć kolejny kamień milowy, którym jest zrobienie tego czy tamtego. Dzięki kamieniom milowym ty także możesz łatwiej i sprawniej monitorować postępy w projekcie i na pewno łatwiej też samemu zespołowi nawet na etapie wyceniania projektu estymować najpierw poszczególne kamienie milowe, a nie od razu cały projekt. Także superprzydatną praktyką jest wpisanie kamieni milowych do zakresu prac, żeby było jasne na jakich etapach realizowany będzie projekt.
Przedostatnim punktem formalnym będzie udokumentowanie wszystkich interesariuszy projektu. Oczywiście masz do tego przygotowany paragraf w templatce. Wypiszmy każdego interesariusza, czy tam sponsora jaką pełni funkcję oraz jaka jest jego rola w projekcie. No, chyba że projekt ma jednego interesariusza, klienta, to wtedy raczej można pominąć ten krok. Pominąć możesz również ostatnią sekcję, jaką znajdziesz w dokumencie, mianowicie „zgody i komentarze do dokumentu”. Biorąc na chłopski rozum i mniej chłopską logikę, to przy ustalonym zakresie prac należałoby się podpisać, żeby nie było niedomówień. A kto ma się podpisać pod tym zakresem prac? Teoretycznie wszystkie zainteresowane strony. Bardzo często są tylko dwie strony – osoba reprezentująca zespół projektowy, np. project manager oraz osoba reprezentująca klienta lub sponsora projektu. Aczkolwiek w zależności od projektu osób decyzyjnych może być więcej. Wspomniałem, że możesz pominąć wypełnianie ostatniej tabeli z dokumentu, gdzie osoby decyzyjne muszą złożyć podpisy pod zakresem prac, bo równie dobrze możesz to załatwić na mailu, czyli po ustaleniu tego zakresu prac, wypełnieniu dokumentu. Można zwyczajnie wysłać dokument mailem do osób decyzyjnych i poprosić o informację zwrotną z akceptacją zakresu. Wszystko co zadziała na twoją korzyść oraz korzyść klienta i zespołu projektowego będzie dobrym posunięciem. Amen. A skoro już ustaliliśmy co wejdzie w zakres prac i mamy na to dupochron w postaci wspomnianego dokumentu to teraz trzeba rozkminić kto dowiezie projekt do końca. Tym sposobem dochodzimy do miejsca, gdzie wielokrotnie pada słowo znienawidzone przez departamenty HR-owe, mianowicie porozmawiamy o zasobach.
Zasoby – z angielskiego resources. Zasoby to ludzie. Czy lubimy semantykę tego słowa? Słowa „zasoby”, czy nie? Oznacza ono po prostu siłę produkcyjną przedsiębiorstwa, a w branży IT tą siłą produkcyjną są głównie specjaliści oraz eksperci w swoim fachu – programiści, testerzy, designerzy, managerowie, itd., itd. Pytanie, z którym ty, jako PM, oraz twoja organizacja bardzo często będziecie się mierzyć to pytanie o to skąd weźmiecie zasoby i jakie zasoby są potrzebne, żeby dany projekt zrealizować. Zarządzanie zasobami, czyli zarządzanie ludźmi niestety nie należy do rzeczy łatwych i też ciężko mi powiedzieć czy do rzeczy przyjemnych, chociaż znam ludzi, którzy to lubią i się tym pasjonują. Co należy zrobić jeszcze zanim projekt wystartuje? Co należy zrobić nawet dużo wcześniej, bo już na etapie offeringu, czyli wtedy, gdy dopiero chcecie złożyć ofertę współpracy potencjalnemu klientowi. A no trzeba policzyć i oszacować ilu specjalistów potencjalnie będziecie potrzebować. Następnie należy oszacować na ile dni lub roboczogodzin będziecie potrzebować każdego ze specjalistów, żeby projekt został zrealizowany, bo kiedy wiemy te dwie rzeczy, czyli ile osób i ile czasu będzie potrzebne, to należy policzyć, ile nas będzie kosztować, po pierwsze, pozyskanie tych specjalistów, a następnie utrzymanie ich w projekcie. Wszystko tutaj, a przynajmniej większość rozbija się o budżet. To ćwiczenie nie jest łatwe, bo tutaj jest sporo wróżenia z fusów. Wymagania biznesowe są najczęściej jeszcze niekompletne na etapie offeringu. Sporo ewentualnych zmiennych po drodze czyha na ciebie i twój zespół zaraz za rogiem i w tym momencie wchodzę ja, cały na biało, z szablonem, który pomoże ci przez to przebrnąć. Udokumentowanie planu na zasoby dla projektu to jedna z kluczowych rzeczy i na pewno jej jeszcze nieraz doświadczysz. Oto krótka lista rzeczy, jakie należy zrobić: ściągasz na spotkanie osoby decyzyjne z twojej firmy, głównie liniowego managera lub szefa HR-u lub jakiegoś dyrektora w zależności od tego jak wygląda struktura w waszej firmie. Przydadzą się także osoby techniczne, które po zapoznaniu się z zakresem planowanych prac doradzą wam jakich oraz ilu specjalistów technicznych będziecie potrzebować, a następnie krok po kroku wypełniacie odpowiednie tabletki. W szablonie umieściłem dla ciebie 5 obszarów, na których trzeba się skupić. Pierwsza tabelka to ogólne informacje o projekcie, zasobach, kosztach i tak naprawdę może być wypełniona na samym końcu. Druga tabelka, drugi obszar z planu zasobów, tak nazywa się ten szablon, pomoże ci udokumentować tzw. wysokopoziomową strukturę prac do wykonania. Rozpisujesz najpierw projekt na poszczególne fazy, np. analiza, zaprojektowanie aplikacji, implementacja, testowanie. Następnie do każdego z tych etapów warto wypisać najważniejsze zadania, np. na etapie projektowania aplikacji trzeba będzie na pewno stworzyć jakiś prototyp dla deweloperów. Na etapie implementacji trzeba będzie dostarczyć najpierw jakiś back-end, potem front-end jako inne, główne zadanie, itd., itd. No, testowanie to wiadomo, trzeba to testować manualnie lub też napisać testy automatyczne. Gdy masz już etapy oraz kluczowe zadania to trzeba się zastanowić jakiego rodzaju specjalista będzie potrzebny do wykonania tych zadań. No przecież implementacją nie zajmie się tester, a projektowaniem aplikacji nie zajmie się programista. Tu jest jeszcze łatwo, bo wiadomo, że do wykonania projektu potrzebny będzie jakiś designer, do zrobienia właśnie analizy przyda się analityk biznesowy, albo jakiś data scientist, a do implementacji back-endu programista back-endowy, do front-endu front-endowiec. Pierwsze koty za płoty, ale im dalej w las, tym nieco trudniej. Do kolejnego obszaru, kolejnej tabeli w tym szablonie trzeba teraz skopiować rodzaje właśnie tych specjalistów, te kompetencje, których potrzebuje, których będziemy potrzebowali, a następnie zastanowić się nad czterema rzeczami: ile potrzebujecie otworzyć etatów do każdej specjalności, na jak długo, kto to potencjalnie będzie, wskazać nawet z nazwiska ludzi, jeśli macie już takich specjalistów na pokładzie i czwarta rzecz: dowiedzieć się jaka jest dostępność każdego specjalisty czyli od kiedy może zacząć i czy pokryje wam czasowo cały projekt. To nie jest łatwe zadanie, ponieważ trzeba tutaj zachować bardzo dużą ostrożność, żeby odpowiednio doszacować potrzebnych specjalistów i ich etaty. Od tego zależeć będzie, nie ukrywajmy, dalszy budżet projektu. Ludzie to jest największy koszt, jaki poniesie wasz klient, który zleca wam projekt. Byłoby głupio przyjść do klienta w połowie projektu i powiedzieć „panie Władku, trochę nie doszacowaliśmy, ile potrzebujemy speców, bo zamiast trzech programistów przydałoby nam się sześciu, także jeśli chcemy zdążyć na czas to musimy teraz podwoić budżet”. To by nie była przyjemna rozmowa. Na moim szablonie zobaczysz przykładowo wypełnione pola w tabelach, także nie powinno być tutaj żadnych technicznych kłopotów co, gdzie warto wpisać. Dwie kolejne tabele to podsumowanie kosztów. Bazując na szacunkach jakie zrobiliście wspólnie, czyli ilu specjalistów na ile czasu potrzebujecie, podsumuj teraz ile będą kosztować was specjaliści dedykowani do każdego etapu projektu. Liczysz to w prosty sposób – liczbę etatów razy liczba dni pracy razy stawka dzienna za etat i masz już koszt wynagrodzeń dla poszczególnych etapów w projekcie. Nie musisz pamiętać tego wzoru, wszystko jest w szablonie. Druga tabela z podsumowaniem mówi natomiast o dodatkowych kosztach. Nie tylko ludzie są kosztem, chociaż to główny koszt takich jak pozyskanie tych specjalistów, czyli koszt rekrutacji, dodatkowe szkolenia dla zespołu, czy przykładowo jakieś narzędzia albo technologie, w które trzeba zainwestować na potrzeby projektu. Jako rezultat po zrobieniu tego ćwiczenia powinniście mieć dwa najważniejsze szacunki: jakich specjalistów na jaki wymiar czasu potrzebujecie oraz jaki jest koszt pozyskania i utrzymania tych pracowników. Dziękuję, jedziemy dalej. Teraz powinno być z górki.
Jedną z kompetencji, którą prawdopodobnie będziesz rozwijać, chyba że już to robisz, to zaradzanie wydajnością zespołu. Dziwnie to brzmi, gdy mówię to po polsku. Zresztą jak połowa terminów z branży technologicznej, które nie mają swoich właściwych odpowiedników w języku polskim. Zarządzanie wydajnością to tzw. performance management. Project managerowie w IT nierzadko mają pod sobą programistów, a jeśli nie mają pod sobą programistów to przynajmniej współpracują bezpośrednio z ich managerami liniowymi. W bardzo dużym uproszczeniu chodzi o to, aby razem z podopiecznym dbać, żeby pracownik był wydajny w pracy, ale także żeby miał poczucie, że stale się rozwija. No bo jak człowiek się nie rozwija to trochę tak jakby się uwsteczniał. Wszyscy wokół stale się rozwijają, zmieniają się także technologie, narzędzia, pojawia się nowa wiedza dziedzinowa. Im lepiej się rozwijasz jako specjalista, tym większą wartość wnosisz do swojej firmy. Powtórzę więc, że jako PM musisz dbać o to, aby twoi pracownicy mieli poczucie ciągłego rozwoju i byli jednocześnie wydajni w pracy. Jak to zrobić? Tutaj musiałbym nagrać osoby podcast, być może kiedyś to zrobię, ponieważ to temat rzeka, ale jest jedno narzędzie, o którym chcę wspomnieć i dla którego przygotowałem szablon. Chodzi o zarządzanie wydajnością pracownika poprzez ustalanie mądrych celów. To jest tzw. metodyka SMART Goals, czyli mądrych celów. W wielu firmach spotkasz się z tym narzędziem. Myślę, że o jego popularności decyduje to, że narzędzie jest dość skuteczne, a przy tym niewiarygodnie proste w obsłudze, ale także w zrozumieniu i w ogóle we wdrożeniu w pracy codziennej. W telegraficznym skrócie – warto raz na kilka miesięcy, ale nie rzadziej niż na pół roku, w sensie nie raz na rok, bo to w ogóle zbyt rzadko, spotkać się ze swoim podopiecznym i ustalić 2-3 cele, nie więcej. Takie cele, które twój podopieczny chciałby zrealizować do kolejnego podsumowania jego pracy. Oczywiście fajnie jak te cele wynikają z feedbacku, z opinii na temat tego współpracownika jakie zebrałeś wśród jego kolegów i koleżanek z pracy, czyli np. jeżeli są z nimi jakieś problemy no to warto się wspólnie zastanowić co zrobić, jaki cel sobie przypisać, żeby ten problem, który być może zespół zauważył się rozwiązał magicznie. I teraz angielskie słowo „smart” oznacza „mądry” i te cele muszą być właśnie mądre. Z kolei w naszej metodyce słowo „smart” to także akronim 5 cech, jakie każdy taki cel musi posiadać. Przykładowo wypełnioną tabelkę z celami SMART znajdziesz w moim szablonie, także najważniejsze po stronie twojej i twojego podopiecznego to omówić obrane cele i upewnić się, że są one „smart”, a oznacza to przede wszystkim, że każdy cel musi być, po pierwsze, konkretny lub skonkretyzowany – z angielskiego specific. Musi być też mierzalny, z angielskiego measureable. Jeżeli to źle wymawiam to przepraszam, nie jestem nativem, ale się staram. Po trzecie musi być osiągalny. Z angielskiego attainable. Musi być relewantny, czyli istotny z punktu widzenia twojego pracownika, to z angielskiego relevant i piąta cecha – taki cel musi być określony w czasie, czyli time-bound. I jeśli spojrzymy na pierwsze litery angielskich słów opisujących te cechy, które musimy uwzględnić to te pierwsze litery ułożą nam się właśnie w słowo SMART. Stąd nazwa metodyki SMART Goals. Zachęcam do skorzystania z tego szablonu, bo to naprawdę świetna pomoc dydaktyczna w czasie rozmów okresowych z pracownikami. Dwóch ostatnich szablonów nie będę opisywał osobno. Gdy je już otworzysz to myślę, że wszystko jest wystarczająco zrozumiale opisane i też nie ma tam żadnej skomplikowanej filozofii, a o czym właściwie traktują dwa ostatnie szablony z naszej dzisiejszej listy? Pierwszy, a tak naprawdę szósty na naszej dzisiejszej liście dokument, to szablon do dokumentowania podjętych decyzji. Przydatna rzecz, chociaż nie niezbędna, natomiast jeśli jako PM potrzebujesz mieć dokument, gdzie będziesz zapisywał historię podejmowanych decyzji w projekcie to ten szablon jest dla ciebie i nie mam tu na myśli tylko twoich decyzji, ale np. decyzji podejmowanych wspólnie z klientem lub w czasie spotkań zespołowych. Bardzo często takie decyzje się później klepie na mailach i odszukać kto, gdzie, kiedy jaką decyzję podjął przegrzebując swoją korposkrzynkę mailową to może być kłopotliwe. Superfajna rzecz ten szablon, bo o nim wciąż mówię, to superfajna rzecz dla osób, które chcą czuć się pewniej mając odnotowane, trochę jak poprawny służbista, wszystkie najważniejsze ustalenia z pozostałymi członkami zespołu lub osobami po stronie klienta. Drugi natomiast dokument, a tak naprawdę ostatni, siódmy na naszej dzisiejszej liście to szablon do zapisywania powstającej dokumentacji w projekcie, czyli taki trochę podgląd na dokumenty, które należy stworzyć lub dostarczyć w niedalekiej przyszłości. Nie chcę, żeby to zabrzmiało jak jakaś „Incepcja”, ale w skrócie to jest dokument do notowania jakie dokumenty powstają i mają powstać w projekcie. Tutaj również korzystanie z takiego szablonu musi wynikać z wyraźnej potrzeby. Ja akurat często spotykałem się, że w projekcie istnieje jakieś repozytorium w chmurze, np. Confluence albo Dysk Google, gdzie zespół umówił się gromadzić i dodawać wszystkie ważne dokumenty oraz ustalenia w trakcie prac w projekcie. Wtedy nie ma aż takiej potrzeby, żeby sobie notować na boku kto jakie dokumenty ma nam dostarczyć, itd., bo można to rozpisać właśnie w jednym miejscu, w takim repozytorium, w którym znajdują się już inne dokumenty projektowe, ale spotykałem się też z takimi organizacjami, gdzie różni ludzi tworzą różne dokumenty, które zapisują w różnych miejscach i wtedy ty weź tu się odnajdź człowieku jako PM. No jako project manager możesz się łatwo w tym pogubić kto jaki dokument obiecał dostarczyć. Nie omawiam dokładnie tego szablonu, bo wszystko w nim jest dość klarownie przedstawione. Wystarczy na bieżąco wpisywać wymagane dokumenty w projekcie, jaki jest status każdego dokumentu, czy on jest, czy on się tworzy, czy on jest na razie wstrzymany, kto nad nim pracuje i kiedy ma zostać dostarczony. No i tym sposobem dojechaliśmy do końca. Jeśli zanudziłem ciebie, drogi słuchaczu, dzisiejszą opowieścią o dokumentacji projektowej to z tego miejsca serdecznie przepraszam i posypuję głowę popiołem, aczkolwiek sam osobiście jestem ogromnym fanem korzystania z szablonów, przerabiania ich pod siebie, tworzenia swoich własnych. Taki już los managera w IT, że pewne rzeczy powinny być mniej lub bardziej sformalizowane oraz udokumentowane. Tego oczekuje się od nas jako profesjonalistów w swoim fachu. Także zapraszam raz jeszcze do zapisania się na mój newsletter, do konsultacji 1:1, ale przede wszystkim zapraszam cię do tego egzotycznego świata zarządzania w IT, jeśli jakimś cudem jeszcze jesteś poza nim.
Dbaj o siebie i innych, cześć.
KONIEC
Źródła
https://clickup.com/blog/project-documentation/
https://www.wordtemplatesonline.net/scope-of-work-sow-templates/
https://www.projectmanager.com/templates/statement-of-work-template
https://www.smartsheet.com/content/project-documentation-templates
Cześć, dziękuję że dzielisz się swoją wiedzą. Cenię Twoje podejście do różnych aspektów zarządzania. Jednocześnie zgłaszam że formularz dzięki któremu można zapisać się na Twój newsletter zgłasza błąd. Przeglądarka chrom, Wersja 112.0.5615.137 (Oficjalna wersja) (arm64). System macOS.
Hej,
Serdeczne dzięki za wyłapanie błędu na stronie! Już parzę co się dzieje.