Pamiętacie bajkę o żabie i skorpionie?

Za chwilę się okaże jaki ma związek z IT.

Nad brzegiem rzeki spotkała się żaba i skorpion. Oboje chcieli przedostać się na drugą stronę. Żaba obyta ze środowiskiem wodnym nie miała żadnych obaw. Gorzej ze skorpionem, nie potrafił przemieszczać się w wodzie. Postanowił przekonać żabę, aby mu pomogła i przepłynęła z nim na grzebiecie.

Żaba w pierwszym odruchu odmówiła. Obawiała się, że skorpion ją ukąsi swoim śmiercionośnym żądłem w czasie tej przeprawy.

Skorpion się żachnął i odwołał do racjonalnych argumentów. Po co miałby to robić? Przecież naraziłoby to ich obydwoje na niebezpieczeństwo i zginęli by oboje. Argument przekonał żabę. Pozwoliła skorpionowi wejść na swój grzbiet i wskoczyła do wody.

Gdy byli na środku rzeki skorpion wykonał gwałtowny ruch odwłokiem i śmiertelnie ukąsił żabę.

Żaba tuż przed śmiercią pyta jeszcze skorpiona dlaczego to zrobił, a ten jej odpowiada

„Przepraszam żabo, taka już jest moja natura”.

Widzicie tu jakąś analogię do wdrożeń IT?

TOP 10 wishful thinking w IT

1. Negocjacje idą jak po grudzie, ale jak tylko klepniemy umowę to ruszymy z kopyta

Jest takie powiedzenie, że jeśli pomysł nie sprawia że od razu chcesz się wziąć do pracy to jest zły pomysł. Nie inaczej jest w takim przypadku.

Jeśli kontrahent nie współpracuje już przy negocjacjach, kiedy poziom ekscytacji nowym projektem jest największy, to co będzie później?

Skąd pomysł, że potem będzie lepiej?

Weź to pod uwagę adresując ryzyka w umowie. Z czasem bowiem okazuje się, że najłatwiej to było w czasie negocjacji.

2.Co prawda negocjacje prowadzę na kolanach, ale jak tylko on powie TAK wstanę i przejmę kontrolę nad sytuacją.

Pamiętasz opowieść Woodiego Allena o łosiu? Gdy opowiada jak zabiera ze sobą łosia, którego myślał, że zabił? Łoś ożył, a on postanawia przemycić go na bal przebierańców. Głowna myśl, która mu towarzyszy to zrzucę z siebie odpowiedzialność. To już nie będzie mój problem. To będzie ich problem. https://www.youtube.com/watch?v=WdObOSqbatA

Jeśli negocjacje prowadzisz na kolanach, to w najlepszym razie zostaniesz w tej pozycji, lepszej opcji nie będzie.

Bardziej prawdopodobna jest jednak gorsza pozycja, tzn że padniesz na plecy i jeszcze się przeturlasz.

Od momentu złożenia podpisu na umowie to będzie jednak tylko twój problem.

3. Kontrahent wygląda dobrze i jego system też.

Wszystko będzie dobrze.

Przychodzi mi na myśl jedna ze scen z Drive, gdy główny bohater grany przez Ryna Goslinga ogląda telewizję z synem swojej sąsiadki i z ust małego chłopca pada pytanie:  Czy on wygląda na dobrego gościa?

Tytułowy Driver wycofany, z chłopięcym uśmiechem wygląda dobrze, do przełomowej sceny w windzie. Wtedy wychodzi z niego cała mroczna natura.

Nie zawsze to co dobrze wygląda, albo dobrze brzmi jest dobrym biznesem. Branża pogrzebowa nie brzmi najlepiej, a jest jednym z pewniejszych biznesów.

Warto o tym pamiętać negocjując umowy na systemy IT.

4. Dostanę to czego chcę.

Może w agile. Normalnie dostaniesz to na co się umówiliście w umowie. Dostawca zwykle dużo lepiej wie co dostarczy, podczas gdy klient ma tylko wyobrażenie, które przy odbiorze zderza się z realiami.

Dlatego warto przeczytać ze zrozumieniem załączniki opisujące to na co się umawiacie. Zupełnie inaczej „rozkminia się” jakąś myśl w swojej głowie, a inaczej taką, która ma postać zapisanego tekstu.

Po filmie „Fargo”, który przyniósł dwie statuetki Oskara, od kolejnego dzieła braci Cohen wszyscy oczekiwali tego samego. Byli pewni, że film będzie sukcesem kasowym. „Big Lebowski” zawiódł oczekiwania i może nie został zmieszany z błotem przez krytyków, ale pochlebnych opinii było zdecydowanie mniej niż krytycznych. Sytuacja nieco zmieniła się kilka lat później, kiedy to zyskał na wartości, ale w IT akurat czas działa na niekorzyść zaimplementowanych rozwiązań i nie warto liczyć na taki obrót spraw.

