Project Manager w IT-realne zarobki

Witam,

Od pewnego czasu zastanawiamy się z kolegą ile może zarabiać IT Project Manager...Załóżmy,że w miarę kumaty, z wymaganymi papierkami/certyfikatami i w średniej wielkości firmie (ewentualnie małe korpo). Oczywiście w necie jest cała masa artykułów i wypowiedzi na ten temat ale rozbieżności na ten temat są tak wielkie,że czasem ciężko uwierzyć w to co ludzie piszą- z jednej strony niebotyczne zarobki i "życie jak w Madrycie" a z drugiej stres,nadgodziny i pensja na zasadzie "co zostanie".

Dlatego chciałem zapytać ile mniej więcej mogą zarabiać Wasi kierownicy/managerowie i czy to są faktycznie "niesamowite ogarniacze"? Pytam z czystej ciekawości... :)

6tys i życie jak w madrycie. Ogarniacze ? raczej to wygląda tak:

To są kolesie, którzy muszą potrafić pisać i czytać. Cała reszta to bonus i oczywiście świetnie jeśli taki człowiek ma doświadczenie w rolach technicznych, ale nie jest to regułą. Zajmują się oni pierdołami organizacyjnymi - owszem, to są bardzo ważne rzeczy, jak np. budżet, terminy, faktury, MPK-i, umowy, licencje, zakupy, świecenie oczami, wciskanie kitów, włażenie w d..., zamawianie pizzy przy jakiś nockach przed terminem ;) , jednak typowy programista woli się od tego trzymać z daleka i dla niego użycie słowa "ogarniacz" w stosunku do PM-a to śmiech na sali. Właściwie często taka funkcja nawet nie oznacza, że ma się podwładnych, a tylko ciągnie się konkretny projekt, gdzie ludzie biorący w nim udział są po prostu na jakiś czas, a normalnie są w oddzielnej hierarchii organizacyjnej.
Myślę, że kasa zależy mocno od kalibru firmy i projektu, przy czym w JanuszSoftach takie stanowisko jak najemny PM raczej nie występuje, bo sam Janusz uważa się za urodzonego geniusza tej roli. ;)

Kasa za PM jest doliczana do budżetu projektów, a dobry PM zarabia sporo więcej od programisty. W Warszawie dla doświadczonych PM są stawki 15k w góre. Dlaczego? Bo to do PM należy odpowiednia alokacja zasobów (Programistów), przygotowanie planu projektu i dopilnowanie aby zmieścić się w czasie i w budżecie bo poślizg na tym polu może oznczać wymierne straty finansowe, znacznie wyższe niż gówniany kod.
A i pisze to z perspektywy programisty, żeby nie było ;)

Zajmują się oni pierdołami organizacyjnymi

hahaha :D :D
Jasne, bo to żeby się zamknąć w terminach i w budżecie to są pierdoły organizacyjne. Nie mówie już o tym że jak się projekt opóźnia / klient zgłasza milion defektów to programiści zwykle mają to w dupie bo im tam płacą za godzinę roboty, a PM wie że to on ponosi ryzyko. Jak sie projekt położy to programista pójdzie do innej firmy i tyle a PM z doświadczeniem w projekcie który padł to może zarządzać najwyżej w mcdonalds na kasie, bo nikt nie będzie ryzykował zatrudnienia go.
Wydaje mi się że z PMem to jest trochę jak z Adminami. Takiej codziennej harówki mają może i mniej / jest bardziej lajtowa póki wszystko idzie zgodnie z planem. Ale jak sie coś zacznie sypać to sytuacja się odwraca i mogą osiwieć w kilka tygodni.

Shalom napisał(a):

Jasne, bo to żeby się zamknąć w terminach i w budżecie to są pierdoły organizacyjne. Nie mówie już o tym że jak się projekt opóźnia / klient zgłasza milion defektów to programiści zwykle mają to w dupie bo im tam płacą za godzinę roboty

