2-5 kontraktów na B2B.

8

Napiszę z perspektywy Team Leadera. Jeśli taski są wykonywane, CR robiony i nie ma problemu by ustawić spotkanie by o czymś pogadać to nie interesuje mnie ile czasu faktycznie ktoś pracuje.

Jeżeli widzę, że osoba nie wyrabia lub kręci na planowanej pozycji i odstaje od reszty to proszę o wymianę takiej osoby.

0

@bilgeits: Zofftopuję trochę, bo i tak lecimy grubo.

Jeśli masz ekipę budowlaną, której mówisz "wpadajcie, do zrobienia łazienka, panele, płytki w kuchni, ściany do pomalowania, robimy na moich materiałach", a ona przychodzi i nie ma worka kleju, prądu nie ma bo zapomniałeś zagadać do Taurona i nie wiesz w sumie od czego mają zacząć - przecież to oni są specjalistami to sobie sami wymyślą jakie masz priorytety w remoncie, to masz rację - to jest nie w porządku kazać tym ludziom siedzieć na dupie i czekać "bo przecież mają zapłacone". Nie miałbym sumienia takim ludziom powiedzieć "macie płacone za dniówkę, siedźcie i sobie na smartfonie poklikajcie". Ja zawalając "umowę" - bo mam za mało kasy, bo nie ogarnąłem pewnych rzeczy nie miałbym przeciwko by sobie na boku dobrali fuchy - tak długo jak zrobiliby mi założone prace w terminie i wykonane byłyby zgodnie ze sztuką.

4

Z mojej perspektywy mogę powiedzieć, że nie jestem zwolennikiem klepania na kilku etatach byle było bo cieszy mnie praca i pełne zaangażowanie w jeden konkretny, najlepiej choć trochę ciekawy projekt. Po prostu sprawia mi to satysfakcje kiedy widzę, że moja praca przynosi efekty, projekt się rozwija, a sam uczę się czegoś nowego. Jednakże wychodzą z tego również inne problemy:

  • Współpracownicy którzy właśnie klepią sobie drugi etat i większość zadań robią "byle było", a potem weź się człowieku męcz z review ich kodu po kilka razy albo pomagaj przy poprawianiu bugów bo oni "nie wiedzą już co się dzieje". Po takiej prośbie zazwyczaj uruchamiam projekt i znajduje błąd w 5-10 minut, który najczęściej jest trywialny. Wygląda to najczęściej tak, że takie osoby w ogóle nie spojrzały na ten problem (i nie mówię tutaj o juniorach).
  • Zarobki, wkładając 2x więcej zaangażowania w projekt nie będziemy zarabiać 2x tyle co osoby na podobnym stanowisku w znacznej większości przypadków. Już bardziej bym powiedział, że może 20% więcej.

I z tego też względu postanowiłem poprosić o bardzo znaczącą podwyżkę, tak aby chociaż częściowo wyrównać mi braki w wypłacie, bo prosta kalkulacja:

  • Ktoś klepie byle jak 2 etaty, pracuje ~8h dziennie, dostaje np. 2x wypłaty po 20k
  • Ja klepie sam jeden etat, pracuje ~8h dziennie, dostaje np. jedną wypłatę 25k

I co się lepiej opłaca? To chyba jasne... Kwoty są przykładowe, chodzi tylko o sens. Dlatego najprawdopodobniej jeśli nie wyjdzie mi z podwyżką/awansem sam zdecyduje się obniżyć swoją wydajność, która i tak pewnie będzie na dobrym poziomie po to, żeby w tym wolnym czasie móc sobie dorobić gdzie indziej :)

Podsumowując, może gdyby pracodawcy, a w szczególności większe korporacje potrafiły mieć bardziej znaczący podział wynagrodzenia w stosunku do wkładu w prace, to ludzie nie musieliby kombinować z pracą na 3 etaty.

7

@vipe223: Niestety, to co piszesz jest prawdą. W IT, patrząc jedynie na kasę "nie opłaca się" pracować wydajnie. Jeżeli zrobisz 2 razy więcej, to nie dostaniesz 2 razy więcej. Patrząc jedynie od strony kasa/wysiłek, najbardziej sensowne jest bycie wiecznym midem. Odpowiedzialność żadna, stres żaden, kasa bardzo dobra.
Z jednej strony, fajnie, że nasza praca jest trudno mierzalna, z drugiej, możesz zapierniczać jak dziki osioł i raczej nikt tego nie zauważy.

3

