Na sztukę

Z czasów pobytu w wojsku zapamiętałem określenie robić coś na sztukę. Chodziło o wykonanie jakiejś czynności z maksymalną niedbałością, najmniejszym możliwym kosztem – byle tylko stworzyć pozory spełnienia rozkazu. Przetarcie zamka karabinu (bo tam zerkał sierżant) przy zostawieniu zatkanej lufy. Kiwanie się z grabiami nad kupką liści przesypywaną z lewej w prawo, a potem z prawej w lewo. Dziubanie łopatą w błotnistym miejscu, gdzie co prawda o sensownym okopie mowy nie ma ale za to ziemia miększa. Pracowite dyżurowanie przy nie podłączonym telefonie. Itd itp. Sztuka jest sztuka.

Wojsko bardzo silnie motywowało do tego typu zachowań – bądź co bądź, ile razy można na serio traktować nakaz sprzątania korytarza tuż przed powrotem oddziału z poligonu, uczyć się instrukcji nigdy nie widzianego urządzenia, czy z uwagą pełnić wartę przed śmietnikiem. Nie jest to zresztą jego monopol, przykładów pełno – od iluśtam kilometrów ścieżek rowerowych, którymi nie da się nigdzie dojechać, po działalność niektórych szkół zawodowych.

No – ale ja o informatyce.

Praca na sztukę jest charakterystyczna dla informatyki biznesowej. W projektach open source czy hobbistycznych zdarza się rzadko – tam, jeśli ktoś nie ma ochoty czegoś robić, to tego nie robi (druga strona medalu to notoryczny brak dokumentacji czy nudnych funkcji). W firmach – odwrotnie. Jeśli coś nakazano czy zamówiono – zwykle się pojawia.

Zadaniem, które wydaje się szczególnie często przyciągać pracę na sztukę, jest pisanie dokumentów. Widziałem już wiele różnych specyfikacji funkcjonalnych, opisów architektury, podręczników administracji i innych ładnie nazwanych publikacji, będących w rzeczywistości stertą śmiecia – nieraz estetycznie sformatowanego, a nawet napisanego w miarę eleganckim językiem, ale – całkowicie bezużytecznego. Niektóre nawet sam pisałem. Klasyczna metoda tworzenia tego typu dokumentów jest prosta: weź analogiczny dokument z innego projektu, poprzerabiaj nazwy firm i komponentów, przepisz wstęp, przejrzyj korygując co bardziej nie pasujące akapity. Gdy tak się nie da, jest druga: weź z jakiegoś szablonu spis treści, napisz w miarę przyzwoicie wstęp i początki rozdziałów, powpisuj co popadnie (byle szybko) w treści, jeśli wynik ma za mało stron, powklejaj jakieś diagramy (autogenerowany schemat bazy danych jest idealny), wygeneruj i wstaw jakieś API, wklej jakieś pliki konfiguracyjne czy screenshoty… I – napisanie takiego dzieła zajmuje mniej czasu, niż jego przeczytanie.

Tego typu urokliwe dokumenty szczególnie lubią powstawać blisko końca projektu – czy końca jakiejś jego formalnej fazy. Powstać muszą, bo wymaga tego schemat organizacyjny, albo wręcz kontrakt. Ważniejsze jest jednak co innego – autorzy nie potrafią powiedzieć komu i do czego pisany dokument ma posłużyć.

Absolutnie nie próbuję tutaj argumentować przeciwko pisaniu dokumentacji analitycznych czy projektowych! Pisane dokumenty są w małych projektach przydatne, a w dużych niezbędne. Ale – muszą naturalnie wynikać z potrzeb. Dokument o tytule Specyfikacja projektowa może stanowić osnowę prac zespołu. Może też stanowić śmieć wykreowany dla zaspokojenia jakiegoś formalizmu, podczas gdy faktyczny projekt powstał zgoła gdzie indziej (od płacht papieru rozwieszonych w pokoju, po strony wiki, dyskusje na forum projektu, czy rozbudowane komentarze w kodzie). Test z czym mamy do czynienia jest nietrudny – kto używa tego dokumentu i do czego? A nawet – jak często ten dokument jest zmieniany? (coś, co powstało w parę dni i nie było od tego czasu ruszone, jest niemal na pewno zrobione na sztukę) czy ile razy był ostatnio drukowany?.

Pozorna praca nie zawsze musi być potępiana, bywa naturalnym odruchem obronnym albo po prostu sposobem na złagodzenie zderzenia żywego projektu z jakąś sztywną strukturą biurokratyczną (nie chodzi tu tylko o niepotrzebne dokumenty, także o gotowe oprogramowanie – np. gdy w ewolucji projektu jakiś komponent okazał się zbędny, ale kontrakt wymusza jego powstanie).

Gorzej, gdy na sztukę zaczynają powstawać rzeczy potrzebne. Niechlujne i nieutrzymywane specyfikacje ważnych protokołów. Skrótowe API rozbijające architekturę systemu. Formularze, których nikt nie jest w stanie poprawnie wypełnić. Przepełnione błędami moduły pomocnicze. Potwornie niewydajne zapytania. Niemożliwe do odczytania wykresy i raporty. Poprawki błędów, które usuwają problem dla wartości ośmiocyfrowych, pozostawiając ten sam problem dla siedmiocyfrowych. Hmm, mógłbym jeszcze długo…

