On 2004-12-08, macko42 <m...@g...pl> wrote:
> 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?
Wiesz, to, co napisała Immona to jedno z kryteriów pozwalających na
rozróżnienie firmy profesjonalnej od rzemieślniczej.

Pozdrawiam
Czesiu
--
Wróbelek Walerek miał mały werbelek
Werbelek Walerka miał mały felerek
Felerek werbelka naprawił Walerek
Wróbelek Walerek na werbelku swym grał

do góry

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

I.

do góry

On 2004-12-08, Immona <c...@W...com.pl> wrote:
> 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. :)
To ja jeszcze dodam od siebie, że znam firmy, gdzie mniejsze projekty robi
się w podobny sposób. Mniejsze w sensie ilości pracujących osób,
niekoniecznie stopnia komplikacji.

Pozdrawiam
Czesiu
--
Serwer odpowiedział:
- Mam trzy i pół macha [...]
http://fun.from.hell.pl/00-ROCZNIK-2001/stare/outloo
k.jpg

do góry

Użytkownik "Michał" <m...@i...pl> napisał w wiadomości
news:5d7a.00001f0f.41b62f80@newsgate.onet.pl...

> napisałyby powiedzmy o 1/4 szybciej niż ja (nie porównuję tutaj jakości
kodu,
> bo zakładam, że byłaby ta sama &#8211; podobna).

a to dlaczego?????

do góry

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?) ;)

powazniej - po miesiacu analizy projektu wielkosci 20-30 os/lat mozna bardzo
niewiele powiedziec na temat jego kosztu. Ba, niewiele mozna powiedziec na
temat tego co jest rzeczywiscie do zrobienia (pomijajac rzadkie przypadki
bardzo typowych rozwiazan, ale nikt raczej nie zamawia dedykowanych systemow
do typowych rozwiazan).
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".

tylko nie wiem co jest w tym "normalnego".



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

do góry

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.

do góry

Użytkownik "Artur R. Czechowski" <a...@h...pl> napisał w wiadomości
news:slrncrdsi5.m92.arturcz@blabluga.hell.pl...
> On 2004-12-08, Immona <c...@W...com.pl> wrote:

> > to po partyzancku i potem jest nie powiem co, to inna sprawa. :)
> To ja jeszcze dodam od siebie, że znam firmy, gdzie mniejsze projekty robi
> się w podobny sposób. Mniejsze w sensie ilości pracujących osób,
> niekoniecznie stopnia komplikacji.

Sa jak widac ludzie, ktorzy "kanoniczny" (jak do niedawna naiwnie sadzilam)
project management traktuja jak bajke o zelaznym wilku. :o

I.

do góry

Immona <c...@W...com.pl> napisał(a):
>
> 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.

poniewaz jest to praktyka powszechna, to wyliczony w ten sposob termin
nie jest znaczaco rozny od konkurencji. W innym dosyc typowym przypadku
termin podany na poczatku jest przeciagany w koncowym rozrachunku. Albo
dostarcza sie rozwiazanie spelniajace nie rzeczywiste potrzeby klienta,
a te zapisane w kontrakcie - zwykle wszystko jest ok, bo po stronie klienta
manager od IT nie polozy swojej glowy przyznajac, ze wymagania byly
zle sformulowane - porzadne sformulowanie wymagan w projekcie rzedu 20-30
lat to zadanie _znacznie_ znacznie wieksze niz miesiac czasu i co wazniejsze -
proktycznie nie wykonalne metoda kaskadowa - - o tym tez mozna przeczytac w
kazdej sensownej ksiazce.


> 2) Analiza punktow funkcyjnych potrafi dac wyliczenia bynajmniej nie wziete
> z sufitu, gdy to robi ktos, kto sie na tym dobrze zna.

to jeszcze powiedz skad wezmiesz WYMAGANIA po miesiacu analizy (ciagle
zakladamy projekt o wielkosci wspomnianej wczesniej).
Od razu odpowiem: z sufitu. Jak sie ktos choc troche zna to jest to
oczywiste.


> > tylko nie wiem co jest w tym "normalnego".
>
> Ze sie pracuje spokojnie, nadgodziny nie sa norma tylko wyjatkiem, a
> wszystko jest pod kontrola.
>

pod tym wzgledem moze i tak. Jesli sie uda podpisac taki kontrakt, to tak.
tyle, ze nie jest to droga do spelnienia rzeczywistych wymagan klienta,
po kosztach zblizonych do optymalnych. Ale jak wiadomo chociazby z filmu Mis -
prawdziwe interesy robi sie na wielkich, slomianych inwestycjach.
Ja nie chce tego nazywac "normalnoscia".




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

do góry

Immona <c...@W...com.pl> napisał(a):

>
> Użytkownik "Artur R. Czechowski" <a...@h...pl> napisał w wiadomości
> news:slrncrdsi5.m92.arturcz@blabluga.hell.pl...
> > On 2004-12-08, Immona <c...@W...com.pl> wrote:
>
> > > to po partyzancku i potem jest nie powiem co, to inna sprawa. :)
> > To ja jeszcze dodam od siebie, że znam firmy, gdzie mniejsze projekty robi
> > się w podobny sposób. Mniejsze w sensie ilości pracujących osób,
> > niekoniecznie stopnia komplikacji.
>
> Sa jak widac ludzie, ktorzy "kanoniczny" (jak do niedawna naiwnie sadzilam)
> project management traktuja jak bajke o zelaznym wilku. :o
>

jesli to o mnie, to tak, faktycznie tak to traktuje.
Podobnie traktuja to tacy panowie jak chociazby Uncle Bob, M. Fowler,
R. Jeffries i wielu, wielu innych. Moze te nawiska obily Ci sie o uszy.
Kanowy w tym fachu staja sie nieaktualne bardzo szybko.
Ale w przypadku, o ktorym mowimy tak nie jest - podejscie, o ktorym piszesz
jest mocno krytykowane od co najmniej 10 lat. I na pewno juz kanonem
nie jest. Chyba, ze kanonem zlego prowadzenia projektu. To, ze jest
ciagle uzywane w wielu miejscach, to duzo za malo zeby je obronic.
Zwlaszcza stosowanie go w tzw. korporacjach niczego nie dowodzi.
(jesli juz to tylko tego jak niewydajne i nieelastyczne sa tego typu
organizacje).

Pewnie bedzie to dla Ciebie zaskoczeniem, ale sa sensowne alternatywy dla
takiego podejscia i daleko im do "partyzantki".



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

do góry

On 2004-12-08, macko42 <m...@g...pl> wrote:
> Pewnie bedzie to dla Ciebie zaskoczeniem, ale sa sensowne alternatywy dla
> takiego podejscia i daleko im do "partyzantki".
Extreme programming? No well, niektóre założenia są fajne, ale ogólnie
to to zdecydowanie nie jest styl pracy do użycia w korporacjach. Pogooglaj
sobie po pl.comp.* przez ostatnie pół roku - było parę dyskusji na ten
temat.

Pozdrawiam
Czesiu
--
UPeeSy strzelają, Admin baty znosi
/z pamiętnika administratora/

do góry