Zwołują spotkania, wygłaszają na nich wstęp i zakończenie. Poganiają, wypytują o statusy i trzeba im wszystko tłumaczyć by powypełniali sobie excele.
Do czego oni są jeszcze?
2
2
Tłumaczenia klientowi czemu mamy opóźnienia, czemu jest źle, co zrobimy żeby było lepiej i zależnie od branży ile będzie musiał za to zapłacić dodatkowo
5
Od trzymania kasy i poganiania programistów żeby wreszcie coś wartościowego dostarczyli.
8
Bohatersko trzymają w ryzach metodyki projektowe, które sami narzucili.
4
Od zwoływania spotkań, ogłaszania wstępu i zakończenia owych, oraz poganiania o statusy i wpisywania ich w excele.
1
2
Od wkur...nia ludzi (ktoś musiał to napisać) :)
1
Nie są potrzebni. Tylko self-organized teams!
2
To są tak zwane bullshit jobs:
http://www.strike.coop/bullshit-jobs/
"It's as if someone were out there making up pointless jobs just for the sake of keeping us all working."
1
W mojej poprzedniej firmie w Krakowie project manager przeglądał codziennie rano buty, koszulki na zalando, jeździł na wakacje w sezonie wiosenym ze 2-3 razy, a programistów traktował jak roboli na plandece, bez należytego szacunku, w sumie rok czasu to trwało, bo potem się zwolniłem. Ale tak teraz myślę, że fajna robota, lepsza niż programisty, bo dużo hajsu a po pracy nie trzeba tyle robić jak programista. Teraz z kolei mam project managera który jest pracoholikiem i siedzi w korpo 180-200 godzin. Nie wiem co lepsze/gorsze, ale szkoda mi chłopa.
1
IMO Project Manager powinien być odpowiedzialny za komunikację z biznesem, synchronizację wielu zespołów (nie tylko developerskich) i - przede wszystkim - dowiezienie tematu. Nie jest to prosta rola ze względu na to, że znajdują się pomiędzy waterfallowym młotem, a edżajlowym kowadłem, a są rozliczani za efekt prac i to nie swoich. Tylko przypomnę, że aby tematy dojeżdżały na produkcję, prace developerskie to tylko ułamek całego projektu - jest jeszcze coś takiego jak marketing, dział prawny, inne zespoły developerskie - to wszystko musi ogarnąć taki PM.
Oczywiście są tacy, którzy znaleźli się w tej roli przypadkiem, tego nie kwestionuję. Jednocześnie lwia część programistów uważa, że najważniejsze jest kodowanie. Niestety nie. Czasem nawet lepiej podjąć decyzję, żeby czegoś nie robić.
0
Są też project managerowie który urzymują stare systemy, tak miałem w poprzedniej robocie, tam taki PM (3-4 letni w jednej firmie) nie ma nic do roboty, poza zebraniem ludzi na calla tygodniowego, a tak to siedział i obczajał ciuszki na zalando, czasem zgłaszał jakieś rzeczy i klepał mi requesty i akceptował timesheet. Jedyne co go wyróżniało to angielski na poziomie c1+ oraz śnieżnobiałe, aktorskie zęby, więc pewnie dlatego miał takie chody.
3
Bardzo cenię dobrych PM'ów. Jeśli PM zwołuje spotkanie, więcej słucha niż mówi i stara się zrozumieć co się dzieje to jest bardzo dobry znak. Developerzy myślą, że są pępkami świata i wszystko robią dobrze, ale w praktyce tak nie jest. Umieją się skupić na małym wycinku swojej pracy, nie rozumieją potrzeb klienta, zazwyczaj nie mają globalnej wizji projektu itd.
PM (taki dobry) potrafi zrobić tak, że te trybiki wskakują na właściwe miejsce - developerzy mogą robić swoje wycinki i jarać się swoją zaje..cią i myślą, że "samo" im wychodzi, a tak na prawdę cały projekt scala PM.
Miałem okazję pracować z PM zupełnie niogarniętymi, jak i z takimi którzy znają się na swojej pracy i różnica jest powalająca. Kiepski PM potrafi położyć projekt z dobrymi developerami (byłem w takiej sytuacji) - dobry potrafi wyciągnąć projekt z średnimi developerami na poziomi wysokiego zadowolenia klienta (byłem w takiej sytuacji).
Mam też doświadczenie z drugiej strony, tj prowadzenia projektu w roli developującego PM'a (nic wielkiego, taki side project) - to jest na prawdę ciężka harówka, żeby tak ułożyć projekt, że każdy wie co ma robić i pracę idą do przodu, choć dla developera to tylko PM taski robi i "organizuje spotkania".
@Julian_ pójdź na spotkanie z klientem w roli pomocy technicznej, to może wtedy Ci się oczy otworzą jaka jest droga od pomysłu w głowie klienta, do jakiegoś atomowego taska, który dostajesz. Do tego jeszcze ktoś Cię musi pilnować bo skoro pytają o statusy, to znaczy, że nawet nie komunikujesz tego prawidłowo w Jirze.
0
Jak w każdej pro-ważnej pracy masz teoretyczny opis stanowiska - dogadywanie się z klientami, ustalanie priorytetów, odpowiedzialność za sukces projektu, koordynacja pracy etc.
W praktyce zawsze był w firmie ktoś inny kto gadał z klientami, klienci sami ustalali priorytety (ew jakiś PO), a pm miał zerową odpowiedzialność (jeżeli tylko ładnie wypełniał excele i podążał procesem, to nic mu nie groziło). Może widziałbym więcej sensu w stanowisku pm-a gdybym pracował pod jakimś użytecznym. Ewentualnie gdybym nie pracował w korpo i "obowiązki" pm-a nie były pokrywane przez parę innych stanowisk.
edit: i z tego co pamiętam z gadania ewangelistów scruma - w scrumie nie ma miejsca na takie stanowisko jak pm.
0
LukeJL napisał(a):
To są tak zwane bullshit jobs:
http://www.strike.coop/bullshit-jobs/
Z tym lepiej ostrożnie, bo facet napisał też książkę i wszedł w szczegóły, w tym podzielił te stanowiska na typy, a jeden z nich to:
- duct tapers, who ameliorate preventable problems, e.g., programmers repairing shoddy code
1
W PL do niczego. Większość z nich z racji tego, że nie potrafią programować a pokończyli jakieś śmieszne studia no i gdzieś pracować przecież muszą. Jak wszyscy wiemy w IT zarobki "good", no to się ich umieszcza (tych chłopaczków z dobrych domów bez krzty zdolności do niczego) na pozycjach manadżerskich. I się zaczyna we łbach przewracać, jak to polska cebula, im wyższe stanowisko tym bardziej chamski i wydaje się takiej pale, że więcej umie i jest ważniejszy.
0
Ja widzę PM jako osobę odpowiedzialną za kontakt z klientem (lub którąś z warstw pośrednich). Ma wiedzę na temat produktu, dzieli się nią, kiedy zespół ma braki lub trafia na coś co wymaga decyzji klienta to PM jest odpowiednią osobą.
Moim skromnym zdaniem PM powinien być przede wszystkim częścią zespołu, nie jako nadzorca, a raczej jako sternik
1
imo to powinien być Product Owner a nie PM i dobrzy PO owszem istnieją ale jest ich bardzo bardzo mało.
0
Po pierwsze PM i programista to potrzebne role w projekcie.
Ich główna różnica to fakt, że programista koncentruje sie na funkcjonalnościach i kodzie, a PM na kliencie i zespole.
Jak widać stosunek do PM nawet w tym wątku jest średni, ponieważ PM ze względu na różnorakie spotkania generalnie utrudnia pracę programiście. Dzieje się tak, ponieważ oba typy mają sprzeczne harmonogramy. Programista potrzebuje mieć duże bloki w ramach których może spokojnie kodować, a PM z reguły więcej osiągnie jeśli lepiej będzie czuł zespół i klienta, dlatego częściej potrzebuje spotkań.
Wartość PM odbierać jako bezużyteczną, ale nic z tych rzeczy. Myślę, że najłatwiej można się o tym przekonać, gdy prowadzi się własną małę firmę :)
1
Raczej problem w tym, że większość projektów jest słabo zarządzana przez PMów, albo ogólnie po macoszemu traktowana przez firmę.
Jak widać po większości głosów jest negatywny oddzwięk.
Jak PM robi dobrą robotę, to nikt nie ma problemu o to że ciśnie bo deadline, każdy jest tego świadomy.
Co innego jak PM nie jest w stanie ogarnąć komunikacji z klientem i budzi się tylko jak jest przypał, bo większość czasu wypełnia excele i przegląda allegro.
A całe bagno spada potem na programistów....
1
Oprócz klepania kodu jest masa innych aktywności. Jak to się dzieje, że projekt jest dostarczany? Samo się zrobi i ustali?
Na PMa można patrzeć jak na właściciela procesu dostarczania (projektu/produktu). Taki proces dostarczania może składać się z wielu współbieżnych pod procesów. Naturalne, że potrzeba kogoś kto będzie kontrolował przebieg takiego procesu i w tym celu odpytuje o stan poszczególnych akcji.
4
yarel napisał(a):
Oprócz klepania kodu jest masa innych aktywności. Jak to się dzieje, że projekt jest dostarczany? Samo się zrobi i ustali?
Jeśli jest lista zadań, znany cel i wiedza biznesowa, to programiści zrobią. Nawet wbrew różnym bezużytecznym pętakom i procesom.
Z mojego doświadczenia wynika, że najsprawniej dowoziły te zespoły, które nie miały wcale interakcji z PMami. Prawdopodobnie dlatego, że takie rzeczy występują w odpowiednio dojrzałych firmach, które są w stanie zatrudnić odpowiednich fachowców i traktować ich jako dorosłych ludzi. To naprawdę bardzo dobrze może działać, no ale większość ludzi wyznaje mentalność niewolniczą i musi mieć nad sobą pana i ciemiężyciela.
Taki proces dostarczania może składać się z wielu współbieżnych pod procesów. Naturalne, że potrzeba kogoś kto będzie kontrolował przebieg takiego procesu i w tym celu odpytuje o stan poszczególnych akcji.
Tylko czemu ma pytać programistę?
1
somekind napisał(a):
yarel napisał(a):
Oprócz klepania kodu jest masa innych aktywności. Jak to się dzieje, że projekt jest dostarczany? Samo się zrobi i ustali?
Jeśli jest lista zadań, znany cel i wiedza biznesowa, to programiści zrobią. Nawet wbrew różnym bezużytecznym pętakom i procesom.
Pewnie jest klasa projektów, w których nie potrzeba PMa, ale...
Jak to się dzieje, że programiści mają co robić?
Jeśli wszystko wiadomo i nie ma żadnych problemów (próbuję w tym momencie sięgnąć pamięcią do ostatniego projektu, na którym tak było... hmm, miałem pecha, nigdy ;) ), to to pewnie zrobią, ale jest też szansa, że jednak nie zrobią. Kto będzie odpowiedzialny za efekt? Chyba, że jak się uda, to nikt nie pyta i jest ok, a jak się nie uda, to nagle odpowiedzialnego brak ("nie wiem o co chodzi, ja swoje zadania zrobiłem")? Jeśli ktoś zostanie ustanowiony jako odpowiedzialny za dostarczenie, to w jego interesie będzie kontrolowanie i dbanie by dostarczyć. Nie wiedziałem jeszcze programisty, który byłby w stanie powiedzieć "to się nie może udać, zatrzymujemy pracę, płacimy karę" i to zrealizować. Chyba, że programiści nie martwią się ograniczonym budżetem i czasem, tylko przepalają co najmniej tyle budżetu i czasu ile jest zaplanowane?
Z mojego doświadczenia wynika, że najsprawniej dowoziły te zespoły, które nie miały wcale interakcji z PMami. Prawdopodobnie dlatego, że takie rzeczy występują w odpowiednio dojrzałych firmach, które są w stanie zatrudnić odpowiednich fachowców i traktować ich jako dorosłych ludzi. To naprawdę bardzo dobrze może działać, no ale większość ludzi wyznaje mentalność niewolniczą i musi mieć nad sobą pana i ciemiężyciela.
Mam podobne obserwacje jeśli chodzi o interakcje zespołu z otoczeniem (nie tylko z PMami), tylko tłumaczę to sobie mniejszym narzutem na komunikację.
Taki proces dostarczania może składać się z wielu współbieżnych pod procesów. Naturalne, że potrzeba kogoś kto będzie kontrolował przebieg takiego procesu i w tym celu odpytuje o stan poszczególnych akcji.
Tylko czemu ma pytać programistę?
Zespół może się tak zorganizować, że nie będzie miał interakcji z PMem i będzie odcięty od bezpośredniej komunikacji przez interfejs w postaci np. team leadera i funkcjonować we względnym komforcie. Programiści raczej (generalizuję) mają ciężki interfejs do komunikowania się z nie-programistami. Taki programista raczej (znów generalizuję) nie pójdzie do PMa i powie "słuchaj jest tak i są takie, a takie problemy, potrzebuję tego i tego", tylko będzie pokątnie marudził i dawał upust swej frustracji (albo nie będzie i po jakimś czasie "rzuci papierem" i będzie twierdził, że ma dość pracy w takim syfie). Rozsądny PM wie, że jak nie widać postępu, nie ma problemów, to coś jest nie tak i trzeba sytuację sprawdzić. Można prościej niż zapytać? ;)
Są różni PMowie. Jednego darzyłem szczególną "sympatią", przybiegał do biurka i już z oddali krzyczał "dostałeś maila?!", "jakiego maila? ping, o właśnie coś przyszło", "no to na kiedy możesz wyjaśnić?!". Staram się rozdzielać osoby od ról które pełnią i nie oceniać czynności realizowanych w ramach określonej roli jako "zbędnych".
1
yarel napisał(a):
Pewnie jest klasa projektów, w których nie potrzeba PMa, ale...
Ja nie tyle mówię, że PMa nie trzeba, co nie trzeba takiego w każdym zespole składającym się z kilku programistów. Niech taki ktoś będzie na poziomie projektu, czy klienta jeśli ktoś pracuje w modelu z klientami (ja już dawno nie). PM w każdym zespole kończy się mikromanagementem, bo gość nie ma co robić, więc nadmiernie nadzoruje.
PM jako osoba z "władzą" ma rozwiązywać problemy i usuwać przeszkody, a nie je tworzyć. No i akceptować urlopy. To cała komunikacja na linii developer <-> PM.
Jak to się dzieje, że programiści mają co robić?
BA dostarcza tasków funkcjonalnych, programiści technicznych, a QA bugów.
Naprawdę, poza tymi trzema grupami ludzi do wytwarzania oprogramowania nikt inny nie jest potrzebny.
Kto będzie odpowiedzialny za efekt?
No to jest właściwie pytanie do PO.
Chyba, że programiści nie martwią się ograniczonym budżetem i czasem, tylko przepalają co najmniej tyle budżetu i czasu ile jest zaplanowane?
No to jest kwestia profesjonalizmu. Dobry programista robi task za taskiem, a jeśli coś jest niemożliwe do zrobienia, to o tym mówi najwcześniej jak to stwierdzi. Jeśli nie ma sensu czegoś robić, bo już np. istnieje, to też o tym powie. Jeśli coś da się zrobić lepiej, to też powie. Jeśli wie, że wymuszone przez management podejście jebnie, to też powie.
Zespół może się tak zorganizować, że nie będzie miał interakcji z PMem i będzie odcięty od bezpośredniej komunikacji przez interfejs w postaci np. team leadera i funkcjonować we względnym komforcie. Programiści raczej (generalizuję) mają ciężki interfejs do komunikowania się z nie-programistami. Taki programista raczej (znów generalizuję) nie pójdzie do PMa i powie "słuchaj jest tak i są takie, a takie problemy, potrzebuję tego i tego", tylko będzie pokątnie marudził i dawał upust swej frustracji (albo nie będzie i po jakimś czasie "rzuci papierem" i będzie twierdził, że ma dość pracy w takim syfie).
Pewnie część programistów ma ciężki interfejs, ale to też działa w drugą stronę. Gdy się widzi, że PM to debil, dla którego najważniejsze jest trzymanie się kurczowo procesów i wymyślonych przez niego zasad zamiast dowożenie produktu, to automatycznie nie będzie się chciało z nim gadać. Gdy kiedyś się gościa poprosiło o pomoc, a on to olał, to nie poprosi się drugi raz.
PMowie po prostu często mają ogromne problemy z ego. Myślą, że są aby rządzić, a tak naprawdę są po to, aby pomagać.
1
Oni tylko piniadze biora! Moje pieniadze z renty.