On 20/07/2013 20:37, slawek wrote:
> Użytkownik "Andrzej Jarzabek" napisał w wiadomości grup
> dyskusyjnych:kseh6s$r8v$...@s...invalid...
>
>> 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,
>
> Jeżeli firma zgodziła się na 12 miesięcy i dwa miliony, to przy 18
> miesiącach i 2.5 milionach kary umowne mogą być bolesne.

Nie mogą być, bo kary umowne są wypłacane w przypadku naruszenia
terminu. W tym przypadku naruszenia terminu nie ma - zamawiający sam
zgadza się przesuwać termin, a jeśli nie, to zgodnie z oryginalną umową
po 12 miesiącach dostaje produkt bezużyteczny.

>> 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.
>
> Zadziwiające: dostawca DOTRZYMUJE umowy a odbiorca NIE DOSTAJE
> ZAMÓWIONEGO SYSTEMU. Logika doprawdy porażająca!

Dostaje zamówiony system. Nie dostaje systemu, którego może używać.

>> 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
>
> W czym problem, jeżeli np. kod źródłowy należy do zleceniodawcy (wiem,
> będzie nieco drożej)?

Może nie być nieco drożej, tylko dużo, dużo drożej. Niektórzy dostawcy w
ogóle się na to nie zgodzą, bo do budowania systemów używają
istniejącego wcześniej kodu, który jest objęty tajemnicą handlową.

Oczywiście jeśli w końcu wylądujesz z milionami linijek kodu źródłowego,
to też nie znaczy, że znajdziesz kogokolwiek, kto się zgodzi wprowadzać
nawet niewielkie zmiany tanio. Musiałbyś znaleźć kogoś, kto ma
ekspertyzę we wszystkich zastosowanych technologiach, lub też
zamawiający musiałby być skłonny zapłacić za naukę przyjnajmniej częsci
z nich. Ponadto w ogóle zrozumienie architektury systemu na podstawie
kodu źródłowego jest niebanalnym zadaniem jeśli nie masz do dyspozycji
kogoś, kto wcześniej nad tym kodem pracował i mógłby ci cokolwiek
wytłumaczyć. W szczególności jeśli wykonawcy zupełnie nie zależy, żeby
zdawany przez nich system był łatwy do zrozumienia przez kogokolwiek
innego. Poza tym coiężko się będzie zabepieczyć przezd wszelkimi
ewentualnościami typu: wykonawca oddaje kod źródłowy, ale testów którymi
wewnętrznie ten kod weryfikował - już nie.

>> Ale jeśli jednak obydwie strony dotrzymają umowy, to Fred wyląduje z
>> dwoma milionami w kieszeni, a Bob z bezużytecznym oprogramowaniem.
>
> No to ja zapytam: a dlaczego bezużytecznym?

Z wielu powodów.

Przede wszystkim tak jak w dużym systemie informatycznym popełnienie w
którymś momencie błędu przez programistę nie jest możliwością, tylko
pewnikiem, tak samo popełnienie błędów przy pisaniu bardzo szczegółowej
specyfikacji tego systemu jest co najmniej bardzo prawdopodobne.
Rewidowanie, czytanie, konsultowanie takiej specyfikacji ciężko jest tak
zrobić, żeby wyłapać wszystkie czy nawet większość takich błędów. Dalsze
eliminowanie tych błędów z coraz większym prawdopodobieństwem przed
podpisaniem umowy jest lawinowo coraz droższe, może nawet dorównać lub
przekroczyć cenę samego softu.

Wyłapanie tych błedów na dalszych etapach jest możliwe, wiele z nich
zauważanych jest już w czasie analizy czy pisania kodu, niektóre przy
testowaniu oprogramowania u wykonawcy, niektóre przy próbie wdrożenia, w
fazie UAT, czy jeśli masz pecha, to już w produkcji. Tak czy inaczej w
takiej sytuacji musisz prosić wykonawcę o zmianę, co oznacza
renegocjację kontraktu, nowy termin, nową cenę.

