Umowy IT a model agile

Problem pojawia się jednak, w przypadku gdyby strony chciały umawiać się na wynagrodzenie ryczałtowe. W takim przypadku niedoskonałą metodą mogą być rygorystyczne egzekwowanie zasady akceptacji przyrostowej, czyli poszczególnych etapów projektu, oraz rezygnacja z opcji odmowy akceptacji całego rozwiązania na zakończenie projektu. Niesie to oczywiście określone ryzyko i wymogi. W szczególności wymóg bardzo głębokiego zaangażowania zamawiającego w cały projekt, aby uniknąć zaskoczenia rzeczywistym kształtem budowanego rozwiązania.

Kolejną kwestią jest ujęcie zasad odpowiedzialności. Przy bardzo blisko pracującym ze sobą zespole oraz generalnej zasadzie ograniczania produkcji dokumentów może być czasami niezmiernie trudne ustalenie, kto i jaką decyzję projektową podjął, a co za tym idzie - kto ponosi odpowiedzialność za jej ewentualne negatywne skutki. W takiej sytuacji trudne okazuje się egzekwowanie choćby kar umownych - jeśli zostały zastrzeżone. Ich ewentualna dotkliwość staje się fikcją, kiedy nie sposób ustalić, np. kto odpowiada za zwłokę w projekcie.

Zobacz również:

  • 9 inwestycji, które CIO powinni przeprowadzić przed nadejściem recesji
  • Zespoły wielofunkcyjne: Nowy imperatyw IT
  • Architektura IT w postpandemicznym świecie

Współdziałanie zamawiającego

Tutaj dotykamy zagadnienia kluczowego dla umów IT w ogóle, a dla umów w projektach agile w szczególności, czyli współdziałania zamawiającego. W przypadku klasycznego projektu zakres wymaganego współdziałania przy wykonaniu zobowiązania (art. 354 § 2 Kodeksu cywilnego) wyznacza treść umowy. Współdziałanie powinno być realizowane w sposób "odpowiadający celowi społeczno-gospodarczemu zobowiązania (tutaj - umowy) oraz zasadom współżycia społecznego, a jeżeli istnieją w tym zakresie ustalone zwyczaje - także w sposób odpowiadający tym zwyczajom". W praktyce projektu IT po stronie zamawiającego - obok wymogów w postaci zapewnienia właściwych licencji, miejsca i środków do pracy w przypadku umowy wykonywanej u klienta - kluczowe są zawsze elementy kooperacji, związane z dostarczaniem informacji i podejmowaniem decyzji.

W przypadku Agile te dwa ostatnie wymogi stają się szczególnie ważne. Precyzyjne ustalenie i przestrzeganie procedur zarządzania projektem po obu stronach staje się kluczowe. Nawet w "zwykłym" projekcie IT jego kontynuacja napotyka na istotne problemy przy opóźnieniach w komunikacji i procesie decyzyjnym. W przypadku projektów typu Agile opóźnienia tego rodzaju niweczą jednak podstawowy atut tego podejścia - szybkość i elastyczność. Dodatkowo pojawiają się pytania o wzajemną odpowiedzialność stron za jakość i sprawność pracy członków zespołu. Zaletą podejścia Agile ma być właśnie sprawne podejmowanie decyzji bez oczekiwania na akceptację na wyższych szczeblach. Zwykle oznacza to umieszczenie w zespołach projektowych osób ze stosownymi kompetencjami decyzyjnymi.

Podsumowując, dotychczasowe standardy umowne wymagają uważnego stosowania w przypadku projektów typu Agile i mogą jak najbardziej stanowić podstawę do prac, ale wymagają uważnego i miejscami dość ostrożnego stosowania.

Radosław Nożykowski jest adwokatem współpracującym z kancelarią Baker&McKenzie.


TOP 200