Premie a wzrost rok do roku

Istnieją stanowiska pracy czy też – szerzej – systemy wynagradzania, gdzie część zmienna wynagrodzenia albo premia zależy od uzyskanego wyniku, np. od wartości sprzedaży. Istnieją też firmy, które prognozują wzrost np. wartości sprzedaży o zadany procent rocznie. Bywa, że na parę lat do przodu. Postanowiłem pokusić się o analizę, czy pracownikowi opłaca się robić wzrost w pierwszym roku, każdego roku po równo czy w ostatnim roku.

Na początek kilka założeń. Praktycznie wszystkie te założenia są nierzeczywiste, ale pewne uproszczenia pozwolą łatwiej liczyć i zobaczyć mechanizm.

  • Wynagrodzenie pracownika jest stałe względem inflcacji, tj. zakładam, że wynagrodzenie się nie zmienia, inflacja nie istnieje, a koszt wysiłku pracownika w każdym roku jest identyczny. Czyste uproszczenie obliczeń.
  • Premia jest proporcjonalna do targetu, zarówno po przekroczeniu, jak i przy nie osiągnięciu. Czyli robiąc 95% planu dostaje 95% premii, robiąc 110% planu dostaje 110% premii.
  • Znany jest zarówno system wynagrodzeń w kolejnych latach, a zakładane targety znane są z góry i są liczone rok do roku, tj. wynik roku drugiego jest podstawą do obliczania wzrostu w roku trzecim. Do symulacji przyjąłem zakładany wzrost 10% w pierwszym i drugim roku, 12% w roku trzecim i czwartym.
  • Celem pracownika jest uzyskanie wyniku średnio 1% ponad plan w każdym roku. Założenie czysto na potrzeby symulacji.
  • Wysiłek pracownika jest wprost proporcjonalny do wykonanej pracy, tj. wartości sprzedaży.
  • Pracownik może osiągnąć dowolny wynik, tj. nie zwolnią go za niewykonanie planu, nawet przez kilka lat z rzędu, a jednocześnie może – w dowolnym roku – znacznie przekroczyć normę.

Pora na symulację:

Rok 0Rok 1Rok 2Rok 2Rok 4Suma
Baza0,100,100,120,12
100110,00121,00135,52151,78618,30
Równomiernie0,110,110,130,13
100111,00123,21139,23157,33630,76
Pierwszy rok0,140,100,120,12
100114,00125,40140,45157,30637,15
Ostatni rok0,100,100,120,16
100110,00121,00135,52157,20623,72
Strata w pierwszym, zysk w ostatnim0,060,100,120,20
100106,00116,60130,59156,71609,90
Duża strata w pierwszym, wysoki wzrost w ostatnim0,020,100,120,24
100102,00112,20125,66155,82595,69
Duży wzrost w pierwszym, strata w ostatnim0,240,100,120,02
100124,00136,40152,77155,82668,99
  • Baza – wariant bazowy, czyli punkt odniesienia bez wzrostu, pracownik nie otrzymuje premii. Wykonał pracę, czyli zmęczył się za 618,3 jednostki.
  • Równomiernie – najbardziej oczywisty wariant: aby uzyskać 4% ponad plan w ciągu czterech lat, pracownik w każdym roku przekracza plan o 1%. Wysiłek 630,76 jednostek.
  • Pierwszy rok – pracownik ambitnie przekracza plan już w pierwszym roku o 4%, pozostałe lata zgodnie z planem. Wysiłek 637,15 jednostek.
  • Ostatni rok – wariant odwrotny do poprzedniego. Pracownik robi zgodnie z planem przez 3 lata, przekracza plan i pobiera premię w czwartym roku. Wysiłek 623,72 jednostki.
  • Strata w pierwszym, zysk w ostatnim – pracownik nie wykonuje planu w pierwszym roku, mocno przekracza plan w ostatnim. Wysiłek 609,9 jednostki.
  • Duża strata w pierwszym, wysoki wzrost w ostatnim – podobny do poprzedniego, ale z większą stratą w pierwszym i wyższym zyskiem w ostatnim. 595,69 jednostek.
  • Duży wzrost w pierwszym, strata w ostatnim – wariant odwrotny do poprzedniego, czyli zryw w pierwszym roku, znaczne niewykonanie normy w ostatnim. 668,99 jednostek.