Drugi powód jest taki, że język naturalny nie jest wystarczająco
precyzyjny, żeby jednoznacznie opisać takie wymagania. W tekście pisanym
po polsku czy po angielsku prawdopodobnie będzie wiele zdań, które można
interpretować na różne sposoby - z których niektóre (które miał na myśli
piszący specyfikację) będą zgodne z wymaganiami zamawiającego, inne nie.
Interpretacje w oczywisty sposób niepoprawne nie przejdą, ale istnieją i
takie, w przypadku których ewentualny sąd uzna, że wykonawca miał prawo
zrozumieć to w taki sposób i nie ma w tym jego winy - np. że wybór
właściwej interpretacji jest oczywisty dopiero znając pewne szczegóły
wewnętrznej organizacji u zamawiającego, które były oczywistą
oczywistością dla piszącego specyfikację (który tam pracuje i tymi
szczegółami żyje), ale o których wykonawca nie mógł wiedzieć
przystępując do umowy.

Kolejny powód jest taki, że zmieniają się realia i software, który byłby
użyteczny w momencie zamawiania może być bezużyteczny w momencie jego
odbioru. Powodem mogą być zmiany w samej organizacji zamwaiającego
(restrukturyzacja, zmiany w modelu biznesowym), zmiana warunków
zewnętrznych (wymiana platformy elektronicznej na Giełdzie Papierów
Wartościowych) lub w pewnych branżąch zmieniające się przepisy lub ich
obowiązujące interpretacje (software jest technicznie zdatny do użycia,
ale jego używanie w takiej formie po zmianie przepisów jest niezgodne z
prawem).

>> 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
>
> Geeez. Zgodziłbyś się. Natychmiast. Wystarczy odpowiednia motywacja.

No to właśnie mówię - małe ryzyko i duży mnożnik byłby odpowiednią
motywacją. Jeśli bym wiedział, że zrobię coś w miesiąc, a już
ekstremalnie nieprawdopodobne jest, żeby mi to zajęło więcej niż trzy,
koszty własne będą żadne, to pewnie się zgodzę na dwuletni termin i
odpowiednio wiele milionów.

W praktyce oczywiście zgodzę się na mniej - bo w zależności od mojej
sytuacji będę np. dużą firmą z dużą ilością zleceń i będę miał całą
kalkulację ryzyka wiedząc np. jak często rzeczywisty czas i koszty
wykonania przekraczają pierwotne estymaty o dany procent, będę miał
armię prawników wpisujących do umów klauzule ograniczające
odpowiedzialność, to będę mógł w ramach tej kalkulacji stracić określone
kwoty na jakimś procencie zleceń i nadal być do przodu z zysków na
pozostałych.

Jeśli natomiast jestem jednoosobową spółką z oo, to nie mam tej armii
prawników i nie stać mnie na straty, ale chroni mnie instytucja
ograniczonej odpowiedzialności - mogę przyjąć zlecenie Boba, przez rok
wypłacać sobie pensje i diety, a jak za rok się nie uda dostarczyć softu
według umowy, to sobie spokojnie zbankrutuję, stracę tego laptopa co go
mam na majątku firmy, a z oszczędności zakupię kolejnego laptopa i użyję
go jako kapitału założycielskiego kolejnej spółki z oo.

>> Ma pracę, bo jest wielu klientów, którzy nie tylko się zgadzają, ale
>> nawet wolą umowy time and materials.
>
> Podobno bezrobocie wynosi około 30% wśród absolwentów. Znaczy się jest
> trochę krucho z klientami, bo inaczej wszystkich młodych i zdolnych
> upchnąć dałoby się w branży IT.

Nie znaczy, bo branża IT jest zainteresowana raczej zyskami niż
obniżaniem bezrobocia wśród absolwentów.

>> Antek znajdzie klienta, tylko tym klientem nie będzie Bob. CO jest
>
> Nie rozumiesz. Bob to pasożyt. Żeruje na rozmaitych bosych Antkach.

Rozumiem. Dlatego właśnie mówię - jeśli formy umowy oferowane przez
Antka spowodują, że Bob sobie pójdzie gdzie indziej, to tylko świadczy o
tym, że Antek dobrze kombinuje.

> Antki uwierzyły w Agile i takie tam. Uwierzyły w to, że da się bez
> prawników, bez umów, podpisów i krawatów. A Bob to paskuda taka sama jak
> np. prawnicy blokujący sprzedaż produktu konkurencji "bo zastosowano w
> nim wkręty o tej samej średnicy co w naszym produkcie".

