Sekrety umów IT – na co zwracać szczególną uwagę, podpisując umowy IT?

To oczywiste, że przy podpisywaniu umów IT niezastąpiona jest pomoc prawna, jednocześnie istnieje również szereg elementów stricte biznesowych, na które warto zwrócić uwagę. To szczególnie istotne właśnie w przypadku cyfrowych transformacji, bowiem to tu najczęściej oczekiwania projektowe rozmijają się z rezultatami. Wielu przedsiębiorców mierzy się z rozczarowaniem po odbiorze systemu IT, kiedy rzeczywistość nie odpowiada początkowym wyobrażeniom. Najczęściej – powołując się na zapisy umowy – usiłuje się wówczas wyegzekwować poprawki od kontrahenta. Niestety, w wielu sytuacjach umowa wspiera raczej wykonawcę, a nie zamawiającego.

Elementy biznesowe w podpisywaniu umów IT

Suma doświadczeń z pracy przy kilkudziesięciu projektach cyfrowych transformacji o skali wdrożeń od kilkudziesięciu tysięcy do kilkunastu milionów złotych pozwoliła mi na sformułowanie kluczowych elementów biznesowych, na które warto zwrócić uwagę, podpisując umowę IT. Uczestniczyłem w tych projektach zarówno po stronie zamawiającego, jak i konsultanta oraz wykonawcy. Uważam, że podstawą do realizacji umowy IT z sukcesem jest skuteczne zarządzanie projektami.

Przed podpisaniem jakiejkolwiek umowy IT należy dobrze rozumieć:

• jaki jest zakres tego przedsięwzięcia
• sposób jego prowadzenia.

Jeśli w którymkolwiek momencie przed podpisaniem umowy pojawia się uczucie niepewności odnośnie do rezultatów – daj sobie przestrzeń na zastanowienie. Nigdy nie podpisuj umowy IT pod presją – zwłaszcza gdy wykonawca stosuje taktyki negocjacyjne i usiłuje wymusić szybkie podjęcie decyzji. Czasami – szczególnie we współpracy z dużymi korporacjami – faktycznie pewne wydarzenia czy okresy, np. koniec roku, mogą narzucać określone ramy procesowania umowy. Najczęściej jednak jest to presja, która w końcowym rozrachunku działa na Twoją niekorzyść.

Sposób realizacji projektu

W największym uproszczeniu możesz pracować w ramach jednego z dwóch założeń, które zostanie opisane w Twojej umowie wdrożeniowej:

Współcześnie dostawcy IT raczej będą Cię przekonywać, że projekt powinien być prowadzony „zwinnie”, w modelu Time & Material, bowiem tego typu wdrożenia dają Ci większą elastyczność i kończą się wyższą satysfakcją interesariuszy. To wszystko, co do zasady, jest prawdą – pod warunkiem spełnienia się jednocześnie dwóch krytycznych czynników: 

1. dostawca jest profesjonalistą i faktycznie potrafi stosować metody zwinne.  
2. Osoba prowadząca projekt ze strony Twojej firmy również jest profesjonalistą w tym zakresie i dobrze wcieli się w rolę tzw. właściciela produktu, czyli osoby zarządzającej backlogiem projektu (uporządkowaną listą zadań, funkcji i wymagań, które mają zostać zrealizowane w ramach projektu). 

Ze spełnieniem obu tych warunków bywa różnie, często do tego nie dochodzi. MŚP współpracują raczej z małymi firmami – zdarzają się braki w wiedzy i umiejętnościach po stronie liderów projektów, a jednocześnie najczęściej nie ma czasu i przestrzeni na inwestycję w wiedzę o zwinnym zarządzaniu projektami dla swojego zespołu. Taka mieszanka nieprzygotowanego dostawcy i nieprzygotowanego zamawiającego kończy się w projektach zwinnych katastrofą.

Dlatego, jeśli czujesz, że możesz być w takiej sytuacji, metody przewidywalne z dobrze przeprowadzoną analizą przedwdrożeniową mogą być dla Ciebie dużo lepszym rozwiązaniem. Stracisz elastyczność, ale zyskasz łatwość zapisania w umowie biznesowej konkretnych wymagań i oczekiwań wobec swojego partnera.Jeśli zdecydujesz się na pracę w modelu Time & Material, to najczęściej trafi Ci się jeden z trzech typów umów.

Zadbaj o to, by sposób rozliczania pracy był wyraźnie zapisany w umowie. Jeśli wybierzesz Fixed Price, to w umowie koniecznie uwzględnij szczegółowy zakres dostarczanych funkcji oraz kryteria ich odbioru (patrz też punkt „zakres projektu”). W wersji Time & Material możesz pozwolić sobie na pewną elastyczność – zdefiniować jedynie np. wizję projektu oraz główne oczekiwania (wraz z kryteriami ich akceptacji), a dalej „otwierać drzwi po kolei”.

