Umowy IT a model agile

Mimo że pewnego rodzaju standardowe wzory umów z dostawcami rozwiązań IT zostały już wypracowane, to powstaje pytanie, czy pozostają one w mocy w przypadku nowszych metod prowadzenia projektów Agile Management.

Czasami pojawia się określenie, że w sferze umów IT pewne rozwiązania są już "standardem". Jest to często prawda i trudno z nią polemizować. Przykładowo standardem coraz częściej jest model umowy o dzieło (ewentualnie umowy mieszanej) dla typowego kontraktu wdrożeniowego przewidującego rozwiązanie pisane i budowane od podstaw. Nie można jednak powiedzieć, że jeden wzór umowy - wymieniony standard - można zastosować we wszystkich spotykanych konfiguracjach projektowych.

Nowe podejście do projektów i umów

Sytuacje te mogą wahać się od umowy "pod klucz" - rozwiązania pisane od podstaw lub oparte na parametryzacji i dostosowaniu oprogramowania bazowego - gdzie odpowiedzialność jest przerzucona na dostawcę, poprzez koncepcje mieszane, aż do umów, w przypadku których dostawca jest jedynie konsultantem (choćby tylko poprzez udostępnienie swoich zasobów kadrowych klientowi). W tym ostatnim przypadku zarządzanie projektem oraz zasadnicza odpowiedzialność pozostają po stronie zamawiającego. Czy jednak dotychczas wypracowane wzory umów pozostają w mocy w przypadku "zwinnych" metod prowadzenia projektów?

Zobacz również:

Jakkolwiek bowiem umowy IT - głównie wskutek importu wzorów z bardziej rozwiniętych rynków - zasadniczo się ujednolicają, tak nowe rozwiązania w prowadzeniu projektów IT stawiają nowe wyzwania, jak napisać prawidłową i adekwatną do projektu umowę. Pierwszym jest sfera weryfikacji, czy projekt osiągnął założony przez strony cel projektu. Kluczowym elementem jest ograniczenie - lub całkowite wyeliminowanie - tworzenia dokumentacji projektowej.

Dotyczy to zwłaszcza opisu docelowego, planowanego kształtu rozwiązania. Tutaj pojawia się oczywisty problem, w jaki sposób dokonywać tej weryfikacji, skoro miernika, uprzednio opracowanego, nie ma lub jest on mocno uogólniony. Powyższa sytuacja staje się wyzwaniem zarówno dla osoby piszącej umowę, jak i dla osób, które będą ją wykonywać. W jaki zatem sposób, co w sumie najistotniejsze, definiować wady rozwiązania? To ostatnie jest kluczowe, aby uniknąć sporu co do prawidłowości wykonania umowy, jak również aby uniknąć problemów na etapie serwisowania.

W projektach Agile nie jest już możliwe bezkrytyczne zastosowanie typowe formuły o zgodności rozwiązania z uprzednio przygotowaną dokumentacją. Oparcie się na - siłą rzeczy subiektywnym - zadowoleniu zamawiającego z dostarczonego rozwiązania prowadzić będzie do niebezpiecznego przechylenia się przewagi na rzecz zamawiającego, w sytuacji gdy cena jest sztywno określona (ryczałt). Sytuacja jest oczywiście odmienna, gdy mamy do czynienia z wynagrodzeniem typu time & material (czas i koszty). Tu teoretycznie klient może w nieskończoność przedłużać proces tworzenia rozwiązania, a nie stanowi to aż tak istotnego problemu dla dostawcy, skoro wynagrodzenie jest uzależnione od przepracowanego czasu.


TOP 200