Czołem,
dotychczas pracowałem od strony sprzedażowe - business development manager/ sales director oraz zarządzałem zespołami sprzedaży - wszystko w firmach IT lub około IT.
Mam w planach lekkie przebranżowienie w stronę PMa.
Jakie szkolenia moglibyście doradzić na początek? Jak to wszystko poukładać?
0
1
A brałeś kiedyś udział w projekcie od strony technicznej? Jeśli nie to, może zacznij od tego.
0
Nie uczestniczyłem, widziałem wyłącznie wewnętrznie w organizacji jak zespół pracuje.
Żeby wziąć udział, tak jak piszesz, muszę wnieść jakieś kompetencje. Stąd moje pytanie - jak to ugryźć
1
Zakładam że umiejętności technicznych nie masz. Więc może jakieś stanowisko analityka przy projkecie finansowym lub coś podobnego.
Pytanie w sumie jak rozumiesz role PM, co ma wchodzić w zakreś twoich obowiązków ?
0
Dawno temu zaczynałem programować niskopoziomowe. Na tą chwilę nie robię tego i nie poruszam się biegle.
Rolę PMa rozumiem jako kompleksowe prowadzenie zespołu (zespołów) w projekcie w zakresie:
- terminów
- budżetowania
- pracy z ludźmi - miękko
- kooperacji z pozostałymi rolami (product owner, scrum master )
- reprezentowanie projektu u klienta końcowego
Oprócz kwestii technicznych robiłem wszytko w dotychczasowych pracach, ale nigdy nie bylem odpowiedzialny za projekt od a do z
4
Nie to, żebym zniechęcał, ale do tej pory średnio mi się układała współpraca z nie technicznymi, bo i tak zawsze kończyło się to tym, że musiałem siedzieć na spotkaniach z klientem :P Zatem jakaś minimalna wiedza od strony technicznej na temat projektu by się przydała (na pewno tym zaplusujesz).
Co do reszty, to na pewno jakiś ITIL, czy PRINCE2 pomoże.
Edit. Natomiast był projekt w którym Scrum Masterka przejęła rolę PMa z uwagi na brak zasobów (kompletnie nie techniczna osoba), ale była na tyle obrotna, że potrafiła poukładać spotkania z odpowiednimi ludźmi (i od strony klienta i ze strony funkcjonalnej i technicznej). Nie było potrzeby zwoływać spotkań ze wszystkimi o niczym, tylko wiedziała kogo z kim połączyć, żeby rozwiązać temat. Także znajomość ludzi w projekcie, ich kompetencji na pewno na duży +.
Dodatkowo to był projekt, dla klienta który ma sklepy otwarte 24/h, więc release'y mieliśmy wieczorami (po 21 - 22) i za każdym razem z nami siedziała na Teamsach, razem z klientem nawet żeby pogadać o głupotach jak działały automaty. Tak żeby pokazać, że jest razem z zespołem : ) I to było coś co bardzo szanowałem.
0
MatD napisał(a):
Nie to, żebym zniechęcał, ale do tej pory średnio mi się układała współpraca z nie technicznymi, bo i tak zawsze kończyło się to tym, że musiałem siedzieć na spotkaniach z klientem :P Zatem jakaś minimalna wiedza od strony technicznej na temat projektu by się przydała (na pewno tym zaplusujesz).
Co do reszty, to na pewno jakiś ITIL, czy PRINCE2 pomoże.
Edit. Natomiast był projekt w którym Scrum Masterka przejęła rolę PMa z uwagi na brak zasobów (kompletnie nie techniczna osoba), ale była na tyle obrotna, że potrafiła poukładać spotkania z odpowiednimi ludźmi (i od strony klienta i ze strony funkcjonalnej i technicznej). Nie było potrzeby zwoływać spotkań ze wszystkimi o niczym, tylko wiedziała kogo z kim połączyć, żeby rozwiązać temat. Także znajomość ludzi w projekcie, ich kompetencji na pewno na duży +.
Dodatkowo to był projekt, dla klienta który ma sklepy otwarte 24/h, więc release'y mieliśmy wieczorami (po 21 - 22) i za każdym razem z nami siedziała na Teamsach, razem z klientem nawet żeby pogadać o głupotach jak działały automaty. Tak żeby pokazać, że jest razem z zespołem : ) I to było coś co bardzo szanowałem.
Jasne, zgadzam się, że wiedza techniczna pomaga. Każda taka kompetencja ułatwia współpracę na każdej płaszczyźnie.
Jednak w takiej sytuacji w jakiej ja jestem i zapewne wiele innych osób kwestie techniczne należy nadrobić umiejętnościami innymi - doborem ludzi, delegowaniem zadań itp
Ogarnięcie Prince, ITIL itp na pewno must have
1
Prince2 jest take daleki od realiow w projektach jak kurs programowania od pracy jako programista :)
Jesli juz pracowales z projektami, ogarnij sobie w firmie prace jako kierownik projektu albo jakis subject matter expert przy projektach technicznych - i po prostu obserwuj i pytaj osoby techniczne jak to dziala.
Poczytaj o Scrumie, u mnie w ostatnich 2 firmach odpowiedzialni za pordukty od strony biznesu byli Product Ownerzy, ktorzy ni w zab nie byli techniczni, ale ogarnieci biznesowo - z czasem pytajac sie osob technicznych i czytajac o tym, nauczyli sie podstaw.