Jackare napisał(a):
>>Powyzsza wypowiedz to zwykle lanie wody, niestety (CMM - o moj Boze).
>>
>
> bede sie niestety up[ieral przy swoim. PM- programista "wypacza" zazwyczaj
> poczatkowe fazy projektu.
Każdy PM, który słabo orientuje się w metodologii zarządzania projektami
wypacza na ogół początkowe fazy.

> 8/10 czasu przeznaczonego na stworzenie czegos od podstaw powinien zajac
> projekt mowiacy CO nalezy uzyskac (jakei efekty, cele, procesy) 2/10 to czas
> przeznaczony na to JAK to zrobic.
Stare i z brodą - zasada Pareto. Takie propocje nakładu pracy
koncepcyjnej (80%) w stosunku do wykonawstwa (20%) zalecane są wszędzie,
nie tylko w metodologii zarz. projektami.

> Niestety, wiekszosc programistow od razu przechodzi do fazy JAK.
> A PM zarzadza- to jego rola. Nie projektowanie, programowanie i inne prace
> merytoryczne nad samym produktem. PM zarzadza- to kierownik, ktory pilnuje
> kto, co gdzie i kiedy oraz za ile.
Dokładnie w ujęciu większość nurtów zarz. projektami, PM to lider, a
więc członek zespołu, również wykonujący prace.

> Wiadomo ze im wiecej ma wiedzy fachowej
> obejmujacej zagadnienie tym latwiej jemu i z nim jest sie komunikowac,
Ponoć ludzie odbierają informację w następujący sposób: 65% to obraz,
38% głos, 7% to treść. Przez telefon to będzie 82% głos, 18% treść. W
słowie pisanym nie wiem, ale wynalazek emotów mówi sama za siebie -
kanał treści jest zbyt ubogi.

Łatwiej będzie mu się komunikować, jeśli potrafi to robic - choćby po to
, by dopytać tam, gdzie brak mu wiedzy merytorycznej.

pozdr.
m.

do góry

Maciek Sobczyk napisał(a):

> Dokładnie w ujęciu większość nurtów zarz. projektami, PM to lider, a
> więc członek zespołu, również wykonujący prace.
W tym momencie przypomniał mi się wyjątek - projekty złożone z PM i
niezależnych podwykonawców (np. inwestycje budowlane pod klucz).

pozdr.
m.

do góry

>
> Przykro mi, ale z powyzszego nic nie rozumiem. Co to "PM- programista"?
> Dlaczego on musi cos wypaczyc?
To PM ktory jest z zawodu programista lub wczesniej pracowal jako
programista.


I o co chodzi z tymi 2/10 i 8/10? Chcesz
> powiedziec, ze analiza wymagan powinna zajac 80% czasu projektu? :-)
>
Tak. 80% casu powinna zajac analiza planowanie i stworzenie PROJEKTU a nie
produktu. Stworzenie produktu wg dobrego projektu powinno zajac 20%
planowanego na wykonanie calosci czasu.

> Probujesz narzucic dualizm "spec od zarzadzania"-"spec od programowania",
tak
> jakby te rzeczy sie wykluczaly. Tak prosto swiat wyglada tylko na
folderach
> reklamowych.
Nie. Probuje wyjasnic ze PM w projekcie informatycznym wcale nie musi byc
programista i nigdzie nie napisalem ze nie moze byc programista. Po prostu
mowie o zagrozeniach: programista bedzie patrzyc na projekt z perspektywy
"jak to zrobic" a nie "co nalezy osiagnac". Identyfikuje to jako jedno z
zagrozen Tak samo wiele zagrozen- innego rodzaju moze generowqac PM ktory
nie jest programista lub informatykiem inneh specjalizacji. Chce tylko
powiedziec ze uwazam ze PM w projekcie informatycznym nie musi byc
programista
--
Jackare
Bytom

do góry

> Probuje wyjasnic ze PM w projekcie informatycznym wcale nie musi byc
> programista i nigdzie nie napisalem ze nie moze byc programista.
Projektant systemu informatycznego (bo chyba to masz na myśli)
MUSI biegle programować w języku podobnym do języka realizacji projektu.

(w nowej ortografii)
Projektant systemu informatycznego (bo hyba to masz na myśli)
MUSI biegle programować w języku podobnym do języka realizacji projektu.


> Po prostu
> mowie o zagrozeniach: programista bedzie patrzyc na projekt z perspektywy
> "jak to zrobic" a nie "co nalezy osiagnac".
Zapomniałeś , że są też inne zagrożenia.
Zagrożenia wynikające z projektu , który nie będzie brał pod uwagę wydolności
sprzetu, oprogramowania, wydolności programistów (to też ludzie) i wielu innych.
(w nowej ortografii)
ZZapomniałeś , że są też inne zagrożenia.
Zagrożenia wynikające z projektu , ktury nie będzie brał pod uwagę wydolności
spszetu, oprogramowania, wydolności programistuw (to też ludzie) i wielu innych.

