On Fri, 19 Jul 2013 21:56:05 +0100, Andrzej Jarzabek
<a...@g...com> wrote:
> W układach, gdzie każda zmiana oznacza negocjację kontraktu,
wszystkie
> zmiany mają spory narzut, ale przy małych, tanich zmianach narzut
> administracyjny potrafi być gigantyczny, więc nie opłaca się ich
robić.
> Klient traci w ten sposób dużo na wartości otrzymywanego produktu.

Sa korporacje (np. taka jedna duza amerykańska o nazwie na "C") w
których tak naprawdę jest: jak projekt nie ma budżetu na co najmniej
kilkadziesiąt tysięcy USD to się go nie robi - nie warto, za duży
narzut administracyjny na negocjacje, akceptacje i zbieranie
"stakeholders" przy jednym stoliku.

RW

do góry

On 19/07/2013 23:15, slawek wrote:
> Użytkownik "Andrzej Jarzabek" napisał w wiadomości grup
> dyskusyjnych:ksc511$ie4$...@s...invalid...
>
>> Tzn. faktycznie projekt może kosztować dwa miliony, ale tylko pod
>> warunkiem, że przyjmiemy możliwość (a nawet wysokie
>> prawdopodobieństwo), że za te dwa miliony dostaniemy software, którego
>> nie będziemy mogli używać.
>
> Bob, który jest biznesmenem, umawia się z Fredem, programistą: Fred
> napisze program który będzie kosztował dwa miliony [euro]. Umowa jest
> sporządzona na piśmie i przy świadkach, Bob wpłaca zadatek wysokości 500
> tysięcy euro, w umowie podany jest czas realizacji jeden rok i takie
> tam. Zgodnie z umową, w czasie jaki był określony, Bob dostaje od Freda
> software (czyli zamówiony program), którego nie da się używać. Bob
> domaga się od Freda: zwrotu zadatku w wysokości 500 tysięcy euro;
> zapłacenia 500 tysięcy euro za niewykonanie (patrz przepisy o zadatku);
> zadośćuczynienia za straty jakie poniosła firma Boba przez nierzetelne
> postępowanie Freda. Fred nie zgadza się oddać pieniędzy, nawet jeżeli
> nie wydał z zadatku ani eurocenta nie ma skąd wziąć drugich 500 tysięcy
> euro. Pomijając nieistotne szczegóły: sąd wydaje wyrok, Fred ma 1 milion
> euro długów plus musi ponieść koszta sądowe.

Na szczęście Fred pozwał wcześniej operatora wózka widłowego Klausa,
który krzyknął na niego "gdzie leziesz baranie?" Sąd przyznaje Fredowi 5
mln euro odszkodowania, a szczęśliwym trafem Klaus wygrał właśnie tę
kwotę na loterii. Bob natomisat wracając do domu zostaje uderzony i
zabity przez meteoryt...

I to tyle w temacie Bobów, myślących, że całe ryzyko prowadzenia biznesu
można przerzucić na kontrahentów.

>>> wymagania naruszaja "timing" projektu - projektu nei da sie wykonac na
>>> czas, a za opoznienia moga byc kary umowne. Wiec co bedzie z tymi
>>> karami?
>
> Jak słusznie zauważył A.L. - co będzie z tymi karami?

Jeśli wykonawca jest w stanie wykonać program według oryginalnej
specyfikacji w terminie, a nie zgodzi się na aneks do umowy, to nie
zapłaci żadnych kar, nawet jeśli bez tego aneksu program jest bezużyteczny.

>> Ale też taki układ niekoniecznie jest korzystny dla zleceniodawcy.
>> Przede wszystkim dlatego, że wykonawca ma w tym momencie wszelkie
>> powody, żeby wydoić z niego ile się da - w kwestii terminów i w kwestii
>
> Jeżeli ktoś z kogoś będzie "doił" - to raczej ten co już ma dwa miliony
> euro do wydania (czyli zamawiający) - niż ten co tęskni aby te dwa
> miliony zarobić (piszący program). Zamawiający "potrzebuje" programu.
> Fakt. Ale ma wybór: firm tworzących software jest dużo. W razie czego
> można jeszcze przez parę miesięcy prowadzić działalność używając
> poprzednich rozwiązań (czyli starych programów.)

Może być tak, że się nie da. Na przykład biznes zamiawiającego może
wymagać elektronicznej łączności z WGPW. Ta niedawno zmieniła system z
WARSET na UTP i całe stare oprogramowanie trzeba było wymienić.

Ale to szczególny przypadek, ogólnie jednak zauważ, że ten moment, o
którym mowa w powyższym "w tym momencie" to moment podpisania umowy.
Jeśli zleceniodawca zlecił program za dwa miliony, a następnie poprosił
o zmianę i dostał wycenę 200 tys., to owszem, może iść do innego
wykonawcy, ale wtedy umowa z poprzednim wykonawcą nie wygasa - ten nadal
ma mu dostarczyć program według poprzedniej specyfikacji, a zamawiający
będzie mu musiał zapłacić te dwa miliony, plus dwa miliony za ten sam
program tym razem od razu z modyfikacją płacone kolejnemu wykonawce,
razem cztery miliony. W takiej sytuacji wykonawca będzie doił, bo wie,
że zamawiającemu bardziej się opłaca zapłacić 200 tysięcy niż dwa miliony.

Oczywiście ma to swoją granicę, ale jeśli zamawiający zamówi kolejno
pięć poprawek po dwieście tysięcy a przy szóstej powie "basta, idę
szukać innego wykonawcy", to razem straci już nie dwa, a trzy miliony. A
nie ma przecież gwarancji, że kolejny wykonawca, mając już w kielni
umowę na dwa miliony nie zacznie go doić w dokładnie ten sam sposób.

> Natomiast firma
> softwareowa musi walczyć z konkurencją i - jeżeli nie będzie miała
> zleceń - to po prostu padnie. Nie stać jej na półroczny przestój.

Dlaczego zakładasz, że firma software'owa może mieć tylko jednego
klienta? Istnieją przeciez bardzo duże firmy software'owe, nierzadko
większe od niejednego ze swoich klientów.

> Dlatego prawdopodobnie na te dwa miliony euro będzie trzeba dość ciężko
> zapracować. W tym mieści się także znoszenie różnego rodzaju dziwacznych
> wymagań (np. że zapis danych ma być na dyskietkach).

Ale akurat wymagania zmiany umowy nie muszą znosić. Mogą się totalnie
wypiąć i dostarczyć bezużyteczny program według oryginalnej
specyfikacji. I swoje dwa miliony dostaną.

