Umowy wdrożeniowe systemów informatycznych w metodyce zwinnej (Agile) są relatywnie młodymi tworami w polskim systemie prawnym. O ile tradycyjne projektowanie usług IT jest powszechnie znane i rozumiane, o tyle już tworzenie umowy w oparciu o nowoczesne metody produkcji i zarządzania przychodzi często z trudem. Wynika to między innymi z tego, iż przepisy prawa od dawna znają tradycyjny model dostarczania oprogramowania (Waterfall). Tym samym prawo zdążyło się dorobić nie tylko odpowiednich przepisów, ale i bogatych komentarzy i orzecznictwa. W praktyce oznacza to, że zamawiając usługę w systemie Waterfall moglibyśmy w zasadzie podpisać najprostszą umowę, a ta „domyślna” baza prawna resztę regulacji dostarczy za nas.
Tymczasem w przypadku wdrożeń Agile nie mamy tego luksusu. Po pierwsze jest to pojęcie jest wciąż relatywnie mało znane prawnikom. Pełnomocnicy częstokroć w ogóle nie wiedzą jak do tematu podejść. Na dodatek prawo w przypadku braku odpowiedniej umowy stawia wykonawcę w dość niekorzystnej pozycji. Rolą dobrego prawnika jest zatem między innymi takie stworzenie umowy wdrożeniowej, aby wszystkie te niedoskonałości wyprostować i zabezpieczyć sprawną współpracę.
Na pierwszym miejscu, w mojej ocenie, powinniśmy postawić język sporządzenia umowy. Mam tutaj na myśli zarówno przejrzyste, proste definicje pojęć, jak i logiczną konstrukcję samego dokumentu. O ile jeszcze w środowisku IT, startupów, software house, czy freelancerów metodyka Agile i jej terminologia jest znana i zrozumiała, o tyle klientom i ich prawnikom niejednokrotnie jest zupełnie obca. A kiedy prawnicy klientów czegoś nie rozumieją, to (z dobrze pojętej ostrożności) nie wyrażają na nią zgody i zaczynają wywarzać otwarte drzwi, próbując „naprawić” dokumentację.
Powyższe stanowi oczywiście spore uproszczenie z mojej strony, jednak nie jestem w stanie zliczyć z pamięci wszystkich sytuacji, kiedy prawnik kontrahenta blokował podpisanie umowy tak długo, aż wszystkie „podejrzane” w jego ocenie zapisy zostały wyjaśnione i przenegocjowane. Finalnie podpisując praktycznie to samo co w pierwszym drafcie. Oczywiście takie negocjacje przekładają się na ogromne koszty operacyjne, prawne i zwykłą frustrację projektem. Jeżeli mamy przed sobą wdrożenie, które ma trwać 3 miesiące, a przez 4 tygodnie przerzucamy się z drugą stroną propozycjami definicji sprintu, to nietrudno o zmęczenie u nas i u zespołu. O kosztach przestoju, rzędu dziesiątek, lub setek tysięcy złotych nie wspomnę.
Do tworzenia dobrej umowy wdrożeniowej dobrze jest podejść jak do pisania ciekawego opowiadania. Tak, aby ktoś kto nie zna się zupełnie na temacie był w stanie zrozumieć tę treść bez specjalnego wysiłku.
Inna szalenie ważna kwestia przy wdrożeniach to decyzyjność i komunikacja. W świetle prawa, osobami wyłącznie uprawnionymi do zmiany warunków umowy takich jak termin, wynagrodzenie, czy zakres pracy są osoby upoważnione do reprezentacji spółki (lub działalności gospodarczej). W praktyce jest to najczęściej zarząd, lub prokurent.
Z samej definicji Agile, kluczowe z punktu widzenia prawa problemy takie jak „dokładnie co” i „dokładnie za ile”, są jednak nie do ustalenia w pierwszym tygodniu. Obie te kwestie definiują się później w czasie wyłaniania się produktu w kolejnych iteracjach. Jest to zjawisko dobrze znane wszystkim, którzy kiedykolwiek pracowali scrumowo. I teoretycznie, zgodnie z przepisami, decyzje odnośnie tych kwestii powinni podejmować prezesi i prokurenci w formie pisemnej. Jest to oczywiście zupełnie niepraktyczne i w rzeczywistości nierealne. Aby uniknąć ryzyka gospodarczego, lub paraliżu decyzyjnego powinniśmy zatem zadbać o odpowiednie uregulowanie tej kwestii. Dobry prawnik powinien zadbać, aby wskazać osoby, które są uprawnione do podejmowania decyzji (PM, Scrum Master) wraz z zakresem w jakim decyzje mogą być przez nie podejmowane.
To jednak nie wszystko. W świetle przepisów, odpowiednią formą zmiany umowy jest jedynie ta dokonywana na piśmie. Tymczasem w realiach wdrożenia jest to zupełnie niepraktyczne i anachroniczne. Dlatego niezbędne jest wskazanie wszystkich wiążących kanałów komunikacji, ze szczególnym określeniem tych elektronicznych. W szczególności jeżeli w gre wchodzą komunikatory w rodzaju Jiry, czy Slacka. Ponadto jeżeli formą komunikacji jest telefon bądź inna komunikacja głosowa to na pewno dobrze zastrzec, że wszystkie takie ustalenia powinny być potwierdzane w formie elektronicznej lub pisemnej.
Nie ma chyba bardziej zapalnego punktu w negocjacjach umów wdrożeniowych niż tryb odbioru wykonanych systemów IT. Tradycyjne podejście do odbioru dzieła następuje oczywiście po wykonaniu całego zamówienia. Tylko jak tutaj ustalić gdzie kończy się, a gdzie zaczyna praca nad systemem, który cały czas żyje, a w każdej kolejnej iteracji pojawiają się (lub znikają) kolejne funkcjonalności. Jak stwierdzić, czy system wykonano prawidłowo, jeżeli wizja klienta jest tylko luźną wskazówką tego, dokąd za pewien czas chcemy dotrzeć, a po drodze może pojawić się jeden lub więcej pivot.
Optymalnym wypracowanym przeze mnie do tej pory rozwiązaniem jest odbieranie prac w formie odbiorów częściowych po zakończeniu każdego Sprintu. W taki sposób pozbywamy się niepewności co do tego, czy poszczególne prace były wykonywane prawidłowo oraz czy błędy są dla całego wdrożenia istotne czy nie. Przy tym możemy się też pokusić o stosowanie dodatkowych mechanizmów usprawniających, takich jak krótkie terminy sprawdzenia przez klienta, czy milczące odbiory. W związku z tym, że odbiór następuje w etapach, minimalizuje się ryzyko po obu stronach i tym samym jest łatwiejsze do zaakceptowania.
Kolejna bardzo ważna kwestia przy tworzeniu umów na wdrożenie systemu informatycznego to sposób określania wynagrodzenia. O ile najbardziej korzystnym dla software house rozwiązaniem jest oczywiście stosowanie rozliczenia wg. stawki godzinowej, o tyle dla zamawiającego jest to już trudny orzech do zgryzienia. Przy obecnym poziomie wynagrodzeń za usługi IT podpisując takie zobowiązanie do rozliczenia in blanco za przepracowane godziny, klient potencjalnie wystawia się na ryzyko finansowe rzędu dziesiątek lub setek tysięcy złotych miesięcznie. Nic więc w tym dziwnego, że wielokrotnie stara się on forsować wynagrodzenia ryczałtowe.
Dobrym rozwiązaniem tego problemu jest zastosowanie limitu godzin (lub dni) pracy nad projektem wraz z estymacją czasu niezbędnego na wykonanie konkretnych zadań. Z jednej strony przed przystąpieniem do wykonania danej funkcjonalności dajemy klientowi obraz czasu jaki może zająć dostarczenie pożądanych funkcjonalności, z drugiej chronimy własny interes finansowy i osiągamy zrozumienie co do możliwych realnych kosztów.
Najczęstszą wątpliwością, która pojawia się tutaj ze strony klientów, to wiarygodność przedstawionych podsumowań godzinowych. Dobrze sprawdza się w takim wypadku praca w odcinkach testowych jeszcze na etapie negocjacji, gdzie klient zleca niewielkie taski (na kilkadziesiąt godzin), a my sprawie wykonujemy je i szybko rozliczamy. W ten sposób możemy oswoić nieco klienta z taką formą wynagrodzenia. Dobrze jest również stosować programy dokładnie śledzące czas pracy poświęcony na poszczególne zadania przez zespół. Szczegółowe informacje pozwalają na budowanie większego zaufania iż rozliczenie zostało sporządzone rzetelnie.
Klauzula ta nie jest stricte związana z wdrożeniem, ale przez jej znaczenie dla software house jako biznesu dobrze jest mieć ją na uwadze. Otóż ogromnym zagrożeniem przy długotrwałym wdrożeniu jest niebezpieczeństwo przejęcia zespołu pracującego nad nim przez danego klienta. Nierzadko po wielu miesiącach współpracy u kontrahenta zapala się wątpliwość, dlaczego w zasadzie ma płacić spore pieniądze za tworzenie swojego systemu zewnętrznemu wykonawcy, jeżeli może po prostu kupić cały, dobrze funkcjonujący team i rozwijać go dalej wewnątrz.