On May 18, 7:51 pm, "Przemek O." <p...@o...eu> wrote:
> W dniu 2011-05-18 14:44, Andrzej Jarzabek pisze:
>
> > A co zrobi, jeśli nie znajdzie dostawcy, który się na takie kary
> > zgodzi (i o którym z dużym prawdopodobieństwem da się powiedzieć, że
>
> Każda umowa ma określone konsekwencje w przypadku jej niewypełnienia. To
> czy będą one w niej zapisany, czy wynikną z kodeksu to inna sprawa.
> Zawsze istnieje odpowiedzialność sprzedawcy / producenta za wytworzony
> produkt.

Oczywiście, nigdy nie pisałem, że jest inaczej.

> > będzie wypłacalny)? Powszechnie wiadomo, ż projekty informatyczne
> > często mają opóźnienia i że warunki są często renegocjowane. Wykonawcy
>
> Źle zarządzanie projekty.

Możemy sobie to tak nazwać, ale w takim razie trzeba stwierdzić, że
zleceniodawca nie ma żadnej możliwości zapewnienia w momencie
składania zlecenia, że projekt nie będzie źle zarządzany, a w dodatku
- zwłaszcza w przypadku większych projektów - szansa, że projekt
będzie źle zarządzany jest znaczna.

> > oprogramowania, zwłaszcza jeśli mowa o dużych firmach, raczej nie będą
> > chętne do brania na siebie ryzyka gigantycznych strat w przypadku
> > kiedy okaże się, że czegośtam w praktyce nie da się zaimplementować.
>
> Nigdy, nawet w czasach gdy pisałem samodzielnie oprogramowanie na
> zlecenie nie podjąłbym się go bez uprzedniej analizy wymagań oraz
> określenia wykonalności. Kurcze - przecież to są podstawy, na ich
> podstawie można oszacować czas trwania projektu oraz jego wartość.
> Przecież nikt w umowie nie wpisze wartości roboczogodziny tym bardziej
> jeśli nie ustali się czasu potrzebnego na realizację projektów. Aż tak
> naiwnych klientów nie ma.

Poszukaj pod "time and materials contract". POza tym są jeszcze inne
możliwości układów, np. proponowany w XP "negotiated scope contract".

> > Analogią raczej byłoby zamówienie stworzenia nowego modelu traktora.
> > Firma potrzebuje nowy model traktora, który będzie maił jakiś
> > specjalny ficzer, i dostaje taki model, tylko że po dostarczeniu
> > okazuje się, że ten model grzęźnie w błocie i jako taki jest
> > bezużyteczny. Wykonawca twierdzi, że dostarczony prototyp spełnia
> > wszystkie warunki zapisane w umowie, a jak zleceniodawca chce taki,
> > który nie grzęźnie, to on chętnie podpisze kolejną umowę na wersję
> > 2.0, tylko że będzie to kosztowało 50 milionów i zajmie kolejne dwa
> > lata.
>
> Po pierwsze jeśli chodzi o traktory to z zasady grzęzną w błocie. Od

Przepraszam, nie znam się na traktorach i nie chcę się znać. Posdstaw
sobie za grzęźnięcie w błocie coś innego, co dyskwalifikuje traktor.

Proponuję w związku z tym porzucić metaforę traktorową i rozmawiać o
tworzeniu oprogramowania.

> Co więcej, analityk w trakcie pracy z klientem bez problemu by to
> wyłapał, przy wizycie na tym błotnistym polu. A mając takie wymaganie,
> wytwórca mógłby przed przystąpieniem do realizacji zlecenia określić czy
> w ogóle jest w stanie coś takiego wykonać.

Przecież analityk pracuje dla wykonawcy, jaki miałby interes w tym,
żeby doradzać klientowi, żeby nie zapomniał o wpisaniu błota do umowy?