> Chce tylko
> powiedziec ze uwazam ze PM w projekcie informatycznym nie musi byc
> programista
Wielu jest takich, którym się tak wydaje. I dlatego pada wiele projektów, i
dlatego ludzie psioczą na informatyków,
którzy informatykami nie są ale się za nich podają.
Ty jesteś jednym z takich "informatyków".
(w nowej ortografii)
Wielu jest takih, kturym się tak wydaje. I dlatego pada wiele projektuw, i
dlatego ludzie psioczą na informatykuw,
ktuży informatykami nie są, ale się za nih podają.
Ty jesteś jednym z takich "informatykuw".


--
Wysłano z serwisu OnetNiusy: http://niusy.onet.pl

do góry

> I o co chodzi z tymi 2/10 i 8/10? Chcesz
> > powiedziec, ze analiza wymagan powinna zajac 80% czasu projektu? :-)
> >
> Tak. 80% casu powinna zajac analiza planowanie i stworzenie PROJEKTU a nie
> produktu. Stworzenie produktu wg dobrego projektu powinno zajac 20%
> planowanego na wykonanie calosci czasu.

Jest to oczywiscie NTG, ale prezentujesz dosc nietypowe podejscie do tematu.
Mi jest znane inne: analiza, planowanie itp powinno zajac tyle czasu ile
potrzeba :-)
Moim nieskromnym zdaniem zasada podzialu 80/20 (dowolnego innego zreszta tez)
do ustalenia proporcji czynnosci takich projektowanie/analiza/implementacja
et cetera to nieporozumienie, ze sie posluze eufemizmem. Nie da sie ustalic
scislych proporcji pomiedzy analiza a reszta, bowiem dopiero z wykonanej
analizy wynika dokladniejsze oszacowanie czasu na projektowanie,
implementowanie, testowanie itd. W szczegolnosci z owej analizy moze
wyniknac, ze trzeba oprogramowac stacje orbitalna, a moze - ze trzeba zrobic
tylko strone w HTML o stacji orbitalnej. Nie ma tez scislych zaleznosci
pomiedzy czasem trwania implementowania a czasem trwania tprojektowania. Te
czynnosci, zreszta, czesto sa robione w stosunkowo krotkich iteracjach,
czesto przez te same osoby.
Przy tworzeniu produktow nieco wiekszych niz e-sklep w php/mysql, tworzenie w
jednym rzucie projektu na tyle szczegolowego, ze sama implementacja bedzie
trwac krocej niz projektowanie jest na tyle kosztowne i ryzykowne, ze swiat
juz dawno zarzucil podobne pomysly. Inzynierowie doszli to takiego wniosku
juz na poczatku lat 70'. A Fred Brooks napisal w '75 doskonala ksiazke m.i.
na ten temat http://en.wikipedia.org/wiki/Mythical_Man_Month. Znaczy on
zauwazyl ze podejscie "najpierw analiza i szczegolowy projekt calosci, potem
implementacja" skutkuje zazwyczaj wyrzuceniem calosci do kosza.


> > Probujesz narzucic dualizm "spec od zarzadzania"-"spec od programowania",
> tak
> > jakby te rzeczy sie wykluczaly. Tak prosto swiat wyglada tylko na
> folderach
> > reklamowych.
> Nie. Probuje wyjasnic ze PM w projekcie informatycznym wcale nie musi byc
> programista i nigdzie nie napisalem ze nie moze byc programista. Po prostu
> mowie o zagrozeniach: programista bedzie patrzyc na projekt z perspektywy
> "jak to zrobic" a nie "co nalezy osiagnac". Identyfikuje to jako jedno z
> zagrozen Tak samo wiele zagrozen- innego rodzaju moze generowqac PM ktory
> nie jest programista lub informatykiem inneh specjalizacji.

Ale zagrozenie to jest lekko wydumane, opiera sie bowiem na wygodnym dla
danej tezy stereotypie (programista -> bedzie robil to i tamto). FUD jednym
slowem.

>Chce tylko
> powiedziec ze uwazam ze PM w projekcie informatycznym nie musi byc
> programista

A to truizm.


A.

--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

do góry

Strokrotko,

Jestes daremna. Walczysz z wiatrakami. Wsadz sobie ta Twoja "ortografie" w
buty - bedziesz wyzsza.
--
Jackare

do góry

Pięknego dnia Mon, 31 Oct 2005 08:07:27 +0000 (UTC), "Aleksander
Galicki" <t...@g...pl> zakodował:

>Otoz idealnie PM powinien posiadac i wiedze i
>owe zdolnosci. Nie ma zadnego dualizmu "soft skills"-"wiedza merytoryczna".
--
Pozdrawiam,
Kaizen x...@c...sz zanim zapytasz odwiedź www.google.com
GG 2122; ICQ#: 64457775 e-mail Rot13 coded
If you cannot make sth good, make it looking good. - Bill Gates

