blog.testowka.pl

Zaspane poniedziałki w niewyspanych autobusach…

opublikowany przez 23, Sie, 2010, w kategoriach Praca, Zarządzanie

Poniedziałek 6.30 – dzwoni budzik – o 7.00 musisz być w pracy, za Tobą ciężki weekend (bo przecież kiedyś trzeba odreagować codzienne nierzadko nudne siedzenie po osiem godzin w pracy przy komputerze, do tego stres wywołany krytycznością wykonywanych zadań oraz napiętym – wręcz niewykonalnym harmonogramem). Pierwsza myśl po otwarciu oczu:  „byle do piątku”. I tak codziennie rano. Ta sama monotonia – sen, praca, dom, sen, praca, dom, sen, praca… A wszystko przez to, że ktoś kiedyś wymyślił, że etat ma mieć 8 godzin. 8 GODZIN! Osiem godzin to przecież 1/3 doby, to 30% naszego życia.

Kilka miesięcy temu miałem rozmowę o pracę w jednej z największych w Krakowie firm/korporacji zajmującą się wytwarzaniem oprogramowania. Rozmowy tej nie przeszedłem (pomijając oficjalną wersję) między innymi dlatego, że wdałem się ze swoim niedoszłym przełożonym w polemikę na temat czasu pracy. Otóż według mnie żaden programista/analityk a tym bardziej tester nie jest w stanie pracować efektywnie przez 8 godzin dziennie pięć dni w tygodniu. Praca na ośmiogodzinnym etacie z pewnością sprawdza się na kasie w supermarkecie, albo przy lżejszych pracach fizycznych, ale na pewno nie podczas pracy w której wymagane jest ciągłe skupienie i wytężone myślenie. Z doświadczenia wiem, że po 6 godzinach wytężonej pracy moja efektywność znacznie spada, co na moim stanowisku (QA/Tester) podczas pracy nad jakością i bezbłędnością czasem krytycznych systemów może oznaczać dla firmy poważne straty, jeśli z powodu zmęczenia jakaś krytyczna usterka przemknie się przez testy i pojawi się na produkcji. Nie wspomnę już nawet o głupotach które zdarzyło mi się robić z przemęczenia (np. ostatnie skasowanie całej zawartości katalogu domowego na jednej z testowych maszyn 🙂 – na szczęście udało się to w miarę szybko przywrócić, ale mogło być gorzej). Z drugiej strony zdarza mi się przesiadywać w biurze nad rozwiązaniem jakiegoś frapującego problemu/zagadnienia czasem nawet po 12-14 godzin niemniej jednak po takim wysiłku potrzebuję porządnego wypoczynku by wrócić z powrotem na wysokie obroty i znów pracować na 100% swojej efektywności. Nie wiem czy Wy też tak macie, nie chce mi się nawet szukać jakiś badań naukowych czy naukawych dotyczących tego zagadnienia, po prostu obserwując siebie wiem że narzucony czas pracy nie sprawdza się w IT. Tutaj ważna jest skuteczność i bezbłędność dlatego nie rozumiem idei normowanego czasu pracy.

Drążąc głębiej ten temat mógłbym dojść do stwierdzenia, że nie rozumiem tego jak ten świat jest zbudowany – bo przecież ludzie powinni sobie ufać i na podstawie tego zaufania budować pewne zależności i podejmować się pewnych zobowiązań. Niestety powyższe dotyczy świata idealnego. Jak jest w rzeczywistości – każdy sam dobrze wie. Powyższe podejście zupełnie nienormowanego czasu pracy mogło by mieć zastosowanie tylko i wyłącznie, gdy mieli byśmy do czynienia ze Specjalistami (przez wielkie „S”) w pełni świadomymi wartości tego co robią i w pełni za to odpowiedzialnymi. Niestety kolejny raz już nie tylko tzw. „rynek IT” psują tzw. „studenci informatyki”, którzy za stosunkowo niskie pieniądze oferują usługi o bardzo niskiej jakości…

PS:  Bez obrazy dla Studentów Informatyki (Wielkie „S” „I”) bo są i tacy, którzy znają się na programowaniu znacznie lepiej niż niejeden programista.

PPS: W tytule nieprzypadkowo fragment piosenki Kumka Olik „Zaspane poniedziałki”.


