Użytkownik "macko42" <m...@g...pl> napisał w wiadomości
news:cp70bt$i1g$1@inews.gazeta.pl...
> Immona <c...@W...com.pl> napisał(a):
>
> >
> > Użytkownik "macko42" <m...@g...pl> napisał w wiadomości
> > news:cp6r3o$mh9$1@inews.gazeta.pl...
> > > Immona <c...@W...com.pl> napisał(a):
> > >
> > > > Twoje doswiadczenie bylo w zlych firmach. W normalnej firmie
pierwszy
> > > > miesiac czy dwa pracy nad projektem to rozeznawanie, ile osobolat
trzeba
> > > > bedzie na niego poswiecic.
> > >
> > > piszesz to powaznie, czy to zart?
> >
> > Pisze to powaznie - z tym, ze mam takie skrzywienie, ze dla mnie
"normalne"
> > firmy to takie piszace software dla miedzynarodowych bankow, producentow
> > samochodow, technologii medycznych itp. Tam, gdzie jest profesjonalny
> > project management, a projekty sa co najmniej sredniej wielkosci (rok
pracy
> > 20-30-tu osob i wiecej). Ze w wiekszosci mniejszych firm w Polsce robi
sie
> > to po partyzancku i potem jest nie powiem co, to inna sprawa. :)
>
> sorry, za ironie, ale czy szacunek czasu/kosztu takiego projektu w
> takich "normalnych" firmach wyglada w taki sposob jak napisalas w innym
poscie
> w tym watku (analityk pyta sie programisty ile zajmie mu czasu zadanie?)
;)

Oczywiscie wstepny szacunek czasu projektu odbywa sie przez analize p.
funkcyjnych, a nie dyskusje z kazdym programista oddzielnie - samodzielne
ustalanie deadline'ow dotyczy raczej biezacej organizacji pracy.

Potem projekt jest dzielony na male kawalki. Sa one rozdzielane, a kazdy
programista sam szacuje potrzebny mu czas i na tej postawie tworzy sie
rozklad jazdy. Dobry programista zwykle jest w stanie oszacowac, ile mu
zajmie dane zadanie. "Zadanie" to tu na tyle mala czesc kodu, ze jest w
stanie ja ogarnac. Jest to sprawdzona metoda, a deadline'y sa szanowane
przez ludzi, ktorzy je sami zadeklarowali.

Jesli ktos stwierdzi, ze nie da rady w tym czasie, zglasza to. W jednej ze
znanych mi firm jest zasada, ze musi zglosic to na tyle wczesniej przed
terminem, ile wiecej czasu mu trzeba (trzeba miesiac dluzej - zglasza to
miesiac przed terminem).

Zbadano w Hameryce, ze programista jest wydajniejszy, czyli szybciej napisze
ten sam kod, jesli sam wyznacza termin. Ta rewelacja jest wspominana w
prawie kazdej wspolczesnej ksiazce o project managemencie w IT.



> W rzeczywistosci bierze sie wyliczenie, ktore sie urodzi w ciagu
> takiej "analizy" (cudzyslow nie jest przypadkowy) - czyli wyliczenie z
sufitu
> i mnozy (a nie dodaje) sie przez cos co eufemistycznie nazwalas
'marginesem
> bezpieczenstwa' (ja raczej nazwalbym to 'wspolczynnikiem robienia klienta
w
> balona'). Wspolczynnik jest zwykle na tyle duzy, ze potem mozna sie
chwalic,
> ze ma sie "90% projektow zakonczonych w terminie".

1) Nie da sie przesadzac - bo na rynku jest konkurencja. Jakby ktos oferowal
kilkakrotnie dluzsze terminy niz inni (ktorym by tez sie udawalo ich
dotrzymywac) to by klienci od niego uciekli.
2) Analiza punktow funkcyjnych potrafi dac wyliczenia bynajmniej nie wziete
z sufitu, gdy to robi ktos, kto sie na tym dobrze zna.

>
> tylko nie wiem co jest w tym "normalnego".

Ze sie pracuje spokojnie, nadgodziny nie sa norma tylko wyjatkiem, a
wszystko jest pod kontrola.

I.