Rzetelne dokumentowanie logiki biznesowej, podobnie jak technicznych zmian w projekcie, to odwieczny problem dla przedstawicieli biznesu. I nie ma się co dziwić. Prowadzenie dokumentacji kosztuje czas i pieniądze, dlatego managerowie uwielbiają pomijać ten wątek. To jednak przepis na kryzys, który doprowadzi firmę do czkawki. W tego wpisu dowiesz się czym dokładnie grozi brak dokumentacji w projekcie IT.

Moja teza nie jest odkrywcza, bo nie zamierzam wynajdywać koła na nowo. Utrzymywanie dokumentacji technicznej oraz biznesowej zawsze generuje koszta, a nie przynosi widocznych zysków. I nie mam tu na myśli tylko kosztów związanych z opłacaniem repozytorium dla dokumentów w cloudzie (np, Confluence, TFS czy pakiet Office). To, przede wszystkim, obciążenie czasowe dla specjalistów pracujących nad aplikacją, tudzież innym oprogramowaniem. Nie sztuką jest opisać mechanizm działania i dodać jakiś sensowny diagram, gdy wdrażamy nową funkcjonalność. Prawdziwy challenge polega na sumiennym aktualizowaniu już istniejących dokumentów, ażeby świeżo wprowadzone zmiany zawsze miały odwzorowanie w opisanej logice. W osobnym tekście wspomnę jak robić to dobrze. Dziś natomiast skupmy się na tym, czym grozi brak dokumentacji, która rzekomo nie przynosi zysków.

[protip: jeśli w twoim projekcie nie prowadzi się dokumentacji, spraw, żeby ktoś z managementu przypadkiem trafił na ten tekst]

Dokumentacja w projekcie to higiena pracy

To temat znany i często podejmowany w firmach informatycznych. Na rzecz dokumentacji technicznej (i biznesowej) lobbują głównie programiści, którzy dbają o jakość i higienę kodu. I za każdym razem dziwię się, jeśli kogoś wciąż to dziwi. Wywieranie oddolnej presji na managemencie, żeby wygospodarować czas na tworzenie i odświeżanie dokumentacji nie jest (i nigdy nie było) żadną anomalią. Owszem, powiedzmy to sobie szczerze, prowadzenie projektu bez dokumentowania logiki jest możliwe. Ale czy opłacalne?

Biznes myśli pieniądzem, dlatego przyjrzyjmy się temu zagadnieniu w kontekście finansów. Często spotykanym argumentem, żeby w czasie developmentu przeskoczyć robienie dokumentacji i wrócić do tego później, jest oczywiście oszczędność czasu. Gdy inwestorzy oraz interesariusze czekają, aż pokażemy im nowe funkcjonalności, mało kogo z biznesu interesują jakieś tam diagramy pochowane po folderach na GDrive, które opisują logikę. Najważniejsze jest to, co zobaczą na demo osoby wykładające pieniądze na aplikację, tudzież inny software.

Liczymy straty przez brak dokumentacji

Trudno udowodnić, że coś, czego użytkownik nie widzi gołym okiem, jest wartościowe dla projektu i powinniśmy poświęcać temu więcej czasu. Jednak, gdy rozłożymy problem na czynniki pierwsze, zobaczymy ile tak naprawdę traci firma oraz zespół developerski. Wypunktuję te rzeczy jedna pod drugą. A zatem, brak dokumentacji technicznej i biznesowej w firmie oznacza, że:

• Wdrożenie każdej nowej osoby do zespołu zajmie więcej czasu, ponieważ to, czego nowy specjalista mógłby dowiedzieć się z dokumentów, będzie musiał usłyszeć od współpracowników. Onboarding staje się przez to jeszcze bardziej absorbujący dla pozostałych członków zepołu.
• Czas developmentu, który jest największym kosztem dla firm IT, wydłuża się. Głównie dlatego, że nowe funkcjonalności często dopisywane są do już istniejącej logiki, więc gdy ta logika nie jest nigdzie opisana, developerzy muszą poświęcać więcej czasu na inwestygację i sprawdzanie jaką logikę zaszyto w kodzie.
• Zwykły refactor kodu potrafi zmyć sen z powiek programisty. Skąd bowiem ma wiedzieć czy dana logika jest właściwa, skoro nikt tego nie udokumentował? Oznacza to więc, że …
• … developer będzie obciążał swojego managera lub product ownera dziesiątkami pytań o logikę, głównie w czasie refaktoru i łatania błędów. Ktoś mu przecież musi wytłumaczyć mechanizm działania tej czy innej funkcjonalności w systemie, jeśli nie ma do tego dokumentacji. Obie strony tracą wtedy czas, który można by spożytkować na bardziej produktywnych zadaniach.
• Zwiększa się liczba fuck upów oraz błędów krytycznych, które ciężko ogarnąć. Wyobraźmy sobie prostą sytuację – wywala się część systemu, do której nie ma dokumentacji, a w zespole nie ma osób pamiętających jak ten segment działał pierwotnie. To może być ciężki temat nawet dla product ownera. Oczywiście, ten oraz inne błędy krytyczne zostaną w końcu załatane, ale sytuacja zeżre o wiele więcej czasu, nerwów i energii zespołu niż powinna.
• Projekt staje się mniej atrakcyjny dla osób z zewnątrz, np. dla przyszłych kandydatów na programistów lub potencjalnych inwestorów. Czy to doświadczeni developerzy, czy znani inwestorzy, jednych i drugich chcielibyśmy mieć zawsze przy sobie. Niestety, brak dokumentacji obniży nasz rating w oczach potencjalnych współpracowników oraz partnerów biznesowych.
• Morale zespołu są niższe, a frustracja większa. Na pewno wpływa to także na rotację specjalistów w firmie. Wybacz mi język z rynsztoku, ale brak dokumentacji zwyczajne potrafi wkurwić.

Prowadzenie dokumentacji w projekcie to must-have, a nie nice-to-have

Tyle wystarczy. Dla pewności, spójrz jeszcze raz na przykłady powyżej, jeśli wciąż wątpisz, że przez brak dokumentacji twoja firma traci czas i pieniądze. Nie negujmy zdrowego rozsądku, a zrobienie dokumentacji niech stanie się częścią definition of done. Wtedy i przedsiębiorstwu, i wszystkim specjalistom, będzie żyło się lepiej.

Daj mi proszę znać w komentarz co jeszcze powinienem dopisać do tej listy. A być może nie mam racji i posiadasz inny punkt widzenia? Chętnie poznam twoja perspektywę.