Najłatwiej napisać o leniwych i niedbałych informatykach. Cóż – jak w każdym zawodzie, tak i w tym, jest jakiś odsetek zdemoralizowanych czy też kompletnie niekompetentnych pracowników. Ale – w mojej ocenie, takich osób jest akurat tutaj stosunkowo mało (choćby dlatego, że próg wejścia jest dość wysoki). Częściej (i gorzej) na sztukę zaczynają pracować wartościowi ludzie.

O jednym z powodów już było. Nie będę pracował z prawdziwym zaangażowaniem, gdy nie widzę sensu wykonywanej pracy – nie wiem, kto i po co ma czytać dokument, nie wierzę, by ktokolwiek korzystał z funkcji, spodziewam się, że komponent nigdy nie zostanie wdrożony. Uwaga: to moje przekonanie może być fałszywe, wynikać np. z braku komunikacji. Na jedno wychodzi. Skoro uważam, że piszę książkę na półkę, zadbam tylko, by miała dobry tytuł i ładne okładki.

Jest zwykłe przeciążenie pracą. Kreatywne, aktywne podejście wymaga pewnego komfortu. Trudno o nie, gdy wszystkie terminy są na wczoraj, trzy nowe zadania spadają jeszcze przed zakończeniem poprzedniego, a do tego nadużywane jest zarządzanie przy pomocy presji czasu i wyniku. Jeden z moich kolegów opowiada świetnie trafioną anegdotę o taczce. Właśnie tak!

Młody robotnik gania dookoła placu budowy z pustą taczką. Spieszy się, męczy. Obserwujący to człowiek w końcu pyta:
- przepraszam, czemu Pan tak lata z tą pustą taczką?
- Panie, my tu mamy taki zapierdziel, że nie ma kiedy załadować!

Mogę być najzwyczajniej w świecie źle zaalokowany. Coraz trudniej pracować w tej branży będąc tylko administratorem Apache 1.3 w środowisku RedHat albo programistą bazodanowym C++ w środowisku OpenVMS (ba – moim zdaniem bardzo wąskie specjalizacje się kończą, informatyk musi dysponować jakąś pulą umiejętności i być gotowym do jej regularnego poszerzania) ale oczekiwanie, że równie dobrze zaprojektuję schemat nawigacyjny serwisu webowego, przygotuję strukturę relacyjnej bazy danych, zdebugguję problemy w komunikacji sieciowej, zrobię Windowsowy instalator, a na koniec udokumentuję architekturę systemu jest przesadnie optymistyczne. Tj... – równie może się spełnić.

Nawet przy zachowaniu technicznej tematyki, ktoś rzucany między zadaniami, tematami i czynnościami jak budowlany przynieś-wynieś zacznie pracować z analogicznym zapałem. I naprawdę nie ma znaczenia, czy rzucanie wynika z optymalizacji projektu i resource-levellingu, czy też z bardziej swojskiej łapanki. Piszą nieraz, że autor projektu czy komponentu łatwiej go poprawi, bo go zna. To prawda, ale nie wiem czy nie ważniejsze jest poczucie własności, odpowiedzialności za swoje dzieło. Gdy jestem traktowany jako 40 roboczogodzin tygodniowo do dowolnej alokacji, mowy o tym nie ma – zamiast zajmować się tworzeniem czegoś, zajmuję się spędzaniem 40 godzin.

To dotyczy nawet dużo prostszych prac. Poczynając od japońskiego odkrycia, że zespół składający od początku do końca jakiś samochód lub maszynę pracuje lepiej, niż ludzie wkręcający te same śruby w 100 samochodów po kolei.

Mogę mieć gorszy okres. Z różnych powodów, od spraw rodzinnych po konflikt w zespole. Bardzo szczególnym przypadkiem gorszego okresu jest czas niedługo po zakończeniu intensywnego, ważnego projektu.

Jest wreszcie, najbardziej subtelna, sprawa zniechęcenia. Gdy angażuję się, zauważam problemy, proponuję ulepszenia. I – trafiam w pustkę. Albo w przełożonego, który po 30 sekundach zapoznawania się z problemem, nad którym myślałem przez tydzień, podejmuje autorytatywną decyzję.  Albo w klienta, który żąda wiernej implementacji nieudanego projektu – bo tak. Albo … Kilka takich wydarzeń z rzędu niesłychanie demotywuje.

Czy praca na sztukę jest bezużyteczna? Wojskowe rozwiązanie problemu to szczegółowa kontrola i weryfikacja. Jeśli sierżant dokładnie sprawdzi karabiny, to będą one wyczyszczone. Problem zmotywowania sierżanta rozwiązywany jest kombinacją kolejnego poziomu nadzoru z doborem osób o niezbędnym minimum złośliwości czy sadyzmu (hmm, podobny profil psychologiczny może dać niezłego testera). Tyle, że w informatyce tak się nie da. Ocenienie jakości programu, projektu czy dokumentu, to trudna i czasochłonna praca, nieraz porównywalna z samym jego wykonaniem. Sierżant nie da rady sprawdzić. Ba! Nawet nie da rady udawać, że sprawdza!

Problem motywowania sierżanta nie jest wcale trywialny. Nawet w wojsku. Ileż to ja umiejętności podobno opanowałem, gdy tam byłem – przynajmniej, jeśli wierzyć raportom moich przełożonych.

No dobra – ale co z tego. Pomarudziłem, ale jakie jest rozwiązanie problemu?

Nie psuć!

Na początku jest dobrze.