>> powie zleceniodawcy że zrobi ją za dodatkowe 20 tysięcy i przesunięcia
>> terminu o sześć tygodni.
>
> Problemem będzie jeżeli zleceniodawca: a. nie będzie chciał wydać ani
> euro więcej; b. przesunięcie terminu jest niemożliwe. Oczywiście, bardzo
> lubimy zleceniodawców, którzy są chętni dawać nam ekstra czas i
> pieniądze... ale to trochę dziecinne myśleć, że takich będziemy często
> spotykać. Ba! Ktoś kto ma dwa miliony euro do wydania... prawdopodobnie
> jest bardzo twardym graczem w biznesie, bo jakoś te dwa miliony euro
> zarobił.

To będzie problem zleceniodawcy, a nie nasz. My nadal dostarczymy
program zgodnie z umową i dostaniemy dwa miliony, a zleceniodawca wyda
dwa miliony i ani euro więcej i w terminie dostanie program, którego nie
będzie mógł używać. Jeśli jest takim właśnie twardym graczem w biznesie,
to najprawdopodobniej te miliony odziedziczył po dziadku.

(pomijając już fakt, że zwykle o wydawaniu milionów nie decyduje ktoś,
kto te miliony zarobił, tylko pracownik na odpowiednim stanowisku
kierowniczym)

>> Ponieważ ilość poprawek nie może być znana z góry, odpowiedź na
>> pytanie "jeśli się umówimy na dwa miliony i dwa lata, to za ile
>> pieniędzy i za ile czau będziemy mieli system, którego używanie będzie
>> miało sens" brzmi "nie wiadomo, może za dwa lata i dwa miliony, ale to
>> raczej mało prawdopodobne; może to będą cztery lata i dziesięć
>> milionów, a może takiego systemu nie dostaniemy nigdy, i nawet nie
>> będziemy mieli kogo pozwać".
>
> Jeżeli będzie takie jakieś gdybanie - to skończy się odpowiedzią - "to
> nie będziemy realizować tego projektu". I co ciekawsze - ty sam możesz
> stać się w firmie zbędny. No bo po co ktoś, kto nie potrafi załatwić
> prostej sprawy, zwłaszcza że projekt nie jest realizowany.

Nie rozumiem, kto to jest w tej opowiastce "ja"? Ja osobiście jako ja
nie odpowiadam za zamawianie oprogramowania. Jeśli chodzi o osobę, która
za to odpowiada, to chyba nie uważasz, że zwolnienie pracownika, który
bierze pod uwagę ryzyko i zatrudnienie takiego, który jest pewien, że
wszystko będzie dobrze - spowoduje, że ryzyko zniknie?

>> I dlatego klient nie będący idiotą może właśnie woleć Agile - żeby
>> uniknąć takiej sytuacji. [płacenia 500 000 USD za drobną zmianę w umowie]
>
> Nie wiem kto jest idiotą: czy klient, którego stać na zapłacenie 500 000
> USD za zmianę w projekcie (czyli spodziewający się, że ta zmiana
> przyniesie zysk przekraczający 500 000 USD)...

Przecież takich potencjalnych zmian może być wiele. Pomijając nawet
dokładność szacowania, część z nich będzie taka, która przyniesiee 500 i
600 tys, ale może być wiele drobnych i tanich w implementacji zmian,
które łącznie przyniosą 2 miliony.

Poza tym, jeśli program, za który już zgodziliśmy się zapłacić 2 miliony
(i tych pieniędzy nie odzyskamy) będzie bez danej zmiany bezużyteczny,
to jaki zysk przyniesie ta zmiana? Dodatkowo możemy zauważyć, że wcale
nie wiemy, czy z tą zmianą program będzie użyteczny - do tego mogą być
potrzebne kolejne zmiany, za które trzeba będzie zapłacić dodatkowo. Ale
bez niej na pewno użyteczny nie będzie.

> ... czy też może klient, który nie wie nawet czego chce i pozwala aby
> manipulował nim zleceniobiorca.

Klient praktycznie nigdy przystępując do negocjacji nie wie czego chce z
nieskończoną dokładnością. Czasem wie na tyle dokładnie, żeby
specyfikacja była wystarczająco jednoznaczna z punktu widzenia prawnego
(w sensie że program, który sąd uzna za spełniający wymogi specyfikacji
będzie też spełniał wymogi klienta), ale bardzo często nie. Z tych, co
nie wiedzą masz tych co nie wiedzą, ale wiedzą że nie wiedzą, oraz tych,
co nie wiedzą, ale wydaje im się że wiedzą.

Ta ostatnia grupa to główni kandydaci do dojenia, a jest na tyle liczna,
że dojenie jest naprawdę sensownym biznes planem i wiele firm żyje z
tego od lat.

Z tych, co wiedzą że nie wiedzą wywodzą się właśnie klienci, którzy
preferują time and materials nad fixed time fixed scope i którzy
doceniają wartość gwarancji, które mogą mieć w umowie dzięki stosowaniu
metdodologii Agile.

do góry

On 20/07/2013 00:19, Roman W wrote:
> On Fri, 19 Jul 2013 21:56:05 +0100, Andrzej Jarzabek
> <a...@g...com> wrote:
>> W układach, gdzie każda zmiana oznacza negocjację kontraktu,
> wszystkie
>> zmiany mają spory narzut, ale przy małych, tanich zmianach narzut
>> administracyjny potrafi być gigantyczny, więc nie opłaca się ich
> robić.
>> Klient traci w ten sposób dużo na wartości otrzymywanego produktu.
>
> Sa korporacje (np. taka jedna duza amerykańska o nazwie na "C") w
> których tak naprawdę jest: jak projekt nie ma budżetu na co najmniej
> kilkadziesiąt tysięcy USD to się go nie robi - nie warto, za duży narzut
> administracyjny na negocjacje, akceptacje i zbieranie "stakeholders"
> przy jednym stoliku.

To jest jasne, że w dużym korpo nie zlecisz byle dupereli oddzielnie.
Większym problemem jest, że nawet w projekcie, w który już wtopiłeś
miliony musisz znowu ponosić te koszta przy każdej dupereli, którą
chcesz zmienić - bo trzeba negocjować aneks do umowy, więc znowu narzut
na negocjacje, szacowanie, ocenę ryzyka, zbieranie stakeholders itd. To
jest prawdziwy ból, bo jeszcze w przypadku dużego projetu za dwa miliony
to ten narzut administracyjny się jakoś rozkłada, to jaki on będzie w
przypadku zmiany, którą jeden programista zrobi w kilka dni?

do góry

On 19/07/2013 23:34, slawek wrote:
> Użytkownik "Andrzej Jarzabek" napisał w wiadomości grup
> dyskusyjnych:ksc9uj$kjh$...@s...invalid...
>
>> Czas pracy programistów kosztuje, ale wprowadzenie dowolnej dupereli,
>> która zajmuje programiście pół godziny, nie wymaga oprócz tego wielu
>> dni pracy prawników, sprzedawców, analityków, i reszty armii ludzi,
>> którzy są potrzebni do negocjowania kontraktu.
>
> Co konkretnie można zrobić w pół godziny?

