Battle for Agility

Umowa fixed price w duchu agile

December 10th, 2008 Marcin Niebudek

Nie tak dawno powstała grupa, której celem jest wypracowanie pewnego szablonu kontraktu na wykonanie aplikacji wg metodyk agile.

Tak faktycznie w Polsce cały czas ciężko uciec od kontraktów typu fixed price ze względu na pewne przyzwyczajenia i strach przed innym rodzajem umowy, która nie zabezpieczałaby odpowiednio klienta (chociaż to raczej pobożne życzenie z tym zabezpieczeniem). No więc zamiast z tym walczyć może należy się z taką sytuacja “zaprzyjaźnić”. Żeby po raz kolejny nie wdawać się w pustą dyskusję na temat tego jakie to fixed price jest złe, postaram się tym razem zamieścić fragmenty faktycznych zapisów z umów jakie sami stosujemy u siebie. A więc podyskutujmy o konkretach…Na początek sekcja dotycząca trybu wykonania projektu:

TERMIN I SPOSÓB WYKONANIA UMOWY

Strony zgodnie ustalają termin rozpoczęcia prac na dzień X a termin zakończenia prac na dzień Y.
Wykonanie umowy odbywać się będzie iteracyjnie, tj. w równych N tygodniowych etapach.
Po każdym etapie, począwszy od etapu nr 2, Zamawiający odbierze od Wykonawcy wykonane elementy Systemu oraz zgłosi uwagi i poprawki.
Przed każdym kolejnym etapem Zamawiający określi elementy, które powinny być zrealizowane przez Wykonawcę w kolejnym etapie w pierwszej kolejności uwzględniając swoje uwagi zgłoszone po odebraniu etapu poprzedniego.
Zamawiający może wprowadzić do zakresu projektu elementy nie przewidziane w załączniku nr 1. Pracochłonność nowych elementów zostanie oszacowana przez Wykonawcę i będą mogły one być zrealizowane w ramach niniejszej umowy bez zmiany wynagrodzenia, jeśli Zamawiający zrezygnuje z innych elementów o tej samej szacowanej pracochłonności. Uznaje się wtedy, że zakres projektu nie uległ zmianie. Nie ulega także zmianie termin ukończenia prac określony w pkt 1.
W przeciwnym wypadku, tj. kiedy Zamawiający wprowadzi do planu nowe elementy bez usuwania z planu innych elementów Systemu, wynagrodzenie Wykonawcy może wzrosnąć proporcjonalnie do pracochłonności nowo wprowadzonych do planu elementów. W takim przypadku zmianie może ulec także termin ukończenia prac określony w pkt 1.

Jest też sekcja:

PRAWA I OBOWIĄZKI STRON

a w niej taki oto punkt, który określa nic innego jak proporcjonalność zapłaty do wykonanej do danego momentu pracy oraz wprowadza swobodę zakończenia projektu przy osiągnięciu odpowiedniej wartości przez klienta:

Jeżeli wykonanie Systemu według zdefiniowanego w załączniku 1 zakresu okaże się niecelowe bądź jeżeli Zamawiający z przyczyn sobie wiadomych zrezygnuje z dalszego wykonywania umowy, Zamawiający będzie mógł odstąpić od niniejszej umowy za zapłatą odpowiedniej części wynagrodzenia za opracowanie Systemu na rzecz Wykonawcy, adekwatną do stopnia ukończenia Systemu.

I jeszcze może:

WYNAGRODZENIE

Wynagrodzenie płatne jest w transzach po każdych … odebranych przez Zamawiającego etapach, proporcjonalnie do stopnia ukończenia prac nad Systemem.
Wykonawca nie może żądać podwyższenia wynagrodzenia, jeżeli wykonał prace dodatkowe bez uzyskania zgody Zamawiającego na zasadach określonych w “TERMIN I SPOSÓB UMOWY”.

To nie są oczywiście wszystkie elementy umowy, ale pozostałe nie są tutaj interesujące bo zawierają raczej elementy standardowe nie związane z procesem agile w żaden sposób. Dodatkowo wyjaśnię tylko, że pojawiający się w powyższych punktach “załącznik nr 1″ (przecież każda dobra umowa musi taki załącznik zwierać :-) to nic innego jak lista user story z oszacowaniami w punktach (o tym jak taka listę do umowy budujemy w następnym poście).

Tym samym chciałbym zachęcić was do dyskusji na temat tego, co o takich zapisach myślicie? A może stosujecie inne, albo dodatkowe? Piszcie… a może uda się jakoś zebrać też i nasz polski sposób na kontrakt agile.

Kategorie: Agile dla managerów, Agile dla klientów, Relacje z klientem, Praktyki agile

(No Ratings Yet)

Loading ...

6 komentarzy Dodaj komentarz

1. ursus | December 11th, 2008 at 11:18