No ale właśnie Antek ma rację - Bob nie będzie pasożytował na nim, tylko
na Fredzie, który nie wierzy w Agile i w związku z tym oferuje kontrakty
fixed time fixed scope. Antek uwierzył w Agile więc proponuje time and
materials, co uodparnia go na atak Boba.

> Pasożytów, na przykład tasiemca, nie szukasz. To pasożyt dopada cię
> znienacka, bo np. nie lubiłeś myć rąk. Podobnie z Bobem. Nigdy nie
> wiesz, kiedy go spotkasz i jak będzie wyglądał. Może np. wyglądać
> zupełnie jak twój serdeczny kumpel ze studiów.

No więc dla Antka Agile jest jak mycie rąk. Nie musi rozpoznać Boba,
wystarczy, że Bob ucieknie z krzykiem jak usłyszy warunki Antka.

>> 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
>
> Bob nikogo nie chce rolować (przynajmniej miejmy nadzieję że nie ma
> osobistej urazy do Freda) - Bob chce zmaksymalizować zysk. A to że przy
> okazji doprowadzi Freda do bankructwa czy jakoś tak... to chyba nie jest
> jakiś wielki problem etyczny (dla Boba).

Bob właśnie chce kogoś rolować, na tym polega jego pomysł na
maksymalizację zysku.

Normalnie jednak produkcja oprogramowania opłaca się, bo istnieje
również taki pomysł na maksymalizację zysku, który nie wymaga
bankrutowania czy doprowadzania do strat wykonawcy. Wręcz przeciwnie -
bankructwo, czy choćby zakończenie współpracy przez wykonawcę jest dla
takich klientów dużym problemem, bo wprowadzanie dlaszych zmian do
oprogramowania staje się znacznie bardziej kosztowne lub wręcz niemożliwe.

>> Ale w przypadku, o którym pisałem, nie dochodzi do zerwania umowy.
>
> Dochodzi. Soft nie spełnia wymagań zawartych w umowie "drobnym
> druczkiem". Jak mawiają Rosjanie: p...no.

No to mamy dwie historie - Nierzetelnego Freda i Freda Naciągacza (przed
przypadek mają takie samo imię). Fred Naciągacz bardzo dba o to, żeby
dotrzymywać terminów, a jeśli już (rzadko) nie da rady, to sumiennie
płaci kary umowne (umawia się tylko tak, żeby go było stać na owe kary)
- nawet jeśli ma do tego dopłacić. Bo cały biznes model Freda Naciągacza
opiera się na tym, że większość klientów chce potem wielu zmian w
specyfikacji i jest skłonna zapłacić za nie sporo więcej, niż te zmiany
kosztują (bo bez nich soft jest z reguły beezwartościowy albo
przynajmniej mocno upośledzony).

I teraz załóżmy, że Bobowi udało się doprowadzić Nierzetelnego Freda do
bankructwa i zainkasować okrągły milion, przy kosztach własnych
powiedzmy 100 tysięcy (stworzenie specyfikacji i napisanie umowy
kosztuje). W międzyczasie dowiaduje się, że niejako Bosy Bolek ma
problemy z dotrzymywaniem terminów, więc proponuje Bolkowi taką samą
umowę na dwa miliony. Dla Bolka dwa miliony to niewyobrażalny majątek,
więc mówi - czemu nie. Podpisuje umowę jako prezes Bolo sp z o o, bierze
pół miliona zaliczki, przez 12 miesięcy wypłaca sobie prezesowską pensję
30 tysięcy miesięcznie, plus pokrywa z zaliczki koszty lanczów
biznesowych, podróży biznesowych, wynajmu biura, pensjęę sekretarki i co
tam jeszcze. Przy tym wszystkim naprawdę uczciwie się stara zrobić
program według specyfikacji Boba. Jest to oczywiście niemożliwe, więc
Bob pozywa Bolka, sąd zadądza milion euro odszkodowania, Bolo zp z o o
ogłasza upadłość, komornik zajmuje majątek firmy w postaci laptopa,
sztuk 1, Bosy Bolek rejestrujee firmę Bolorz sp z o o, wykładając jako
kapitał zakładowy równowartość laptopa, sztuk 1, z pieniędzy, które
zarobił jako preze Bolo sp z o o. Bosy Bolek jest do przodu, Bob stracił
właśnie pół miliona, ale póki co jest jeszcze 400 tys. do przodu.