do góry

> > Probuje wyjasnic ze PM w projekcie informatycznym wcale nie musi byc
> > programista i nigdzie nie napisalem ze nie moze byc programista.
> Projektant systemu informatycznego (bo chyba to masz na myśli)
> MUSI biegle programować w języku podobnym do języka realizacji projektu.

Kochanie ;-)

PM to project manager- w naszym pięknym i trudnym języku znany jako
kierownik projektu. On nie musi programować w żadnym języku programowania.
Co się wg Ciebe stanie w przypadku projektu na który składa się wiele
technologii, np baza danych lub kilka różnych baz, aplikacje użytkowe,
oprogramowanie integrujące z innymi systemami i urządzenia wykonawcze
(oczywiście sterowane mikroprocesorowo) stworzone tylko na potrzeby
aktualnie realizowanego projektu ?
Czy kierownik projektu lub nawet projektant systemu musi biegle programować
we wszystkich zastosowanych technologiach? A może najlepiej będzie jak on to
wszystko sam od A do Z zrealizuje :-) ?

>
> (w nowej ortografii)
Tak, tak - ubierz się ładnie....


> Zapomniałeś , że są też inne zagrożenia.
> Zagrożenia wynikające z projektu , który nie będzie brał pod uwagę
wydolności
> sprzetu, oprogramowania, wydolności programistów (to też ludzie) i wielu
innych.

Od tego jest między innymi PM aby te zagrożenia zidentyfikować i pokierować
projektem w taki sposób aby zminimalizować wpływ zagrożeń na realizację
projektu

> (w nowej ortografii)
O, jak miło ! Jesteś już ubrana. Pan doktor czeka.....

> Wielu jest takich, którym się tak wydaje. I dlatego pada wiele projektów,
i
> dlatego ludzie psioczą na informatyków,
> którzy informatykami nie są ale się za nich podają.
> Ty jesteś jednym z takich "informatyków".

Kotku, co rozumiesz pod pojęciem "informatyk" ? I po co te osobiste przytyki
?
Dlaczego zakładasz, że wiesz kim jestem i że na dodatek z tego kim jestem
wynikają same złe rzeczy :-)

Jesteś denna z ortografii i mosisz paskudne ciuchy. Jesteś też na pewno
gruba i nosisz okulary -7 dioptrii.
Pan doktor już czeka.

--
Jackare
Bytom

do góry

Pięknego dnia Sat, 29 Oct 2005 11:42:50 +0200, "Adamzrk"
<a...@g...pl> zakodował:

>
> Jestem ciekaw czy mozna być project managerem bez doświadczenia w
>projektowaniu/programowaniu? Widząc ogłoszenia o pracę najczęściej jest ono
>wymagane, jednak u mnie na uczelni twierdzą inaczej. Proszę o opinię.

Doświadczenie w programowaniu na stanowisku PM jest tak samo
niezbędna, jak umiejętność jeżdżenia samochodem. Wcale nie jest
niezbędna - a czy się przyda w jakimkolwiek stopniu, zależy od
projektu.

Równie dobrze na stanowisku PM menadżera projektu budowy systemu ERP
może się sprawdzić informatyk jak i ekonomista - za to psycholog
będzie miał łatwiej.

Zarządzanie projektem (nawet informatycznym) ma bardzo niewiele
wspólnego z informatyką. Zarządzanie projektem to kierowanie grupą
ludzi i zasobami - nie jest Twoim zadaniem projektowanie
funkcjonalności, testowanie aplikacji czy nawet ustalanie zasad
komentowania kodu źródłowego.
Większość zadań PM to kwestie, tfu, polityczne (dobranie zespołu,
motywowanie go), kontrolowanie postępu prac, zapewnienie zespołowi
odpowiednich zasobów i informacji do działania.

Jedyną pożyteczną wiedzą z zakresu IT dla PM jest znajomość aplikacji
biurowych z naciskiem na MS Project (lub podobne narzędzie).
--
Pozdrawiam,
Kaizen x...@c...sz zanim zapytasz odwiedź www.google.com
GG 2122; ICQ#: 64457775 e-mail Rot13 coded
If you cannot make sth good, make it looking good. - Bill Gates

do góry

Dnia 01.11.2005 Kaizen <x...@c...sz> napisał/a:
> motywowanie go), kontrolowanie postępu prac, zapewnienie zespołowi
No, do tego: ^^^^^^^^^^^^^^^^^^^^^^^^^^

> odpowiednich zasobów i informacji do działania.
>
> Jedyną pożyteczną wiedzą z zakresu IT dla PM jest znajomość aplikacji
> biurowych z naciskiem na MS Project (lub podobne narzędzie).
to jednak pewna wiedza merytoryczna też się przydaje.

--
Dariusz Sznajder
DSZ1-RIPE

do góry