Scrum/agile może to i są z wierzchu dziwne rytuały, ale jedna z ważniejszych tam rzeczy jest taka, że niedomykanie się terminów, budżetu, zakresu, jakości wychodzi na bieżąco, a nie po roku lub dwóch okazuje się, że PM błędnie wyssał oszacowania z palca lub niedokładnie odczytał je z sufitu. Jeśli programiści mają wszystko w dupie, to coś jest nie tak z taką organizacją.

ajp napisał(a):

Shalom napisał(a):

Jasne, bo to żeby się zamknąć w terminach i w budżecie to są pierdoły organizacyjne. Nie mówie już o tym że jak się projekt opóźnia / klient zgłasza milion defektów to programiści zwykle mają to w dupie bo im tam płacą za godzinę roboty

Scrum/agile może to i są z wierzchu dziwne rytuały, ale jedna z ważniejszych tam rzeczy jest taka, że niedomykanie się terminów, budżetu, zakresu, jakości wychodzi na bieżąco, a nie po roku lub dwóch okazuje się, że PM błędnie wyssał oszacowania z palca lub niedokładnie odczytał je z sufitu. Jeśli programiści mają wszystko w dupie, to coś jest nie tak z taką organizacją.

Kolego drogi, wmawiaj tak sobie dalej :)

Projekty są najczęściej fixed price i fixed time - klient często ma już zaplanowaną akcje marketingową i wdrożenie zanim jeszcze ktoś napisze jedną linijke kodu. Kolejna rzecz to nie PM powinien szacować pracochłonność tylko architekt rozwiązania, dodatkowo estymaty są jeszcze przed formalnym przekazaniem projektu do realizacji.

Scrum i inne agile to ciekawy sposób mydlenia oczu zespołom, że mają coś do powiedzenia, bo sprinty tamto siamto i demokracja.
Ch*j nie demokracja, hajs ma sie zgadzać ;)

To zależy o jakiej wielkości projektach jest mowa. Czy może zaplanowana akcja marketingowa, to chodzi o to, że właściciel warzywniaka ma zniżkę na wydruk ulotek ważną tylko na 3 miesiące? ;P Czy to może ja mam takie wielkie szczęście, że biorę udział w jedynym sensownym, chociaż na kilkadziesiąt osób. Byłem też w większym i na sztywny termin, ale tam była za to taka kasa, że można to było zrobić kilka razy jednocześnie niezależnymi zespołami.
To co, tak będzie sensownie, że PM pójdzie sobie do McD, programiści pójdą do innej pracy, bo mieli wszystko w d..., a biznes klienta pójdzie do piachu? Czy może lepiej współpracować, rozważyć plany zapasowe, obcięcie zakresu, przesunięcie terminu, stopniowy rozruch?

@ajp nie no hurtowania pani grażynki i pana janusza to może i przeżyje miesiąc dłużej bez nowego programu do drukowania faktur, ale jak piszesz soft dla sondy kosmicznej która ma tygodniowe okno startowe a następne za 10 lat to już nie ma miejsca na taką obsuwę ;) "Obcinanie zakresu i przesuwanie terminu" też słabo widzę ;) Tak samo zresztą jak chcesz wypuścić soft podczas jakiegoś konkretnego wydarzenia i po prostu musi być wtedy gotowy, bo juz kampania reklamowa kupiona i reklamy zapłacone.
Niemniej właśnie współpracować, rozważyć plany zapasowe, obcięcie zakresu, przesunięcie terminu, stopniowy rozruch to są rzeczy którymi zajmuje sie PM. A nie pierdoły organizacyjne ;)

Czyli przeszliśmy od zarobków PM do wad ołówka :)

Wielki Młot napisał(a):

Kasa za PM jest doliczana do budżetu projektów, a dobry PM zarabia sporo więcej od programisty. W Warszawie dla doświadczonych PM są stawki 15k w góre.

Zarabia sporo więcej, a stawki ma takie same? Przedziwna matematyka.

