Andrzej Jarzabek wrote:

> On May 18, 1:24 pm, Michal Kleczek <k...@g...com> wrote:
>> Andrzej Jarzabek wrote:
>> > On May 18, 11:14 am, Michal Kleczek <k...@g...com> wrote:
>> >> Michal Kleczek wrote:
>>
>> >> Aha - oczywiscie:
>> >> 4) Firma zajmuje sie wytwarzaniem oprogramowania, postanowila zalapac
>> >> sie na "buzzwordy" i znalazla klientow, ktorzy sa sklonni placic jej
>> >> na zasadzie "time and material" i wierza (na jakiej podstawie?), ze to
>> >> sie oplaci. Klienci ci to albo ci z p. 3) albo zatrudniaja management
>> >> z p 1) i 2).
>>
>> > A na jakiej podstawie wierzą, ze się opłaci w dowolnym innym
>> > przypadku? Na jakiej podstawie wierzą, ze jeśli w umowie zapiszą
>> > funkcjonalność i termin, to produkt z taką funkcjonalnością zostanie
>> > faktycznie dostarczony w takim terminie?
>>
>> Np. na podstawie zapisow umowy, ktore mowia o tym, ze dostawca placi kary
>> umowne za niewywiazanie sie z umowy. Kary sa okreslone w takiej
>> wysokosci, zeby stanowily mozliwie duza rekompensate za stracony czas,
>> srodki, utracone korzysci itd.
>
> 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
> będzie wypłacalny)?

Bedzie tak dlugo podnosil wynagrodzenie az:
a) znajdzie sie dostawca
b) stwierdzi ze sie nie oplaca i/lub znajdzie substytut

Jesli chodzi o wyplacalnosc dostawcy to przyjeta praktyka jest wymog roznego
rodzaju zabezpieczen finansowych. Jak dostawcy na takie nie stac, to znaczy
ze jest gowniany i wspolpraca z nim jest ryzykowna. Jezeli i tak go
wybieramy, to znaczy, ze stac nas na takie ryzyko.

> Powszechnie wiadomo, ż projekty informatyczne
> często mają opóźnienia i że warunki są często renegocjowane. Wykonawcy
> 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ć.

Dlatego tez istnieje cos takiego jak analiza wymagan, studium wykonalnosci i
inne metody pozwalajace zminimalizowac ryzyko wystapienia takiego przypadku.
Gdyby takich metod nie bylo to nikt by sie nie podjal budowy mostu sredniej
wielkosci (bo sa to metody dotyczace zarowno IT jak i innych przedsiewziec).
Te metody maja jedna rzecz wspolna - najpierw sie mysli, potem sie robi -
taki waterfall.

>
>> > Na jakiej podstawie wierzą,
>> > że produkt formalnie spełniający warunki określone w umowie będzie
>> > miał dla nich jakąkolwiek wartość?
>>
>> No chyba nie zapisuja w umowie wymagan na bezwartosciowy dla nich
>> produkt. Jak firma potrzebuje np. 10 traktorow to wpisuje w umowie, ze
>> chodzi o traktory a nie - dajmy na to - wagony kolejowe.
>
> 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.

To zadna analogia. Jezeli klient nie wyartykuuje, ze traktor ma jezdzic po
blocie i w nim nie grzeznac, to dostanie traktor, ktory byc moze bedzie, a
byc moze nie bedzie grzeznac. Sek w tym, ze metody "agile" zakladaja, ze
najpierw nalezy zrobic w pelni funkcjonalny traktor i za niego zaplacic, a
potem zobaczyc czy sie nada.
Normalni ludzie, jak nie sa pewni czego chca to robia _prototyp_ (lub serie
prototypow). Ale nikt nie wymaga (w odroznieniu od agile), zeby prototyp byl
w pelni funkcjonalny - bo po co za to placic? (zreszta to juz wtedy nie jest
prototyp).

--
Michal