пропозиції роботи
Tomasz Zbik
PRINCE2 Practitioner, Kierownik Projektów Finansowych, Hewlett-Packard Global e-Business Operations Sp. z o.o.
Wypowiedzi
-
Aby mieć możliwość przeczytania tego posta musisz być członkiem grupy Zarządzanie Projektami
-
Witam
Spotkałem się z zasadą "nota kredytowa per faktura" - dotyczyło to rabatów które były przyznawane po dokonaniu zapłaty (im szybciej płacisz tym większy masz rabat). W następnym rozliczeniu z klientem noty kredytowe nabyte przy poprzednim paymencie były rozliczane w następnym paymencie) - klient definiował za co płaci z czego czerpie rabat -
Skup się na kulturze i strukturze organizacyjnej firmy oraz na procesie decyzyjnym związanym z projektami. Pamiętaj że tego rodzaju dokumentacja i procedury mają za zadanie:
1. Dokumentować podjęcie się odpowiedzialności za dane przedsięwzięcie (np Karta Projektu która określa sponsorów, kierownika projektów itp)
2. Dokumentować treść i sposób prowadzenia projektu (zakres, plan, budżet itp)
3. I co najważniejsze - tego typu dokumenty i procedury mają za zadanie umożliwienie procesu monitorowania postępów i zmian w projekcie.
Jeśli teraz masz za zadanie stworzenie takiego obszaru to niestety ale na naukę od podstaw jest trochę za późno - chociaż w internecie możesz znaleźć wzorce niektórych dokumentów - niektóre firmy i instytucje je publikują.
Powodzenia -
Czy masz jakiś konkretny problem do rozwiązania?
-
Aby mieć możliwość przeczytania tego posta musisz być członkiem grupy Zarządzanie Projektami
-
Aby mieć możliwość przeczytania tego posta musisz być członkiem grupy Zarządzanie Projektami
-
Paweł S.:
Po informatyce i ekonometrii niekoniecznie tworzy sie oprogramowanie. Wnioskowanie oparte o założenia nie zaś o fakty prowadza natomaist zwykle do wielu błędów.
Nadal uwazam, że poznawanie jakiejkolwiek metodyki specyficznej dla branży ma sens dopiero po poznaniu podstaw, tak wiec zakładajac, że Autorkę interesuja softwere'owe proejkty informatyczne, SCRUM-a zostawiłbym na koniec.
Panie Pawle
Proszę nie mieć mi tego za złe ale mam wrażenie, że nasza dyskusja obraca się w niepotrzebną przepychankę na argumenty. To prawda że SCRUM i Agile zostały stworzone dla potrzeb programistycznych ale z równym powodzeniem mogą być wykorzystywane do tworzenia jakiegokolwiek nowego produktu/wymagań funkcjonalnych w innych obszarach (np motoryzacja - przykład BMW)- SCRUM i Agila to przede wszystkim praktyki a to jak je wykorzystamy zależy od nas - nie zgadzam się z twierdzeniem że dana metodyka jest specyficzna dla tej czy innej branży. W swojej pierwszej odpowiedzi wspomniałem o Agile, Scrum i książce pana Philipsa ponieważ uważam że jest to dobry początek aby uświadomić sobie czym jes PM - wspomniane pozycje są proste i praktyczne - przez co są zrozumiałe - i to wg mnie jest dobry początek. Później jak zasugerowałem można sięgnąć po o wiele bogatsze w wiedzę opracowania jak PMBoK. To że Joanna studiuje informatykę i ekonometrię jest faktem a nie założeniem, w związku z tym opracowania PM związane z IT mogą być dla Niej łatwiejsze do przełożenia na praktykę (oczywiście że nie musi w przyszłości zajmować się programowaniem ale wg mnie najważniejsze to zrozumieć podstawy aby później móc się dalej rozwijać bez braków kompetencyjnych). Co do reszty w pełni się z Panem zgadzam.
Powodzenia -
Dlaczego "Zarządzanie projektami IT" oraz Agile i SCRUM? Autorka słowem nie wspomina ani nie ma w profilu informacji, że interesują ją projekty IT, a podane metodyki oraz literatura tych właśnie dotyczą.
Projekty IT są drobmnnym ułamkiem wszystkich realizowanych projektów, do tego mają swoją specyfikę, która niekoniecznie przystaje np do budowalnych projektów inwestycyjnych (ciekawe jak przebiegłaby budowa wieżowca zarządzania zgodnie ze SRUM-em ;-) )
Pozostałe punkty brzmią sensownie. Co do literatury polecam nieodmiennie zacząć od "Zdążyć przed terminem" DeMarco, potem Wysocki - Efektywne zarządzanie projektami, można dorzucić studia przypadków Kerznera i "Łańcych krytyczny" Goldratta. Jeśli podeprzemy to mądrze wybranymi studiami podoplomowymi lub dobrym szkoleniem, dołączymy następnie (istotna kolejność) podręcznik któejś z metodym (PRINCE2 / PMBoK) i zaczniemy tę wiedzę wykorzystywać w praktyce najpierw jako asystemt PM-a potem jako PM - sukces murowany :-)
Powodzenia!
PawełPaweł S. edytował(a) ten post dnia 11.01.10 o godzinie 19:00
Autorka jest na 4 roku studiów na kierunku Informatyka i Ekonometria więc nie przypuszczam by miała zamiar budować wieżowce, w związku z tym przypuszczam że i ten punkt "brzmi sensownie". -
Joanno
Tak z mojej historii, najpierw trzeba mieć doświadczenie w jakiejkolwiek branży aby mieć jako-takie pojęcie o procesach i realiach panujących w prawdziwym środowsku pracy (procedury, relacje międzyludzkie, praktyki i wszelkie problemy jakie się z tym wiążą). Dobrze, że wiesz co chcesz robić ponadto wnioskuję po kierunku studiów że będziesz miała ku temu możliwości, ale bez podstawowego doświadczenia zawodowego ciężko będzie Ci przekuć wiedzę teoretyczną w praktykę. Spójrz na ogłoszenia o pracę na stanowisko PM - pracodawcy poza wiedzą o PM wymagają doświadczenia/ wiedzy specjalistycznej.
A poza tym:
1.Pracując na stanowisku innym niż PM staraj się wychodzić z inicjatywą i upsprawniać procesy - nawet jeśli pracodawca cię nie doceni ty zdobędziesz podstawowe doświadczenie i będziesz mogła wzbogacić swoje CV.
2. Naukę teorii PM polecam od podstaw - jeśli jesteś zainteresowana projektami IT polecam pozycję - http://helion.pl/ksiazki/zarzit.htm
Jest to bardzo praktyczne i zrozumiałe opracowanie.
3. Jeśli masz podstawy wiedzy PM - rozwijaj ją studiując PMBoK, opracowania dotyczące Agile i Scrum
4. Bezdyskusyjnie - bardzo przydatne jest uczestniczenie w szkoleniu organizowanym przez profesjonalnego trenera - znów chodzi o to że będzie on w stanie przetłumaczyć teorię w praktyczne przykłady
5. Jeśli już zrealizujesz pukty 1 -4 nie czekaj aż ktoś cię awansuje na PM - aplikuj i staraj się sama zdobyć takie stanowisko w tej czy innej firmie.
To co napisałem to w 100% droga którą sam przeszedłem, mam nadzieję że i tobie się uda.
Pozdrawiam i życzę powodzenia. -
Aby mieć możliwość przeczytania tego posta musisz być członkiem grupy Zarządzanie Projektami
-
Aby mieć możliwość przeczytania tego posta musisz być członkiem grupy Zarządzanie Projektami
-
Aby mieć możliwość przeczytania tego posta musisz być członkiem grupy Zarządzanie Projektami
-
Aby mieć możliwość przeczytania tego posta musisz być członkiem grupy Zarządzanie Projektami
-
Polecam "Zarządzanie Ryzykiem w Projektach" - Carl L. Pritchard.
Treśc powstała w oparciu o standardy PMI i dotyczy ryzyka tak w projektach jak i w procesach operacyjnych.
Pozdrawiam
Dołącz do GoldenLine
Oferty pracy
Sprawdź aktualne oferty pracy
Aplikuj w łatwy sposób
Aplikuj jednym kliknięciem