Przesunąć przycisk raczje tak. Podobnie dołączyć dodatkowe informacje do
logu, które są dostępne w momencie powstania komunikatu (np. zamiast
"Błędny kod PESEL" logować "Błędny kod PESEL '1234567' dla rekordu ID
1"). Pewnie zamienić gdzieś "3 miejsca po przecinku" na "4 miejsca po
przecinku" itd.

Przy czym mówimy o samym czasie pracy programisty (łacznie z napisaniem
unit tests), oczywiście nawet w Agile jest jakiś narzut na takie
czynności - ktoś musi wytłumaczyć o co chodzi, trzeba oszacować koszt,
spriorytetyzować, napisać acceptance test itd. Ale łącznie ten narzut
nie jest gigantyczny, powiedzmy, że wszystko powyższe może zająć kolejne
pół godziny.

do góry

On 18/07/2013 14:50, A.L. wrote:
> On Thu, 18 Jul 2013 04:16:46 +0100, Andrzej Jarzabek
> <a...@g...com> wrote:
>
>> "W umowie nic nie ma, że ma logować błędne NIP-y. Możemy to zrobić jako
>> change request, za dwa tygodnie przygotujemy aneks do umowy"
>> Aneks za dwa tygodnie może opiewać na kwotę 100 tysięcy dolarów, plus
>> trzeba zaangażować dział prawny, procurement i co tam jeszcze.
>
> Drogi Kolego, kolega chce mnie pzrekonac do czego?...

Że tego typu umowy mogą być bardzo niekorzystne dla klienta. Że rzekoma
zaleta fixed time fixed scope że niby wiemy co i kiedy dostaniemy i
wiemy ile zapłacimy to miraż. W rzeczywistości klient nie wie kiedy
dostanie to, czego chce ani ile to będzie kosztować, jedynie tyle, że na
pewno nie będzie to taniej niż opiewa umowa.

Kolega miał tezę, że poważni klienci zawsze zawierają umów time and
materials, bo nikt nie zamiawia systemu nie wiedząc wcześniej ile
zapłaci i kiedy dostanie. Otóż chcę kolegę przekonać, że część klientów
zdaje sobie sprawę, że z fixed time, fixed scope również tego nie
wiedzą. Dość spora grupa też uważa, że time and materials i Agile
pozwoli zrobić to taniej, da rezultat bardzej odpowiadający potrzebom,
oraz ograniczy wiele rodzajów ryzyka.

> Nie neguje ze sa dziedziny gdzie Aglie sie sparwdza doskonale, gdzie
> siedzi sie z klientem przy jednym ekranie, nie robi sie zadnych
> planow, umow i aneksow i gdzie zadna ze stron nie wie o co chodzi.
> Ale to dla mnie jak bajki o elftch i trollach

W branży finansowej się sprawdza, akurat wiem jak jest z software house
robiącym oprogramowanie dla banków inwestycyjnych, gdzie w tym samym
business unit są projekty agile i nie-agile. Plany, umowy i aneksy jak
najbardziej są, nikt (w develomencie) nie siedzi z klientem przy jednym
ekranie, ale Agile nie tylko daje się stosować, ale też daje lepsze
rezultaty niż tradycyjne metody.

do góry

Użytkownik "Andrzej Jarzabek" napisał w wiadomości grup
dyskusyjnych:ksd4sn$1r4$...@s...invalid...

>Na szczęście Fred pozwał wcześniej operatora wózka widłowego Klausa, który
>krzyknął na niego "gdzie leziesz baranie?" Sąd przyznaje Fredowi 5 mln euro
>odszkodowania, a szczęśliwym trafem Klaus wygrał właśnie tę kwotę na
>loterii. Bob natomisat wracając do domu zostaje uderzony i zabity przez
>meteoryt...

Bardziej prawdopodobne, że sąd oddali pozew Freda: Klaus zwracał się nie do
Freda, ale do barana, a przecież Fred nie jest baranem. Fred będzie musiał
zapłacić koszta sądowe.

Zupełnie inaczej, bo automatycznie, działa mechanizm zadatku: jeżeli zerwie
umowę zamawiający, to traci zadatek; jeżeli wykonawca, to traci zadatek i
musi jeszcze zapłacić drugie tyle.

Gdzie uderzy meteoryt? Nie wiadomo. Przeciętny Bob nie ma na to wpływu. Ale
mechanizm z zadatkiem jest prosty i przewidywalny, wcześniej czy później
ktoś sprytny może użyć go np. do walki z konkurencją. Zwłaszcza z partacką
konkurencją.

>I to tyle w temacie Bobów, myślących, że całe ryzyko prowadzenia biznesu
>można przerzucić na kontrahentów.

Jeszcze raz: Bob nie myśli że coś można, Bob po prostu ma taki biznes -
szukanie naiwnych firm programistycznych i ich podpuszczanie.

Oczywiście Bob nie musi "na celownik" wziąć firm związanych z informatyką -
dolna branża jest możliwa. Ale informatycy są tak pewni siebie i swojej
inteligencji, że nie są trudni.

>Jeśli wykonawca jest w stanie wykonać program według oryginalnej
>specyfikacji w terminie, a nie zgodzi się na aneks do umowy, to nie zapłaci
>żadnych kar, nawet jeśli bez tego aneksu program jest bezużyteczny.

Kwestia tego, co tam było w umowie. Bob sam jest prawnikiem, ma kilkunastu
innych prawników do pomocy i nie jeden raz robił ten numer. Fred myślał że
umowy są niepotrzebne, bo Agile zakłada "przyjacielski" model współpracy.
Oczywiście sąd może stanąć po stronie Freda. Ale jeżeli Fred jest
powszechnie znany z niedotrzymywania terminów itd. itp. - to raczej to mu to
nie pomoże. Z drugiej strony Bob wybrał Freda po dokładnym rozpoznaniu
rynku.

>Może być tak, że się nie da. Na przykład biznes zamiawiającego może wymagać
>elektronicznej łączności z WGPW. Ta niedawno zmieniła system z WARSET na
>UTP i całe stare oprogramowanie trzeba było wymienić.

Kwestia tego, co tam było w umowie. "Trzeba" - to oczywiste. Ale pytanie
"kto płaci" nadal aktualne. Właśnie dlatego zatrudnia się prawników. Bo
prawnicy to po prostu oszczędność kosztów.

Oczywiście tego rodzaju oszczędność ma sens przy dostatecznie dużych
projektach. Gdy piszesz "bazę danych szlachów i kaloszy" dla firmy teścia
zatrudniającej 1.5 osoby, to mało prawdopodobne, że będą tam jakieś ukryte
haki (poza np. wizytami teściowej).

>Oczywiście ma to swoją granicę, ale jeśli zamawiający zamówi kolejno pięć
>poprawek po dwieście tysięcy a przy szóstej powie "basta, idę szukać innego
>wykonawcy", to razem straci już nie dwa, a trzy miliony. A

Owszem, ale uważanie że Bob jest na łasce Freda, bo zamówił u Freda dzieło
lub usługę, to myślenie niedojrzałe i życzeniowe.

>To będzie problem zleceniodawcy, a nie nasz. My nadal dostarczymy program
>zgodnie z umową i dostaniemy dwa miliony, a zleceniodawca wyda

Jeżeli np. zleceniodawcą jest spółka zoo i ta spółka zwyczajnie zbankrutuje,
to chyba jednak się mylisz.

Podobny problem, jeżeli zamówienie składała osoba fizyczna która potem już
nie żyje, nie ma spadku, spadkobierców. W zasadzie to jej problem (bycie
nieżywym to nie jest fajna perspektywa), ale skoro już jest martwa, to
specjalnie się tym nie stresuje. Ty - owszem - bo musisz np. zapłacić
rachunki - pensje programistów, prąd, opłaty za pomieszczenia, koszty
wykupionych licencji... - no chyba że strzelisz sobie w łeb i dołączysz do
nieboszczyka.

>będzie mógł używać. Jeśli jest takim właśnie twardym graczem w biznesie, to
>najprawdopodobniej te miliony odziedziczył po dziadku.

Jeżeli żyje w PL, to nikła jest szansa że po dziadku - policz, dziadek
musiałby zebrać je mniej więcej 40 lat temu.

Oczywiście są ludzie którzy mają pieniądze po dziadku, po babci. Ale błędnie
zakładasz, że jak ktoś umie pisać programy (zakładam że umiesz), to
jednocześnie cała reszta świata to frajerzy.

>(pomijając już fakt, że zwykle o wydawaniu milionów nie decyduje ktoś, kto
>te miliony zarobił, tylko pracownik na odpowiednim stanowisku kierowniczym)

Ciekawa hipoteza.

>za to odpowiada, to chyba nie uważasz, że zwolnienie pracownika, który
>bierze pod uwagę ryzyko i zatrudnienie takiego, który jest pewien, że
>wszystko będzie dobrze - spowoduje, że ryzyko zniknie?

Jeżeli ryzyko projektu X jest tak duże, że uniemożliwia realizację projektu
X, to nikt nie będzie płacił pensji pracownikom za realizację
nierealizowanego projektu X. To logiczne.

>Poza tym, jeśli program, za który już zgodziliśmy się zapłacić 2 miliony (i
>tych pieniędzy nie odzyskamy) będzie bez danej zmiany bezużyteczny,

Dlaczego nie odzyskamy? Po to są umowy, zadatek i prawnicy.

>Ta ostatnia grupa to główni kandydaci do dojenia, a jest na tyle liczna, że
>dojenie jest naprawdę sensownym biznes planem i wiele firm żyje z tego od
>lat.

Trudno uznać taką praktykę za uczciwą, a "dojone" firmy za szczególnie
dobrze zarządzane.

Oczywiście, być może masz rację - dla tego rodzaju złodziejstwa Agile jest
być może dobrym rozwiązaniem - pozwala naciągać klientów na wieczne
"zmiany".

do góry

On 2013-07-19 21:53, Roman W wrote:
> Test może byc typu
> x = 4.5;
> expected = 10.4;
> assertEquals (expected, f (x));
> I jaka ma wtedy wartość jako dokumentacja?

Przypuszczam że zbliżoną do:

// funkcja f
// przyjmuje: double - pierwszy parametr
// zwraca: double
int f( int, char* ) { }

Czyli żadną.

Ale już taki test:

assert( parseDouble( "1.0" == 1.0 ) );
assert( parseDouble( "1E0" == 1.0 ) );
expect_throw( parseDouble( "1e0" ) );
expect_throw( parseDouble( "1,0" ) );

... ślicznie dokumentuje.

do góry

On 20/07/2013 09:08, slawek wrote:
> Użytkownik "Andrzej Jarzabek" napisał w wiadomości grup
> dyskusyjnych:ksd4sn$1r4$...@s...invalid...
>
>> Na szczęście Fred pozwał wcześniej operatora wózka widłowego Klausa,
>> który krzyknął na niego "gdzie leziesz baranie?" Sąd przyznaje Fredowi
>> 5 mln euro odszkodowania, a szczęśliwym trafem Klaus wygrał właśnie tę
>> kwotę na loterii. Bob natomisat wracając do domu zostaje uderzony i
>> zabity przez meteoryt...
>
> Bardziej prawdopodobne, że sąd oddali pozew Freda: Klaus zwracał się nie
> do Freda, ale do barana, a przecież Fred nie jest baranem. Fred będzie
> musiał zapłacić koszta sądowe.

Jeśli już mówimy o tym, co jest bardziej prawdopodobne, to również
bardziej prawdopodobne jest, że sąd oddali pozew Boba, i to Bob będzie
nie tylko musiał Fredowi zapłacić dwa miliony euro za bezużyteczny
software, poniesie koszty procesu, ale też niebanalne koszty stworzenia
szczegółowej specyfikacji nikomu niepotrzebnego systemu komputerowego
sporej skali.

> Zupełnie inaczej, bo automatycznie, działa mechanizm zadatku: jeżeli
> zerwie umowę zamawiający, to traci zadatek; jeżeli wykonawca, to traci
> zadatek i musi jeszcze zapłacić drugie tyle.

No ale że traci zadatek nie znaczy, że nie musi zapłacić reszty.

> Gdzie uderzy meteoryt? Nie wiadomo. Przeciętny Bob nie ma na to wpływu.
> Ale mechanizm z zadatkiem jest prosty i przewidywalny, wcześniej czy
> później ktoś sprytny może użyć go np. do walki z konkurencją. Zwłaszcza
> z partacką konkurencją.

Niby jak?

> Jeszcze raz: Bob nie myśli że coś można, Bob po prostu ma taki biznes -
> szukanie naiwnych firm programistycznych i ich podpuszczanie.
>
> Oczywiście Bob nie musi "na celownik" wziąć firm związanych z
> informatyką - dolna branża jest możliwa. Ale informatycy są tak pewni
> siebie i swojej inteligencji, że nie są trudni.

Bob ma biznes taki, że chodzi po różnych wykonawcach i zleca im
wykonanie czegoś bezużytecznego, po czym kiedy to wykonają, pozywa ich
za straty spowodowane tym, że dostarczony produkt jest bezużyteczny?

I na takim biznesie można zarobić? W jakim państwie?

>> Jeśli wykonawca jest w stanie wykonać program według oryginalnej
>> specyfikacji w terminie, a nie zgodzi się na aneks do umowy, to nie
>> zapłaci żadnych kar, nawet jeśli bez tego aneksu program jest
>> bezużyteczny.
>
> Kwestia tego, co tam było w umowie. Bob sam jest prawnikiem, ma
> kilkunastu innych prawników do pomocy i nie jeden raz robił ten numer.
> Fred myślał że umowy są niepotrzebne, bo Agile zakłada "przyjacielski"
> model współpracy.

Nie. Mylisz dwóch programistów. Fred doiciel wierzy w kontrakty fixed
price and scope i w dojenie klientów na zmianach. Antek agilista zakład
przyjacielski model współpracy, i dlatego nigdy nie podpisuje takich
kontraktów, tylko zawsze nalega na time and materials. W kontrakcie
Antka nie ma wielostronicowej specyfikacji produktu, tylko statement of
intent. Antek nie zawiera umowy na dwa miliony euro zaa produkt, tylko
na czterdzieści tysięcy euro za tydzień produkowania.

Co właściwie Bob zrobi Antkowi? Będzie co poniedziałek chodził na
spotanie z Antkiem, priorytetyzował ficzery do zaiplementowania w
kolejnej iteracji, zatwierdzał plan iteracji, zatwierdzał acceptance
testy, a co piątek przychodził po odbiór wersji demo, zatwierdzał
odbiór, podpisywał umowę na wykonanie kolejnej iteracji z intencją
dalszej współpracy, a po roku pozwie Antka za to, że te rzeczy, o
których mówił przez cały rok, że są dla niego najbardziej wartościowe,
właściwie są bezwartościowe i że poniósł straty w związku z tym, że
zapłacił Antkowi za program robiący właśnie te rzeczy?

> Oczywiście sąd może stanąć po stronie Freda. Ale
> jeżeli Fred jest powszechnie znany z niedotrzymywania terminów itd. itp.
> - to raczej to mu to nie pomoże. Z drugiej strony Bob wybrał Freda po
> dokładnym rozpoznaniu rynku.

No ale skąd założenie, że Fred nie dotrzymuje terminów? Fred bardzo się
stara, żeby terminów dotrzymywać i być zawsze w 100% zgodnym z umową -
to podstawa biznes planu Freda.

Jeśli natomiast Bob jest powszechnie znany z zamawiania bezużytecznych
rzeczy, a potem zaskarżania wykonawców o straty z powodu ich
bezużyteczności, to pewnie nawet jego pozew nie trafi na salę.

>> Może być tak, że się nie da. Na przykład biznes zamiawiającego może
>> wymagać elektronicznej łączności z WGPW. Ta niedawno zmieniła system z
>> WARSET na UTP i całe stare oprogramowanie trzeba było wymienić.
>
> Kwestia tego, co tam było w umowie. "Trzeba" - to oczywiste. Ale pytanie
> "kto płaci" nadal aktualne. Właśnie dlatego zatrudnia się prawników. Bo
> prawnicy to po prostu oszczędność kosztów.

O czym ty piszesz? Ja piszę o tym, że nie zawsze zamawiający
oprogramowanie może łyknąć fakt, że to, co zamówił i dostał nie spełnia
jego potrzeb, bo może działać na starym oprogramowaniu. Czasem żeby
działać musi wymienić i tyle. Zazwyczaj zapłaci on, bo aż takich dobrych
prawników, żeby znaleźli mu wykonawcę, który zrobi za darmo, to raczej
nie znajdzie.

>> Oczywiście ma to swoją granicę, ale jeśli zamawiający zamówi kolejno
>> pięć poprawek po dwieście tysięcy a przy szóstej powie "basta, idę
>> szukać innego wykonawcy", to razem straci już nie dwa, a trzy miliony. A
>
> Owszem, ale uważanie że Bob jest na łasce Freda, bo zamówił u Freda
> dzieło lub usługę, to myślenie niedojrzałe i życzeniowe.

Nie zawsze jest, ale jest wystarczająco często, żeby model biznesowy
Freda Naciągacza był powszechnie stosowany w przemyśle. W
przeciwieństwie do modelu Boba Pieniacza, który jest twoim wymysłem.

>> To będzie problem zleceniodawcy, a nie nasz. My nadal dostarczymy
>> program zgodnie z umową i dostaniemy dwa miliony, a zleceniodawca wyda
>
> Jeżeli np. zleceniodawcą jest spółka zoo i ta spółka zwyczajnie
> zbankrutuje, to chyba jednak się mylisz.

Bankructwo to osobny pomysł i oczywiście ryzyko dla wykonawcy. Ale
zauważ też, symetrycznie, że jeśli Fred ma spółkę z oo, to nawet jeśli
sąd zasądzi mu ten milion czy ile tam odszkodowania, to Fred może sobie
spokojnie zbankrutować i egzekucja będzie z majątku spółki - w wysokości
np. jednego laptopa. Więc dla Boba ten biznes jest dodatkowo ryzykowny
(poza tym że sąd w rzeczywistości mu nic nie przyzna).

>> będzie mógł używać. Jeśli jest takim właśnie twardym graczem w
>> biznesie, to najprawdopodobniej te miliony odziedziczył po dziadku.
>
> Jeżeli żyje w PL, to nikła jest szansa że po dziadku - policz, dziadek
> musiałby zebrać je mniej więcej 40 lat temu.

Po pierwsze - nie było mowy o Polsce. Czy model biznesowy Boba jest
jakoś szczególnie możliwy w Polsce akurat? Po drugie, nawet będąc w
Polsce można mieć dziadka, który 40 lat temu nie był w Polsce. Po
trzecie, dziadek mógł tydzień wcześniej wygrać w totka i zejść z
wrażenia na zawał.

> Oczywiście są ludzie którzy mają pieniądze po dziadku, po babci. Ale
> błędnie zakładasz, że jak ktoś umie pisać programy (zakładam że umiesz),
> to jednocześnie cała reszta świata to frajerzy.

To nie tak. Jest tak, że jak się ma doświadczenie w biznesie
software'owym, to się wie rzeczy, których klienci mogą nie wiedzieć i
ich na tym rolować. Ponadto jeśli klient jest organizacją, to zachowanie
analogiczne do "niewiedzy", "frajeryzmu" czy "idiotyzmu" może wynikać
nie z cech osobistych decydenta, tylko z kultury i polityki w takiej
organizacji. Nawet sam podałeś przykład - zaopatrzeniowiec mówi "i co z
tego, że w umowie będą dwa miliony i termin roczny - powinniśmy się
przygotować na to, że może to trwać trzy lata i kosztować dziesięć
milionów". I ty byś takiego zaopatrzeniowca wyrzucił, a on może nie jest
głupi, więc nawet jeśli tak myśli, to powie "udało nam się wynegocjować
korzystną umowę, my zapłacimy dwa miliony a dostawca dostarczy nam
program za rok, jak się spóźni to zapłaci wysokie kary umowne, a jak nie
dostarczy, to go pozwiemy i wyprocesujemy wysokie odszkodowanie z nawiązką".

>> (pomijając już fakt, że zwykle o wydawaniu milionów nie decyduje ktoś,
>> kto te miliony zarobił, tylko pracownik na odpowiednim stanowisku
>> kierowniczym)
>
> Ciekawa hipoteza.

Raczej zupełnie banalny fakt.

>> za to odpowiada, to chyba nie uważasz, że zwolnienie pracownika, który
>> bierze pod uwagę ryzyko i zatrudnienie takiego, który jest pewien, że
>> wszystko będzie dobrze - spowoduje, że ryzyko zniknie?
>
> Jeżeli ryzyko projektu X jest tak duże, że uniemożliwia realizację
> projektu X, to nikt nie będzie płacił pensji pracownikom za realizację
> nierealizowanego projektu X. To logiczne.

Pensje zwykle płaci się pracownikom na podstawie umowy o pracę, a nie za
realizację projektu. Owszem, jeśli zrezygnujesz z zamawiania danego
projektu, to możesz musieć lub chcieć dokonać redukcji. Tylko że po
pierwsze można zauważyć, że z samego faktu, że przy akurat tak a nie
inaczej sformułowanej umowie ryzyko jest niedopuszczalne, to nie znaczy,
że znika otrzeba zrobienia tego, albo że nie da się ryzyka ograniczyć
innym rodzajem umowy.

Jeśli natomiast chcesz powiedzieć, że pracownik zleceniodawcy może
powiedzieć swojemu szefowi "ta umowa na dwa lata jest bardzo korzystna,
weźmy ją", mimo że doskonale wie, że umowa jest niekorzystna i narazi
firmę na spore straty - tylko dlatego, żeby mieć pracę przez kolejne dwa
lata - to owszem, może się tak zdarzyć. W niczym oczywiście to nie
zmienia fdaktu, że umowa jest niekorzystna, więc pracownik zyska na
okłamywaniu pracodawcy, a pracodawca straci. Jedynie można zauważyć, że
programowe wywalanie ludzi, którzy mówią, że ryzyko jest duże, tym
właśnie się mści.

>> Poza tym, jeśli program, za który już zgodziliśmy się zapłacić 2
>> miliony (i tych pieniędzy nie odzyskamy) będzie bez danej zmiany
>> bezużyteczny,
>
> Dlaczego nie odzyskamy? Po to są umowy, zadatek i prawnicy.

Bo zgodnie z umową dostawca wypełnił swoje zobowiązanie. To, że
zamówiłeś coś bezużytecznego to twój problem.

>> Ta ostatnia grupa to główni kandydaci do dojenia, a jest na tyle
>> liczna, że dojenie jest naprawdę sensownym biznes planem i wiele firm
>> żyje z tego od lat.
>
> Trudno uznać taką praktykę za uczciwą, a "dojone" firmy za szczególnie
> dobrze zarządzane.

Zgoda! Tylko że właśnie taka jest moja teza - naleganie klienta
zamawiającego oprogramowanie na umowę fixed price fixed scope jest
bardzo często objawem złego zarządania.

> Oczywiście, być może masz rację - dla tego rodzaju złodziejstwa Agile
> jest być może dobrym rozwiązaniem - pozwala naciągać klientów na wieczne
> "zmiany".

Zakałapućkałeś się. Tego rodzaju złodziejstwo wymaga fixed price fixed
scope. Agile z kontraktem time and materials właśnie jest
zabezpieczeniem klienta przed tego rodzaju złodziejstwem.

do góry

Użytkownik "Andrzej Jarzabek" napisał w wiadomości grup
dyskusyjnych:ksds4b$f1t$...@s...invalid...

>Jeśli już mówimy o tym, co jest bardziej prawdopodobne, to również bardziej
>prawdopodobne jest, że sąd oddali pozew Boba, i to Bob będzie

Dlaczego miałby oddalić? Przecież jest umowa, a Fred jej nie dotrzymał.
Sprawa jest tak oczywista, że najmądrzej gdyby Fred zgodził się zapłacić bez
procesu - przynajmniej uniknie kosztów.

>software, poniesie koszty procesu, ale też niebanalne koszty stworzenia
>szczegółowej specyfikacji nikomu niepotrzebnego systemu komputerowego

Dlaczego miałby ponosić? Gdyby Fred wywiązał się z umowy - tak, wtedy Bob
musiałby zapłacić Fredowi dwa miliony euro. Ale Fred dał się podpuścić - Bob
miał lepszych ekspertów od IT - i podjął się realizacji czegoś, co
zwyczajnie go (jego firmę) przerasta. Zapewniam cię, że tzw. branża widziała
nie takie rzeczy.

>No ale że traci zadatek nie znaczy, że nie musi zapłacić reszty.

Bob nie traci zadatku, bo to nie on nie dotrzymał umowy. Zadatek to forma
zabezpieczenia: ten kto złamie umowę musi płacić. Jeżeli Bob złamałby... ok,
zadatek przepadł. Ale jeżeli Fred, to nie tylko że Fred oddaje zadatek
Bobowi, ale jeszcze musi "z automatu" dać drugie tyle. Tak to działa
(przyznaję, sam się kiedyś nieco zdziwiłem).

>Bob ma biznes taki, że chodzi po różnych wykonawcach i zleca im wykonanie
>czegoś bezużytecznego, po czym kiedy to wykonają, pozywa ich za straty
>spowodowane tym, że dostarczony produkt jest bezużyteczny?
>
>I na takim biznesie można zarobić? W jakim państwie?

Co, strach obleciał? ;)

