> recepta na kleske. Istotny jest tutaj efekt skali. Sredniego rozmiaru soft
to
> kilka tysiecy klas - kilkaset tysiecy linii kodu. Circa
> kilkanascie-kilkadziesiat osobolat na sama implementacje. To pare lat w
> kilkunasto-kilkudziesiecio osobowym zespole. Chcesz powiedziec, ze nalezy
> najpierw 8 lat projektowac, a pozniej 2 lata implementowac?
>
Oczywiście masz racje co do efektu skali i wiadomym jest ze nie robi sie
tego w calosciowych blokach tylko mniejszymi iteracjami np tak jak to
opisuje model spiralny czy nowsze podejścia. Upieram sie tylko przy tym ze
programowanie w sensie kodowania i testowania powinno byc tylko funkcja
wykonawcza w stosunku do tego co opracuje analityk i projektant. Twierdze
tez ze bolaczka i przyczyna porazki wielu projektow jest skupienie tych
trzech funkcji w jednej osobie. Zapewne dzieje sie tak z przyczyn
ekonomicznych, ale wlasnie praca analityka i projektanta stanowic powinna
80% ilosci (czasu) i ciezaru gatunkowego a praca programisty- kodera 20%.
Mialem okazje pracowac w firmie gdzie ten podzial byl bardzo wyraźny i moim
zdaniem przekladalo sie to na naprawde dobre efekty. W firmie gdzie obecnie
pracuje, w dziale informatyki takiego podzialu nie ma. Te same osoby
wykonują analizę, projekt i implementaję. Czasem ktos "trzeci" zrobi
przeglad projektu, ale całość procesu tworzenia oprogramowania, zresztą
także złożonego mogłaby trwać moim zdaniem krócej i efektywniej.
Nie ma też kogoś takiego jak PM który koordynowałby działania zespołu
programistów i zarządzał całością przedsięwzięcia, tak więc w porównaniu z
poprzednią firmą wszystko to "jakoś się samo toczy" ale nie jest to taka
"maszyna" która działała u mojego porzedniego pracodawcy. Przyczyną tego
stanu rzeczy są oczywiście finanse, lae konsekwencje także są niestety
mierzone finansowo, np. skutkiem nieprzeprowadzenia odpowiednich testów
softu jest postwanie kolejnych 4 wersji ktre również zawierały błedy, czyli
jak to mówią "Nowa wersja jest to stara wersja z nowymi błędami". W modelu
który funkcjonował w mojej poprzedniej firmie nie było czegos takiego- soft
nie wyszedl póki nie przeszedł udokumentowanych testów i póki wszelkie błedy
nie zostały usunięte. Byćmożewydaje się to droższe, ale w efekcie było
tańsze. Istotną sprawą była też odpowiedzialność. Nie pisałem o tym
wcześniej ale u poprzedniego pracodawcy opracowałem także i wdrożyłem ISO
(certyfikacja w kwietniu 2003), więc podział zadań i odpowiedzialności był
identyfikowalny i czytelny. Nie zdarzało się że wystąpił błąd ale nikt nie
wiedział kto go popełnił albo nikt nie był za niego odpowiedzialny. To
dyscyplinuje zwłaszcza na tych bardziej odpowiedzialnych stanowiskach.

Abstrahując od wszystkiego co tu zostało napisane nadal uważam że PM w
projekcie informatycznym nie musi być programistą a patrząc szerzej PM
jakiegokolwiek projektu nie musi być fachowcem branżowym- powiniem miec do
dyspozycji zespół projektowy zdolny do wykonania projektu i powinien umieć
wykorzystać (a często też kreować) jego potencjał.

Pozdro
--
Jackare
Bytom

dla mnie już chyba EOT :-))

do góry

Kaizen wrote:
> Pięknego dnia Tue, 1 Nov 2005 23:06:39 +0100, Dariusz Sznajder
> <d...@b...tu.kielce.pl> zakodował:
>
>> Do ułatwienia ww. zbierania. Wspólna baza pojęciowa (jak to już ktoś
>> gdzies w tym watku napisał) ułatwia po prostu komunikację.
>
> Dokładnie - to jest jedyne, do czego może przydać się znajomość
> merytoryczna problemu. Ale czy żeby rozmawiać o piłce nożnej trzeba w
> nią grać?

Żeby rozmawiać o piłce przy piwku - nie trzeba. Ale dla trenera to jednak
przydatna umiejętność.

Uważam, że kierownik projektu nie powinien być czynnym
programistą/analitykiem
czy projektantem. To przeszkadza, i to mocno.
Natomiast dobrze jest, żeby miał doświadczenie w pracy
na chociaż jednym z tych stanowisk (byle nie równocześnie).