14 Comments for this entry

  • Kasia Firkowska

    Ktoś tu chyba zapomniał, że te 8 godzin pracy to nie jest 8 godzin wytężonej pracy umysłowej na najwyższych obrotach. Wliczyć w to należy wszelkie spotkania i obsługę maili, nie mówiąc już o przerwach kawowych i obiedzie. Trochę ciężko mi uwierzyć, że ktoś jest w stanie non stop ciupać kod przez 8h/5 dni w tygodniu 😉
    Jeśli odniesiemy to z kolei do pracy w korporacji, to tzw. administracji dojdzie nam jeszcze więcej, więc z idealnego dnia pracy tworzy się 5-6 naprawdę efektywnej roboty.

  • Krystian

    Tutaj Polska rózni się od „zachodu”. Ja mam 36h godzin pracy tygodniowo i nienormowane godziny w ktorych mam byc w biurze. Co jakiś czas bez problemu mogę nie przyjść w piątek, jeżeli pracuję 8h dziennie. Szef nigdy nie zagląda w rejest godzin (check-in – check-out). Mogę brać work from home. W Holandii propagowane jest teraz pracowanie z domu, bo to rozładowuje korki i też jest bardziej efektywne dla pracownika.
    Teraz powiem jeszcze coś z perspektywy frameworku Scrum,w którym pracuje. Planując kolejny Sprint w Scrumie, bieżemy pod uwagę w moim zespole max 6h efektywnej pracy na dzień. Średnia jest 5h wykonanej pracy. Wiadomo, że w ciągu dnia sprawdza się maile, czyta newsy i dyskutuje. I to jest zupełnie normalne. W Polskich firmach zaczynajacych ze Scrum na pytanie ile godzin dziennie planujemy na faktyczną pracę, kierownik projektu zawsze wyrywa się z hasłem „Jak ile? Dzień pracy ma 8 godzin!”. W sensie, że pracownicy za 8h mają płacone, więc jakoś mają to zabookować na projekty. W Polsce chyba ciągle panuje syndrom psa ogrodnika w połączeniu ze stylem zarządzania „slave master”. A potem po kolejnym Sprincie jest zdziwienie, że godziny są wykorzystane, a praca nie jest ukończona.

  • streser

    W moim przypadku często odpisywanie na maile też jest wytężoną pracą umysłową.
    Znam firmy w których faktycznie pracuje się po 8h/5dni w tygodniu na stanowisku programisty, a przerwy to tylko te wyznaczane przez kodeks pracy, mało tego – kiedyś usłyszałem tekst: „Owszem masz co godzinę pięć minut przerwy, ale jest to przerwa od pracy przy komputerze – w tym czasie możesz np. wypełniać papierki”.

    Właśnie o to mi chodzi, że nikt nie jest w stanie ‚ciupać’ przez 8h/5dni w tygodniu – dlatego nie widzę sensu w trzymaniu programistów 8h zamkniętych w biurze…

    Temat tzw. administracji to już zagadnienie na oddzielną notkę o marnotrawieniu czasu i papierkologi…

  • streser

    Co do pracy w Scrum – w Code Sprinters posunęliśmy się nawet dalej – doszliśmy do wniosku, że lepiej wychodzi planowanie w Story Pointach a nie w godzinach, więc za velocity zespołu przyjęliśmy określoną ilość SP a nie 40 czy 30 godzin razy ilość pracowników.
    Mało tego – praktyka pokazała, że nie zbyt dobrze sprawdza się przeliczanie velocity na członka zespołu – jedna osoba więcej czy mniej owszem wpływała na ogólne velocity zespołu ale nie było to deterministycznie skalowalne. Żeby nie było wątpliwości taką sytuację udało nam się osiągnąć dopiero po kilku miesiącach wspólnej pracy w zespole, który docierał się przez cały czas i samemu wypracowywał zasady pracy.

    Ogólnie to też jest temat na oddzielną notkę – szykuje się całkiem ciekawe Case Study – może nawet na jakąś prezentację gdzieś 🙂

  • Krystian

    Story pointy to pojęcie abstrakcyjne. Taski też określacie w Story Pointach? Wtedy jaka jest odpowiedź na „Ile jeszcze potrzebujesz, że skończyć zadanie?”? „Yyyyy… 2 Story Pointy”?

    Velocity na członka zespołu nie ma znaczenia, bo dynamika zespołu stosuje się inaczej w zależności od składu. Nadal 9 kobiet nie urodzi dziecka w jeden miesiąc 😉

  • streser

    Taski to trochę inny kaliber – owszem estymowaliśmy je w godzinach, ale te godziny to nie jest żadna znacząca metryka, to bardziej informacja dla nas samych. Doświadczenie pokazało, że nie sprawdza się też przeliczanie godzin na story pointy i w drugą stronę. SP to jednostki abstrakcyjne, które mają obrazować to jak jedno zadanie wygląda na tle innych. Dysponując odpowiednio dużym zbiorem już ukończonych i wyestymowanych wcześniej zadań można śmiało prognozować velocity zespołu. Tylko tak jak pisałem zespół musi mieć pewne doświadczenie w projektach scrumowych żeby to wypaliło, wszystko przychodzi z czasem. Ponadto członkowie zespołu też się uczą więc z czasem te same czynności zajmują im mniej czasu. Więc np. utworzenie nowego template’u jakiejś strony które na początku projektu zostało wyestomowane na 5SP po kilku miesiącach pracy nad podobnymi templatami, opracowaniu odpowiedniego workflowu, czy nawet zbudowaniu jakiegoś frameworka może zostać wyestymowane na 1SP. Wynika z tego śmiałe stwierdzenie, że velocity zespołu jest/powinno być stałe, ale to już kwestia estymacji i tego jak robi to zespół. Według mnie każda metoda jeśli sprawdza się w praktyce jest dobra nie ma ogólnej zasady jak to robić. Scrum jest tylko narzędziem a to jak go wykorzystamy zależy od nas.

  • Krystian

    Jeżeli godziny w taskach to nie jest metryka, to z czego robicie Sprint Burndown?

  • streser

    Jest jeszcze Items Burndown – spalanie Story Pointów.

    A co do Sprint Burndown to warto się zastanowić co chcemy by ten wykres przedstawiał i jak należy go interpretować – jako wykres spalania powinien pokazywać ile godzin zostało danego dnia zrzuconych, ale w praktyce czasem jest tak, że nie zrzuca się nic, albo zrzuca się kilka i dopisuje nowego taska, albo w ogóle okazuje się, że po dogłębnej analizie dany task zajmie nam więcej czasu niż planowaliśmy i podnosi się estymat. IMO kwestia godzin jest bardzo płynna – i taka powinna być – burndown, czy same godziny przy taskach mają każdego dnia obrazować miejsce w którym jesteśmy – owszem mają wskazywać na postępy, ale nie można tego traktować na zasadzie logowania ilości godzin pracy.

    Napisałem że nie jest to ZNACZĄCA metryka, bo dla mnie tylko w połączeniu z Ideal Sprint Burndown pokazuje gdzie jesteśmy w danym momencie, ale tak jak wcześniej pisałem to jest bardzo płynne i tak na prawdę może nam tylko powiedzieć że jest źle jeśli tak będzie – nie ma się co cieszyć za wcześnie póki na Sprint Backlogu są jeszcze jakieś Itemy otwarte.

    Bardzo długo zajęło w naszym zespole wypracowanie w praktyce zasady nie zaczynania nowego itema zanim poprzedni nie został skończony/zamknięty (ale to też szeroki temat).

  • Łukasz Herok

    Też uważam, że ciągła 8h praca umysłowa jest nieefektywna.

    Patrząc na to z innej strony. Skoro zwarłeś ze swoim pracodawcą umowę na etat – praca 8h i masz komfort stałej pensji co miesiąc (a nie niepewna kasa płacona zadaniowo), to chyba uczciwie rzecz biorąc twój pracodawca może od ciebie oczekiwać dobrej pracy przez 8h. Oczywiście nie znaczy to, że masz siedzieć 8h przed komputerem – bo to na pewno jest nieefektywne. Myślę, że nic nie stoi na przeszkodzie aby robić sobie więcej dużych przerw – których nie wliczasz do czasu pracy.

    Podpisując klasyczną umowę o pracę, sprzedajesz swojemu pracodawcy 8h swojego czasu.
    Czasu w którym masz dla niego wytworzyć jakąś wartość.
    Jakość produktu jaką w tym czasie wytworzysz będzie podległa ocenie twojego pracodawcy.
    Czas jaki potrzebujesz na relaks, aby wytworzyć naprawdę coś dobrego to już twoja sprawa.

    No chyba że podpisujecie umowę na 8h i wiecie jeden i drugi, że przez te 8h ty faktycznie będziesz pracował 4h. Ale wtedy to chyba nie powinna być umowa na cały etat…

  • streser

    Właśnie o to mi chodzi. Moim zdaniem w IT nie ma miejsca na pracę 8h dziennie. Programowanie, projektowanie a nawet testowanie jest to praca twórcza.

    Owszem zgodnie z prawem pracy etat = 8h. Ale ja nie widzę sensu w marnowaniu zasobów i nieefektywnej pracy.

    Owszem zawarłem z moim pracodawcą umowę, w której sprzedałem mu 8h z każdego mojego dnia i dlatego właśnie codziennie spędzam w biurze te osiem godzin (uśredniając – czasem jest to kilka minut mniej, czasem więcej). Niestety widzę, że jestem mniej efektywny niż w mojej poprzedniej pracy gdzie nikt nie przejmował się tym czy przychodzę do biura o 8 i wychodzę o 16, czy może przychodzę o 18 i wychodzę o 20, albo w ogóle nie przychodzę tylko pracuję z domu. Był termin w którym coś powinno zostać zrobione (realny termin) i wszyscy się tego trzymali. Dzięki temu pracodawca mógł być niemal pewny, że to co zaplanowaliśmy zostanie wykonane w terminie, a my podchodziliśmy do terminów rzetelnie, nikt nie mówił od pierwszego dnia, że nie uda się wykonać zadania w terminie. Owszem od tego też były pewne odstępstwa, ale jak to bywa w projektach informatycznych nigdy nie jesteśmy w stanie wszystkiego przewidzieć.

    PS: Pozwolę sobie w oparciu o powyższe komentarze napisać kolejną notkę na temat czasu pracy i jej efektywności…

  • nuah

    Po co narzekać na teraźniejszość taka jaka jest. Jeśli nie podoba Ci się polityka firmy, w której pracujesz to albo ją zmień, zatrudnij się na umowę zlecenie, kontrakt (polecam), otwórz własną działalność (najlepsze wyjście).
    Tylko przy tym jak otwierasz własną działalność to jestem pewny że będziesz siedział dłużej przed biurkiem niżeli 8 godzin i spokojnie szedł sobie do domu, zostawiając za zamkniętymi drzwiami Fiskus itp itd
    Przychodząc do pracy na te 8 godzin nie musisz się martwić że nie masz co robić, że trzeba znaleźć kolejny projekt bo ten się kończy, że na tydzień deadline a ty czekasz na dokumentacje systemu z Indii, że nagle twój projekt został przejęty przez firmę z Indii bo są tańsi a równie wydajni.

  • streser

    Pytanie co ma dla Ciebie/mnie większą wartość – święty spokój czy dobrze wykonane zadanie i satysfakcja z własnej pracy.

  • Nuah

    Z twojej wypowiedzi wynika że nie do końca jesteś usatysfakcjonowany z własnej pracy ponieważ „sprzedajesz się” swojemu pracodawcy na 8 godzin, to ja Ci właśnie pokazuje Ci jak to wygląda z drugiej strony.
    Poza tym „studenci informatyki” niekoniecznie psuja rynek, oni też gdzieś muszą zdobyć doświadczenia. Aby w pewnym momencie stać się profesjonalistą (w założeniu) w swojej dziedzinie. Większy problem/zagrożenie jest jeśli chodzi o tanią siłę roboczą z Chin a zwłaszcza z Indii, oni zrobią to samo co ty tylko o wiele taniej i w tym przypadku nie oznacza że mniej profesjonalnie.

  • streser

    Swoją „pracę” staram się wykonywać zawsze tak by mieć z niej satysfakcję. Niezadowolony jestem z reguł i formalizacji narzucanych przez pracodawcę.
    Fakt, „tania siła robocza” to poważne zagrożenie, niemniej jednak uważam, że wolny rynek i zdrowa konkurencja to nic złego. Co do „studentów informatyki” faktycznie to nie oni są winni tylko Ci, którzy ich zatrudniają.
    Jeśli chodzi o zmianę pracy, to uważam, że było by to w pewnym stopniu poddanie się – zanim zdecyduję się na tak radykalny krok, wolę spróbować zmienić coś w obecnej – zmiany których próbuje dokonać nie dotyczą tylko mojego widzimisię, ale także w znaczący sposób mogły by wpłynąć na produktywność całej firmy. Moje „narzekanie” wynika między innymi z pragmatyzmu który chcę stosować. Mało tego, ostatnio zamiast narzekać próbuje zmieniać to co mi przeszkadza, zaczynając przeważnie od siebie. Niestety formalizacja niektórych rzeczy sprawia, że wiele zmian i ulepszeń jest niemożliwych do przeprowadzenia. Niestety tajemnica firmowa nie pozwala mi na przytoczenie przykładów, ale mogę zapewnić, że dla ambitnego testera niektóre z procedur to jeden wielki WTF?!

Skomentuj