Przypuszczam że w USA. Skoro tam można zarobić na zbyt gorącej kawie,
wypalonych papierosach i prowadzić spory który prostokąt jest bardziej
prostokątny. Ogólnie - w każdym państwie w którym DZIAŁAJĄ sądy i są
DOTRZYMYWANE umowy.

>Nie. Mylisz dwóch programistów. Fred doiciel wierzy w kontrakty fixed price
>and scope i w dojenie klientów na zmianach. Antek agilista zakład
>przyjacielski model współpracy, i dlatego nigdy nie podpisuje takich
>kontraktów, tylko zawsze nalega na time and materials. W kontrakcie

Nie podpisuje - nie ma pracy.

Idziesz do krawca. Każesz mu uszyć garnitur, określasz kolor i krój
(wybierając z propozycji jakie pokazuje krawiec). Przychodzi do krawca
znowu - a ten pokazuje ci, że zamiast garnituru uszył kalesony i kapelusz.
Zapłacisz?

>Antka nie ma wielostronicowej specyfikacji produktu, tylko statement of
>intent. Antek nie zawiera umowy na dwa miliony euro zaa produkt, tylko na
>czterdzieści tysięcy euro za tydzień produkowania.

W kontrakcie Antka nie ma wielostronicowej specyfikacji... z bardzo
oczywistej przyczyny - po prostu Antek nie zdołał znaleźć klienta na swoje
(nieokreślone) usługi - więc i kontraktu nie ma.