Dzięki temu ma większe szanse na:
1) znalezienie wspólnego języka z zespołem
2) bycie poważnie traktowanym przez podwładnych
3) zrozumienie co się w projekcie dzieje
4) przewidywanie skutków swoich decyzji
5) trafną ocenę zagrożeń

Z drugiej strony - takie doświadczenie samo w sobie nie wystarcza do
dobrego kierowania projektem. Wiedza o zarządzaniu projektami oraz
osobiste predyspozycje są bardzo ważne.
Doskonały programista może być fatalnym materiałem na szefa projektu
(widziałem to zbyt wiele razy...), ale też "specjalista od zarządzania"
bez wiedzy merytorycznej potrafi koncertowo rozwalić projekt
(tyle że w inny sposób).

--
Marek "Barbidu" Barbaszyński
---- The signature has been optimized away
---- www.modele.civ.pl

do góry

>
> > recepta na kleske. Istotny jest tutaj efekt skali. Sredniego rozmiaru soft
> to
> > kilka tysiecy klas - kilkaset tysiecy linii kodu. Circa
> > kilkanascie-kilkadziesiat osobolat na sama implementacje. To pare lat w
> > kilkunasto-kilkudziesiecio osobowym zespole. Chcesz powiedziec, ze nalezy
> > najpierw 8 lat projektowac, a pozniej 2 lata implementowac?
> >
> Oczywiście masz racje co do efektu skali i wiadomym jest ze nie robi sie
> tego w calosciowych blokach tylko mniejszymi iteracjami np tak jak to
> opisuje model spiralny czy nowsze podejścia. Upieram sie tylko przy tym ze
> programowanie w sensie kodowania i testowania powinno byc tylko funkcja
> wykonawcza w stosunku do tego co opracuje analityk i projektant. Twierdze
> tez ze bolaczka i przyczyna porazki wielu projektow jest skupienie tych
> trzech funkcji w jednej osobie. Zapewne dzieje sie tak z przyczyn
> ekonomicznych, ale wlasnie praca analityka i projektanta stanowic powinna
> 80% ilosci (czasu) i ciezaru gatunkowego a praca programisty- kodera 20%.

Ale dlaczego "powinna"?

IMO mieszasz troche. Tu jest kilka rzeczy; to, ze role projektanta i analityka
powinny byc przypisane do roznych osob wynika z jednego (analityk potrzebuje
zupelnie innych umiejetnosci i wiedzy niz reszta - biznesowych, a nie
technicznych), to ze programista nie powinien testowac wynika z czegos innego
(testowanie to zadanie osobnego zespolu QA). Natomiast programista-projektant
to sensowne rozwiazanie w wielu przypadkach. Wydaje mi sie ze nie do konca
wiesz na czym polega praca projektanta w normalnym projekcie i dlatego starasz
sie przeciwstawic role projektanta i programisty. Zadaniem projektanta jest (pi
razy oko) zidentyfikowac i zaproponowac rozwiazania dla najwazniejszych
technologicznie problemow, a takze stworzyc i zaproponowac tzw architekture
przyszlego systemu. Jest to w pewnym sensie "programowanie" ale na nieco
wyzszym poziomie abstrakcji i, z reguly, w mniej formalnym jezyku. Nie ma
scislej granicy miedzy programowaniem a projektowaniem - ta granica jest
ustalana dla roznych technologii empirycznie i oznacza zazwyczaj subiektywny
podzial problemow na ogolne i szczegolne, te wazne i te mniej. Podzial
na "projektowanie" i "programowanie" jest w pewnym sensie podobny do podzialu
na "strategie" i "taktyke". Jest w ogolnym przypadku prawda, ze jesli sie nie
przyznaczy odpowiednia ilosc czasu na "strategie" to moze powstac koszmarny
system, ale konkretne proporcje powinny wynikac z logiki sytuacji, a nie byc
odgornie ustalone. Empiria zas pokazuje ze 80/20 do rzeczywistosci sie nie ma
nijak. "80/20" raczej wyglada na haslo wyjete z prezentacji marketoidow - trąci
bowiem przywiazaniem do zaokraglonych liczb i uproszczonej wizji swiata.
Dlaczego nie 81/19? Albo 82/18, czy 71,333/28,667?


> Mialem okazje pracowac w firmie gdzie ten podzial byl bardzo wyraźny i moim
> zdaniem przekladalo sie to na naprawde dobre efekty.

