Nie masz czasu na DOKUMENTACJE? – To lepiej go znajdź
Na początku chcę powiedzieć, że nie jestem ortodoksem jeśli chodzi o tworzenie dokumentacji. Uważam, że są projekty, których nie ma sensu dokumentować.
Twierdzę jednak, że pisanie dokumentacji oszczędza bardzo dużą ilość czasu.
Wiem, że napisanie dokumentu potrafi być pracochłonne, ale koniec końców jesteś na plusie dzięki korzyściom z jej pisania.
Mam wrażenie, że często firmy nie tworzą dokumentacji bo są zbyt zajęte bieżączką. Mają tyle pootwieranych aktualnych tematów, że nikt nie wyobraża sobie znalezienia czasu na stworzenie dokumentacji.
Ta sytuacja jest analogiczna do poniższego memu.
*na potrzeby tekstu używam pojęć dokumentacja i analiza przedwykonawcza przemiennie.
Kolejnym najczęściej występującym powodem nie tworzenia dokumentacji jest brak formalnej roli analityka w firmie.
Wiem, że stworzenie dobrej dokumentacji nie jest proste. Ale uwierz mi, że nie musisz być formalnie zatrudniony jako analityk by stworzyć dokument, który przyniesie korzyści dla pracy Twojego zespołu.
Widziałem wiele świetnych dokumentów napisanych przez kierowników projektów, senior programistów lub testerów. Wszystko jest kwestią praktyki.
Jakiś czas temu napisałem wpis o tym jak tworzyć dokumentację. Polecam ci rzucić okiem.
Jak dokumentacja ci pomoże?
Najważniejszą kwestią są sprawy analityczne.
Przy wylewaniu z siebie myśli (na klawiaturę) musisz się zastanowić nad tym co piszesz. Lubię używać stwierdzenia, że „sam układasz sobie projekt w głowie”.
Podczas wywiadu z klientem prawdopodobnie przeprowadziłeś analizę. Pisanie dokumentacji jest syntezą.
Tworząc rozwiązanie sam je walidujesz podczas pisania. Możesz zaprojektować mockupy, diagramy – sam zobaczysz co jest potrzebne żeby odpowiednio przekazać swoje myśli.
To co chcę zaznaczyć w kontekście oszczędności czasu to fakt, że przed realizacją pracy DOKŁADNIEJ JĄ PRZEMYŚLISZ.
A uwierz mi – nic nie idzie sprawniej niż przemyślany projekt. Z mojego doświadczenia wynika, że najwięcej zmian w projekcie są spowodowane niewłaściwą analizą.
Albo nie odkryliśmy dokładnie potrzeb klienta, albo źle zaprojektowaliśmy naszą aplikację.
W każdym razie zmiany to pisanie tego samego w inny sposób, więc w pewnym sensie tracisz czas.
Ja podczas pisania dokumentacji milion razy (w przybliżeniu 😉 ) zauważyłem, że proces przekazany od klienta się „nie spina”.
Wyłapałem ogromną ilość luk procesowych, które wpadały w ślepy zaułek.
To wszystko dzięki temu, że pisząc dokumentację musiałem „wyobrazić” sobie efekt finalny projektu.
Wiedza o Dokumentacji IT na twój adres e-mail?
Pisząc RAZ, mówisz to samo WIELE RAZY
Wyobraź sobie sytuację, w której nie tworzysz dokumentacji. Tak czy siak w jakiś sposób musisz przekazać programistom co trzeba zrobić.
Rozmawiasz z jednym, rozmawiasz z drugim… może nawet zbierzecie się „w kupę” i powiesz to raz. Możemy nawet założyć, że uczestnicy zrobią notatki lub to co opowiadasz jest poparte lakonicznymi emailami.
Tak czy siak będziesz musiał powtórzyć to więcej niż raz. Ludzie nie są idealni i o części tego co mówiłeś zapomną. Wszystko to przy optymistycznym założeniu, że ZROZUMIELIŚCIE się i wszystkie strony tak samo wyobrażają sobie efekt końcowy. To nie jest takie oczywiste.
Dobra dokumentacja jest JEDNOZNACZNA. Czyli nie ważne kto ją czyta – każdy powinien zrozumieć ją tak samo. Nie jest łatwe tworzyć takie dokumenty, ale wszystko jest kwestią praktyki.
Spisując to co ma być zrobione tak naprawdę „mówisz to wiele razy” nie poświęcając na to czasu. Czyli go oszczędzasz.
W razie pytań możesz odesłać do dokumentacji. Gdyby były w niej luki – możesz uzupełnić dokument. To lepsze zamiast zwoływać zebranie lub pisać aktualizujący email dotyczący wymagań.
Przechodząc przez to (proces tworzenia dokumentacji) przy kilku projektach staje się to procesem.
Wiesz co jest istotne, od czego zacząć, wiesz kto ma potwierdzić wymagania – twoja organizacja zaczyna mieć procesy analityczne. Dużo łatwiej jest później wyciągać wnioski który klocek procesu należy poprawić.
W sytuacji gdy działacie „losowo”, w każdym przypadku inaczej – bardzo trudno wyciągnąć obiektywne wnioski.
Podsumowanie
Nie zawsze warto pisać dokumentację. Jest masa projektów, w których dokumentacja jest przerostem formy nad treścią. Są to szczególnie proste i krótkie projekty (jednak takie w rzeczywistości rzadko się zdarzają).
Musisz traktować tworzenie dokumentacji jak inwestycję. Stworzenie jej pochłania czas, ale w kolejnych fazach projektu pozwala go zaoszczędzić. To się opłaca.
Tworząc dokumentacja „układasz sobie” projekt w głowie. Pozwala to przewidzieć wiele detali, które mogłyby zaprowadzić zespół w ślepy zaułek.
Powtórzę jeszcze raz: nic nie idzie sprawniej niż dobrze przemyślany projekt. Dokumentacja ci w tym pomoże.
Pisząc dokumentację poświęcasz na nią czas „raz” natomiast zespół ma ją na żądanie. To tak jakbyś mógł przemówić do nich wiele razy nie poświęcając na to czasu.
Polecam rozmawiać przez dokumentację (pisząc ją) z klientem i zespołem realizacyjnym.
Gdy wypracujecie wspólną nomenklaturę i sami wypracujecie proces wytwarzania oprogramowania w oparciu o analizę to zauważycie, że to BRAK DOKUMENTACJI wydłuża czas realizacji.
Nie musisz być formalnie zatrudniony jako analityk by tworzyć dokumentację. Potraktuj funkcję analityka jako rolę, którą może odgrywać „każdy” – kierownik projektu, senior programista itp.
Dziękuję, że przeczytałeś ❤️
Pssst... przygotowałem dla Ciebie kilka prezentów - wybierz co Ci się przyda! 👍