>No ale skąd założenie, że Fred nie dotrzymuje terminów? Fred bardzo się
>stara, żeby terminów dotrzymywać i być zawsze w 100% zgodnym z umową - to
>podstawa biznes planu Freda.

Ale z jaką umową? Że może robić co chce, jak chce i za wszystko płaci mama i
tatuś... tzn. mistyczny klient? Get real.

>Jeśli natomiast Bob jest powszechnie znany z zamawiania bezużytecznych
>rzeczy, a potem zaskarżania wykonawców o straty z powodu ich
>bezużyteczności, to pewnie nawet jego pozew nie trafi na salę.

Sąd po prostu oceni: czy umowa była prawidłowo zawarta i czy Fred jej
dotrzymał. Reputacja Boba nie ma nic do rzeczy.

Skoro firmy-trolle robią niezły interes na patentach, to jednak twoja ślepa
wiara w kierowanie się przez sądy (np. w USA) interesem Freda jest nieco...
nieuzasadniona.

>Bankructwo to osobny pomysł i oczywiście ryzyko dla wykonawcy. Ale zauważ
>też, symetrycznie, że jeśli Fred ma spółkę z oo, to nawet jeśli

Nie symetrycznie. Jeżeli zadatek/zaliczka wynosi 500 000 euro, a cena
całkowita to 2 000 000 euro, to bankructwo Boba jest stratą 4 razy bardziej
kosztowną dla Freda niż bankructwo Freda dla Boba. Na tym właśnie polega
cały trik - Bob ryzykuje stosunkowo mało, Fred znacznie więcej. Oczywiście,
być może Fred da radę sprzedać produkt robiony dla Boba komuś innemu...

