On May 19, 4:42 pm, "Przemek O." <p...@o...eu> wrote:
> W dniu 2011-05-19 16:53, Andrzej Jarzabek pisze:
>
> > I jaką korzyść z tego uświadomienia ma wykonawca?
>
> Taką że w połowie projektu nie musi renegocjować umowy, bo klientowi coś
> się przypomniało lub o czymś mu się zapomniało. Pół biedy jeśli skończy
> się tylko na renegocjacji a nie pociągnie to za sobą zmiany połowy
> wykonanego projektu. To chyba logiczne?

Przecież nie mówimy o sytuacji, kiedy w umowie stoi, że traktor
koniecznie ma grzęznąć w błocie. Jeśli wykonawca wie, że traktor nie
powinien grzęznąć w błocie (a wie, bo ustalił to pracujący dla niego
analityk), a zleceniodawca nie nalega na wpis w umowie, to nie ma
żadnego interesu w tym, żeby nalegać na wpisanie tego do umowy (albo
choćby sugerować zleceniodawcy, że powinien). W ten sposób bazowo
zakłada, że zrobi traktor, który nie grzęźnie, ale gdyby były jednak z
tym trrudności, to nie musi renegocjować umowy i nie musi płacić kar
za opóźnienia - wiedząc, że jest takie wymaganie _może_ jednak
próbowac renegocjować umowę na swoją korzyść (np. wydłużając termin
albo zwiększając cenę za enchancement).

> > Albo i nie. Bo przecież z punktu widzenia zleceniodawcy zamawia on
> > ciągle ten sam produkt.
>
> Też pisze że możliwość, czyli można (jeśli są ku temu powodu) ale nie
> trzeba. Wszystko musi mieć swoje uzasadnienie.

W realistycznych scenariuszach jest oczywiście tak, że często
współpracują firmy, które mają do siebie jakieś tam zaufanie i dopóki
wiedzą, że druga strona nie robi ich w bambuko, wykazują elastyczność
i zrozumienie. I to są właśnie dobre warunki do działania agile:
niezależnie od tego, jak konkretnie jest sformułowana umowa, wykonawca
mówi stakeholderom, że są obiektywne trudności takie i takie z
dostarczeniem takiego i takiego kawałka funkcjonalnosci, ale rozmawiał
z customer representative i doszli do wnisku, że można trochę okroić
scope i cośtam uprościć tak, żeby produkt nadal miał sens, ale za to
zleceniodawca może dostać pierwszy release na trzy miesiące przed
terminem i zacząć już na nim zarabiać, a my obiecujemy w dalszej
kolejności zająć się tym, co wypadło. I customer representative i
tygodniowe iteracje z wersją demo są również po to, żeby zleceniodawca
wiedział, że nie jest robiony w bambuko.

> To żaden porządny developer nie wziąłby zlecenia którego nie jest w
> stanie wykonać, a już na pewno nie dałby terminów lub kosztów poniżej
> faktycznie potrzebnych.

Bo każdy porządny developer ma Oracle Machnine wpiętą w slota PCI.

> > powiedzieć "bździągąbator jest w umowie, dostarczacie w terminie albo
> > płacicie kary". I teraz jeśli w umowie nie ma błota, to wykonawca mówi
>
> No logiczne, czemu miałoby być inaczej. W interesie zleceniobiorcy jest
> podawać realne terminy.

W interesie zleceniobiorcy jest również znać notowania giełdy na
przyszły tydzień, i żeby mu diamenty z nieba do ogródka spadały.

> > "ok, dostarczymy traktor z bździągąbatorem, ale za to nie jeżdżący po
> > błocie".
>
> Jeśli tego nie ma w umowie, to to wspominanie jest bez sensu. A jeśli na
> etapie zbierania wymagań nie wyłapano owego "błota" to na pewno w czasie
> renegocjacji jakiś biały kołnierzyk o tym sobie przypomni... A co.
>
> Podstawowa różnica że ja zakładam obie strony kompetentne i uczciwe, a
> nie kombinatorskie. Jeśli zleceniodawca podaje nierealne terminy
> wykonania, zniżone koszty lub podejmuje się zleceń o których wie z góry
> że nie jest w stanie wykonać, to powinien być pociągnięty do
> odpowiedzialności za swoje działania. Na drugi raz pomyśli dwa razy
> zanim zacznie kombinować. A jak nie to zniknie z rynku i sprawa też się
> rozwiąże.

Ja przecież nie zakładam, że zleceniobiorca wie z góry. Ja zakładam,
że nikt nie wie z góry.