Są dwa możliwe wyjścia z tej sytuacji – albo masz świetnego właściciela produktu, który będzie umiał priorytetyzować zakres i usuwać mniej ważne oczekiwania na rzecz tych ważniejszych, co utrzyma budżet projektu w ryzach, albo czeka Cię jego przekroczenie. Branża tech jest pod tym kątem bezwzględna – im mniej wiesz na starcie, tym więcej dowiesz się w trakcie trwania projektu. 

Zakres projektu

Projekty IT są wyjątkowo trudne, ponieważ są złożone. Bardzo łatwo tu o wzajemne niezrozumienie, szczególnie jeśli w komunikacji używa się ogólnych zwrotów typu: „wygodne”, „użyteczne”, „zgodne ze standardami branżowymi”. Propozycja współpracy w projekcie IT często wiąże się z imponującym zestawem obietnic. Wyobraźmy sobie ofertę na wdrożenie „zintegrowanego obiegu dokumentów”. Co dokładnie oznacza to określenie? Które dokumenty i procesy zostaną włączone do systemu, a które pozostaną poza jego zakresem?

Niedostateczne zrozumienie tych aspektów może prowadzić do poważnych problemów w trakcie realizacji projektu. W modelu Time & Material prawdopodobnie osiągnie się zamierzony cel, ale koszty mogą zaskoczyć. Z kolei w modelu Fixed Price może uda się utrzymać kontrolę nad wydatkami, ale efekt może okazać się niezadowalający.

Nie przejmuj się różnymi sprytnymi sztuczkami, które dostawcy będą stosować, aby udowodnić Ci, że to nie jest przedmiot umowy. Będą to robić, często oddziałując bezpośrednio na Twoje ego, próbując pokazać Ci, że nie znasz się albo na oprogramowaniu, albo na zwinnych projektach. Nie martw się – nie musisz się znać „w ich oczach”, za to musisz czuć, że umowa zabezpiecza Twoje interesy i otrzymasz to, czego potrzebujesz.

W tej części skupię się szerzej na modelu Fixed Price, ale to nie znaczy, że zagadnienia te w ogóle nie dotyczą umów typu Time & Material. Nawet jeśli zgadzasz się na to, że projekt będzie miał tylko „ogólną wizję” oraz estymację budżetu, a nie pełny budżet, i robisz to świadomie, to nadal umowa powinna Ci zagwarantować wiedzę. Między innymi o tym, w jaki sposób będzie powstawać wartość, np. w jaki sposób realizowane będą sprinty, ile potrwają, kiedy przysługuje prawo zgłaszania uwag, za co płaci klient, a za co wykonawca. Co w przypadku, gdy w sprincie będą błędy –  zapłaci za nie klient czy wykonawca? 

Odpowiedzi na te pytania będą bardzo różne, ale musisz je rozumieć. A zatem, chociaż w umowach typu Time & Material zakres będzie z reguły znacznie bardziej ogólnie zdefiniowany, to kluczowe jest, by dokładnie wiedzieć, w jaki sposób będą wykorzystywane Twoje pieniądze i jaki masz na to wpływ. Co więcej, do ogólnej definicji wizji z takiej umowy, zastosowanie będzie miała większość uwag przedstawionych poniżej.

Otrzymując ofertę na produkt, upewnij się, że jednoznacznie definiuje ona zakres projektu. W branży IT często można spotykać się z ofertami, które są przepełnione skomplikowanym żargonem i nie zawsze jasnymi oczekiwaniami. Ważne, aby pamiętać, że skomplikowany język nie stanowi o jakości oferty. Jeśli napotkasz na terminy lub zapisy, które są dla Ciebie niejasne lub nie rozumiesz, czego partner od Ciebie oczekuje, nie wahaj się pytać o wytłumaczenie, nawet jeśli oznacza to zwrócenie się o pomoc do znajomych z branży.

Kluczowe jest zdefiniowanie kryteriów akceptacji, czyli konkretnych warunków, które muszą być spełnione, aby projekt, zadanie czy funkcja zostały uznane za zakończone. Mają one fundamentalne znaczenie w zarządzaniu projektami, ponieważ definiują oczekiwania i stanowią jasny punkt odniesienia dla wszystkich stron.

Pomagają one unikać nieporozumień i zapewniają, że wszystkie strony mają tę samą wizję produktów projektu. Umowa powinna jednoznacznie definiować sposób i zasady tworzenia kryteriów akceptacji w trakcie projektu, a w przypadku gdy są one już znane na starcie, to powinny być częścią specyfikacji projektu. Kryteria są kluczowe, by uniknąć rozczarowania rezultatami, które odbiegają od początkowych wyobrażeń. Również wizualizacje projektu powinny być czytelne i jasne powinno być, jak mają być zaimplementowane w rozwiązaniu IT. Warto zatem ustalić, czy wizualizacje i makiety są „drogowskazem”, czy projekt ma być ich precyzyjną reprezentacją.