>sąd zasądzi mu ten milion czy ile tam odszkodowania, to Fred może sobie

Nie zrozumiałeś: przy zadatku nie musi nawet być sądu - po prostu zadatek to
taka suma, która "przepada" stronie zrywającej umowę. Jeżeli zadatek wynosi
x, to biorący zadatek musi zwrócić 2x, tj. tyle ile dostał i jeszcze drugie
tyle. Dura lex...

>spokojnie zbankrutować i egzekucja będzie z majątku spółki - w wysokości
>np. jednego laptopa. Więc dla Boba ten biznes jest dodatkowo ryzykowny

Nie martw się. Bob sprawdził ogólnie dostępne dane nt. firmy Freda,
dokładnie wie ile może wyciągnąć z biedaka. Ponadto bardzo się ucieszy że
Fred zbankrutuje - zostanie wyeliminowana konkurencja dla niego (lub dla
jakiejś Elsy).

>To nie tak. Jest tak, że jak się ma doświadczenie w biznesie software'owym,
>to się wie rzeczy, których klienci mogą nie wiedzieć i ich na tym rolować.
>Ponadto jeśli klient jest organizacją, to zachowanie

Lubisz myśleć że jesteś najsprytniejszym chłopakiem w mieście?

>Pensje zwykle płaci się pracownikom na podstawie umowy o pracę, a nie za
>realizację projektu. Owszem, jeśli zrezygnujesz z zamawiania danego