5. Mamy umowę fixed price.

Zapłacę tyle na ile się umówiliśmy.

Może i tak. Ale za to wynagrodzenie dostaniesz to na co się umówiłeś, czyli nie koniecznie to czego chcesz.

A to czego chcesz może kosztować przy dobrych wiatrach co najmniej 20% więcej. I tu wracamy do punktu 4. Mając tego świadomość lepiej już na etapie początkowej euforii zadbać o budżet prac dodatkowych i zarządzanie zmianą.

6. Dwa miesiące i projekt będzie gotowy.

Tak wiem, w umowie jest harmonogram, i kary umowne za opóźnienie, prawo do odstąpienia od umowy i kilka innych klauzul, którymi możesz zaszachować wykonawcę. I przede wszystkim ufasz swojemu wykonawcy, który zapewnia cię, że zdąży.

To wszystko niewielkie ma znaczenie, bo harmonogram wdrożenia zmienisz co najmniej dwa razy i za każdym razem negocjacje będą cię kosztować sporo energii i czasu. Może zatem od razu lepiej pokusić się o bardziej realne planowanie? I dobre zarządzanie zmianą.

7. Mogę zrobić z oprogramowaniem co chcę,

mam przecież prawa autorskie.

Możesz zrobić z oprogramowaniem to na co pozwala ci umowa, czyli to na co się umówiłeś ze swoim wykonawcą. O ile umowa potwierdza fakty, bo w zakresie praw autorskich te mają kluczowe znaczenie.

W razie sporu jako potencjalnie nabywający prawa autorskie będziesz musiał udowodnić fakty, a nie istnienie zapisów w umowie. A nie wszyscy o tym pamiętają. Poszłabym nawet dalej i zaryzykowała stwierdzenie, że w większości przypadków fakty mają się nijak do umowy.

Fakty mogą być bowiem takie:

• Majątkowe prawa autorskie są dalej u podwykonawcy twojego wykonawcy (bo nie zadbał o ich przeniesienie);
• Osobiste prawa autorskie są na 100% u podwykonawcy twojego wykonawcy jako twórcy, pytanie tylko czy wykonawca zadbał o ich niewykonywanie;
• Majątkowe prawa autorskie są gdzieś w łańcuszku dostaw, ale raczej nie u końcowego wykonawcy.
• Elementem systemu są open-source i niestety w żaden sposób nie będziesz mieć do nich praw.

8. Nie martwię się, bo jak coś to mam kody źródłowe.

Tak myślisz? Jeśli są u ciebie w sejfie, zostały sprawdzone, są zaktualizowane to rzeczywiście zmartwień masz o połowę mniej. Od tych, którzy mają tylko zapisy w umowie, zobowiązujące wykonawcę do ich złożenia w depozycie, a będą mogli je z niego wyciągnąć gdy nadejdzie TA chwila.

9. Nie martwię się. W razie czego mam kary umowne.

Nie wiedzieć czemu kary umownej stwarzają poczucie bezpieczeństwa u zamawiających. Im wyższe tym większe. Niektóre umowy budują swoisty model całego biznesu na karach umownych. Rzeczywiście możesz je naliczyć. Czy je realnie wyegzekwujesz? To już inna historia. Może, w części jeśli masz dobre zabezpieczenie na wypadek nienależytego wykonania. W każdym innym przypadku raczej czeka cię spór o nie z wykonawcą.

10. Mam gwarancję i serwis, jestem bezpieczny.

Poczucie bezpieczeństwa może być złudne. Jeśli majątkowe prawa autorskie (w tym prawo do rozwoju) wraz z prawem do opracowań pozostały przy wykonawcy, a wykonawca zmienił strukturę, został wchłonięty przez inny podmiot lub przestał istnieć masz problem. Chyba że jesteś bankiem, w umowach wdrożeniowych dla systemów bankowych jest zwykle coś na kształt disaster recovery plan. W innych to ogromna rzadkość.

Ekonomista Irving Fisher na parę tygodni przed czarnym czwartkiem, poprzedzającym Wielki Kryzys powiedział: „ceny akcji osiągnęły coś, co wygląda jak permanentny płaskowyż.

Dość szybko okazało się, że to tylko myślenie życzeniowe.

Jak będąc żabą nie wpaść w pułapkę zastawioną przez skorpiona? Czyli jak nie wpaść w pułapkę myślenia życzeniowego w IT?

Zmienić myślenie.

I zamiast upierać się przy wizji „optymistycznego scenariusza” odwołać się do dowodów i racjonalności.

Renata W.Lewicka – od kilkunastu lat pomagam klientom przebrnąć przez proces tworzenia i negocjowania umów. Specjalizuję się w prawie związanym z nowymi technologiami oraz prawie autorskim.http://www.legalcoffee.pl/o-mnie/