Pamiętaj również, że możesz działać hybrydowo. Również w umowie typu T&M możesz wcześniej przeprowadzić szczegółową analizę projektu, by zrozumieć funkcje i kryteria akceptacji, zaplanować kolejne sprinty i poznać koszt rozwiązania. Zachowasz wtedy przejrzystość i bezpieczeństwo metod przewidywalnych oraz możliwość elastycznego zmieniania zakresu metod zwinnych (w praktyce w trakcie trwania projektu nowe funkcje będą zastępować te mniej potrzebne z pierwotnej analizy). 

Niestety to będzie zdecydowanie najdroższe podejście do realizacji projektu, ponieważ trzeba przeprowadzić analizę przedwdrożeniową i w przypadku niewystarczająco profesjonalnego właściciela produktu może pojawić się problem przekroczenia budżetu. Z praktyki biznesowej mogę jednak powiedzieć, że tak prowadzone projekty – hybrydowo z dobrą analizą zaczerpniętą z metod przewidywalnych (czasami uproszczoną), a potem zwinną realizacją z profesjonalnym właścicielem produktu – przynosiły najlepsze efekty biznesowe i najwyższą satysfakcję interesariuszy. Niestety nie każdą firmę będzie stać na pracę w takim podejściu.

Komunikacja, metodyka i precyzowanie wymagań obu stron

Projekt to nie tylko zakres działań podlegających realizacji, ale również codzienna współpraca. Ważne jest, aby w umowie IT szczegółowo opisać nie tylko zakres projektu, ale również metodę komunikacji:

• jak często będą odbywać się spotkania,
• jakie kanały komunikacji będą wykorzystywane (najlepiej umówić się na konkretne narzędzia i omówić zasady ich używania)
• kto będzie odpowiedzialny za poszczególne aspekty projektu. 

Bardzo ważne jest, aby czytelnie przedstawić organizację projektu oraz to, jak będzie prowadzone raportowanie w projekcie, szczególnie dotyczące wykorzystywania budżetu i czasu. W trakcie trwania projektu dobra komunikacja to również regularne raportowanie postępu prac i wczesne sygnalizowanie potencjalnych problemów. Dzięki temu obie strony mogą lepiej zarządzać oczekiwaniami i efektywnie reagować na zmieniające się warunki.

Zwracam uwagę, że należy szczególnie uważać na potencjalne „ukryte koszty” i „ukryte terminy” w ofertach i umowach. Jest to częsta praktyka, która może zwiększyć ogólny koszt projektu. Koniecznie zwróć uwagę, czy Twój zespół jest w stanie reagować w terminach podawanych przez wykonawcę i jakie są konsekwencje niewywiązywania się. Z reguły, gdy przychodzi do egzekucji kar umownych, okazuje się, że klient ma z nimi problem, bo nie realizował postanowień umowy o wzajemnej terminowej współpracy w trakcie projektu. Nie bój się negocjować terminów Twoich reakcji. Lepiej usłyszeć na negocjacjach, że jest się „mało zwinną firmą”, niż mieć potem teoretycznie dobrą, a w praktyce nieegzekwowalną umowę.

Koniecznie też zwróć uwagę na wszelkie prace „przerzucane” na klienta. Bardzo niewinnie brzmiący zapis: „klient dostarczy wszystkie dane w postaci XYZ do migracji wygenerowane ze swoich systemów” może oznaczać kilkaset godzin dodatkowej pracy dla Twojej załogi. Nie mówię, że masz się na to nie zgodzić (szczególnie że często tego typu warunki mogą istotnie obniżyć koszt umowy), ale miej świadomość realnych nakładów pracy, które będą niezbędne po Twojej stronie. To również są koszty.

Na koniec jeden z moich ulubionych aspektów sprawdzania umów IT, który bardzo łatwo weryfikuje profesjonalizm wykonawcy. Koniecznie zapytaj swoich partnerów, w jakiej metodyce będą pracować i jakie są oczekiwania wobec Ciebie. Najlepiej niech wykonawca prześlę Ci metodykę/zasady projektowe, które będzie wykorzystywać. Zachowaj czujność, jeśli widzisz w umowie zapisy typu: „metodyka własna oparta o zasady agile”. To niestety nic nie znaczy i już kilka razy zdarzyło mi się, że wykonawca nie był w stanie opowiedzieć, jak dokładnie będzie przebiegać praca w projekcie, a na prośbę o wysłanie metodyki reagował po kilku-kilkunastu dniach. To powinno zapalić u Ciebie pomarańczowe światło. Wykonawca, który faktycznie ma „własną metodykę”, powinien od razu przesłać do Ciebie jej opis, a ten, który korzysta z gotowych standardów, bez problemu, a nawet z przyjemnością opowie, w jaki sposób pracuje.