O, to umowy o pracę nie można rozwiązać? Ciekawe, ciekawe.

>że znika otrzeba zrobienia tego, albo że nie da się ryzyka ograniczyć innym
>rodzajem umowy.

Owszem, i o takich porządnych umowach pisał m.i. AL.

>Bo zgodnie z umową dostawca wypełnił swoje zobowiązanie. To, że

Bob zastrzegł "drobnym druczkiem" że program ma działać. A nie działa.

do góry

On 20/07/2013 15:12, slawek wrote:
> Użytkownik "Andrzej Jarzabek" napisał w wiadomości grup
> dyskusyjnych:ksds4b$f1t$...@s...invalid...
>
>> Jeśli już mówimy o tym, co jest bardziej prawdopodobne, to również
>> bardziej prawdopodobne jest, że sąd oddali pozew Boba, i to Bob będzie
>
> Dlaczego miałby oddalić? Przecież jest umowa, a Fred jej nie dotrzymał.

Przecież właśnie dotrzymał. Dostarczył bezużyteczny program według
specyfikacji w terminie.

>> software, poniesie koszty procesu, ale też niebanalne koszty
>> stworzenia szczegółowej specyfikacji nikomu niepotrzebnego systemu
>> komputerowego
>
> Dlaczego miałby ponosić? Gdyby Fred wywiązał się z umowy - tak, wtedy
> Bob musiałby zapłacić Fredowi dwa miliony euro. Ale Fred dał się
> podpuścić - Bob miał lepszych ekspertów od IT - i podjął się realizacji
> czegoś, co zwyczajnie go (jego firmę) przerasta. Zapewniam cię, że tzw.
> branża widziała nie takie rzeczy.

No dobrze, ale jak ta sytuacja ma się do tego, o czym pisałem. Przypomnę
o czym pisałem:
* chcesz zamówić program na umowę fixed price fixed scope, na przykład
system księgowości,
* masz różne propozycje od wykonawców zróżnymi rodzajami umów,
* chcesz zamówić program tak, żeby wiedzieć, ile będzie kosztowało i
kiedy będziesz miał ten program,
* wybierasz więc wykonawcę, który proponuje umowę fixed price fixed
scope. Spędzasz ileś czasu nad wykonaniem specyfikacji dla swojego
systemu księgowości,
* wykonawca ogląda twoją specyfikację, mówi dwa miliony euro, 12 miesięcy,
* stwierdzasz, że warto zapłacić dwa miliony i zaczekać 12 miesięcy na
taki system księgowości, jakbyś chciał,
* zakładamy, że dostawca dotrzymuje umowy,

Pytanie, jeszcze raz, przy założeniu, że dostawca dotrzymuje umowy,
kiedy będziesz mógł wdrożyć wykonany przez niego system i zacząć
prowadzić według niego księgowość, oraz ile cię to będzie kosztowało?

Jeśli uważasz, że odpowiedź brzmi 12 miesięcy i dwa miliony, to w
większości przypadków byś się mylił. Prawidłowa odpowiedź brzmi "nie
wiadomo", może to być 18 miesięcy i 2.5 miliona jeśli masz szczęście,
ale może to być równie dobrze 5 lat i 10 milionów, albo możesz w ogóle
nie dostać takiego systemu. Zakładając, jeszcze raz, że dostawca
dotrzyma umowy.

Gdyby nie dotrzymał to, jak piszesz, mógłbyć pozwać go i dostać
odszkodowanie. Ale jeśli dotrzyma, to nikogo nie możesz pozwać i
ostatecznie koleś może po wzięciu 10 milionów powiedzieć, że dalszych
zmian nie zrobi i zostawić cię z systemem, którego nie da się używać. I
sądownie będzie to nie do ruszenia.

