Naucz się tworzyć wartościową dokumentację projektową
- czym jest dokumentacja,
- dla kogo ją tworzymy i jak rozróżniamy różne typy dokumentacji,
- słów kilka o stylach pisania,
- gdzie tworzyć dokumentację – wraz z dodatkowymi narzędziami – propozycjami, które można rozważyć,
- trzy filary dobrej dokumentacji
- i w końcu… po co ktoś miałby czytać dokumentację?
lub poniżej przeczytaj więcej o produkcie.
Dla kogo ten e-book?
Dla newbie
Dla juniorów
Dla seniorów
Dla ciekawskich
Twoje korzyści
Stworzysz dokumentację
Zrobisz porządek
Wykonasz ćwiczenia
Zrozumiesz proces
Przeczytaj fragment
Dokumentacja to miejsce, które przyspiesza to, co chcemy zrobić. Jeżeli więc trafiamy do przestrzeni, gdzie przez kolejne trzydzieści minut będziemy szukać odpowiedzi – oznaczać to będzie, że skopaliśmy zadanie, a naszą dokumentację możemy wyrzucić do kosza. Wyobraź sobie programistę, który kończy już swoje zadanie, jest piątek, 15:45. Za piętnaście minut chce iść na zasłużony odpoczynek. Musi jeszcze tylko wpiąć token autoryzacyjny i gotowe! Token jest dostępny w dokumentacji (nie polecam tego rozwiązania – wszelkie hasła, tokeny i poufne dane powinny być zapisywane w firmowych menadżerach haseł!). Nasz programista wchodzi więc do dokumentu i… no właśnie. Co dalej? Gdzie to może być? W zakładce „informacje ogólne”? Nie, tam jest coś o spotkaniach. Może w „autoryzacja”? Nie, tam jest jakiś skrypt do łączenia z bazą danych. Może więc w „tokeny”? Nie, tu są tokeny do endpointów API. Nie tego szukamy. O, jest coś takiego jak „dla programistów!”. Ah, tu PM wpisał „pamiętaj o logowaniu czasu”. Dowcipniś. No nic, wyszukiwarka. „token: 92 wyniki”. „token autoryzacyjny: 61 wyników”. I po weekendzie.
Nie jest to miejsce, by omawiać konfigurację Confluence, ale dodam jedną istotną rzecz – przestrzeń ta umożliwia kontrolę nad dostępami. Możesz więc wrzucić dostęp wszystkim w ramach projektu lub wybranym osobom. Dzięki temu na jednej przestrzeni mogą pracować analitycy biznesowi, klienci, CTO, CEO, QA i inni specjaliści – z dostępem tylko do swoich zakładek. To bardzo pomaga przy organizacji skomplikowanych projektów, które dzielą się na podprojekty i wiele różnych zespołów.
Rzućmy na pierwszy przykład, czyli dokumentację minimalną:
- czytelny spis treści, czyli miejsce z którego bezproblemowo przejdziemy do interesujących nas informacji czy obszarów,
- informacje ogranizacyjne – kiedy i jakie spotkania odbywają się w ramach procesu wytwórczego oraz ich cel. Zdaję sobie sprawę, że terminy są podane w kalendarzu, ale wyobraź sobie kogoś, kto dopiero dołączyć i nie ma jeszcze zaproszenia – dzięki takiej stronie będzie wiedział na co się przygotować i poukłada swoje inne spotkania. Cele daily, planningów czy refinementów również są istotne. Pamiętaj bowiem, że nie zawsze będzie Ci dane pracować z doświadczonymi specjalistami, czasami będą to osoby dopiero raczkujące w IT,
- zespół projektowy – warto rozpisać pełny zespół, który pracuje nad projektem wraz z informacjami kto jest za co odpowiedzialny (DevOps, Frontend Developer itd.). Jest to bardzo pomocne dla wszystkich nowych członków zespołu, gdy nie wiedzą,
- obszary techniczne.
Najczęściej zadawane pytania
Dokument ma 25 stron A4. Pomijając wstępy, screeny i inne “dodatki” (choć wartościowe!), masz tu 20 stron konkretów. Oraz pięć ćwiczeń.
Dziesiątki projektów i… często te same problemy z dokumentacją projektową. Warto ich nie powielać, po prostu zadziałaj zgodnie z e-bookiem i patrz jak działa 🙂
Pisz śmiało na firmowego maila, kontakt[małpka]altedu.pl