Wasze Historie #16: Co ma wspólnego developer z psem Pawłowa?

Na co dzień prowadzę projekty IT. Zdarza się też, że gromadzę wymagania projektowe, czyli przygotowuję tzw. analizy przedwykonawcze, na podstawie których programiści realizują projekt. Będąc na każdym etapie powstawania projektów zauważam szereg problemów skłaniających mnie do przemyśleń. Dzisiaj chciałbym się z Wami podzielić jednym z nich – czyli co ma wspólnego developer z psem Pawłowa? W tym wpisie zawarłem kilka anegdotek z mojego doświadczenia pracy z programistami – m.in. o dawaniu feedbacku na temat pracy i konstruowaniu kryterium oceny developerów.

Niniejszy post jest częścią cyklu "Wasze Historie".
Autor: Karol Wójciszko
Sprawdź też Fanpage i kanał YouTube Karola!

Co by tu dzisiaj zepsuć?

Głęboko wierzę w to, że ludzie z natury nie są źli. Uważam, że bardzo rzadko zdarza się sytuacja, w której ktoś przychodzi do pracy z myślą “co by dzisiaj zepsuć w projekcie?”. Większość osób chce być profesjonalistami i zachowują się na tyle profesjonalnie na ile potrafią – każdy lubi wykonywać dobrze pracę, a gdy jest jeszcze za to doceniany to czyni to perfekcyjny duet na linii pracownik – szef. Trzeba natomiast pamiętać, że będą zdarzały się sytuacje, w których mimo starań nie będzie nam się podobała praca developera – co nie czyni go “złym”. To świadczy jedynie o tym, że jego umiejętności twarde/miękkie nie pasują do stanowiska, na którym pracuje. Z perspektywy czasu wydaje mi się to logiczne – jednak nie zawsze takie było. Poruszam ten temat w jednym z wpisów z serii #spowiedź o tym żeby przypisywać właściwe zadania właściwym osobom.

Powiedz mi jak cię oceniają, a powiem ci jak się będziesz zachowywał

Każdy swoim zachowaniem dąży do tego, żeby było mu “jak najlepiej” – świadomie lub nie. To właśnie dlatego jeśli np spóźnienie jest karane to staramy się być na czas, a jeśli nie są wyciągane konsekwencje – mniej dbamy o punktualność. Chcemy, żeby było nam “lepiej” i wolimy uniknąć kary, a w przypadku gdy nie ma konsekwencji ze spóźnienia – wybieramy dłuższy sen. Bierzemy to co subiektywnie wydaje nam się “lepsze”. Wbrew pozorom nie rodzimy się z tą wiedzą co jest “lepsze” – uczymy się tego na podstawie tego jak nas oceniają.

To samo się dzieje gdy jesteśmy developerem i rozpoczynamy pracę w nowej firmie. Na początku nie wiemy co jest istotne – czy najważniejszą rzeczą jest zamykanie zadań, czy może uzupełniony timesheet? Może liczy się dostępność w ciągu dnia? Nie wiesz, musisz się tego nauczyć. Powiem więcej – mało która organizacja zdaje sobie sprawę co jest z jej punktu widzenia istotne. Potrafią to egzekwować, ale nie potrafią tego nazwać. Każda organizacja dobiera indywidualnie wcześniej wspomniane”wskaźniki”. Dobrym wyznacznikiem tego, że wskaźniki są źle dobrane jest sytuacja, gdy wszystko na papierze jest OK, a w praktyce nie do końca działa jak powinno.

Na pewno spotkaliście się z firmą, która zatrudnia wyłącznie wykształconych programistów z wysokimi umiejętnościami, używają najnowszych i “najlepszych” narzędzi, a mimo to coś jest nie tak i projekty nie są kończone w terminie. W teorii wszystko jest w jak najlepszym porządku – ludzie mają kompetencje by wykonywać dobrze swoją pracę, jednak tak się nie dzieje. To właśnie przykład źle dobranych wskaźników oceny pracy. Takie rzeczy nagminnie dzieją się w różnego rodzaju fabrykach z liniami produkcyjnymi. Zmiana (pracownicy) są oceniani po tym np ile wyprodukują danego dnia części – więc starają się wyprodukować ich jak najwięcej. Niby nie ma w tym nic złego, wiele osób uważa, że więcej = lepiej. Jednak jeśli oceniamy wyłącznie ilość to znacznie spada jakość – przez to część produkcji nie jest w ogóle użyteczna. Kolejną rzeczą jest to, że konkretna zmiana pracownicza będzie produkowała elementy nawet wtedy gdy będzie ich nadmiar – co będzie skutkowało zajmowaniem znacznej części magazynu, generowało koszta i narażało nadmiar elementów na zniszczenia. Nie jest to wina pracowników – oni wykonują swoją robotę najlepiej jak potrafią, robią to po czym będą oceniani. Winne jest kierownictwo za źle dobrane wskaźniki oceny. Bo chyba nikt nie uważa, że pracownik fabryki powie w pewnym momencie: “Ej, nie będę narażał firmy na straty, przestanę produkować te elementy, nawet jeśli to będzie kosztem zwolnienia za niesubordynację!” :).

