Ostatnio nawiązałam ciekawą internetową znajomość z Karolem Wójciszko. Karol pisze i nagrywa podcast o zarządzaniu projektami i zespołami, a oprócz tego uczy też na temat dokumentacji projektowej. I właśnie ta część jego działalności zainspirowała mnie do poruszenia tego tematu na mojej stronie. Zaczęłam się zastanawiać co właściwie project manager (w IT) powinien wiedzieć o dokumentacji projektowej.
Po co nam dokumentacja?
Zacznijmy od początku. Po co jest dokumentacja? Usłyszałam kiedyś takie mądre zdanie „Umowy podpisujemy na złe czasy”. Po części tak samo jest z dokumentacją systemów informatycznych. Jest to forma kontraktu między biznesem a programistami. W relacji klient – dostawca stanowi też podstawę do rozliczenia kontraktu z klientem. Sprawdzamy czy produkt, który otrzymaliśmy na końcu jest zgodny z dokumentacją.
Dokumentacja to jest taka rzecz, której brak odczuwamy dopiero gdy zaczynają się problemy. Bo póki jest dobrze, to nikt o niej nie myśli. W końcu wszystko jakoś się kręci bez niej.
Dlaczego dokumentować projekt?
- Dokumentacja definiuje zakres projektu. Co za tym idzie stanowi podstawę do rozliczenia z klientem. A dobrze zdefiniowany zakres zwiększa szansę na klienta zadowolonego z projektu.
- Dokumentacja przyspiesza prace i ogranicza zmiany. Nie musimy o wszystko dopytywać, najważniejsze rzeczy mamy ustalone przed rozpoczęciem zadania.
- Taniej wprowadzać zmiany „na papierze”. Wprowadzanie zmian w dokumentacji kosztuje zdecydowanie mniej niż zmiany gotowego produktu i możliwe jest o wiele wcześniej.
Czy każdy projekt potrzebuje dokumentacji?
Niby nie, ale jednak tak 😊 Ale nie w każdym projekcie będzie ona wyglądała tak samo. W projektach publicznych, albo w dużych przetargach dokumentacja jest bardziej formalna. Często jej zakres, rodzaje dokumentów a nawet ich wzory określa umowa. Będzie ona raczej obszerna, często podzielona na różnego rodzaju dokumenty opisujące system na różnych poziomach szczegółowości (np. osobno na poziomie biznesowym i osobno bardziej technicznym).
Jednak dokumentacja to nie zawsze opasłe tomy. W Scrumie i ogólnie w Agile rolę dokumentacji pełnią np. User Story. Tam opisywane są oczekiwania użytkowników wobec systemu.
Z trzeciej strony mamy jeszcze małe projekty np. wdrożenia stron internetowych gdzie za dokumentację można uznać wypisany zakres (np. listę podstron) i projekt graficzny.
Wszystko zależy od skali projektu i tego jaki tryb pracy przyjmiemy z klientem.
Co powinna opisywać dokumentacja systemu?
Dokumentacja na poziomie biznesowym powinna opisywać oczekiwania użytkowników wobec systemu (wymagania) a na poziomie technicznym kluczowe informacje dotyczące ich realizacji. Może zawierać projekt architektury systemu, opis technologii, projekt GUI czy np. opis dostosowania w przypadku wdrażania gotowego produktu.
Co można dokumentować w projekcie:
- Wymagania użytkowników i sposób ich realizacji
- Opis architektury systemu
- Zakres przetwarzanych danych
- Opis technologii
- Przebieg procesów biznesowych
- Projekt GUI
- Opis dostosowania systemu w przypadku analizy przedwdrożeniowej gotowego systemu
- Strukturę danych
- Integracje między systemami
- Przypadki testowe
Sposoby dokumentowania systemów
Najczęściej oprócz tzw. opisu słowno-muzycznego do dokumentowania systemów stosuje się diagramy UML (m.in. diagramy przypadków użycia, sekwencji, klas) lub BPMN gdy mamy potrzebę udokumentowania procesu.
Inaczej udokumentujemy system raportowy inaczej taki, którego podstawą jest ergonomiczne GUI a jeszcze inaczej opiszemy złożone procesy w firmie.
Stosowanie diagramów nie jest niezbędne. Ważne jest by sposób prezentowanych informacji pozwalał na jednoznaczne zrozumienie wszystkich interesariuszy projektu. Jeśli zamiast skomplikowanego diagramu łatwiej będzie zrobić szkic lub makietę ekranu – to tak zróbmy.
Czy project manager musi umieć tworzyć dokumentację?
Zazwyczaj dokumentacja tworzona jest przez analityka (lub kogoś o podobnej roli, np. Product Owner tworzący historyjki). Często wyróżniamy jeszcze analityków biznesowych i systemowych.
Oczywiście project manager nie musi tworzyć dokumentacji. Ale nie oszukujmy się – nie zawsze będzie dostępny analityk, czasem w mniejszych firmach / projektach rola analityka i PM jest łączona. Myślę, że PM powinien co najmniej rozumieć dokumentację w takim stopniu, żeby móc o niej swobodnie rozmawiać zarówno z klientem jak i ze swoim zespołem. Nawet jeśli to nie on jest jej autorem.
Jak nauczyć się robić dokumentację?
To tylko mały wstęp do tematu dokumentacji projektowej. Więcej o dokumentacji możesz dowiedzieć się w bezpłatnym e-booku Karola „Jak napisać dokumentację”. A jeśli na poważnie interesujesz się tematem i chcesz pogłębić swoją wiedzę w tym zakresie koniecznie zobacz kurs Dokumentacja Pro na który zapisy kończą się już 28.04.2021 o godzinie 23.00. Lepiej się spieszyć!
Czego dowiesz się z kursu Dokumentacja Pro:
- Jak napisać dokumentację dla programistów?
- Przeprowadzisz wywiad z klientem o projekcie
- Odpowiednio dobierzesz i zaprojektujesz diagramy projektowe UML
- Utworzysz makiety do dokumentacji
- Opracujesz spis treści (strukturę) dokumentu
- Nauczysz się pisać zrozumiałym językiem
- Dowiesz się jak sprawnie pracować z klientem i zespołem nad dokumentacją
- Ułożysz wstępny harmonogram realizacji do dokumentacji
- Nauczysz się pisać zrozumiały dokument dla klienta i swojego zespołu
- Poznasz darmowe narzędzia do tworzenia diagramów i makiet
Jestem Magda, ta z narudo.pl – entuzjastka technologii, project manager i analityk
IT. Wspieram przedsiębiorców i twórców internetowych w skutecznym wykorzystywaniu narzędzi online i sztucznej inteligencji oraz organizacji i planowaniu. Wierzę w optymalizację pracy i efektywne zarządzanie, jestem gotowa podzielić się swoim doświadczeniem i wiedzą abyśmy mogli pracować mądrzej, nie ciężej.
