Projekt nie istnieje bez dokumentacji; pytanie brzmi, co dokładnie powinno trafić do danego zestawu podstawowego na początku i jak najlepiej utrzymać dokumentację w procesie.
Co i jak ma dokumentować project manager, by nie utonąć w papierowym wirze. Zapytaliśmy o to dwóch ekspertów:
Denis Shamatazhy zaczynał jako developer, a przez ostatnie 5 lat pracował w zarządzaniu projektami i produktami, więc ma obraz na proces tworzenia dokumentacji z różnych stron.
Natalia Belousova ma za sobą 9 lat w roli PM, wie jak „wyciągnąć” skomplikowane projekty i potrafi znaleźć wspólny język z każdym klientem.
Przystępując do realizacji projektu, należy zrozumieć, że dokumentacja nie jest tylko po to, aby zajmować się samym procesem. Tworzenie dokumentacji nie jest najbardziej ekscytującą rzeczą, więc doświadczony PM natychmiast szuka gdzie i jak można zaoszczędzić czas i zasoby.
Aby stworzyć naprawdę przydatne dokumenty, weźcie pod uwagę dwa czynniki:
- cel – w jakim celu tworzony jest dany dokument;
- odbiorca – kto będzie korzystał z tego, co napisaliście.
Określ, po co piszesz
Dokumenty, bez których trudno się obejść, należą do jednej z trzech kategorii:
- Dokumenty formalne: raportowanie do zarządu, klienta lub umowy. Nie można tego zaniedbywać, ale lepiej jest jak najwięcej delegować.
- Ustalanie umów: zobowiązania wobec trójkąta projektowego: budżet, terminy, zakres. Możesz je zapisywać w dokumentach w Wordzie, tabelach kalkulacyjnych, protokołach, mailach.
- Oszczędność czasu, aby nie trzeba było powtarzać tego samego różnym osobom. Na przykład, zrobić stronę w Confluence raz i wysłać link tej strony do każdego, kto dołączy do projektu. Osoba przeczyta i będzie wszystko wiedziała, a PM nie będzie musiał tracić czasu na wyjaśnianie.
Denis Shamatazhy Project / Product Manager w Redmadrobot:
Kiedy byłem w startupie, nasza dokumentacja rozwiązywała kilka celów jednocześnie. Zdarzało się więc, że onboarding, zatwierdzenia, follow-upy czy dokumentacja techniczna i analityka były zapisywane razem. Każdemu było powiedziane: „Ta część dokumentu nie jest tobie potrzebna, czytaj odtąd”.
W pewnym momencie doszliśmy do zupełnie oczywistego odkrycia. Jeden dokument powinien osiągać jeden główny cel, bo to pozwala zaoszczędzić czas.
Jakie cele można wykorzystać do grupowania dokumentów:
- Onboarding: procesy w Jira, zasady komunikacji z klientem, jak odbywają się spotkania.
- Warstwa dokumentacji, która odpowiada za scoping: baza wiedzy, zadanie techniczne. Jedna z opcji – to przestrzeń w Confluence z bazą wiedzy.
- Dokumenty do przekazania projektu, np. program i metodyka testów.
Pomyśl o tym, kto będzie czytał
Określenie celu dokumentu – to pierwszy krok. Następnym jest pomyślenie o odbiorcach, którzy będą korzystać z tego, co zostało napisane.
Czasami PM próbuje podsumować absolutnie wszystko w wartościach biznesowych, a zespół nie rozumie, czego się od niego wymaga: gdzie jest w tym wszystkim logika. Tak samo błędem jest podawanie szczegółów technicznych klientom, którzy na takich detalach się nie znają.
Denis Shamatazhy Project / Product Manager w Redmadrobot:
Kiedy przychodzę do projektu, staram się sporządzić portret psychologiczny klientów, aby sprawdzić, na ile rozumieją oni język techniczny. Jeśli tego nie rozumieją, staram się napisać jak najbardziej przejrzyście, a potem dodatkowo pokazać to komuś, kto nie jest osobą techniczną, aby zobaczyć czy wszystko jest zrozumiałe.
Jeśli się zwracam do osób z zespołu,to jest to bardziej skomplikowane, bo potrzebują zarówno wymagań systemowych jak i biznesowych.
Często zdarza się sytuacja, że PM podaje na tyle techniczny opis jakiegoś elementu, że programista nie rozumie, po co ma go budować. A kluczowym czynnikiem przy budowie każdej nowej funkcjonalności jest zakomunikowanie programistom, jaki problem biznesowy jest rozwiązywany.
Bo jeśli jeden z uczestników nie rozumie problemu biznesowego, to istnieje duże prawdopodobieństwo, że zespół zrobi nie to czego oczekują lub nie będzie zmotywowany.
Spróbuj naszkicować sformułowania, których użyjesz, by zwrócić się do odbiorców. Ważne jest indywidualne podejście, aby zadanie było bardziej zrozumiałe. Potrzebne jest osobne podejście do klienta i do zespołu, dlatego tworząc dokumentację, weź pod uwagę, dla kogo piszesz. Programistom lepiej będzie napisać instrukcję, a klientowi, który nie ma pojęcia o niuansach technicznych, lepiej będzie wytłumaczyć za pomocą obrazków i przykładów.
Zawsze staraj się uzyskać informację zwrotną, czy ten konkretny dokument jest potrzebny, czy nie, czy tekst jest zrozumiały. Rozumiejąc cel i to, komu dokument będzie potrzebny, zobaczmy, jaki będzie minimalny zestaw, aby bez problemów dla PM-a i zespołu rozpocząć projekt.
Minimalny zestaw na początku projektu
Podstawowy zestaw dokumentacji startowej obejmuje:
- Karta projektu – to dokument, który opisuje kto jest klientem, co robimy, kiedy trzeba to zrobić, cel itp. Są firmy, w których karta projektu jest obowiązkowa, ale czasem można się bez niej obejść. Na przykład, jeśli firma ma dobry onboarding, to zespół i klient dokładnie wiedzą, jak pracujemy i co chcemy osiągnąć.
- Lista funkcji jest obowiązkowa, od niej zaczyna się projekt: PM ocenia listę funkcji, uzgadnia ją z klientem i na jej podstawie tworzy plan projektu.
- Hierarchiczna dekompozycja pracy jest taka sama jak lista funkcji, tylko bardziej uporządkowana i podzielona na role. Może się przydać, jeśli chcesz w wygodny sposób pokazać części składowe projektu.
- Ocena projektu – to część obowiązkowa.
- Plan projektu – ważne jest, aby wybrać odpowiednie narzędzie, w którym będziemy prowadzić plan: np. Excel, Miro.
Musisz nie tylko uzgodnić z klientem, jak rozpoczniesz i poprowadzisz projekt, ale także jak go oddasz. PMB (program i metodyka badań) może być opisana formalnie lub w luźniejszej formie. Najważniejsze, aby ustalenia dotyczące przekazania projektu były ustalone w formie pisemnej i to na samym początku.
Natalia Belousova, PM w Redmadrobot:
Chciałabym zwrócić uwagę na umowę. Z jakiegoś powodu nie wszyscy PM-owie ją czytają, a to bardzo ważne, bo w umowie mogą być zawarte rzeczy, które formalnie trzeba zrobić, a które łatwo przeoczyć. Na przykład lista obsługiwanych urządzeń lub lista wersji. Dlatego zawsze sensowne jest czytanie umowy.
Aby zrozumieć, jak postępować w konkretnym przypadku, należy podejść do niego z ekonomicznego punktu widzenia. Zadaj sobie pytania: „Co się stanie, jeśli nie zrobię danego dokumentu, jakie ryzyko może się z tym wiązać? Jeśli te ryzyko zostanie podjęte, to jak sobie z nim poradzę? Czy będzie mnie to kosztowało tylko kilka dodatkowych godzin pracy z programistą i analitykiem? Czy grozi mi to, że klient powie: obiecaliście mi to – i będę musiał wydać dodatkowe 20% budżetu?
Przygotowanie dokumentacji powinno działać w oparciu o odpowiedzi na pytania:
- Dla kogo to robię?
- Po co to robię?
- Co się stanie, jeśli tego nie zrobię?
- Jakie jest ryzyko dla mnie i dla zespołu?
Tworzyć dokument na każdą potrzebę lub wyjaśniać to ustnie – to często kwestia opłacalności. Musisz zrozumieć, co byłoby „tańsze”: mówienie nowym uczestnikom za każdym razem, co dzieje się w projekcie, lub pisanie tego raz w Confluence.
Nie wystarczy stworzyć zestawu startowego dokumentacji. Wszystko co napisał PM musi być aktualizowane w trakcie trwania projektu.
Praca z dokumentami w procesie
Oczywiście z dokumentami trzeba pracować systematycznie. Ale zdarzają się sytuacje, gdy projekt nie ma wysokiego priorytetu i zasoby są zaoszczędzone kosztem dokumentacji, wtedy PM ma więcej czasu na inne działania projektowe. Jednak gdy pojawią się zapytania klientów, to odpowiedź zajmie wtedy sporo czasu.
Natalia Belousova, PM w Redmadrobot:
Zdarzają się sytuacje, że zaoszczędziłeś na aktualizacji dokumentacji, a potem klient pyta:
„Słuchajcie, a co jeśli zmienimy to i tamto w metodach – będziemy mieli problem czy nie?”
Wysyłasz zapytanie do programisty, analityka lub testera, albo sprawdzacie je samodzielnie i zdajecie sobie sprawę, że odpowiedź zajmie wam godziny. Ponieważ nie jest to nigdzie ustalone, trudniej jest dowiedzieć się, jak wszystko działa.
Właściwą rzeczą jest aktualizowanie dokumentów w trakcie, ale nie zawsze tak jest.
Kiedyś pracowaliśmy przez 1,5 roku bez zaktualizowanej dokumentacji. Produkt nie był priorytetowy, był podtrzymywany, okresowo poprawialiśmy drobne rzeczy, ale nie robiliśmy nic szczególnego. Odpowiednio, oszczędzaliśmy jak tylko mogliśmy i nie aktualizowaliśmy bazy wiedzy. Chociaż klient nie zrezygnował z nas, nie wydarzyło się nic krytycznego, ale poświęcaliśmy więcej czasu na inne zamówienia.
Aby nie doprowadzić sytuacji do punktu krytycznego, trzymajcie się zasady: zrobiliście nową funkcję, to od razu zaktualizujcie dokumentację. Zajmuje to niewiele czasu w procesie, a przynosi wiele korzyści później. Jeśli tego nie zrobicie – kiedyś okaże się, że straciliście mnóstwo czasu. Lepiej więc na bieżąco aktualizować całą dokumentację. Jeśli nie macie czasu, spróbujcie stworzyć szablon, który posłuży za podstawę ekspresowej wersji analizy.
Denis Shamatazhy Project / Product Manager w Redmadrobot:
W startupie była taka sytuacja, że przez dziewięć miesięcy nikt nie robił dokumentacji, po prostu nie było czasu. Wszystko było dobrze, pojawiły się inwestycje, a potem przestaliśmy szybko się rozwijać. Kiedy projekt zaczął się wolno i liniowo rozwijać, okazało się, że nie wiemy nic o tym, co się dzieje: jak działają API, gdzie jakie pola wchodzą. Wszystko to z jakiegoś powodu było w darmowym Slacku. W pewnym momencie nagromadziło się tyle pracy, że napisanie brakującej dokumentacji zajęłoby miesiąc lub więcej.
W końcu doszliśmy do punktu, w którym programiści zaczęli narzekać: „Koledzy, nie możemy odpowiadać na pytania o to co, gdzie i jak działa”. Musieliśmy przeznaczyć czas na dopracowanie oraz na aktualizację dokumentacji podczas każdego sprintu.
Właściwe narzędzia
Wybór niewłaściwych narzędzi jest jedną z przyczyn spadku jakości w rozwijającym się projekcie. Istnieją różne formy i podejścia do prowadzenia dokumentacji.
Lista najczęściej używanych narzędzi:
- Google Drive do przechowywania wszelkiego rodzaju plików z możliwością udostępniania i edycji online.
- Dropbox jest alternatywą dla Google Drive. Na Dropboxie pojawiła się możliwość odłączenia urządzenia dużo wcześniej. Jeśli na przykład pracownik zgubi swój telefon, możliwe jest odcięcie dostępu do tego urządzenia w Dropbox, a to wpływa na poprawę bezpieczeństwa.
- Confluence to współdzielona przestrzeń robocza, baza wiedzy do tworzenia, przechowywania i edycji dokumentów.
- Notion to zasób podobny do Wikipedii. Dobrze sprawdza się w przypadku podstawowej dokumentacji, zwłaszcza o produkcie. Może być ogólnie używany jako zamiennik Confluence i zaoszczędzić sporo pieniędzy, ponieważ Notion jest tańszy.
- Miro pomaga zrobić szybki przegląd dokumentów. Jest to narzędzie gdzie można wstawiać różne informacje: retrospekcje, ogłoszenia, zatwierdzanie designu z interesariuszami, podgląd projektu z programistami.
Natalia Belousova, PM w Redmadrobot:
Wszystko co mogę, robię w Confluence, a resztę przesyłam na dysk Google jako pliki.
Miro jest wygodnym narzędziem do uzgodnienia wymagań z klientem, ponieważ ludziom trudno jest zrozumieć tylko słowne opisy. Dużo bardziej intuicyjne i produktywne jest robienie map w Miro, a podczas wspólnego calla wyjaśnienie i omówienie poszczególnych przypadków. Wtedy klient wszystko zrozumie i może zostawić uwagi bezpośrednio w Miro. PM poprawi wszystko wspólnie z designerem, a klient odnotuje, że uwaga została rozwiązana.
Niezależnie od tego, jakich narzędzi używacie, trzymajcie się podstawowych zasad:
- Dokumentacja powinna być zsynchronizowana i, jeśli to możliwe, dostępna online. Każdy z nas spotkał się z sytuacją, w której dokumenty przychodzą jako pliki w Microsoft Word, PM dokonuje edycji, zrzuca je z powrotem – i wszystko to trwa tak długo, jak to tylko możliwe. W przypadku zespołów zdalnych, w których jest dziesięć godzin różnicy w czasie, synchronizacja online jest szczególnie istotna: możecie szybko edytować dokument i wszyscy to widzą.
- Zawsze sprawdzajcie dostępy. W przeciwnym razie możecie doprowadzić do nieprzyjemnej sytuacji, np. firma zsynchronizowała się z klientem za pomocą bazy wiedzy w Confluence. Jednocześnie w bazie danych prowadzony był zapis: z kim firma współpracuje, z jakim klientem, z jakim pytaniem do kogo się zwracać. I była też mała rubryka – charakterystyka komunikacji: z tą osobą lepiej się kontaktować w Telegramie, ta jest bardzo ciężka, z tą lepiej się nie komunikować. Byłoby niedobrze gdyby Klient to zobaczył. Tak więc, jakkolwiek banalnie to brzmi, sprawdzajcie dwukrotnie prawa dostępu.
Dokumentów dotyczących projektu jest wiele, więc bez logicznej struktury łatwo się pogubić. Gdy nawigacja jest słaba, zespół nie będzie w stanie znaleźć danego dokumentu poprzez wyszukiwanie i założy, że potrzebne informacje po prostu nie istnieją.
Zrozumiała nawigacja
Aby dokumenty projektowe były przydatne, trzymaj się kilku prostych zasad:
- Potrzebne dokumenty są dostępne w wyszukiwarce.
- Nawigacja ma przejrzystą strukturę.
- Przegląd dokumentacji odbywa się raz na kwartał.
Nie ma uniwersalnej rady, ale prostą zasadą jest takie skonstruowanie zadania, aby osoba mogła sformułować swój problem i intuicyjnie znaleźć go w dokumentacji.
W przeciwnym razie okaże się, że np. chcesz zobaczyć, gdzie znajdują się klucze do certyfikatów, ale będziesz musiał szukać wśród nazw typu screens, risks, requirements.
Denis Shamatazhy Project / Product Manager w Redmadrobot:
Testowanie nawigacji: poproś kogoś, kto jest bardzo nieobeznany z projektem, daj mu strukturę twojego Confluence i poproś go o znalezienie konkretnego dokumentu. Jeśli 2-3 osoby nie potrafią intuicyjnie znaleźć dokumentu, to trzeba zająć się nawigacją.
Przeprowadzaliśmy test, gdzie poprosiliśmy osoby nieznające naszej dokumentacji projektowej i prosiliśmy ich o znalezienie jakiegoś artykułu. Wszystkim udało się to zrobić.
PM ma wiele zadań w projekcie. Dlatego jeśli jest możliwość oddelegowania dokumentacji komuś innemu, to jak najbardziej należy to robić.
Delegacja
Delegowanie również musi być wykonane prawidłowo. Zdarza się, że PM zbytnio ufa zespołowi, zwłaszcza gdy w projekcie jest silny analityk. PM tak się rozluźnia, że przestaje zagłębiać się w dokumenty, a później, na etapie przekazania, pojawiają się problemy.
Dlatego delegując zadania, nie zapominajcie o sprawdzeniu. Nie chodzi o to, żeby wszystko odczytać w całości. Musi być systematyczny przegląd zaktualizowanej dokumentacji, aby zrozumieć, czy wszystko jest w porządku z analitykiem i testerem, i czy nie ma jakiegoś zagrożenia dla procesu, który został stworzony wiele miesięcy temu. Na tym polega sztuka zarządzania – poświęcić niewiele czasu i jednocześnie nie przegapić procesu.
Denis Shamatazhy Project / Product Manager w Redmadrobot:
Często miałem sytuację, w której BA zajmuje się całą dokumentacją niefinansową. PM występuje wtedy z jednej strony jako account manager, a z drugiej jako taki „ojciec projektu”, który pilnuje, aby jego „rodzina” nie zrobiła nic niestosownego. W takiej sytuacji zadaniem PM-a jest upewnienie się, że wszyscy produktywnie dogadują się i rozwiązują konflikty. Zadania związane z organizacją są czasochłonne, więc większą ich część wykonuje analityk; mimo to dbam o to, by przeglądać wszystko, co jest napisane.
Nie należy delegować raportów finansowych czy raportów o klientach, ale wymagania biznesowe można spokojnie przekazać BA. Koniecznie przeczytajcie wszystkie dokumenty, bo projekt będzie przekazany do PM-a. Jeśli w wymaganiach biznesowych jest coś dziwnego lub niezrealizowanego, należy to natychmiast skorygować.
Co należy zapamiętać
Nie ma uniwersalnej listy dokumentów. Nawet w tej samej firmie, przy tym samym sposobie prowadzenia projektów, zestaw dokumentów może być różny, bo różni są klienci i różna jest komunikacja z zespołami programistów.
Gdy PM zrozumiał, jakim celom służy dokument i do kogo jest przeznaczony, staje się jasne, które dokumenty są potrzebne, a które nie.
W czasie trwania projektu:
- wybierajcie odpowiednie narzędzia do przechowywania i pracy z dokumentami;
- twórzcie system nawigacji, który zrozumie nawet początkujący użytkownik;
- delegujcie pracę i sprawdzajcie wszystko, co zostało zrobione przez innych pracowników.