>> No ale że traci zadatek nie znaczy, że nie musi zapłacić reszty.
>
> Bob nie traci zadatku, bo to nie on nie dotrzymał umowy. Zadatek to
> forma zabezpieczenia: ten kto złamie umowę musi płacić. Jeżeli Bob
> złamałby... ok, zadatek przepadł. Ale jeżeli Fred, to nie tylko że Fred
> oddaje zadatek Bobowi, ale jeszcze musi "z automatu" dać drugie tyle.
> Tak to działa (przyznaję, sam się kiedyś nieco zdziwiłem).

Ale jeśli jednak obydwie strony dotrzymają umowy, to Fred wyląduje z
dwoma milionami w kieszeni, a Bob z bezużytecznym oprogramowaniem.

>> Bob ma biznes taki, że chodzi po różnych wykonawcach i zleca im
>> wykonanie czegoś bezużytecznego, po czym kiedy to wykonają, pozywa ich
>> za straty spowodowane tym, że dostarczony produkt jest bezużyteczny?
>>
>> I na takim biznesie można zarobić? W jakim państwie?
>
> Co, strach obleciał? ;)

A co ja mam do tego? Ja nie świadczę usług, a gdybym świadczył, to
raczej na umowach time and materials. Na fixed price fixed scope to bym
się zgodził dopiero przy bardzo małym ryzyku i bardzo dużym mnożniku i
tylko w sytuacji, kiedy sppokojnie mógłbym spławić klienta, jeśli będzie
się domagał sie niższej ceny i/lub krótszego terminu.

> Przypuszczam że w USA.

A ja przypuszczam, że nie.

>> price and scope i w dojenie klientów na zmianach. Antek agilista
>> zakład przyjacielski model współpracy, i dlatego nigdy nie podpisuje
>> takich kontraktów, tylko zawsze nalega na time and materials. W
>> kontrakcie
>
> Nie podpisuje - nie ma pracy.

Ma pracę, bo jest wielu klientów, którzy nie tylko się zgadzają, ale
nawet wolą umowy time and materials.

> Idziesz do krawca. Każesz mu uszyć garnitur, określasz kolor i krój
> (wybierając z propozycji jakie pokazuje krawiec). Przychodzi do krawca
> znowu - a ten pokazuje ci, że zamiast garnituru uszył kalesony i
> kapelusz. Zapłacisz?

Nie zapłacę, ale nie ma tu żadnej analogii do Antka Agilisty. Antek
przecież w każdej iteracji wykonuje to, co wybrał do zrobienia klient -
co ma w umowie.

>> Antka nie ma wielostronicowej specyfikacji produktu, tylko statement
>> of intent. Antek nie zawiera umowy na dwa miliony euro zaa produkt,
>> tylko na czterdzieści tysięcy euro za tydzień produkowania.
>
> W kontrakcie Antka nie ma wielostronicowej specyfikacji... z bardzo
> oczywistej przyczyny - po prostu Antek nie zdołał znaleźć klienta na
> swoje (nieokreślone) usługi - więc i kontraktu nie ma.

W rzeczywistym świecie istnieją firmy z powodzeniem sprzedające takie
usługi. I są one jak najbardziej (kontraktowo) określone, po prostu nie
przez specyfikację produktu.

Antek znajdzie klienta, tylko tym klientem nie będzie Bob. CO jest
kolejną zaletą strategii biznesowej Antka, bo Antek nie chce zawrzeć
umowy z kimś takim jak Bob. Na szczęście oprócz Bobów, którzy zamawiają
oprogramowanie tylko po to, żeby wyrolować dostawcę, istnieje jeszcze
mnóstwo klientów, którzy zamawiają, bo naprawdę tego softu potrzebują
(zakładając oczywiście, że ktoś taki jak Bob w ogóle istnieje, w co
szczerze wątpię, a ty, jak rozumiem, jako uzasadnienie ich istnienia
masz tylko wątpliwą spekulację typu "skoro istnieją królewny, muszą
również istnieć smoki".

>> No ale skąd założenie, że Fred nie dotrzymuje terminów? Fred bardzo
>> się stara, żeby terminów dotrzymywać i być zawsze w 100% zgodnym z
>> umową - to podstawa biznes planu Freda.
>
> Ale z jaką umową? Że może robić co chce, jak chce i za wszystko płaci
> mama i tatuś... tzn. mistyczny klient? Get real.

Nie, że ma w danej iteracji zrobić to, co wybierze klient na początku
tej iteracji.

>> Jeśli natomiast Bob jest powszechnie znany z zamawiania bezużytecznych
>> rzeczy, a potem zaskarżania wykonawców o straty z powodu ich
>> bezużyteczności, to pewnie nawet jego pozew nie trafi na salę.
>
> Sąd po prostu oceni: czy umowa była prawidłowo zawarta i czy Fred jej
> dotrzymał. Reputacja Boba nie ma nic do rzeczy.

No i zobaczy - umowa została zawarta prawidłowo, Fred dotrzymał
warunków. To, że otrzymany przez Boba software jest bezużyteczny nie ma
nic do rzeczy.

>> sąd zasądzi mu ten milion czy ile tam odszkodowania, to Fred może sobie
>
> Nie zrozumiałeś: przy zadatku nie musi nawet być sądu - po prostu
> zadatek to taka suma, która "przepada" stronie zrywającej umowę. Jeżeli
> zadatek wynosi x, to biorący zadatek musi zwrócić 2x, tj. tyle ile
> dostał i jeszcze drugie tyle. Dura lex...

Ale w przypadku, o którym pisałem, nie dochodzi do zerwania umowy.

>> To nie tak. Jest tak, że jak się ma doświadczenie w biznesie
>> software'owym, to się wie rzeczy, których klienci mogą nie wiedzieć i
>> ich na tym rolować. Ponadto jeśli klient jest organizacją, to zachowanie
>
> Lubisz myśleć że jesteś najsprytniejszym chłopakiem w mieście?

Nie jestem firmą robiącą software na zamówienie, ja jako ja w ogóle nie
występuję w tej historyjce.

>> że znika otrzeba zrobienia tego, albo że nie da się ryzyka ograniczyć
>> innym rodzajem umowy.
>
> Owszem, i o takich porządnych umowach pisał m.i. AL.

Właśnie pisał o dokładnie takich umowach, w których opisane dojenie
występuje na maksa. Vide historia o przesunięciu przycisku za ćwierć
miliona.

>> Bo zgodnie z umową dostawca wypełnił swoje zobowiązanie. To, że
>
> Bob zastrzegł "drobnym druczkiem" że program ma działać. A nie działa.

Działa. Co więcej działa tak, jak jest to wyspecyfikowane w umowie. A że
Bob nie może go używać, to problem Boba.

do góry