Weltschmerz napisał(a):

Projekty są najczęściej fixed price i fixed time

No i jeśli w połowie projektu okazuje się, że są małe szanse osiągnąć wymarzony przez klienta termin, to trzeba dołożyć ludzi. Tu jakby nie ma wielkiej filozofii.

Kolejna rzecz to nie PM powinien szacować pracochłonność tylko architekt rozwiązania, dodatkowo estymaty są jeszcze przed formalnym przekazaniem projektu do realizacji.

Takie estymaty mają 1000% rozrzutu i 300% niepewności, więc są niewiele warte.

A co do Scruma - przede wszystkim w tej metodyce nie ma kogoś takiego jak PM.

somekind napisał(a):

Zarabia sporo więcej, a stawki ma takie same? Przedziwna matematyka.

Napisałem "od", takie widły to raczej góra stawek programistów w PL, ale oczywiście mogą być wyjątki.

somekind napisał(a):

No i jeśli w połowie projektu okazuje się, że są małe szanse osiągnąć wymarzony przez klienta termin, to trzeba dołożyć ludzi. Tu jakby nie ma wielkiej filozofii.

Niestety prosto to wygląda z perspektywy osoby, która nie jest PM, bo:

• skąd tych ludzi?
• ile czasu zajmie wdrożenie aby osiągnąć produktywność?
• o ile obniży się wydajność zespołu jak dostawisz niekomatybilny klocek?
• kto za tego człowieka zapłaci?

somekind napisał(a):

Takie estymaty mają 1000% rozrzutu i 300% niepewności, więc są niewiele warte.

Takie estymaty są podstawą wyceny projektu, więc jak najbardziej są wiele warte, dosłownie. Często estymowany jest koszt wewnętrzny, a do klienta idzie inna wycena bo np: plan sprzedaży firmy zakłada wypracowanie przychodu X, koszt developmentu to Y i można go rozłożyć między N klientów. Do tego, estymowanie zaczyna się do analizy funkcjonalnej, która z technologią ma niewiele wspólnego, po tym dopiero architektura i projekt rozwiązania. I cały czas jest zarządzanie ryzykiem.
Sztuką jest robić to tak aby nie popłynąć z wyceną i dopiąć kontrakt, bo monetyzacja owego kontraktu jest źródłem pieniędzy na Twoim koncie.

somekind napisał(a):

A co do Scruma - przede wszystkim w tej metodyce nie ma kogoś takiego jak PM.

Tak bo PM jest często wyżej i może mieć pod sobą wiele zespołów scrumowych, pełniąc często role Account Managera.
Tak czy siak, zapomnij o Scrumie w biznesie no chyba, że masz klienta, któremu odpowiada praca na tzw "time & material".

somekind napisał(a):

A co do Scruma - przede wszystkim w tej metodyce nie ma kogoś takiego jak PM.

Bardzo bym chciał żyć w świecie, w którym PMowie są niepotrzebni. A co do Scruma - faktycznie, w teorii takiej osoby nie ma. W praktyce business owner rzadko jest osobą odpowiedzialną za budżet. Osobą odpowiedzialną jest właśnie PM. I w związku z odpowiedzialnością budżetową przychodzi cały szereg fajnych rzeczy - jak pilnowanie faktur, ułaskawianie góry itp.

Nie zrozumcie mnie źle - uważam, że Agile/Scrum to najlepsze co mogło się przytrafić procesowi developmentu (no, może poza TDD). Ale uważam też, że żeby go uskutecznić trzeba też mieć odpowiednie ku temu warunki. Sam pracowałem w firmie, w której jeden z działów wprowadził Scruma, z wielką pompą i dumą. I do tej pory jest wszystko super pięknie. Tyle tylko, że te "super pięknie" oznacza "oni są ciągle spóźnieni, nawet w porównaniu do ludzi pracujących w waterfallu". No, ale mają Agile'a.

Weltschmerz napisał(a):

