współpraca | Programista też człowiek

Zdemotywowany zespół programistów to utrapienie. Kosztowne i nieprzyjemne. W przeciwieństwie do pracy fizycznej, którą latami wykonywano pod przymusem bata, praca umysłowa jest ciężka lub niemożliwa do wyegzekwowania siłą…

Oto siedem oznak, że zespół jest zdemotywowany:

1. Nierozmowność

Na spotkaniach on-line większość osób milczy, na spotkaniach na żywo bawią się telefonami.

2. Reaktywność

Członkowie zespołu zachowują się reaktywnie – nie wychodzą z inicjatywą, ale czekają na polecenia.

3. Wychodzenie jak najwcześniej, przychodzenie jak najpóźniej

Nie lubiąc pracy ludzie próbują spędzać w niej jak najmniej czasu – przychodzą idealnie o dziewiątej, wychodzą zaś punkt piąta. O ile robi tak jedna osoba, może to znaczyć, że mamy do czynienia z kimś bardzo zorganizowanym, jednak, jeśli wszyscy pracownicy uciekają pod koniec dnia jakby w biurze wybuchał pożar – wiedz, że coś się dzieje.

4. Częste obserwowanie zegarka, patrzenie za okno, przesiadywanie w kuchni, w toalecie

Każdy sposób jest dobry, by uciec od pracy, której się nie lubi. Kawa co godzina, siku co pół godziny, spacer do chillroomu trzy razy dziennie.

5. Bezproduktywność

Ostateczny skutek demotywacji – po prostu praca nie jest zrobiona albo jest zrobiona w absolutnie minimalnym stopniu.

6. Brak ochotników

Szef przychodzi do zespołu i szuka ochotników. Wszyscy patrzą w monitory, nikt nie podnosi ręki. Maciek wychodzi do toalety. Magda do kuchni. Bartek nawet nie zdjął słuchawek.

7. Absencja

Urlopy na żądanie, L-quattro, bóle głowy, menstruacje, kace, cokolwiek. Nie lubiąc miejsca pracy ludzie próbują z niego uciekać. Choćby jeden dzień bez patrzenia na ten nieszczęsny projekt jest dla nich wybawieniem.

***

Objawy demotywacji to jednak niekoniecznie problem jedynie zespołu. Łatwo jest zrzucić winę na konkretnych ludzi, na projekt, na kierownika. Wydaje się jednak rozsądniejszym, by spojrzeć na sprawę analitycznie. Może inne zespoły utrudniają naszemu pracę? Może walczą między sobą? Może procedury w przedsiębiorstwie są nieznośne? Może płace niskie? Może słaby sprzęt przeszkadza w pracy? Demotywacja jest jak gorączka. Trzeba ją zwalczać, by nie zabiła, ale też trzeba poznać jej przyczynę, bo faszerowanie się lekami przeciwgorączkowymi bez diagnozy może doprowadzić do tragedii.

Do zadania tytułowego pytania i próby udzielenia na nie odpowiedzi skłonił mnie ten artykuł: https://wedlugplanu.pl/zarzadzanie-projektami/noestimate-manifest-wycen/ , w którym autor odnosi się do idei #noestimate, czyli postulatu porzucenia wyceny zadań, Dla wielu osób zabrzmi to pewnie, jak zgrzyt paznokci na tablicy i wierutna bzdura, ale prawdę mówiąc coś jest moim zdaniem na rzeczy.

Programiści oczywiście wiedzą, czemu nie lubią wyceniać zadań. Wydaje mi się jednak, że osoby z biznesu mogą nie do końca rozumieć tę awersję do deklarowania szacowanego czasu wykonania pracy…

Wstyd i poczucie winy

Zacząłbym od tego, że spora część programistów jest dobrymi, pracowitymi ludźmi. Taka osoba nie lubi rzucać słów na wiatr. Jeśli mówi, że coś zajmie tydzień, a okazuje się, że nie da się go wykonać, odczuwa negatywne emocje. Wstyd, poczucie braku wymaganych umiejętności, wrażenie, że się kogoś zawiodło. Rozwiązania w tej sytuacji są dwa – odmowa udzielania kolejnych wycen lub ich zawyżanie.

Zadanie niemożliwe

Fundamentalny problem polega na tym, że w wielu przypadkach prawidłowe wykonanie wyceny, oszacowanie czasu wykonania zadania jest po prostu niemożliwe.

