Na stronie portalu analizawymagań.pl ukazał się bardzo interesujący i wartościowy wpis: wywiad z prawnikiem, Łukaszem Węgrzynem. Zaczyna się tak:
Jakie są najczęstsze przyczyny problemów w umowach wdrożeniowych i jakie są ich skutki z punktu widzenia sporów sądowych na polskim rynku IT?
Stosunkowo najczęstszym powodem sporów jest legendarny już zakres, a konkretnie trudność w odpowiedzi na pytanie o co tak naprawdę się umówiliśmy.
Powodów takiego stanu rzeczy jest wiele. Jednym z nich jest między innymi niewłaściwie wykonana analiza przedwdrożeniowa. Analiza to jeden z podstawowych załączników umowy wdrożeniowej, wyznaczający jej zakres, a zatem to, co ma zostać w wyniku podpisania umowy zrealizowane.
Nierzadko analizy przedwdrożeniowe posługują się generalnymi pojęciami lub pojęciami, których znaczenie nie jest wystarczająco jasno i precyzyjnie określone. Taka sytuacja skutkuje z kolei dużą dowolnością interpretacyjną, a tym samym powoduje, że strony umowy wchodzą w spór co do właściwego brzemienia konkretnych zapisów analizy, które decydują o zakresie umowy, czyli o tym, co zostanie lub nie zostanie w wyniku umowy zrealizowane.
Kolejna przyczyna problemów nie jest związana z tym ?CO? mamy zrobić, ale ?JAK? to mamy zrobić. W praktyce sprowadza się do sytuacji, w której strony niewystarczająco jasno i precyzyjnie opisały w umowie poszczególne etapy przebiegu wdrożenia. To bardzo częsty problem, w rezultacie którego strony zaczynają się przerzucać odpowiedzialnością co do realizacji konkretnych działań niezbędnych dla właściwej, a co najważniejsze efektywnej realizacji projektu wdrożeniowego. Stad już tylko krok do eskalacji sporu i całkowitej klęski projektu. (Źródło: Rola analizy w umowie wdrożeniowej- wywiad z Łukaszem Węgrzynem)
W powyższym cytacie (a gorąco polecam cały wywiad) wytłuściłem kilka kluczowych tez.
Zakres projektu to faktycznie klucz, przede wszystkim MUSI być zamknięty. Zaraz odezwą się zwolennicy zwinnego Agile.. ale pojęcie “zamknięty zakres projektu” to nie żaden wodospad, zamknięty zakres projektu oznacza tylko i wyłącznie to, że istnieje (zawarto w umowie) kryteria pozwalające stwierdzić, że (czy?) umowę wykonano.
Niewłaściwie wykona “analiza przed-wdrożeniowa” to nic innego jak dokument mający wady opisane wyżej i poniżej w dalszej części.
Bardzo ważne: nie tylko CO ale także JAK. Z [[BABoK]] wiemy, że poza tak zwanym opisem produktu jako czarnej skrzynki (nasze CO chcemy), warto wykonać także opis tak zwane białej skrzynki czyli opisać “Jak to ma działać”. Bez tego skazujemy się na masę niejasności brak kryterium odbioru (co testować??).
Celem moim jest dzisiaj przede wszystkim zachęcenie Państwa do lektury tego wywiadu i tylko troszkę uzupełnienie i słów Pana prawnika. Wywiad kończy się zaś tak:
Proszę o 5 kluczowych rad dla osób, które zajmują się przygotowywaniem umów wdrożeniowych.Z oczywistych względów będzie to wysokopoziomowe spojrzenie.
1.Po pierwsze im jaśniej i prościej tym lepiej.
2.Po drugie nie tylko ?CO? ale również ?JAK.
3.Po trzecie właściwy opis procedur współdziałania stron. Nie zostawiajmy szarych stref, względem których trudno określić która ze stron jest za nie odpowiedzialna.
4.Po czwarte kary umowne powinny stymulować, nie paraliżować. Dobrze opisany mechanizm kar umownych, oparty na obiektywnie wyliczalnych parametrach to naprawdę rzadkość w kontraktach wdrożeniowych.
5.I po piąte, piszmy kontrakty które odpowiadają założeniom biznesowym. Tak co do zakresu projektu, jak i sposobu jego realizacji. W przeciwnym wypadku przygotujmy się na szuflady pełne umów.
(Źródło: Rola analizy w umowie wdrożeniowej- wywiad z Łukaszem Węgrzynem)
Dodam od siebie:
1. umowa nie może być niezrozumiała, żadne tłumaczenia i branżowym (tak prawniczym jak i informatycznym) języku nie są dopuszczalne, w razie potrzeby słownik pojęć aczkolwiek ja osobiście preferuję jasne wysławianie się i definiowanie listy trudnych słów i korzystanie z nich w umowie.
2. Z mojego doświadczenia: nie lista wymagań na setki pozycji a projekt, dokładnie tak jak zamawia się budowle: króki opis i rysunki techniczne (w IT skomentowane diagramy UML).
3. Podstawa to plan komunikacji w projekcie i narzucone narzędzia (nie mail a współdzielone na równych prawach repozytorium dokumentów).
4. Wysokie kary umowne budują wyłącznie asekuracyjne, pozbawione samodzielnego działania projekty, kończące się w styku “każdy zrobił co miał zrobić tylko, że nie nie mamy”. Osobiście preferuję umowy bez żadnych kar umownych ale z prawem wypowiedzenia przez każda ze stron w dowolnym momencie za rozliczeniem prac wykonanych.
5. Umowa powinna być relatywnie prosta, oparta na celach biznesowych wdrożenia, każdy projekt to odkrywanie problemów w toku prac, biznesowy cel projektu bywa czasem jedynym “światełkiem w tunelu”.