Masz projekt dla Telecomu - przetarg na fixed price. Zgłasza się 15 firm wybierany jest zawsze najtańszy z najlepszych. Klienta interesuje tylko końcowa cena, nie przyjmuje do wiadomości, że czegoś z zakresu możesz nie dostarczyć. Złożenie oferty z proponowaną umową podobną do tej, którą sugerujesz - od razu Cię dyskwalifikuje :(

Nie udało mi się jeszcze wynieść Agile na zewnątrz do poziomu kontraktu. Z zewnątrz dla klienta był zwykły kontrakt fixed price - fixed scope. Wewnętrzna organizacja zespołu to już inna bajka, ale to na ogół klienta nie interesuje.
2. maciej.zawadzkI@o2.pl | December 11th, 2008 at 11:49

Jestem bardzo ciekawy jak przy takich umowach wygląda właność kodu źródłowego. Mógłbyś przytoczyć jakies punkty które regulują prawa do źródeł i modyfikacji?
3. Jacek Laskowski | December 11th, 2008 at 12:14

“o tym jak taka listę do umowy budujemy w następnym poście” - już nie mogę się doczekać! Bardzo zwięźle przedstawiasz temat. Obyś posiedział jeszcze w hotelu, nie przez 1,5 tygodnia, ale np. 1 miesiąc (brrr, powiedziałem to na głos?! Oby się nie spełniło, co? ;-))
4. Marcin Niebudek | December 11th, 2008 at 21:13

@ursus
Doświadczeń z Telekomami nie mam, ale zauważ, że w tych zapisach nie ma mowy o tym, że cena jest nieznana. wręcz przeciwnie - jest fixed. Chodzi bardziej o uregulowanie w umowie zmian zakresu w trakcie projektu - bo tak faktycznie do tego się tylko sprowadza przy fixed price. Czym innym natomiast jest to, czy taki Telekom będzie chciał spojrzeć na coś tak obrzydliwego jak user story i jakieś tam punkty.

@maciek
No sprawa własności kodu wyglądała jak dotąd raczej normalnie, tzn. nie stosowaliśmy żadnych zapisów dotyczących stopniowego nabywania własności po każdej iteracji (bo jak rozumiem to jest intencją twojego pytania). Zwykle prawa majątkowe podlegają przekazaniu klientowi na koniec i wtedy stosujemy np. takie zapisy:
- Z dniem akceptacji ostatecznej wersji Systemu przez Zamawiającego, autorskie prawa majątkowe do elementów Systemu wykonanych przez Wykonawcę przechodzą na Zamawiającego.
- Razem z przeniesieniem autorskich praw majątkowych, na Zamawiającego przechodzi wyłączne prawo udzielania zezwoleń na wykonywanie autorskiego prawa zależnego.
- Przeniesienie autorskich praw majątkowych, z zastrzeżeniem prawa Wykonawcy do wynagrodzenia, następuje nieodpłatnie/odpłatnie.
Do tego dochodzi gwarancja i w czasie gwarancji klient nie ma np. prawa niczego zmieniać na własną rękę. Jeśli natomiast mówimy o zatrzymywaniu praw do kodu (albo do jego części - np. bibliotek bardziej ogólnego użytku) to wchodzimy w temat licencji i zapisy bywają różne, ale jak już pisałem to nie ma wiele wspólnego z agile.
5. Wiktor Kapanowski | January 15th, 2009 at 11:20

Marcin,

W mojej opinii ta umowa reguluje zarządzanie zmianą oraz prawa i obowiązki obu stron w iteracyjnym podejściu. Nie rozwiązuje ona moim zdaniem problemu fixed-price - pierwszy punkt określa datę zakończenia projektu (której pochodną jest wartość kontraktu). Skąd możesz wiedzieć przed rozpoczęciem projektu jakie będziesz miał velocity zespołu w danym projekcie, kiedy skończysz projekt i ile powinno kosztować?

Być może rozwiązaniem byłoby określanie w umowie przybliżonej daty zakończenia (np. między 1 września a 15 października), a po 5 iteracjach precyzowanie daty zakończenia, ale czy klient się na to zgodzi? Macie jakieś dobre pomysły lub doświadczenia w tym zakresie?
6. Marcin Niebudek | January 15th, 2009 at 12:01

To troche nie tak… umowa jest normalna, tzn. jest fixed-price i jest okreslony termin. Faktycznie zaczalem troche od tylu i musze sie pospieszyc z opisem jak dochodzimy do tego jaka jest cena dla takiego kontraktu i jaki jest termin.

Innymi slowy to co tutaj opisalem to jedynie usankcjonowanie umowa procesu prowadzenia zmian w zakresie projektu opierajac sie na backlogu z okreslonym rozmiarem punktowym. Mamy ustalony zakres, ustalona cene i termin. I te punkty mowia tylko jak, zgdnie z umowa, zarzadzamy zmianami i pracujemy iteracyjnie.

Natomiast to w jaki sposo ustalamy cene i termin, czyli tez jak estymujemy wstepny zakres o zakladamy nasze velocity zeby zgrac zakres z terminem i z tego wyliczyc cene do kontraktu, opisze w kolejnym poscie.