Tymczasem Fred Naciągacz dowiaduje się o Bobie. Co prawda to nie jego
typowy klient, ale Fred widzi tutaj pewną okazję. Namawia przyjaciela,
żeby zwierzył się Bobowi przy barze jak to się przejechał na tym, że
zlecił jakiś soft u takiego Cholernie Nierzetelnego Freda. Fred
Naciągasz tymczasem odnajduje Nierzetelnego Freda i proponuje intratną
współpracę. Bob oczywiście wkrótce pojawia się u Freda Naciągacza z
propozycją wykonania softu za dwa miliony. Fred patrzy na specyfikację
produktu i jest wniebowzięty - to dokładnie ta sama specyfikacja, którą
dostał Nierzetelny Fred, z tym samym drobnym druczkiem - Bob ogranicza
koszty i czas nie wymyślając za każdym razem nowej specyfikacji za sto
tysięcy. Ponieważ z pendrajwa Nierzetelnego Freda Fred Naciągasz ma
program stworzony według tej specyfikacji, razem z testami, analizą
itd., nie spełniając jedynie drobnego druczku, Fred Naciągacz może
wyliczyć, że uzupełnienie programu o wymagania drobnego druczku to
najwyżej 6 miesięcy roboty. Podpisuje umowę na 12 miesięcy i dwa
miliony, bierze pół miliona zadatku (Bob już jest 100k w plecy) i w 6
miesięcy oddaje program według specyfikacji, łącznie z drobnym drukiem.
Bob może w tym momencie tylko albo zgodnie z umową zapłacić 2 miliony
(jeśli ma), albo zbankrutować. Przy czym jeśli się okaże, że Bob jako
zarządzający spółką Bob Holdings zamówił oprogramowanie za 2 miliony w
momencie kiedy spółka nie miała ani kapitału, ani spodziewanych
dochodów, ani nawet zdolności kredytowej (z braku kapitału i dochodów),
a w dodatku, że to już trzeci raz Bob składa takie zamówienie, to jednak
obstawiam, że są na to paragrafy, którymi można ścignąć Boba osobiście,
cywilnie i prawdopodobnie również karnie. Fred Naciągacz więc zarobi nie
tylko pół miliona zadatku i co tam się ściągnie z egzekucji Bob
Holdings, ale być może również przychód ze zlicytowania domu, samochodu
i sztucznych cycków żony Boba. Bob tymczasem wiesza się w celi na
prześcieradle...

>> 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.
>
> Spoko, spoko. Jeżeli przesunięcie przycisku kosztowało 250 000 euro ($?)
> to pewnie przyniosło przynajmniej 250 000 + 1 euro zysku. Inaczej nikt
> nie przesuwałby tego przycisku.

A jeżeli zamawiający miałby mieć 200 tys (chodziło o dolary nie euro,
ale mniejsza o to) zysku z przesunięcia innego przycisku, to już
zostawił ten drugi przycisk jak był i stracił 200 tysięcy.

To jest oczywiście uproszczona wizja, bo w rzeczywistości w biznesie
masz do czynienia z profilem ryzyka a nie z pewnymi zyskami czy
stratami. Może np. być tak, że złe położenie przycisku powoduje, że co
jakiś czas operator wciska nie ten przycisk i powoduje mniejsze lub
większe straty - nie wiadomo jakie, ale można oszacować
prawdopodobieństwo, że będą np. w przedziale 100-150 tys. I kwestia jest
taka, że w zależności od profilu ryzyka może się okazać, że korzystanie
z programu nie ma sensu, bo ryzyko strat spowodowane złym przyciskaniem
źle położonego przycisku przeważa jakiekolwiek korzyści z korzystania z
programu. I w tym momencie, jeśli zamawiający nie zgodzi się zapłacić
250 tys. za przesunięcie przycisku, to te dwa miliony wydanee już na ten
program są pieniędzmi wyrzuconymi w błoto.