Opowieści o pracy na kilku etatach przypomniały mi pewną anegdotę z przeszłości: ktoś kiedyś mi powiedział, że jak pracował w Niemczech (załóżmy, że była to praca w stylu układania kostki brukowej) to dostał reprymendę od jakiegoś niemca za robienie zbyt szybko. Trochę wtedy tego nie rozumiałem.

Na ostatniej confiturze Kuba Nabrdalik miał (imho ciekawe) wystąpienie na którym opowiadał o pewnych swoich przemyśleniach i protipach związanych z pracą programisty. Wspominał między innymi, że programiści (podobnie jak graficy) do ostatecznego kształtu swego kodu dochodzą w sposób iteracyjny i że to normalne, że często pierwsze rozwiązanie leci do kosza.

Konkluzja z tego jest taka, że dobry kod wymaga czasu bo nikt go nie pisze od ręki za pierwszym podejściem.
Jak to się przekłada na fakt, że ktoś ciągnie 2 lub więcej projektów (gdzie estymata przynajmniej dla pozorów jest robiona by zając full time)?
Ano wydaje mi się, że tak, że raczej tworzy kod który "ma działać tu i teraz" aniżeli coś co iteracyjne, drogą ewolucji, po cr i konsultacjach jest coraz lepsze, odpowiednio otestowane, zrozumiałe, rozszerzalne i dające się efektywnie utrzymać w przyszłości (a gdzie jeszcze miejsce na ewentualny refaktor kodu który dotykamy przy okazji zmiany?).

Nie chce mi się wierzyć w cuda, że przeciętny mid z kilkuletnim doświadczeniem pisze za pierwszym strzałem kod tak dobry, że ciężko o lepszy mimo, że taki Nabrdalik, jako osoba z wieloletnim doświadczeniem, wprost mówi, że to ciężka sprawa i raczej wygląda to inaczej.

3
RequiredNickname napisał(a):

Jak to się przekłada na fakt, że ktoś ciągnie 2 lub więcej projektów (gdzie estymata przynajmniej dla pozorów jest robiona by zając full time)?
Ano wydaje mi się, że tak, że raczej tworzy kod który "ma działać tu i teraz" aniżeli coś co iteracyjne, drogą ewolucji, po cr i konsultacjach jest coraz lepsze, odpowiednio otestowane, zrozumiałe, rozszerzalne i dające się efektywnie utrzymać w przyszłości (a gdzie jeszcze miejsce na ewentualny refaktor kodu który dotykamy przy okazji zmiany?).

IMO to nie o to chodzi. Z mojego doświadczenia, pisać kod idzie szybko, ale zdobyć wymagania co dokładnie powinien ten kod robić - to jest najbardziej czasochłonne. I nie, nie piszcie mi, że w tickecie Jiry powinno być wszystko jednoznacznie opisane xd

1

Prosta piłka, jako że zadane pytanie w poście dotyczy B2B, to powiedziałbym że można mieć tyle kontraktów ile się chce, i to bez żadnego kombinowania, bo wykonujesz usługi a nie zawierasz stosunek pracy. Jasne, kwestia umowy, ale jeśli ktoś idzie z zamiarem OE to raczej nie podpisze umowy gdzie musi być dostępny w X godzinach i on-site, zresztą legalność takiego zapisu w umowie B2B byłaby mocno dyskusyjna. A jeśli nie ma tego w umowie, no to droga wolna.

Z UoPem oczywiście inna sprawa, i moim zdaniem tak jak jest to opisane w polskim kodeksie pracy to niestety proszenie się o dyscyplinarkę, szczególnie jak właśnie wcześniej wspomniane nagłe zwołanie pracowników on-site, i co wtedy z drugą robotą? Na UoP nawet nie ma zbytnio jak zniknąć z dnia na dzień.

19

rozumiem ze ludzie ktorzy podnosza argument o oszustwie pilnie pracuja 8h, a przerwy odliczaja. Nie pisza postow na 4p w czasie pracy oraz nie przegladaja socialow.

3
nowy_kret_2 napisał(a):

rozumiem ze ludzie ktorzy podnosza argument o oszustwie pilnie pracuja 8h, a przerwy odliczaja. Nie pisza postow na 4p w czasie pracy oraz nie przegladaja socialow.

większość osób jak typowych Polaków boli dupa.
Wiadomo, że są osoby które pewnie siedza te 8h i cisną nonstop ale nie każdego dnia.

A większość realnie pracuje nie licząc przerw od 4h fo 6h max

1

Znam Scrum Masterów co robią po 3-4 kontrakty. Głównie w "niedojrzałych organizacjach" bo tam łatwiej udawać, że coś robisz/jesteś jedynym SM i nikt nie wie co w sumie powinieneś robić.

1 użytkowników online, w tym zalogowanych: 0, gości: 1