Niektórzy wierzą w to, że gdy coś zapiszą to inni automatycznie będą zgodnie z tym postępowali. Bardziej szczegółowa specyfikacja projektowa daje im poczucie większej kontroli. To bardzo złudne. I zajmuje dużo czasu, który można lepiej spożytkować. W tym poście znajdziesz mój punkt widzenia na temat dokumentacji, specyfikacji oraz opasłych analiz.
Dokumentacja daje złudne poczucie kontroli
Większości ludzi, na szczęście, nie trzeba już przekonywać do tego, że metodyki zwinne w IT są lepsze od podejścia klasycznego (kaskadowego). Czas robi swoje, coraz więcej specjalistów korzysta ze Scruma czy innych zwinnych „sposobów na robienie internetów” i widzi praktyczne zalety takiego podejścia. Niestety jednak, raz na jakiś czas budzą się demony przeszłości, które podpowiadają ludziom, aby wszystko wrzucać w duże bloki analiza/projekt/wykonanie i opisywać wielkimi księgami mądrości w postaci dokumentacji czy analizy wymagań. Agile sprzyja temu, aby ciąć niepotrzebną papierologię do minimum, więc czemu nie wykorzystać tej zalety? Nie oznacza to całkowitej rezygnacji ze spisywania wiedzy czy wymagań. Jednak można to robić mądrze i fajnie.
Wydaje nam się, że wiemy co mamy robić, bo w końcu jest specka/papier. Programista siada, zaczyna kodzić (albo grafik projektować) i… boom. Ktoś kto to spisywał zapomniał o czymś ważnym. Albo zaplanował to głupio. I co teraz? Zrobić jak jest napisane! No, ale jeśli coś się zrobi słabo to można odpowiedzieć “w specyfikacji było tak napisane”. Dokumentacja zatem poniekąd zdejmuje z nas odpowiedzialność. A wystarczyło porozmawiać :)
Znaczna część z nas, jakoś podskórnie, nie może się wyzbyć pragnienia uporządkowania rzeczywistości projektowej w sposób sztywny, formalny i wręcz biurokratyczny. Problem leży w dobieraniu narzędzi i tym do jakiego stopnia kontroli i porządku chcielibyśmy dojść. Zamiast usztywniać rzeczywistość i pakować ją w ramy można pogodzić się z tym, że jest to pewna forma chaosu, który wbrew pozorom ma sens i logiczny układ, którą da się oswoić.
Podsumowując: co jest złego w formalnych speckach/dokumentacjach?
OK, rozpisałem się trochę, ale mogę to też ująć w formie krótkich punktów, które lepiej zobrazują temat :) Czego najbardziej nie lubię w opasłych tomiszczach specyfikacyjno-dokumentacyjnych?
- Generują bardzo małą wartość w stosunku do czasu, który trzeba im poświęcić
- Prawie nigdy się ich nieaktualizuje
- Nawet jak jest czas na aktualizacje to robienie tego mija się z celem, bo ciągle się coś zmienia i trzeba bardzo często aktualizować dokument
- Nikt tego tak naprawdę nie czyta
- Z reguły nawigacja po repozytoriach wiedzy jest beznadziejna i nie można znaleźć tego co się chce
- Dla dokumentów opisujących rzeczywistość (np. Jak działa usługa X?) rzecz jest zdezaktualizowana często już po paru tygodniach
- Jeśli zatem znalazłem dokument, to czy mogę mu ufać? W końcu był pisany rok temu!
- Sprzyjają zwalaniu winy na tego kto spisywał wymagania
No dobra, czasem trzeba coś spisać. Ale tylko czasem!
Nie mówię o tym, że w ogóle należy zrezygnować ze specek itd. Będą sytuacje, w których warto solidnie opisać wymagania czy zrobić konkretny brief. Sytuacja, w której może to się przydać to współpraca z klientem zewnętrznym, który nie bardzo kuma internety. Albo jakiś zupełnie nowy feature, który z jakiegoś względu musi być tak, a nie inaczej zrobiony i nie ma miejsca na odstępstwa. Czasem napisanie dokumentacji służy temu kto to spisuje – po to, żeby sam sobie ułożył w głowie projekt w trakcie jego opisywania. No i czasem dokumentacja będzie opisywała funkcjonalność, z której ludzie często korzystają, a mają z nią problemy – wówczas się na pewno przyda. Zwinność nie oznacza podejścia “zero dokumentacji”, ale sprzyja temu, żeby ją ciąć i traktować jak narzędzie wspierające, a nie obciążające.
Co zamiast pisania dokumentacji/specek?
No dobra, ale jakoś musimy przekazać to co ma zostać wykonane. Jest do tego kilka rzeczy, które można łączyć. Oprócz suchego, nudnego tekstu można stosować:
- Rozmowy <- z premedytacją o tym napisałem; niby oczywiste, ale… :)
- User stories
- Prototypy / makiety
- Diagramy / flowcharty
- Notatki na makietach / projektach
- Zdjęcia whiteboardów, na której opracowano już koncepcje
- Komentarze w kodzie
- Dobry team, otwarty na komunikację i środowisko które sprzyja wymianie wiedzy
- Team, który nie rotuje co miesiąc (kumulowanie wiedzy)
- Praca na przykładach – przy okazji demonstracji, prezentacji itp.
- Fajne formy prezentacji tego co zrobiliśmy lub chcemy zrobić (np. Posty blogowe, video, prezki) – sprzyja dzieleniu się wiedzą w organizacji, pomaga przynajmniej wskazać kto w organizacji się tematem zajmował :)
Dlaczego unikam dokumentacji czy specyfikacji? Podsumowanie
W tekście zamiennie stosowałem określenia, które albo opisują rzeczywistość zastaną/wytworzoną (dokumentacje – “po”) albo specki, które dotyczą tego co ma być zrobione (“przed”). W ostatecznym rozrachunku są to dla mnie po prostu “papiery”. Uważam, że ogromnym błędem jest traktowanie ich jako swoistego remedium na problemy komunikacyjne lub jakiekolwiek inne choroby, które próbują zaleczyć. Jeśli mamy problem z komunikacją to znaczy, że coś nie działa między ludźmi, a nie w bazie wiedzy. Spisywanie faktów, wymagań, instrukcji, procedur niczego tu nie zmieni. Czasem, wręcz prowokacyjnie można spisać tylko minimalne podstawy po to, aby powstawała interakcja i wymiana poglądów. Do tego jednak trzeba przygotować team i być bardzo świadomym konsekwencji.
Wykorzystane zdjęcia / grafiki: Congerdesign, Unsplash
W odpowiedzi na “Dokumentacja daje złudne poczucie kontroli”
Programy i wszystkie platformy są mega pomocne, ale nie można zapominać, że trzeba umieć się ze sobą komunikować. Dlatego też w 100% się z Tobą zgadzam, że warto postawić na komunikację między ludźmi, a nie tylko na programy.