Pora na wnioski. Jak widać, istnieją spore rozbieżności między włożonym wysiłkiem pracownika (i jednocześnie zyskiem pracodawcy), przy takim samym zarobku pracownika. Pracownikowi opłaca się jak najbardziej odłożyć wysiłek w czasie. Przy odpowiednim planowaniu może on uzyskać premię, czyli wyższy sumaryczny przychód, wkładając nawet mniejszy wysiłek, niż w wariancie bazowym! Kosztem obniżenia wykonanej pracy w pierwszym roku. Co oznacza mniejszy sumaryczny zysk pracodawcy.

Jak widać nie jest to zdrowy system. W zależności od tego, kto jest „sprytniejszy”, nie służy on ani pracodawcy, ani pracownikowi i wprowadza on dodatkowy antagonizm między interesami pracodawcy a pracownika.

Bieganie i rower w 2019 – podsumowanie

Rok ma się ku końcowi, sezon rowerowo-biegowy bardziej skończony nie będzie, więc pora na małe podsumowanie.

Rower

Na początek rower. Zacząłem później, niż w zeszłym roku, chyba w maju. Po drodze małe zawirowania logistyczne ze sprzętem, koniec końców korzystałem z roweru głównie (tylko?) do dojazdów do pracy i głównie z Nextbike. Jeździć przestałem jakoś we wrześniu. Przekłada się to na wynik – tylko niecałe 400 km, czyli mniej niż w zeszłym roku. 24,5 godziny w ruchu. Not great, not terrible, poniżej planu.

Bieganie

Za to, jak pisałem w zeszłym roku, zacząłem trochę biegać. Spodobało mi się, kupiłem wtedy dedykowane ciuszki, co mocno uniezależniło mnie od pogody – znaczy może być chłodniej, tak do ok. 8-10 stopni. Ogólnie jak nie mam parcia na dedykowane rozwiązania i uważam, że można się ruszać w czymkolwiek, tak u mnie przy bardziej intensywnych aktywnościach fizycznych sprawdzają się syntetyki – odprowadzają pot, lepiej regulują temperaturę, szybko wysychają po praniu. Nie mam nic do bawełny, ale dedykowane lepsze.

Wystartowałem chyba już w lutym, biegam nadal (na pewno biegałem w listopadzie), choć nieco rzadziej. No właśnie. Jak zaczynałem, to biegałem raz w tygodniu, dystanse różne, raczej okolice 4 km. W tym roku doszedłem w pewnym momencie do 5 km, potem zwiększyłem częstotliwość do dwóch razy w tygodniu. Nieoptymalnie, bo dzień po dniu, ale znowu – logistyka. Teraz ze względu na pogodę biegam rzadziej – moja ulubiona trasa zbyt błotnista, butów na tego typu nawierzchnię nie mam (jeszcze!) i zwyczajnie się ślizgam. Zmieniłem trasę na inną i choć zdarzyło mi się biec w deszczu i nie było dramatu, to wolę jak jest sucho i nie jest przeraźliwie zimno. Czyli możliwe, że grudzień i styczeń bez biegania. A może kupię jeszcze jakieś ciepłe ciuchy? Zobaczymy.

Biegam po swojemu, mocno nieortodoksyjnie. Przede wszystkim, ma być fajnie i bez napinki. Lubię kontrolować czas i dystans, więc biegam ze smartfonem. W garści. Do tego co robię, zegarek sportowy z GPS itp. to overkill. Chociaż nie próbowałem, może by mi się spodobało? Biegam z przerwami na marsz. Kumpel uświadomił, że ma to fachową nazwę metoda Gallowaya. Ale niezupełnie, bo też robię to po swojemu – marsze nieco rzadsze i nieco dłuższe. Mierzone dystansem, nie czasem. Przerwy nie tyle planowane, co wynikające z trasy. Kontrola dystansu z GPS, bieganie z kontrolą prędkości i „na czuja”, nie na tętno. Rozważałem smartband, ale w tym miejscu mógłbym napisać wiele smutnych rzeczy na temat sytuacji w ekosystemie androidowym, jeśli chodzi o appki, smartbandy i ich integrację między sobą. Więc olewam ten temat, i po prostu biegam.

Statystyka: 22 godziny w ruchu, 228 km, 49 biegów. Średnio niemal jeden tygodniowo.

Instalacja podatnych wersji oprogramowania HOWTO

