Dzisiaj temat kulturowy. Żyjemy w mocno nieagile’owym kraju, a mindset jakim karmieni jesteśmy od urodzenia niewiele ma wspólnego ze zwinnością. Bo od zawsze wmawia nam się, że lepiej być zapracowanym niż zrobić to samo szybko i mieć z głowy. Skąd się bierze ta gloryfikacja zapracowania?
Zapracowany == pożyteczny?
link-timesheet,IT
W dobie wszechobecnego wypełniania timesheetów i przeliczania ról na zysk można mieć wrażenie, że nawet w branży IT liczy się „wykonywanie pracy”, a nie jej kończenie. Stąd na przykład traktowanie SM-a jako roli kosztowej, o czym pisaliśmy chociażby w tekście „Skuteczny Scrum Master„.
Mówiąc wprost – skoro zatrudniamy profesjonalistów i płacimy im x zł za osiem godzin pracy, to chcemy, żeby ten czas odpracowali. Nie liczy się efekt, jaki chcemy osiągnąć, ale „dupogodziny”. No bo jeśli tę samą pracę ktoś wykona w cztery godziny to postrzeganie większości jest takie, że firma na tym „traci”. Przecież wtedy płaci za 4 godziny „nicnierobienia”. Ktoś mógłby zostać dwa razy dłużej i zrobić dwa razy więcej.
Tylko to nie zawsze tak działa. Nie zależy nam na wyciśnięciu ludzi jak cytryny, tylko na efektywnej, długofalowej pracy. Budując zespoły, dbając o skomplikowane relacje wewnątrz niego budujemy (współ)odpowiedzialność za wyniki, co zwraca nam się w długim terminie. Tu zawsze pojawia się gwiazdeczka: jeżeli nasz projekt trwa dwa miesiące po których rozwiązujemy zespół, to faktycznie praca po 60 czy 80 godzin tygodniowo będzie bardziej efektywna. Tylko czy na pewno chcemy iść w tę stronę?
W tym miejscu warto też przypomnieć jeden z moich ulubionych sucharów. Jak nazywa się autostrada, której utylizacja osiągnęła sto procent? Parking. (kurtyna) Tak się kończy pogoń za „utylizacją zasobów”, niektórzy dodaliby „ludzkich”.
Po efektach ich poznacie
Nie warto pracować bez efektów. Gdybym miał możliwość pisania tekstów takich jak ten w dziesięć minut, to bym z niej skorzystał. Tak samo zatrudniając kogoś do współpracy wolę osobę, która zrobi co trzeba w godzinę, a nie taką, która będzie nad czymś siedziała pół nocy. Niestety, w naszym klimacie ten, kto siedzi w nadgodzinach to dobry pracownik, a ten co zrobi to samo w pięć godzin i wyjdzie do domu jest leniem.
„Przecież jak będę płacił za efekty, to ludzie zrobią minimum tego, co trzeba w połowę czasu i pójdą sobie do domu.” – Polska Szkoła Managerska
Wiele patologii rodzi się z prób doceniania nie tego, co trzeba. Weźmy na przykład nasze „ulubione” Velocity. Nie od dziś wiadomo jest, że gdy zaczniemy porównywać prędkość między zespołami, chwalić tych co „dowożą więcej” albo wręcz ich za to premiować, to sami sobie strzelimy w kolano. Albo oba.
Szerzej tematem wypaczania systemów premiowych zajmowaliśmy się przy okazji tekstu o motywacji. Dla przypomnienia: intencje nie mają znaczenia, bo zarówno świadomość jak i podświadomość zadziałają tak, aby nasz „cel premiowy” wypaczyć. Nie ze złej woli, ale z powodu ludzkiej natury. Więc jeżeli już coś chcemy doceniać, to raczej nie bezpośrednie rezultaty naszej pracy, ale wyniki naszego produktu. Czyli, na przykład ilość operacji wykonanych przez naszych klientów albo popularność naszej aplikacji. Tego się nie da „zhakować”.
Tylko tu pojawia się jeden problem. Możemy osiągnąć cel, wcale się przy tym nie wysilając. I z jakiegoś powodu, jest duża szansa, że zostanie to źle odebrane. Bo taki mamy klimat i brak zaufania. Przecież jeśli zatrudnimy zmotywowanych ludzi i damy im ciekawą pracę, to oni sami będą chcieli ją wykonywać jak najlepiej. Bo ich to kręci.
A może nawet przy okazji wykażą się pozytywnym lenistwem.
Pragmatyzm, a zapracowanie
Pragmatyk jest „pozytywnie leniwy”. Jeżeli można coś zrobić na dwa sposoby, przy czym jeden wymaga większego nakładu pracy, a drugi – dużo mniejszego, to zrobi on to tym prostszym.
Mieliśmy ostatnio bardzo ciekawą dyskusję na temat tego, czy Scrum Team może proponować rozwiązania, które można zrealizować bez tworzenia Przyrostu. Jeżeli w backlogu mamy wymagania, a nie zadania, to jestem sobie w stanie wyobrazić, że jakąś potrzebę biznesową można spełnić bez developmentu. Ot, wykorzystujemy już gotowe elementy i procesy i voilà, mamy to co chcieliśmy.
Zwykle nie będzie aż tak różowo. Ale czasami jesteśmy w stanie szybko wytworzyć MVP, które będzie wystarczające do przetestowania naszej idei „na ludziach”, a które nie będzie wymagało budowy systemu do zarządzania wszechświatem. Tutaj przypominamy klasyczny przykład z deskorolką wyciągniętą z piwnicy i otrzepaną z kurzu. Dostarczając taki produkt zapewniamy sobie a) czas na tworzenie bardziej dojrzałego rozwiązania b) możliwość sprawdzenia w praktyce, czy w ogóle ten kierunek ma sens.
Wróćmy jednak do naszej prostoty. Z jednej strony powinniśmy wybierać rozwiązania najprostsze, prowadzące jak najszybciej do celu. Z drugiej strony każdy z nas jakoś podświadomie boi się, że jeśli zrealizujemy „dwa razy więcej dwa razy szybciej”, to następnym razem po prostu dostaniemy osiem razy więcej do roboty.
I tu z pomocą przychodzi nam Scrum. Poniekąd.
Scrum, a zapracowanie
Scrum nie zakłada, że będziemy pracować coraz szybciej i szybciej, bo każdy taki postęp kiedyś się skończy. Tu można by wdać się w ekonomiczną dyskusję na temat tego, dlaczego firmy (i kraje) cenione są za tempo wzrostu, a nie za zdolność do utrzymania wydajności. Przecież nie da się przyspieszać w nieskończoność. Ale wróćmy do naszych zespołów.
„Procesy zwinne umożliwiają zrównoważony rozwój. Sponsorzy, deweloperzy oraz użytkownicy powinni być w stanie utrzymywać równe tempo pracy w nieskończoność.” – Agile Manifesto
Development Team dba o stan swoich umysłów (i zapracowania) na spotkaniu zwanym Sprint Planning. To tam dba o to, żeby ilość pracy w Sprincie nie rosła wykładniczo. Co więcej, rozsądny Product Owner będzie wolał, żeby zespół realizował 80% historycznego maksimum w każdym Sprincie, zamiast od 60% do 100%, w zależności jak pójdzie. Przewidywalność jest bardzo istotna dla PO.
Planowanie to nie jest jedyne miejsce, gdzie wykorzystujemy pragmatyzm i staramy się oszczędzić sobie pracy. Inne to oczywiście Product Backlog Refinment, gdzie powstaje pierwsza koncepcja rozwiązań. I to tam możemy sobie zapewnić, że najpierw zrobimy rozwiązanie proste, szybkie i często dalekie od ideału, a potem, jeżeli będzie taka potrzeba, zostanie ono rozwinięte.
Dzięki tym dwóm mechanizmom oraz oddaniu sposobu spełnienia wymagań biznesowych do „leniwych” zespołów jesteśmy w stanie zmniejszyć nasze zapracowanie. Niekoniecznie znaczy to, że będziemy wytwarzać mniej, ale za to będziemy robić to mądrzej. Pozbędziemy się wodotrysków, którymi nasz odbiorca nie jest zainteresowany i skupimy się na dostarczaniu wartości.
Do walki z gloryfikacją zapracowania wcale nie potrzebujemy jednak Scruma. Przede wszystkim potrzebujemy innego nastawienia i kultury w naszej organizacji. Nie patrzmy na to, ile kto „siedzi”, bo wtedy faktycznie ludzie będą siedzieć, zamiast pracować. Zamiast tego skupmy się na efektach i patrzmy na organizm zespołowy jako na całość. Jak to powtarzaliśmy wielokrotnie – zapewnijmy im odpowiednie środowisko, dajmy zaufanie, a oni się zorganizują tak, że efekty będą bardziej niż zadowalające.
I to od nich wtedy zależy czy zrobią to leniwie, czy wybiorą bycie zapracowanymi.
