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

>
> Użytkownik "macko42" <m...@g...pl> napisał w wiadomości
> news:cp93lt$smf$1@inews.gazeta.pl...
> > Immona <c...@W...com.pl> napisał(a):
> >
> > > Wymagania klienta?
> > > W tej dzialce, gdzie jeden biznesowy gigant zamawia software u drugiego,
> nie
> > > ma takich jazd z kaprysami i zmianami, jak gdy zamowienia dokonuje firma
> > > kompletnie nie znajaca sie na tym, co zamawia. Zamawiajacy wie, czego
> > > potrzebuje i jest w stanie wspolnie z wykonawca opracowac specyfikacje,
> w
> > > ktorej nie bedzie potem radykalnych zmian
> >
> > spokojnie. Zakladasz, ze jest juz zamawiajacy i wykonawca.
> > Niestety wykonawca zostaje zazwyczacj wybrany na podstawie _ofety cenowej_
> > jaka przedstawil.
>
> Do jednej firmy, ktora znam, jest kolejka chcacych, zeby dla nich napisala
> soft. A bynajmniej nie jest najtansza - przeciwnie.
> Sa na swiecie ludzie i firmy, dla ktorych sie liczy jakosc i marka. Cena
> jest gdzies na koncu rzeczy, ktore sie licza.

ja tez znam takie firmy. Liczy sie "marka". Jakosc nie - bo ta jest wyjatkowo
marna w firmach, o ktorych pisze. Ale mniejsza o to.
w powyzszym chodzilo glownie o to, ze cena w ofercie jednak musi sie znalezc
i o to jak ja wyznaczyc. I ze ten proces jest w wielu przypadkach postawiony
na glowie.

> (I biedni sa ci, ktorzy musza dzialac na rynku, na ktorym konkuruje sie
> glownie cena.)

roznie bywa z ta biednoscia ;)


> A oferta cenowa powstala w wyniku mniej wiecej miesiaca
> > "analizy" na podstawie wymagan, ktore zamawiajacy przedstawil.
> > A zamawiajacy zwykle nie potrafi przedstawic porzadnych wymagan.
> > Bo to jest trudne i potrafia to w zasadzie wylacznie ludzie, ktorzy
> zajmuja
> > sie tym profesjonalnie,
>
> Zamawiajacy ma zespol, ktory zajmuje sie tym profesjonalnie.

w cytacie, ktory obcielas bylo cos o ciaglosci tego procesu.
Zespol po stronie zamawiajacego moze takie rzeczy robic na papierze.
Kwestionuje wartosc czegos takiego. Papier jest cierpliwy.


> > Praca zamawiajacego z kazdym kandydatem na wkonawce nad specyfikacja
> wymagan
> > jest w praktyce nierealna.
>
> Powtarzam - to kandydatow na klientow jest kolejka.

dobra. to jak juz sie ten klient dopcha, to siadaja z wykonawca robia
analize i juz jest wszystko jasne? tak?


> > analizy. Zapewniam, ze jest to znacznie, znacznie wiecej niz 1 miesiac
> > przy projekcie tej wielkosci.
> >
>
> ok, nie upieram sie przy 1 miesiacu. "1-2 miesiace" i 20-30 osobolat" to
> byly liczby rzucone _oddzielnie_. Zauwaz, ze kogos z dyskutantow zszokowala
> sama idea poswiecania 1 miesiaca na sama analize :)

to dobrze, ze sie nie upierasz.
Ja, natomiast, nie wierze w skutecznosc KOMPLETNEJ
analizy robionej z gory. I za tym stoi wiekszosc obecnych opracowan
z inzynierii oprogramowania.

> > > > Od razu odpowiem: z sufitu. Jak sie ktos choc troche zna to jest to
> > > > oczywiste.
> > >
> > > Cierpisz na uraz postandersenowy czy co? :)
> >
> > cos w tym rodzaju :)
> > nie znosze przerostu formy nad trescia.
>
> Kusi mnie, zeby Cie spytac, z jakimi firmami (imiennie) miales do czynienia,
> ale rozumiem, ze mozesz nie chciec tego powiedziec.
>

dobrze rozumiesz. Napisze, ze z moich doswiadczen i z rozmow z wieloma
ludzmi z innych firm wynika, ze wszedzie jest podobnie do bani.

> >
> > chyba sie rozumiemy. Mam tez pewne doswiadczenie zwiazane z szacowaniem
> > kosztow projektow. I moje doswiadczenia sa takie: wymagania sa prawie
> zawsze
> > slabo przygotowane i dosyc powaznie sie zmieniaja/precyzuja (kwestia tylko
> > nazwy) w tzw. praniu.
>
> Tak zawsze jest; rozwiazaniem jest dobra organizacja "prania", czyli
> dogranie najwiekszej mozliwej ilosci szczegolow przed rozpoczeciem
> kosztownych dzialan.

wlasnie ze NIE. to jest podstawowy BLAD. Chodzi o to, zeby jak najwczesniej
zaczac pranie. I prac "elastycznie". Szczegoly czesto nie sa mozliwe
do dogrania przed praniem. A najbardziej kosztowne sa wlasnie bledy
popelnione na etapie analizy. Bledy w programowaniu sa najmniej kosztowne.
Dlatego trzeba jak najszybciej weryfikowac analize. To sa fundamentalne
zasady, o ktorych trabi kazda sensowna pozycja z inzynierii oprogramowania
od ladnych paru lat.