Kiedy ktoś zapyta nas, ile czasu zajmie nam przygotowanie kotleta schabowego, jesteśmy w stanie odpowiedzieć w miarę konkretnie. Zakładamy przy tym, że mamy wszystkie składniki i nic się nie wydarzy oraz że już kiedyś to robiliśmy.

Zwróćmy uwagę na te założenia. Zastanówmy się, co się dzieje, gdy nie są spełnione.

Zaczynamy pracę nad schabowym. Oszacowaliśmy ją na 30 minut. Otwieramy lodówkę i okazuje się, że mięso jest zepsute. Idziemy więc do mięsnego. Po 45 minutach wracamy z mięsem. Mówimy sobie – powinniśmy o tym pomyśleć. Nauczeni na błędzie rozglądamy się po kuchni i zastanawiamy się, co jest nam niezbędne. Tłuszcz, patelnia, kuchenka, panierka, tłuczek, deska, jajka. Wydaje się, że wszystko mamy. Zaczynamy raz jeszcze. I nagle okazuje się, że mimo dobrego terminu przydatności do spożycia wszystkie cztery jajka, jakie mieliśmy w domu są zepsute. Oczywiście powinniśmy mieć ich więcej, może dwie paczki, myślimy. Idziemy do sklepu i kupujemy jajka. “Zmarnowaliśmy” kolejne 30 minut, a jeszcze nie zaczęliśmy smażyć mięsa…

Mamy nowe jajka. Mamy mięso. Mamy wszystko. Ubiliśmy mięso tłuczkiem, obtoczyliśmy w panierce. Zaczynamy smażyć. I nie wierzymy własnym oczom. Wyłączono prąd.

Na szczęście tylko na 15 minut. W końcu udało się coś ugotować. Z początkowych 30 minut zrobiło się jednak… ponad dwie godziny.

Rzetelna wycena

Zakładając, że chcielibyśmy wykonać rzetelną wycenę musielibyśmy mieć:

kompletną specyfikację zadania, bez żadnych niespodzianek i improwizacji
doświadczenie w wykonywaniu analogicznych zadań
znamy narzędzia i zależności oraz system
wszystkie nasze zależności już istnieją i są niezawodne

Doświadczenie uczy, że nie tylko nie wszystko powyższe udaje się spełnić, lecz zwykle wręcz nic. Co więcej zrealizowanie tak rzetelnej wyceny zajmuje ogrom czasu i jest po prostu dysfunkcjonalne.

Współczynnik fi

Patrząc na powyższe problemy próbujemy zatem wycenę zawyżyć. Niektórzy mnożą przez dwa, inni przez współczynnik fi, czy inne pi albo stałą Plancka. Nic to nie daje, bo jak nieskończoność mnożona przez stałą daje nieskończoność, tak iloraz – czy choćby iloczyn – niepewności przez dowolną liczbę również równa się niepewności.

Czy jest na tym bożym świecie zadanie estymowalne?

Rozkładając już ręce w żałosnym geście zadajemy sobie powyższe pytanie. I w zasadzie odpowiedź brzmi: tak. Owszem, w wielu scenariuszach da się sensownie wyceniać. Kiedy robimy kolejną stronę wizytówkę w tej samej technologii, kiedy po edycji produktu tworzymy feature edycji kategorii w tym samym projekcie itp.

Niestety jednak sposobu wyceny projektów nowych, nowych feature’ów, implementacji w nieznanych frameworkach, wykonywanych przez nowo powstałe zepoły – nie ma. Po prostu nie ma.

Po co zatem szacować?

Na koniec odniosę się znów do wspomnianego na początku artykułu. Wyjaśnia on dobrze do czego – mimo ich pozornego braku logiki i ich niedokładności – potrzebne są wyceny. Warto rzucić okiem: https://wedlugplanu.pl/zarzadzanie-projektami/noestimate-manifest-wycen/

W wielkim jednak skrócie, by nie powtarzać niepotrzebnie argumentów, potrzebne są do planowania biznesu, budżetowania i alokacji zasobów. Możemy się w wycenie pomylić, choćby i dwukrotnie, ważne tylko, by nie o rząd wielkości, by z dwóch godzin nie zrobiło się godzin dwieście. Warto o tym pamiętać zarówno będą programistą, jak i zarządzając projektem.

Tag: współpraca

7 oznak, że twój zespół jest zdemotywowany