-
Co jest pracą a co nie?
Podobno kiedyś, dawno temu na Wojskowej Akademii Technicznej w Warszawie był sobie pewien naukowiec. Miał on taki zwyczaj, że kiedy rozwiązywał jakiś trudny problem, to chodził tam i z powrotem po pokoju – ruch pomagał mu myśleć. Legenda głosi, że do WAT trafił nowy komendant i traf chciał, że z okna jego gabinetu było świetnie widać okno pokoju owego naukowca znajdujące się po drugiej stronie podwórza. Nie raz więc komendant obserwował go chodzącego intensywnie po pokoju. W końcu nie wytrzymał, wezwał go do siebie i powiedział mu tak:
– Proszę pana, widzę jak chodzi pan stale tam i z powrotem po pokoju. Tak być nie może. My płacimy panu za to, żeby pan pracował naukowo a nie chodził po pokoju. Proszę siedzieć i uczciwie pracować przez osiem godzin. Do widzenia!
Nie wiem czy anegdota ta jest prawdziwa, ale dość dobrze ilustruje ona absurdalność wąskiego postrzegania pracy – zwłaszcza intelektualnej – jako czegoś co da się sprowadzić do konkretnej czynności. Niestety, takie postrzeganie jest powszechne – a przy tym jak wszelkie błędne przekonania – prowadzi do podejmowania bezsensownych działań.
Źródłem tego problemu jest niewątpliwie fakt, że przez większą część historii ludzkości większość pracy wykonywanej przez większość ludzi to była praca fizyczna. Przy pracy fizycznej jest dość łatwo określić kiedy się pracuje a kiedy nie. Odruchowo zatem to na pracy fizycznej zbudowane są intuicje, którymi się posługujemy mówiąc o pracy. Ba! Są one nawet zawarte w samym języku (np. „pracować w pocie czoła”).
Pojawienie się prostych maszyn w wieku 18 i 19 niewiele zmieniło – człowiek najczęściej dostarczał zręczności i inteligentnego sterowania, którego maszyny te nie miały. Praca zatem tym różniła się od pracy fizycznej, że polegała na obsłudze jakiegoś urządzenia. Wszystkie wywiedzione z pracy fizycznej intuicje co do tego kiedy pracownik pracuje a kiedy nie nadal pozostawały prawidłowe. Pracownik pracował kiedy stał przy maszynie i coś robił, kiedy od niej odchodził to nie pracował. Zatem, czas przez niego na pracy, a więc obsłudze jakiejś maszyny, mógł być dobrą miarą produktywności.
Na początku zeszłego wieku Taylor dodał do tego naukową systematyzację jeszcze skuteczniej wbijając nam do głów takie dwie zasadnicze intuicje:
- praca to obsługiwanie jakiejś maszyny lub wykonywanie jakiejś czynności,
- czas pracy jest dobrą miarą pracy gdyż kiedy pracownik nie obsługuje maszyny lub nie wykonuje czynności to nie przynosi wartości – a więc nie pracuje.
Zaowocowało to pomiarem czasu pracy i optymalizacją zarówno tego czasu jak i czynności czy wręcz ruchów pracownika tak, żeby ów czas pracy był maksymalnie dobrze wykorzystany. Ponieważ kolejną cechą prostej pracy są proste miary jej rezultatów – sztuki wyprodukowanych części, metry czy kilogramy materiału, litry płynu itp. – łatwo było określić wydajność jako stosunek właśnie takiej miary ilościowej do czasu spędzanego przez pracownika na pracy. Jak już ją można było zmierzyć to można było obserwować wpływ różnych działań (np. skrócenia czasu pracy do 8h) na tak rozumianą wydajność.
W przemyśle był to krok do przodu, jednak cały ten mechanizm kompletnie się załamuje przy pracy intelektualnej. Weźmy na przykład osobę programującą (często etykietowaną jako „programista”). Stwierdzenie, że programista pracuje kiedy wytwarza kod jest tak absurdalne, że aż ciężko uwierzyć, że może być traktowane poważnie. A jednak sami programiści często tak właśnie postrzegają swoją pracę uważając za czas efektywnej pracy tylko momenty kiedy siedzą przed ekranem i klepią kod pozostając w mitycznym stanie „flow”. I – logicznie – ludzie widzący tak swoją pracę postrzegają wtedy wszelkie inne wydarzenia w pracy – na przykład spotkania – jako „nie-pracę”, a więc marnotrawstwo i bezsens. Podobnie, niestety, myśli wielu kierowników.
Tymczasem kod jest tylko efektem najważniejszego procesu w pracy intelektualnej jakim jest myślenie. Narzędziem tej pracy jest mózg, który programista zasadniczo ma ze sobą cały czas. Czy jeśli jadąc autobusem do domu zastanawia się jaki algorytm przyłożyć do problemu to pracuje czy nie? Zewnętrznie nie – nie siedzi przy komputerze, w ogóle nie przebywa w biurze, efektem nie jest choćby pół linijki kodu. Faktycznie jednak pracuje.
Idźmy dalej. Jeśli nasz programista nie pracuje w pojedynkę, to musi jakoś uzgadniać rozwiązania i to, co będzie robione z innymi – czy komunikacja z nimi to „nie-praca”? Czyż zatem czas spędzony np. w zespole przed tablicą na omawianiu rozwiązań i towarzyszące temu zwykle tworzenie na owej tablicy typowych dla tego procesu bazgrołów – schematów, zapisków – nie jest również integralną częścią pracy? Jest nią oczywiście, nawet pomimo tego, że efektów tej pracy nie da się zmierzyć punktami funkcyjnymi.
A przecież to tylko pierwszy „poziom błędu” – jeśli tak można powiedzieć – bo przecież zespół programistów może stworzyć piękny, elegancki kod, który jednak będzie całkowicie bezwartościowy. Kiedy tak będzie? Ano kiedy ów kod nie będzie przydatny dla użytkownika czy klienta. W takiej sytuacji cały czas spędzony na jego tworzeniu można uznać za całkowicie zmarnotrawiony. Jak widać kluczowe znaczenie ma komunikowanie się programisty z klientem, które niewątpliwie jest również integralnym elementem pracy, bo bez tego może się ona okazać całkowicie pozbawiona sensu. Zatem na przykład poświęcone temu dokładnie spotkanie zwane „Przeglądem Sprintu” jest integralną częścią pracy a nie „nie-pracą” albo przerwą w pracy. Istotą jego jest bowiem badanie czy wytworzony produkt ma sens dla odbiorców. I choć programiści nie stworzą na tym spotkaniu ani jednej klasy to jest to inherentna część ich pracy.
Nie negując zatem wagi i znaczenia samego kodowania oraz koniecznego dla tego skupienia (bo rzeczywiście na tym schodzi dużo czasu) praca zwana programowaniem jest złożoną pracą intelektualną, składającą się z wielu czynności, podczas których powstaje wiele produktów pośrednich o ulotnej wartości nie będących kodem (jak choćby owe bazgroły na tablicy – bardzo wartościowe tu i teraz dla konkretnego zespołu, zupełnie bezwartościowe już miesiąc później).
Wszystko co napisałem powyżej biorąc sobie jako przykład osobę programującą (którą dla wygody pisania określiłem stosowną etykietką) odnosi się do wszelkich specjalistów, którzy coś tworzą i wymyślają – np. testerów, grafików, pisarzy itp. W istocie to, co chcielibyśmy osiągnąć – ów „wysokowydajny zespół” który jest celem zabiegów Scrum Masterów i innych (bo przecież nie tylko w Scrumie takowy zespół jest możliwy) to zespół, w którym wszyscy wkładają wszelkie swoje kompetencje w tworzenie dobrego produktu – a więc nie tylko poprawnego technicznie ale i sensownego, wartościowego – nie zaś skupiają się na wykonywaniu swoich wąskich czynności stroniąc od wszystkiego innego jako „nie-pracy”.
Jest ważne by zdawać sobie sprawę, że twórcza praca intelektualna nie polega na tym, że każdy „zaetykietkowany” człowiek wykonuje swoje określone czynności („zadania”). Brak tej świadomości prowadzi organizacje do robienia rzeczy głupich takich jak na przykład liczenie godzin pracy zespołów developerskich czy etykietkowanie i tworzenie silosów specjalizacji.
-
Kwintesencja polskiego problemu z etyką pracy
To zdjęcie pokazuje świetnie, w jednym obrazie, pewien feler naszej kultury, który odciska się przemożnie na etyce pracy w Polsce.
Najpierw wyjaśnienie dla laików co na tym zdjęciu widać. Jest to zdjęcie z toalety w wagonie PKP. Na zdjęciu widzimy u góry specjalny dozownik do mydła w kawałkach. Dozownik ten działa w ten sposób, że jeśli pokręcać ręką czarnym pierścieniem widocznym u dołu to przez znajdujący się w nim otwór spadają na dłoń wiórki mydła zeskrobywane ze znajdującej się w środku kostki. Kostki muszą być specjalne – mieć odpowiednie wymiary oraz charakterystyczny kształt podłużnego prostopadłościanu z dziurką w środku. Takie właśnie mydło widzimy leżace pod dozownikiem.Obrazek ten jest znany praktycznie każdemu, kto podróżował kiedykolwiek w Polsce pociągiem. Mydła leżące pod dozownikami są tak powszechne, że wiele osób nie wie nawet, że powinny się znajdować w urządzeniu widocznym na zdjęciu – i że jest to właśnie dozownik do mydła. Ba! Nie wiedziało o tym nawet wiele osób na grupie dyskusyjnej miłośników kolei, gdzie zdjęcie to wrzuciłem przed paroma dniami. Zakładam jednak, że wiedzą o tym pracownicy PKP (obecnie PKP IC albo jego podwykonawca), którzy sprzątali ten wagon. Mimo to jednak mydło leży tam gdzie leży.
Urządzenie, któremu poświęciłem już tyle miejsca nie jest jakimś lokalnym polskim wynalazkiem ani czymś niezwykłym. Do lat siedemdziesiątych – kiedy to zaczęły je wypierać z wagonów dozowniki mydła w płynie – stanowiło standardowe wyposażenie toalety wagonowej w większości krajów Europy. W związku z tym spotyka się je do dziś w starszych wagonach w Czechach, w Niemczech, we Francji. Nigdy nie leży jednak pod nim kawałek mydła – nie, zawsze jest on w środku a urządzenie działa. I na tym właśnie polega różnica.
Czy widzisz już gdzie leży problem?
-
Moc etykiet
Dowiedziałem się ostatnio o dość zaskakujących badaniach, które dobitnie pokazują jaki wpływ na postrzeganie ma język.
Mianowicie pewien badacz zauważył, że w starożytnych dziełach nie ma słowa na określenie koloru niebieskiego – a w szczególności nigdzie nie ma wzmianek o tym, by niebo miało jakiś szczególny kolor. Jest to jeszcze ciekawsze, jeśli połączymy to z badaniem pewnego współcześnie istniejącego w Afryce plemienia, które w swoim języku też słowa na określenie niebieskiego nie ma. Jak pokazały eksperymenty (polegające na pokazywaniu na ekranie kwadracików o różnych kolorach i proszeniu o ich rozróżnianie) ludzie z tego plemienia po prostu niebieskiego nie widzą – a ściślej nie rozróżniają od zielonego. Na tej podstawie postawiono dość śmiałą tezę, że starożytne ludy, które zbudowały fundamenty naszej cywilizacji nie tylko nie umiały niebieskiego nazwać, ale wręcz tego koloru nie dostrzegały właśnie dlatego, że nie umiały go nazwać (przeczytaj cały artykuł na ten temat – warto).
Piszę o tym, bo jest to świetny przykład na to jak silnie nasze myślenie kształtuje język, z którego korzystamy. Choć nasze oczy odbierają obiektywnie te same fale elektromagnetyczne, to co w efekcie widzimy wypływa ze świadomości. To spójne z wiedzą o funkcjonowaniu mózgu – w istocie nie widzimy „obiektywnie”, oczami, obraz dopiero kreuje mózg. A to na jakiej podstawie to robi jest mocno ugruntowane kulturowo, w tym oczywiście także przez język – najsilniejszy nośnik skojarzeń i obiektów, które można „zobaczyć”.
Skoro tak dzieje się z tak zdawałoby się obiektywną i prostą rzeczą jak kolory, to w takim razie o ile silniejsze jest samodefiniowane się człowieka poprzez etykiety, pod którymi się postrzega. W tym kontekście takie etykiety jak „tester” czy „programista” (albo „starszy referent”) od razu określają co ich nosiciele robią – a czego nie. Głównym problemem owych etykiet nie jest nawet to, że powodują odruchowe wręcz zawężanie zakresu postrzegania i odpowiedzialności (a ściślej klasyfikowania co jest rzeczą, którą powinienem się zająć i za którą odpowiadam, a co nie), ale to, że w kontekście pracy, w którym działają, niejako spłaszczają człowieka do jednego wymiaru, jednej umiejętności. To z koleji prowadzi nie tylko do silosów ze wszystkimi problemami, jakie one tworzą, nie tylko do poszukiwania lokalnych optymalizacji efektywności (w istocie psujących efektywność całości) ale przede wszystkim do niepełnego wykorzystania możliwości ludzi, którzy tworzą organizację.
Wydawałoby się zatem, że najlepiej byłoby nie nadawać żadnych nazw – po prostu pozbyć się etykiet niczym źródła zła. Przecież w małych firmach (często obecnie znanych pod niekoniecznie poprawnie użytą ale modną nazwą „startup”), gdzie z założenia wszyscy robią to co umieją i co jest w danej chwili potrzebne tak właśnie jest, a stanowiska i związane z nimi etykiety służą głównie do prezentowania się firmy na zewnątrz.
Jednak etykiet nie tak łatwo się pozbyć. W większych organizacjach jak również przy wieloetapowych procesach występuje konieczność jakiegoś nazwania i uporządkowania (zorganizowania) ludzi wykonujących różne prace choćby po to tylko by wiedzieć z czym móc iść do kogo bez konieczności znania wszystkich osobiście. Nadto obiektywnie istnieją też różne specjalizacje i specyficzne umiejętności, których złożenie jest potrzebne by dostarczyć usługę czy zbudować produkt. Niewątpliwie ułatwia i porządkuje tak myślenie jak i komunikację gdy można uprościć opis organizacji do ról i ich interakcji bez konieczności analizowania i opisywanie wielowymiarowego bytu jakim jest człowiek pełniący każdą z tych ról.
Powstaje zatem swego rodzaju sprzeczność – etykiety zawężąją postrzeganie i mają wiele niefajnych skutków ubocznych, wszelako opisanie załogi liczącej paręset osób firmy określeniem „ludzie” nie jest zbyt przydatne. Jak z tej sprzeczności wyjść?
Jednym rozwiązaniem jest to, co proponuje Scrum – w kontekście konkretnego zespołu wszyscy to „deweloperzy”, a pełniona rola zmienia się zgodnie z możliwościami człowieka i potrzebami zespołu. Wszelako jest to jednak „lokalna optymalizacja” – jeśli coś rozwiązuje, to tylko w obrębie jednego zespołu i tylko w obrębie kompetencji i umiejętności bezpośrednio związanych z jego pracą.
Szersze podejście proponuje Holakracja, która wprowadza explicite rozdział pomiędzy rolami a ludźmi. W ujęciu Holakracji organizacja jest stworzona z ról, które mają określone odpowiedzialności i uprawnienia. Ludzie nie są rolami, a jedynie je „animują”. Nie ma zatem relacji jeden-do-jeden między rolą a człowiekiem. Jeden człowiek może animować wiele ról jednocześnie (np. ta sama osoba może jednocześnie animować rolę „programista” jak i rolę „marketer w mediach społecznościowych”) jak również wiele osób może animować jednocześnie jedną rolę (np. trzy osoby animujące rolę „sprzedawca”). Z założenia ról nie tworzy się „dla ludzi” (czyli mając na uwadze konkretną osobę), ale by zaspokoić potrzeby organizacji – nowa rola tworzona jest wtedy, kiedy uważa się, że rozwiąże ona jakąś bolączkę, a nie wtedy kiedy trzeba kogoś zatrudnić czy znaleźć mu miejsce. Dopiero kiedy jest rola zastanawiamy się kto mógłby ją „animować”.
Wdrożenie Holakracji to duże przedsięwzięcie (wdrożyć ją w pełni nie jest łatwo – bagaż formalizmów i konieczność całkowitej zmiany sposobu funkcjonowania powodują, że jest to trudny proces), ale można wykorzystać to podejście do kwestii ról bez zastosowania całości. Wystarczy po prostu przyjąć ten sposób myślenia, ogłaszając go załodze wraz z wyjaśnieniem, a następnie wprowadzić jakiś widoczny sposób przypisywania ludzi do ról, w którym nie trzymamy się relacji „człowiek == rola”.
Można się przy tym wspomóc praktyką „Project Credits” z Management 3.0, która wprowadza dwa równległe systemy etykiet. Jedne to klasyczne „job titles”, które są raczej stałe i których używa się przede wszystkim na zewnątrz po to, by ludziom nie znającym dobrze naszej organizacji łatwiej było zrozumieć czym się mniej-więcej zajmuje dana osoba (a więc z czym można do niej przyjść). Drugie („Project Credits”) to kontekstowe i zmienne nazwy opisujące to, co dana osoba aktualnie robi. Oczywiście, wewnątrz organizacji dużo ważniejsze są te drugie etykiety.
To tylko dwa przykłady – z pewością da się wymyślić jeszcze inne praktyki. Najważniejsze to zerwać z etykietowaniem ludzi trwale opisem ich roli w ten czy inny sposób.