Jak przekonać szefa do pisania dokumentacji?
Podzielę się dziś z Tobą moją historią – jak pomimo początkowej niechęci do dokumentacji, sprawiłem, że wszyscy chcieli ją mieć.
Pewnie nie raz i nie dwa wkurzyło Cię coś na co nie masz wpływu.
Chodzi mi tutaj o rzeczy w stylu:
- mogli wcześniej dać znać to bym zdążył
- mogli to przemyśleć, wtedy nie trzeba byłoby 2x tej samej pracy wykonywać
Takie bardziej przyziemne to:
- szef jest uczulony na dokumentacje
- szef chce żeby robić [ tutaj sposób, który nie działa ]
Przekonanie szefa nie jest łatwe bo wielu szefów / przełożonych rozmawia z pozycji siły.
Niestety często takie działania wprowadzają projekt w krąg śmierci. Pisałem o tym w poprzednim wpisie, rzuć okiem.
Zdradzę Ci pewien sposób dotyczący tego jak wdrożyć pisanie dokumentacji do organizacji nawet gdy jest opór ze strony szefostwa.
Wiedza o Dokumentacji IT na twój adres e-mail?
Alergia na dokumentację
Są osoby, które mają alergię na dokumentację. Spotkałem kilku klientów na swojej drodze, którzy bronili się jak mogli przed tym, żeby im napisać dokumentację.
Zazwyczaj argumenty są śmieszne w stylu:
- nie mamy czasu na pisanie dokumentacji
- po co ją pisać, jak można programować
- nikt tego nie przeczyta
Generalnie, co zdanie to absurd. Starałem się ewangelizować tłumacząc, że
- planując prace przed wykonaniem skracamy czas realizacji
- projekt skończymy szybciej bo redukujemy zmiany w zakresie
- dokumentacje można napisać zrozumiale dla biznesu
Niektórzy się zgadzali, ale trafiło się kilku ananasków, którzy stali oporem z argumentem (nie do przejścia): NIE bo… NIE.
Bunt w zespole – historia prawdziwa
Podzielę się z Tobą moją przygodą, która wydarzyła się naprawdę u jednego „ananaska”, który stał okoniem przed pisaniem dokumentacji.
Tak jak wspomniałem wcześniej – nie byłem w stanie dyskutować z argumentem NIE, BO NIE.
Byłem wtedy odpowiedzialny za koordynowanie działań IT – więc należało do mnie:
- dowożenie na czas
- dbanie o spójność logiczną projektu
No ale JAK TO ZROBIĆ BEZ ANALIZY?
Zostało mi odebrane narzędzie, którym mogłem osiągnąć swoje cele.
Ujmując to obrazowo – musiałem walczyć na miecze, bez miecza 🙂
Na początku czułem ogromną frustrację i niesprawiedliwość – jakim prawem wymagasz ode mnie czegoś czego nie jestem w stanie dowieźć bo narzucasz mi metody, które nie działają?
Czułem się z góry skazany na porażkę.
Zdradzę Ci „background” sytuacji, abyś mógł lepiej zrozumieć moją pozycję.
Dotyczyło to środowiska, gdzie równolegle toczyło się wiele projektów i takich koordynatorów jak ja było kilku.
Każdy z nas miał wspólne ograniczenia – odgórna niechęć do dokumentacji.
Kiedy zacząłem się radzić kolegów – jak żyć? Nikt nie miał recepty na to rozwiązanie. Czułem się więc bardzo osamotniony, bo ciężko było mi zrobić przewrót.
Miałem podskórne wrażenie, że reszcie taki stan rzeczy nie przeszkadza.
„Nie ma dokumentacji bo… nie. Nie dowozimy bo… nie dowozimy.”
20 litrów kawy później
Długo myślałem o tym jak mogę poprawić sytuację kiedy zwykła rozmowa na argumenty nie działa.
Rozrysowałem diagram konfliktu i wynikało jasno, że tkwimy w kręgu śmierci.
Wiedziałem, że zmiana jest możliwa tylko jeśli będziemy działać oddolnie.
Mój pierwszy krok jaki zrobiłem to: POPRAWA OPISÓW ZADAŃ DLA PROGRAMISTÓW.
Pozwolę sobie na trochę teorii, aby wyjaśnić Ci dlaczego zacząłem od tego.
Dokumentacja to nie tylko word lub PDF. Dokumentacja to spisanie sposobu realizacji, zakomunikowanie go. Czy to będzie na Confluence, czy w Word, czy w E-mail – to nie ma znaczenia.
Nie ma również znaczenia czy opis jest w jednym miejscu, czy rozbity na cząstki.
Dlatego opisy zadań dla programistów to nic innego jak FRAGMENTY DOKUMENTACJI.
Na efekty nie trzeba było długo czekać programiści od razu zauważyli różnicę.
Wcześniej dostawali opis zadania, które trwało tydzień w dwóch linijkach, później było do tego 30 poprawek.
Tworzenie opisów zadań trwało dłużej, ale zamknięcie zadania było szybsze bo było mniej poprawek.
Próbuję przybić do brzegu (long story short)…
Inicjatywa oddolna zaczęła się tworzyć – czyli programiści zauważyli, że gdy zadania opisuje Karol, to robi się je lepiej, szybciej i jest mniej stresu w pracy bo wiadomo co trzeba zrobić.
Po kilku tygodniach na spotkaniach (wszystkich zespołów) zaczęło się przewijać oddolnie (od programistów) – „a może róbcie takie dokładne opisy jak u nas? Wtedy mamy mniej poprawek„.
Nie mogłem tego przepuścić i zdradziłem w czym tkwi sekret tego, że pracuje się przyjemniej. Chodzi oczywiście o dokładne opisy zadań (fragmenty dokumentacji).
Niestety ta historia to nie bajka – inne zespoły (a właściwie PM) niechętnie wdrażali te opisy bo były bardziej pracochłonne. Druga część próbowała opisywać dokładniej, ale nie wiedziała jak to robić dobrze.
Szkoda, że wtedy nie było mojego kursu Dokumentacja.Pro 😀
Mimo, że inni nie podążyli drogą dokumentacji, ja byłem konsekwentny.
Generalnie trend był taki, że ludzie chcieli pracować przy moich projektach. Mam nadzieję, że nie brzmi to zbyt buńczucznie.
Inicjatywa oddolna działała prężnie, zmiana w podejściu DOKŁADNYCH OPISÓW ZADAŃ vs OPISÓW „NA ODWAL SIĘ była widoczna.
Doszło to do „szefostwa” (pocztą pantoflową), że te opisy są lepiej tworzone, pracuje się przyjemniej. Jest mniej awarii w projekcie.
Oczywiście nie było cukierkowo i lukrowo – fuckupy zdarzały się również (jak to u każdego), ale było ich mniej.
Gdy do szefostwa doszła informacja, że DOKŁADNE OPISY przynoszą korzyści to wtedy wszedłem ja, cały na biało.
Powiedziałem, że mogę osiągać jeszcze lepsze efekty, jeśli będę mógł opisy zadań łączyć w jedno miejsce i wykonywać je przed rozpoczęciem „etapu projektu”. Zamiast w trakcie task by task.
Oczywiście powyższe zdanie to nic innego niż pisanie dokumentacji, ale celowo chciałem to powiedzieć tak, aby nie użyć słowa na D. 😉
Akceptacja tego rozwiązania, aby można było planować pracę i opisywać ją przed realizacją i „legalnie logować czas”, który poświęciliśmy na to było niczym innym niż pisaniem dokumentacji.
Logika obroni się sama
Jak widzisz – kiedy ewangelizacja (tłumaczenie) nie działa, trzeba spróbować innych metod.
W moim przypadku podziałało dodanie realnej wartości przez tworzenie opisów zadań.
Programiści zauważyli różnicę i chcieli więcej. Podszedłem do tego metodą małych kroków.
Czyli zacznijmy od małej zmiany (opisów zadań), a dzień po dniu zaczniemy pisać dokumentację.
Jestem wielkim fanem powiedzenia: Dzień po dniu nic się nie zmienia, ale kiedy patrzysz wstecz wszystko jest inne.
W taki sposób polecam Ci działać gdy walczysz z argumentem NIE BO NIE.
Logika obroni się sama. Jeśli planujesz to mniej przebudowujesz.
Ważne jest abyś dobrał ten pierwszy mały krok do swojego środowiska projektowego.
Dziękuję, że przeczytałeś ❤️
Pssst... przygotowałem dla Ciebie kilka prezentów - wybierz co Ci się przyda! 👍
