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ć?
- Rejestracja:prawie 5 lat
- Ostatnio:prawie 5 lat
- Postów:4
0
- Rejestracja:prawie 5 lat
- Ostatnio:prawie 5 lat
- Postów:4
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
- Rejestracja:około 7 lat
- Ostatnio:18 dni
- Postów:145
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.
edytowany 2x, ostatnio: MatD
- Rejestracja:prawie 5 lat
- Ostatnio:prawie 5 lat
- Postów:4
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
- Rejestracja:prawie 6 lat
- Ostatnio:ponad rok
- Postów:7
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.