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

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.

bookmark_borderPrawo Brooksa

Estymacja się nie udała, deadline nas pokonał, nie wyrobimy się. Manager dorzuca ludzi do projektu, ale okazuje się to być gaszeniem pożaru benzyną. Poznajcie prawo Brooksa.

Fred Brooks jest jedną z najbardziej znanych postaci z dziedziny rozwoju oprogramowania. W Polsce nie wiedzieć czemu jest stosunkowo nieznany, a szkoda. Brooks zrobił w życiu dwie wielkie rzeczy – solidnie przyłożył się do rozwoju produktów IBM, w tym OS/360 oraz napisał książkę Mityczny osobomiesiąc. To właśnie z niej, a konkretniej z tytułowego eseju pochodzi prawo nazwane jego nazwiskiem – prawo Brooksa.

Prawo Brooksa mówi:

„dodawanie ludzi do opóźnionego projektu opóźnia go jeszcze bardziej”

Bardzo bym chciał, by świadomość tej reguły upowszechniła się nad Wisłą, bo oszczędziłoby to wielu programistom i menedżerom zbędnego stresu…

Dziewięć kobiet nie urodzi dziecka w miesiąc

W eseju opisującym prawo Brooksa, autor rozróżnia zadania na trzy rodzaje:

  • zadania idealnie podzielne
  • zadania niepodzielne
  • zadania podzielne, wymagające komunikacji

Zadania idealnie podzielne

Skręcanie długopisów lub zbieranie szparagów to przykłady zadań idealnie podzielnych. Dzielimy to, co jest do wykonania na części i przydzielamy różnym pracownikom. Nie istnieje potrzeba by się między sobą komunikowali. Chcąc wykonać pracę szybciej możemy wysłać na pole albo do skręcania więcej ludzi. Wyślemy dwukrotnie więcej, dwukrotnie szybciej skończą.

Zadania niepodzielne

Choćbyśmy do wymiany oleju w samochodzie przydzielili pięciu mechaników, to nie zrobią tego szybciej. Olej musi spłynąć, nowy musi być nalany. Nic nie da dodawanie ludzi.

Zadania podzielne, wymagające komunikacji

I tu właśnie dochodzimy do tworzenia programowania. Wykonanie nowej aplikacji wymaga koordynacji między członkami zespołu. Co więcej wymaga również wdrożenia nowych osób.

Poniższa grafika ilustruje, jak lawinowo rośnie potencjalna ilość interakcji w zespole w zależności od ilości członków. Każda interakcja, rozmowa, wymiana wiedzy między dwoma osobami kosztuje czas, czas tym cenniejszy im bardziej spóźniony jest projekt.

Nowi ludzie w projekcie

Najgorsze w prawie Brooksa jest to, że jest ono sprzeczne z intuicją. Wydaje się bowiem oczywiste, że jeśli jakieś zadanie będzie wykonywała większa ilość osób to muszą je skończyć szybciej. W końcu projekt to nie jedno, ale wiele zadań. Na tablicy „do zrobienia” są różne taski, więc wezmą je i zaczną działać. Co może pójść nie tak?

Wbrew pozorom – sporo.

Przychodzą nowe osoby. Konfigurują swoje komputery, instalują oprogramowanie, ściągają kod źródłowy. Niby coś robią, ale żadnego z tego widocznego efektu przez pierwsze godziny/dni. Wydaliśmy pieniądze, a nie zyskaliśmy jeszcze nic.

Wszystko jest technicznie gotowe, nowi mogą zacząć pracę. Muszą się jednak dowiedzieć, co mają do zrobienia. Organizuje się więc spotkania wyjaśniające naturę projektu. Teraz już nie tylko nowe osoby w projekcie nie posuwają pracy do przodu, ale też dotychczasowi członkowie zespołu przestali pracować nad tym co kluczowe.

Spotkania się zakończyły. Nowi mniej więcej wiedzą, co robić. Zaczynają pracę. Wydaje się, że postęp w końcu ruszy z kopyta. Tymczasem wszystkie okresowe spotkania w zespole zaczęły zajmować więcej czasu. Zakładając, że pracujemy w scrum – dłuższe stają się daily, refinementy, planowanie sprintu i retrospekcja.

Wszystko wydaje się iść do przodu, ale to, czego nie widać na pierwszy rzut oka, to nieustanne pytania nowych osób do starej części zespołu. Nie da się również zauważyć, że te pytania przerywając pracę rujnują ich skupienie. Czasami po kilku minutach rozmowy programista potrzebuje piętnastu minut lub pół godziny, by wrócić do produktywności sprzed rozproszenia. Co więcej programiści pracują przecież nad tymi samymi plikami w zespole. Kiedy było ich trzech nie wchodzili sobie za bardzo w drogę. Nagle okazuje się, że merge’owanie, scalanie plików po zmianach kolejnych trzech osób staje się zmorą i zajmuje dużo czasu. Wydajność wszystkich znacząco spadła, zadowolenie również, a postęp jest wolniejszy, niż się spodziewaliśmy. Dopadło nas prawo Brooksa.

To co, nic nie robić?

Co robić w przypadku opóźnionego projektu to oczywiście doskonałe pytanie, na które jak sądzę nie da się odpowiedzieć ogólnie. Nie byłbym na tyle ortodoksyjny, by stwierdzić, że na pewno nie można dodać kolejnej osoby do zespołu, ale sądzę, że warto się nad tym dobrze zastanowić, przemyśleć ile takich osób i na jak długo planujemy dokoptować, a także koniecznie trzeba porozmawiać z zespołem i zapytać, jak taki pomysł im się podoba.

W wielu przypadkach naprawdę nie ma sensu dodawać ludzi do spóźnionego projektu. Deadline i tak będzie przekroczony, praca zakończy się szybciej, niż gdyby nie dodawać nikogo, a koszt będzie niepotrzebnie zwiększony.

Co jednak bardziej istotne, czasami dodanie ludzi do zespołu może skończyć się autentyczną tragedią. Wtedy prawo Brooksa ujawnia się z całą jaskrawością. Jeśli termin jest naprawdę krótki, a ilosć osób już oscyluje wokół dziewięciu i chcemy dorzucić jeszcze czwórkę, może się okazać, że zespół się kompletnie komunikacyjnie zakorkuje i nie tylko nie dostarczy produktu na czas, ale dostarczy zdecydowanie później, niż byśmy się spodziewali i to absurdalnie większym kosztem.