> Nie mozna calkowicie wyeliminowac zmian wymagan w
> trakcie projektu, ale mozna je zminimalizowac na tyle, zeby nie naruszaly w
> drastyczny sposob opracowanego "rozkladu jazdy".

jak to minimalizowac zmiany? Zmiany nie wynikaja tylko z bledow popelnionych
na etapie ustalania zalozen. Zmieniaja sie tez wymagania. Mowimy o sporych
projektach, ktore musze trwac jakis czas. Jest niemal pewne, ze w tym czasie
zmieni sie wiele (firma klienta sie zmienia, zmieniaja sie uwarunkowania
zewnetrzne, przepisy itp itp). Zmiany sa pewne.
Zmian nie mozna minimalizowac. Nalezy sie do nich dostosowac. Rozklad jazdy
nie jest zadna wartoscia. Przynajmniej nie powienien byc. A tego co piszesz
wynika, ze w Twoim hiperporfesjonalnym rozwiazaniu jest glowna wartoscia.

> Jesli Twoje doswiadczenia
> sa inne, nie neguje ich, ale ja mowie, ze _mozna_ i ze widzialam, ze mozna,
> a nie, ze wszedzie tak jest.
>
> W zwiazku z tym szacowanie z gory jest oczywiscie
> > mozliwe, ale jest bardzo ryzykowne. Ryzyko polega oczywiscie na
> > niedoszacowaniu, co konczy sie glowa szacujacego ;) Dlatego mamy
> 'wspolczynnik
> > bezpieczenstwa' dzieki ktoremu pracuje sie, jak piszesz, w miare
> komfortowo.
> > I za ktory klient slono zaplaci.
>
> :)
> placac za dowolny towar pokrywasz tez koszty tego, co producent/sprzedawca
> wydal m.in. na ubezpieczenie. Koszty roznego rodzaju zabezpieczen sa
> przelewane na klienta w kazdej branzy.
>

ale ja pisalem o przesadnym zabezpieczeniu, ktore wynika ze ZLEGO podejscia
do organizacji projektu. Fakt, ze to podejscie bywa wymuszona przez klienta.
Coz za glupote trzeba placic.
Mam tez pewne doswiadczenia w pracy w inny sposob i wiem, ze to NIE MUSI
tak wygladac.

> > heh. zazdroszcze Ci takiego spojrzenia na swiat. tak, kapitalizm, wolna
> > reka rynku :) Naprawde chcialbym wierzyc w to wszystko. A zwlaszcza
> > w kompetencje fachowcow z wielkich korporacji. bycie zgorzknialym jest
> > srednio przyjemne.
>
> Roznie bywa z korporacjami. Bywa beznadziejnie - szczegolnie tam, gdzie
> korporacja jest z innej branzy niz IT, a bierze sie za IT i to pod nadzorem
> menezerii marketoidalnej. Ale w korporacjach bedacych skupionymi na IT jako
> na swojej glownej dzialalnosci zatrudnia sie z reguly kompetentnych ludzi.
>

chyba malo widzialas. Albo mamy rozne pojecie "kompetencji".
Metoda waterfall, lansowana przez Ciebie, jest dla typowym przejawem
niekompetencji. I to powaznej niekompetencji (jesli wybrana a nie narzucona).

> > Zdarzylo mi sie pracowac m.in. przy dwoch projektach realizowanych dla 2
> > duzych bankow (jeden, to jeden z wiekszych bankow europejskich - projekt
> > za granica, drugi jeden z wiekszych bankow w Polsce - mysle, ze spokojnie
> > mozna nazwac je 'gigantami'). W obu projektach uczestniczyly firmy uwazane
> za
> > absolutny top firm doradczych, dostawcow oprogramowania.
>
> Firmy konsultingowe czy IT?

jedne i drugie. w tym 'doradcze z branzy IT'.

> > Zapewniam, ze to byly "wielkie i slomiane inwestycje". Jeden z projektow
> > zastal przerwany po ok. 4 latach (pracowalo w nim ok. 200 osob)
>
> nie mow mi jeszcze ze w jednym duzym zespole :)

w jednym. podzielonym na kilkanascie mniejszych.
Zreszta wielkosc tego zespolu tez byla nonsensowna.
Ale prowadzenie projektu zlozonego z 50 osob nie jest ani tak
prestizowe, ani tak lukratywne jak prowadzenie projektu zlozonego z 200 osob.
A koncu to byly wlasnie firmy, do ktorych ustawiaja sie kolejki wiec klient
lykal (i lyka dalej) wszystko.

> > > A na serio - wiem, ze wiekszosc tego rynku zalosnie wyglada, zwlaszcza u
> nas
> > > w Polsce, a ja gadam o miedzynarodowych koncernach.
> >
> > ja tez caly czas gadam o miedzynarodowych koncernach :)
>
> Widac gadamy o innych :)

tego nie jestem do konca pewny ;)

> <tu z trudem sie powstrzymuje od wzniesienia okrzyku na czesc moich
> ulubionych firm>

Krzycz. moze wysle swoje CV.


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