Niekiedy zachodzi potrzeba uruchomienia starej, podatnej wersji systemu lub usługi w celu przetestowania czegoś, np. exploita. W przypadku Debiana i podobnych dystrybucji opartych na pakietach deb, instalacja starej wersji systemu bywa nieco problematyczna. Po pierwsze, system pakietów nie wspiera downgrade’u, po drugie, domyślnie instalator instaluje najnowsze wersje pakietów, jeśli tylko ma taką możliwość.

Sposoby instalacji podatnych wersji oprogramowania

Sposobów na instalację starszych, podatnych wersji pakietów jest wiele. Można kompilować określoną wersję, ale nie jest to wygodne, jest czasochłonne i niekoniecznie uzyskamy wersję dokładnie taką, jaka była w systemie, np. z powodu patchy nakładanych przez Debiana czy nieco innego środowiska w którym pakiet był budowany[1].

Skoro jednak korzystamy z dystrybucji opartej o pakiety binarne, można także próbować robić downgrade pakietów, albo usuwać pakiety i instalować przy pomocy dpkg zamiast apt[2]. Jeśli nie mamy pecha, wszystko zadziała czy to od razu, czy po małym force przy instalacji. Można też instalować ze starych obrazów instalacyjnych, bez dostępu do sieci. Czasem jednak nie mamy szczęścia. A wszystko można zrobić szybciej i prościej.

Repozytorium starych wersji pakietów Debiana

Przede wszystkim, i tak trzeba jakoś zdobyć podatne wersje pakietów. W przypadku Debiana istnieje snapshot.debian.org, czyli serwis z oficjalnymi, snapshotami mirrorami repozytoriów Debiana. Doskonałe miejsce pozwalające i na pobranie pakietów w takich wersjach, w jakich były w danym momencie w repo, i na postawienie całego systemu w stanie na dany dzień. Snapshoty wykonywane są częściej, niż raz dziennie. Poza głównym repozytorium pakietów dostępne inne, w tym security i backports, więc trudno sobie wyobrazić coś lepszego. Pozostaje instalacja systemu z wykorzystaniem powyższych repozytoriów.

Naprościej można to zrobić z użyciem debootstrap, poprzez podanie mirrora., z którego mają być pobierane pakiety. Przykładowo, aby zainstalować Debiana Buster w wersji, w jakiej był on dostępny dzień po wydaniu:

debootstrap buster /chrooted/ https://snapshot.debian.org/archive/debian/20190707T150059Z/

Po instalacji należałoby jeszcze wejść do chroota i uzupełnić sources.list o wpisy dla repozytorium security, zaktulizować pakiety i… gotowe. W katalogu /chrooted będzie dostępny podatny system. Jeśli był tam podmontowany dysk zdalny, to można uruchomić podatną maszynę według podlinkowanej wyżej instrukcji.

Wykorzystanie LXC do uruchamiania podatnych wersji

Istnieje jeszcze szybszy i IMO wygodniejszy sposób uruchomienia podatnej wersji systemu. Można wykorzystać kontenery LXC do instalacji, a następnie uruchomienia podatnego systemu. O tyle wygodne i bezpieczne, że kontener LXC może być dostępny – i jest to domyślna konfiguracja – wyłącznie z poziomu hypervisora, bez udostępniania go na świat. Kontener z Debianem Buster w wersji na dzień po wydaniu z użyciem LXC tworzymy:

lxc-create -n test -t debian -- -r buster -a amd64 --mirror=https://snapshot.debian.org/archive/debian/20190707T150059Z/ --security-mirror=https://snapshot.debian.org/archive/debian-security/20190707T153344Z/

I gotowe. Po zakończeniu powinniśmy mieć dostępny kontener LXC z podatną wersją systemu. W tym przypadku o nazwie test, którym możemy zarządzać w standardowy sposób, czyli sources.list będziemy mieli:

cat /etc/apt/sources.list
deb https://snapshot.debian.org/archive/debian/20190707T150059Z/          buster         main
deb https://snapshot.debian.org/archive/debian-security/20190707T153344Z/ buster/updates main

[1] Przy weryfikacji zgodności pakietów pomóc mogą reproducible builds.
[2] W tym miejscu nadal odsyłam do wpisu o wajig i zachęcam do zapoznania się z narzędziem. To stary wpis, nie wszystkie opisane okoliczności muszą być prawdziwe, ale wajig ma się dobrze. Warto więc zatem go poznać.