> 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 :-))