80%/20% ?? Caly czas piszesz tak jakbys gdzies widzial duzy dzialajacy soft
stworzony za sensowne pieniadze w taki sposob, ze implementacja zajela 20%.
Przyznam, ze dla mnie to sa bajki o zelaznym wilku. Mozesz mi przyblizyc nieco
szczegoly tego projektu? Moze byc na priva.


A.

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

do góry

Dzięki za wszystkie opinie.
Widzę, że znajomość technologii nie jest potrzebna project managerowi i w
przyszłości moim project managerem może być nawet ktoś kto przez studia
(informatyka) sobie przeszedł bez żadnego wysiłku.... A czy w ogóle do bycia
project managerem projektu strict informatycznego potrzebny jest dyplom mgr
informatyki? Jak wynika z powyższych wypowiedzi odpowiedź jest prosta:
nie....

Pozdrawiam

do góry

> Dzi?ki za wszystkie opinie.
> Widz?, ?e znajomo?ae technologii nie jest potrzebna project managerowi i w
> przysz?o?ci moim project managerem mo?e byae nawet kto? kto przez studia
> (informatyka) sobie przeszed? bez ?adnego wysi?ku.... A czy w ogóle do bycia
> project managerem projektu strict informatycznego potrzebny jest dyplom mgr
> informatyki? Jak wynika z powy?szych wypowiedzi odpowied 1/4 jest prosta:
> nie....

Nie, nie jest. Osoba obsadzona w roli PM musi mieć przede wszystkim duże
zdolności organizacyjne i interpersonalne, ponadprzeciętną empatię oraz
dobrze znać biznesowe aspekty metodyk wytwarzania oprogramowania. W
idealnym przypadku PM powinien mieć jeszcze *odrobinę* doświadczenia
analitycznego w zakresie tematycznym, którego dotyczy projekt, oraz
interesować się inżynierią oprogramowania, ale... najważniejsze jest
doświadczenie w zarządzaniu. Od spraw technologicznych jest Architekt,
od zarządzania jakością dział QA, a praca PM to mnóstwo rozmów,
zbieranie informacji o postępach, zarządzanie budżetem, zadaniami,
czasem i ludźmi, kontrolowanie ryzyka, raportowanie stanu prac
przełożonym. Wielu geeków rozpoczynając pracę w dużej firmie nie może w
rozgoryczeniu zrozumieć, że szefem projektu jest absolwent ekonomii,
biologii czy socjologii (w dodatku kobieta - szowinizm nadal
powszechny). I że Ci ludzie nie muszą znać C++ czy nawet mieć na biurku
Firefoxa, żeby efektywnie zarządzać projektem. Każdy PM pewnie
potwierdzi, że największym problemem nie są przeszkody technologiczne,
na jakie trafia zespół, ale poznanie ludzi, odpowiednia motywacja,
balans między potrzebami zespołu a naciskami z góry i prowadzenie
efektywnej współpracy umożliwiającej wyznaczanie realnych milestonów. To
poprzeczka trudna do przeskoczenia dla ludzi zamkniętych w
technologiach. A apodyktyczność nie musi być synonimem PM, co niektórzy
tutaj sugerują.

Pojawiły się jeszcze w tym wątku głosy o CMM. CMM nie jest metodyką, ale
standardem mającym mierzyć poziom dojrzałości procesu wytwarzania
oprogramowania - w skali od 1 do 5. Zdecydowana większość polskich firm
nie wyłączając największych nie osięga poziomu drugiego (bo nie ma ani
czasu, ani potrzeby), jedyną firmą w kraju, która ma certyfikowany CMM
5, jest Motorola Kraków. Wiele firm chwali się osiągnięciem poziomu
drugiego. RUP aspiruje do CMM 2. CMM nie ma bezpośredniego związku z
zarządzaniem projektem informatycznym na poziomie biznesowym poza tym,
że z utrzymaniem kolejnych poziomów wiążą się bardzo konkretne, stałe
wydatki.

Podział 80/20 w kontekście analiza / projektowanie & implementacja &
testowanie & wdrożenie & szkolenie jest mało realny nawet w przypadku
wdrożeń systemów standardowych. W przypadku tworzenia systemów od
podstaw rozbija się całkiem o rosnącą nie bez powodu popularność metodyk
agile.

Jeszcze odnośnie "skłonności do kompetencji". Rzadko zdarza się, żeby
dobry projektant-programista był dobrym analitykiem. Dużo łatwiej jest
przyjąć perspektywę PM'a analitykowi niż programiście. Można snuć teorie
podparte psychologią, płcią mózgu, itp., można też po prostu przejść z
tym do porządku dziennego i robić to, na czym człowiek zna się najlepiej.

pozdrawiam,

--
mgl

do góry