Momencik, trwa przetwarzanie danych   loading-animation

#83848

(PW) ·
| Do ulubionych
W historii https://piekielni.pl/83841 przedstawiłem postać M., poniżej kilka innych jego piekielnych zachowań.

M. po awansie na menadżera pokazywał, że ma władzę, regulował co się dało, choć te rzeczy od dawna działały. Do tego mój były szef to osoba uwielbiająca wszelkie tabelki, raporciki, prezentacje, a najgorsze jest to, że bardzo czepiał się ich formy i przykładał do niej większą wagę niż do treści. Te wszystkie cechy doprowadziły do kilku sytuacji, które z zewnątrz mogą brzmieć śmiesznie, a nie strasznie, ale nasz zespół wkurzały bardzo.

1) Pracy w nadgodzinach jest u nas dużo, w zasadzie jest elementem krajobrazu. Jako kierownik M. nie widział problemu w tym, żeby nadgodziny zgłaszać mu w systemie do raportowania czasu pracy dzień po ich przepracowaniu. Jako menedżer ustalił zasady dotyczące nadgodzin w zależności od powodu i jego (nie)dostępności w celu zgłoszenia ich, np.:
- jak jest ktoś pisze lub dzwoni, że coś jest pilne, to jak on jest dostępny to mamy ustalić, czy to jest pilne i czy robimy nadgodziny, a jak go nie ma, to sami możemy ocenić.
- jak ktoś z zagranicy, z innej strefy czasowej ustawi nam spotkanie po godzinach, to wystarczy zgłosić w systemie dzień po.
- jak jest dużo pracy, to mamy ustalić z nim DZIEŃ WCZEŚNIEJ, że chcemy robić nadgodziny.

To ostatnie to jakiś absurd rodem z Dilberta, czy "Paragrafu 22". U nas wnioski spływały z dnia na dzień, z innej strefy czasowej i bywało, że wychodząc zostawiałem 3 niezaczęte sprawy, a następnego dnia rano było 33, gdzie przerobić mogłem 8. Tak więc umawianie się dzień wcześniej było totalną abstrakcją.

Do tego M. nie pozwalał wykonywać zadań pobocznych w nadgodzinach, a jednocześnie na spotkaniach dziennych jak ktoś chciał ustawić taką rzecz jako jeden z dziennych priorytetów, to się nie zgadzał. Ale oczywiście domagał się wypełniania tych pobocznych zadań (np. wypełnianie raportów, aktualizacja procedur, nauka nowego systemu). Tak więc jak z jakichś powodów go nie było, to cały zespół robił te dodatkowe rzeczy, żeby nie mógł nam kazać robić czegoś innego, żeby potem opieprzyć za niezrobienie tego dodatkowego szajsu.

2) M. stworzył instrukcję do pisania instrukcji. Dokument ten opisywał cechy, które spełniać mają instrukcje wewnętrzne w zespole. Generalnie nasze główne zadania były opisane w różnych instrukcjach, zawierających nawet screen shoty z różnych systemów, te obrazki miały zaznaczone istotne fragmenty - to jest bardzo pożyteczne i pomocne, dzięki takim instrukcjom nowi pracownicy są w stanie sami robić standardowe zadania, a podpytywać tylko o te niestandardowe. Dodatkowo łatwiej jest o wymienność przy chorobach czy urlopach. Nawet jak ktoś nie wykonuje jakiejś działki lub nie działa w jakimś systemie, to po wejściu w instrukcję, powoli, krok po kroku jest w stanie wykonać zadanie.

Problem w tym, że instrukcja do pisania instrukcji skupiała się na formie, nie treści. Mówiła, jakiej szerokości mają być screeny, jaką czcionką ma być pisana, jakie mają być odstępy, że ważne rzeczy mają być w ramkach (czerwonych, 2 1/4 piksela grubości) itp.

Część osób dostała w celach rocznych aktualizację instrukcji w kwestiach merytorycznych (co popieram, dla mnie to bardzo ważne, żeby takie rzeczy były aktualne, w poprzedniej pracy wiecznie nie były i mnie to strasznie irytowało) oraz dostosowanie istniejących instrukcji do wymogów z tego tworu, co już dla mnie jest bzdurą. I parę osób robiło od nowa po 100 screenów, żeby miały właściwą szerokość, zmieniało czcionki i ramki, zamiast procesować zgłoszenia. A robota stała. Ale ja ich nie winiłem, wręcz przeciwnie, sam mówiłem koledze, żeby robił screeny, a nie wnioski, bo jak wnioski będą leżeć, to opieprz dostaniemy wszyscy, a jak nie będzie ramek i screenów, to tylko on.

Korpo

Skomentuj (12) Pobierz ten tekst w formie obrazka
Ocena: 62 (94)

Komentarze

Momencik, trwa ładowanie komentarzy   ładowanie…