Napisałem "od", takie widły to raczej góra stawek programistów w PL, ale oczywiście mogą być wyjątki.

A Ty niby nie podałeś góry dla PMów?

Niestety prosto to wygląda z perspektywy osoby, która nie jest PM, bo:

• skąd tych ludzi?
• ile czasu zajmie wdrożenie aby osiągnąć produktywność?
• o ile obniży się wydajność zespołu jak dostawisz niekomatybilny klocek?
• kto za tego człowieka zapłaci?

Skąd brać ludzi - to nie problem PM, tylko firmy. (Oczywiście głupotą jest obiecywanie klientowi ludzi, których się nie ma.)
Czas wdrożenia i spadek wydajności - dlatego należy dodać tych ludzi sensownie, a nie na zasadzie, że "jeden student zastąpi nieskończoną liczbę specjalistów". ;) A jeśli okaże się, że nie ma sensu dodawać ludzi, to się ich nie dodaje.
A za ludzi płaci klient, przecież nie urząd pracy...

Takie estymaty są podstawą wyceny projektu, więc jak najbardziej są wiele warte, dosłownie.

Finansowo może i są warte, ale jeśli chodzi o ich związek z rzeczywistością są zupełnie bezwartościowe. Zwłaszcza, jeśli tak jak proponujesz, nie uwzględni się w nich architektury i technologii.

Często estymowany jest koszt wewnętrzny, a do klienta idzie inna wycena bo np: plan sprzedaży firmy zakłada wypracowanie przychodu X, koszt developmentu to Y i można go rozłożyć między N klientów.

To zależy od modelu biznesowego firmy. Nie każda firma ma plany sprzedażowe, nie każdy kontrakt to fixed price.

Sztuką jest robić to tak aby nie popłynąć z wyceną i dopiąć kontrakt, bo monetyzacja owego kontraktu jest źródłem pieniędzy na Twoim koncie.

Ja akurat jestem sprzedawany klientowi na godziny. I wydaje mi się, że tak jest z większością ludzi w tej branży, takie przynajmniej mam wrażenie na podstawie rozmów kwalifikacyjnych na których byłem w ciągu ostatnich 2 lat. Ale oczywiście mogę nie mieć racji.

Tak czy siak, zapomnij o Scrumie w biznesie no chyba, że masz klienta, któremu odpowiada praca na tzw "time & material".

Rozsądni klienci już wiedzą, że oprogramowanie to nie jest wykopanie dołka 2x3x4 metry i zwyczajnie nie da się zaplanować ile to zajmie czasu i zasobów przed rozpoczęciem. Rozsądni klienci już wiedzą, że waterfall nie działa. Rozsądni klienci zdają sobie sprawę z tego, że może zajść potrzeba zatrudniania więcej ludzi, przełożenia terminu zakończenia prac, albo zmniejszenia funkcjonalności.
Im większy projekt tym większym samobójstwem jest fixed price. Zarówno dla wykonawcy jak i klienta.

wartek01 napisał(a):

Bardzo bym chciał żyć w świecie, w którym PMowie są niepotrzebni.

Nie mówię, że sa niepotrzebni, napisałem tylko, że w Scrumie ich oficjalnie nie ma. :)

Sam pracowałem w firmie, w której jeden z działów wprowadził Scruma, z wielką pompą i dumą. I do tej pory jest wszystko super pięknie. Tyle tylko, że te "super pięknie" oznacza "oni są ciągle spóźnieni, nawet w porównaniu do ludzi pracujących w waterfallu". No, ale mają Agile'a.

Bo nie wystarczy programistów wysłać na szkolenie ze standupów, a jednego testera obwołać scrum masterem, żeby być agile. Agile jest jak repozytoria - zazwyczaj błędnie używane przez ludzi, którzy coś tam słyszeli, ale nie do końca zrozumieli, i robią po swojemu.
Może i jest dobry dla klienta i producenta, ale z drugiej strony jest rakiem, który zabija produktywność dobrych programistów.