Dlatego uważam za bardzo trafne stwierdzenie: powiedz po czym cię oceniają, a powiem ci jak będziesz się zachowywał. Analogię z fabryki można przenieść na każdy zawód – w tym programistę, kierownika projektu etc.

Wiem, że długo rozwijałem się aby wreszcie przytoczyć analogię tytułową, ale pewnie wielu z was załapało ją już we wcześniejszych akapitach.Jeśli ktoś nie zna eksperymentu z psem Pawłowa, tutaj daję link, w którym jest opisane warunkowanie klasyczne. Organizm psa, wiedząc, że będzie karmiony zachowywał się tak by łatwiej było mu jeść (ślinił się, a ślina trawi pokarm). Jest to odruch bezwarunkowy. Zauważam w tym dużą analogię do tego jak sami adaptujemy się do dawanych nam zadań w pracy. Wiemy, co jest oczekiwane i w pewnym sensie wykonujemy je odruchowo. Dostając zadanie wiemy jakie parametry będą oceniane – staramy się je wykonać tak by osiągnąć jak najwyższą ocenę parametrów (co często nie jest tożsame z jak najlepszym wykonaniem zadania). Więcej o miarach projektowych opisałem w wpisie jak raportować stan projektu?

Pozytywny feedback

Kolejną myśl opiszę z perspektywy kierownika projektu i developera, ale ta analogia jest aktualna również dla innych relacji przełożony – nadzorujący. Uważam, że najważniejszym narzędziem w pracy jest komunikacja. Kierownicy projektu komunikują developerom co będzie efektem ich pracy. Jeśli mają zastrzeżenia co do pracy również dają o tym znać. W tym miejscu poruszę temat dawania uwag w celu korygowania błędów by polepszyć jakość pracy. Spotkałem wielu kierowników projektu, którzy w ramach zasady otwartej komunikacji dawali feedback developerom na temat ich pracy. Były to uwagi w stylu: “to było złe, nie rób tego więcej”. Dochodziło do sytuacji, że praca developerów była korygowana uwagami na temat tego gdzie popełnili błędy. Tak jak wcześniej wspomniałem – ludzie adoptują się do wskaźników po których byli oceniani. Doszło do tego, że ich założeniem było “nie popełnić błędów” – bo jeśli nie popełnię błędu to znaczy, że dobrze przepracowałem dzień. Oczywiście miarą była liczba uwag.

Większość developerów po pewnym czasie nauczyła się co można i czego nie można i nie popełniali błędów. Z pozoru sytuacja wygląda ok, jednak wcale taka nie była. Kierownik projektu przybrał miarę liczby wytkniętych błędów – przez co żeby utrzymać jakość musiał poddawać działania kontroli. Sprawdzać czy nie zawierają zachowań, które trzeba skorygować. Nie muszę mówić jak bardzo jest to absorbujące. Ja sam, może nie w takiej skali, ale również popełniałem ten błąd. Do pewnych przemyśleń natomiast skłoniła mnie książka Dale Carnegie “Jak zdobyć przyjaciół i zjednać sobie ludzi”. Przeniosłem pewną myśl z książki na zarządzanie projektami i w perspektywie czasu pozytywny efekt był zauważalny. Głównie chodzi o to, żeby mówić developerom nie o tym co zrobili źle, ale o tym co zrobili dobrze. Nie mam tutaj na myśli głaskania i kadzenia. Chodzi o to żeby wyznacznikiem miary była dobrze wykonana praca, a nie brak błędów. Żeby to osiągnąć nie trzeba mówić “jesteś świetny, niesamowity kod!”. Wystarczy zwykłe “właśnie o to chodziło”. Nie chodzi o chwalenie – chodzi o zakomunikowanie, że tego oczekiwałeś. Stosując takie podejście uzyskujesz to, że zespół uważa, że wyznacznikiem pracy jest dobrze wykonana robota. Zespół nie stara się NIE POPEŁNIĆ błędu, tylko dostarczyć jakościowe rozwiązanie. To nie jest tożsame. Dzięki temu nie trzeba nadzorować każdej godziny pracy w poszukiwaniu błędów w pracy – wystarczy rzucić okiem na efekt końcowy – zespół jest bardziej zmotywowany do osiągania celów, bo ocenia się go po efekcie pracy.

Podsumowanie

Chcę żeby była jasność – jestem daleki od “amerykańskich poradników” skupiających się na sentencjach “możesz osiągnąć wszystko”. Nie chodzi mi o couching, skupiający się na mówieniu miłych rzeczy. Chcę przekazać to, że komunikując o tym, że ktoś wykonał dobrze swoją pracę zmieniamy punkt widzenia i wyznaczniki pracy. Nie mam badań na ten temat, ale “u mnie działa” – zauważalnie. Twierdzę również, że bez konstruktywnej krytyki się nie obejdzie – chodzi jednak o to by odpowiednio dobierać wskaźniki oceny, bo robiąc to źle sami tworzymy sobie niepotrzebną pracę. Kluczowe jest zachowanie balansu pomiędzy rodzajem dawanych uwag. Jeśli w twoim projekcie na papierze wygląda wszystko OK, natomiast praktyka pokazuje coś zupełnie innego – zastanów się głębiej nad treścią tego wpisu.