Na jednym z forów LinkedIn pojawiła się niedawno “propozycja”, jak pisać tak zwane “umowy Agile”. Uznałem, że kilka komentarzy warto tu dla Państwa umieścić.
Nie będę komentował całej tej propozycji, odniosę się jedynie do tego co wzbudziło moje “zainteresowanie”, a mianowicie to w jaki sposób usługodawcy, stosujący tak zwane zwinne metody, podchodzą do realizacji swoich projektów.
4. Przedmiot umowy. Odwołując się bezpośrednio do metodologii Agile, powinniśmy w tym miejscu umieścić CEL jaki stawia sobie klient, a pomóc w jego realizacji chce dostawca. Namawiam, aby poświęcić wystarczającą ilość czasu i maksymalnie w kilku zdaniach zdefinować i opisać rzeczywisty cel. Jest to o tyle ważne, że pomoże nie zgubić się w trakcie realizacji projektu. W momencie kiedy zakończymy projekt będziemy mogli wrócić do niego i zweryfikować czy został osiągnięty. […]
Pierwszy problem to termin “metodologia Agile”, która, obawiam się, że nie istnieje. Jedyne co znajdziemy (szukaj w Google) to strzępy prób definicji oraz “słynny” Manifest Agile”, który to tekst nie jest żadną metodologią (sł. j.polskiego: metodologia – nauka o metodach badań naukowych stosowanych w danej dziedzinie wiedzy). Ten Manifest nie jest nawet opisem metody (sł. j.polskiego: metoda – świadomie stosowany sposób postępowania mający prowadzić do osiągnięcia zamierzonego celu). Manifest nie mówi “co i jak zrobić by…”, nie jest metodą, to raczej tylko pryncypia (sł. j.polskiego PWN: pryncypium – najważniejsza dla kogoś lub dla czegoś zasada albo wartość).
Jeżeli uznać, że celem umowy jest “CEL jaki stawia sobie klient” to pytanie brzmi: kto i co realizuje? Bo jeżeli Ktoś ma cel, to realizuje go “ten Ktoś” kto go ma, a nie ktoś inny. Ale CEL jak najbardziej jest ważny. Jednak jeżeli moim celem jest np. zamieszkanie w domu, to jest to Mój cel. Celem ekipy budowlanej jest postawienie dla mnie domu (zlecenie) a nie zamieszkanie w nim. Mój CEL (cel Klienta) raczej nie jest ani celem umowy z developerem, ani celem developera (celem developera jest postawić dom i otrzymać za to wynagrodzenie).
Czytamy dalej.
8. Warunki wynagrodzenia i terminy płatności. To bodaj najbardziej istotny z punktów umowy, który różni się od dotychczas spotykanych w ?starych? umowach. Jego treść w pełni odwołuje się do wartości i prawd metodologii Agile.
Tu dla porządku przypomnę tak zwany Manifest Agile (źr. http://agilemanifesto.org/):
(1) Ludzi i interakcje ponad procesy i narzędzia, (2) Działające oprogramowanie ponad obszerną dokumentację, (3) Współpracę z klientem ponad formalne ustalenia, (4) Reagowanie na zmiany ponad podążanie za planem.
Tak więc są to niestety faktycznie jedynie pewne pryncypia czy wartości ale nie metoda.
Najważniejsza zmiana polega na tym, że dostawca cyklicznie, w krótkich okresach czasu 1-2 tygodni, dostarcza działające rozwiązanie, a odbiorca na bieżąco odbiera i płaci za nie. Dla ułatwienia, rozliczenia finansowe następują na koniec każdego miesiąca, kiedy to wystawia się fakturę zbiorczą za cztery iteracje, (w przypadku sprintów tygodniowych). W przypadku realizacji krótszych projektów oczywiście robi się to szybciej.
Zgadzając się na takie rozliczenia, strony umowy akceptują partnerskie podejście do projektu. Dostawca szybko dostarcza skończone, przetestowane i działające rozwiązanie, a odbiorca na bieżąco płaci za nie. Ważne jest aby okres rozliczeniowy nie był dłuższy niż 1 miesiąc. Pozwala to obu stronom umowy na bieżącą, (miesięczną), weryfikację i potwierdzenie chęci dalszej współpracy.
(źr. cytatów: Jak skonstruować umowę Agile?).
Powyższy tekst (opis realizacji umowy) to nic innego jak jednak stara Umowa Zlecenia znana z Kodeksu Cywilnego (Art. 750 [Umowy o świadczenie usług] Do umów o świadczenie usług, które nie są uregulowane innymi przepisami, stosuje się odpowiednio przepisy o zleceniu.). Jest to tak zwana umowa starannego działania. Generalnie, umowa taka nie daje Nabywcy (Klient) żadnego zabezpieczenia jakości i efektu, gdyż to on wybiera i angażuje Zleceniobiorcę, który obiecuje, że dochowa staranności. Cechą umowy Zlecenia jest możliwość jej wypowiedzenia w dowolnym momencie (i tu autor faktycznie ma rację).
Czy Klient ma jakąś możliwość obrony przed nierzetelnym wykonawca usługi? Na szczęście ma (KC):
Art. 740 [Obowiązki zleceniobiorcy] Przyjmujący zlecenie powinien udzielać dającemu zlecenie potrzebnych wiadomości o przebiegu sprawy, a po wykonaniu zlecenia lub po wcześniejszym rozwiązaniu umowy złożyć mu sprawozdanie. Powinien mu wydać wszystko, co przy wykonaniu zlecenia dla niego uzyskał, chociażby w imieniu własnym.
Tu jednak warto zwrócić uwagę na to, że w przypadku sporu wartość będą miały jednie pisemne “wiadomości” i “sprawozdania”. Czy się to komuś podoba czy nie, jak na razie, nie ma żadnych “zwinnych umów”, są umowy zlecenia (umowa starannego działania) i o dzieło (umowa efektu). Zaś w kwestii zakwalifikowania danej umowy do jednej z powyższych, decyduje jej treść a nie tytuł. Umowa Zlecenia, co ciekawe, nie zawiera pojęcia “licencji” czy “praw”, te zawiera umowa o dzieło (tak zwana umowa efektu). Tak więc polecam Państwu krótkie konsultacje z prawnikiem, przed zawarciem “zwinnej umowy”, by ocenić jakie ryzyko podejmujecie, bo w umowie zleceniu, wykonawca – pracując i pobierając wynagrodzenie – nie podejmuje żadnego ryzyka, nie licząc, możliwości zerwania trwającej umowy z wykonawcą (co niestety bardzo często ma miejsce w przypadku projektów programistycznych). W takich umowach 100% ryzyka bierze na siebie Klient. Pewien cynizm tej umowy polega a tym, że to, co Klient “odbiera i płaci” np. co dwa tygodnie, to nie “rozwiązanie” które jest Jego Celem a jakiś bieżący fragment prac… gotowy produkt jest celem projektu, on będzie “dostarczony” na zakończenie.
Panie Jarosławie,
Zgadzam się z nakreślonymi ryzykami. Zgadzam się również, że te ryzyka są tym większe im projekt ma charakter backofficeowy (zwiększa firma, złożona logika biznesowa, rozbudowane procesy biznesowe). W świetle tego ciągle pozostaje jednak pytanie jak formalnie najlepiej układać relacje z dostawcą w przypadku np. rozwoju nowego produktu internetowego. Niezmiernie trudno tu zdefiniować zakres produktu, który na pewno przyniesie sukces, sukces takiego produktu często wypracowuje się iteracyjnie, za każdym razem oceniając głos odbiorców i stawiając kolejne hipotezy co to tego jak powinien wyglądać produkt w kolejnej iteracji. Stąd idea MVP i przyrostowego budowania produktów internetowych startupów. I teraz mamy z jednej strony umowę zlecenie, która słabo zabezpiecza interesy zleceniodawcy, ale daje dużo elastyczność na zmiany w założeniach produktowych, z drugiej umowę o dzieło, która zdecydowanie lepiej zabezpiecza interesy zleceniodawcy, ale przy założeniu dobrze określonego / zdefiniowanego dzieła. Natomiast określenie z góry, tylko na bazie hipotez twórców, dzieła internetowego (jeszcze przed jego zbudowaniem i rozpoczęciem walidacji tychże hipotez w rynku), które na pewno będzie sukcesem jest mało możliwe. Oczywiście pozostaje podzielenie projektu na wiele małych iteracji, gdzie w skali powiedzmy 4-8 tygodni, można efekt w miarę dobrze zdefiniować, i podpisywać kolejne umowy o dzieło, ale to też oznacza sporą pracochłonność i zwiększone koszty transakcyjne (prawnicze). Może spotkał się Pan kiedyś z konstrukcją umowy ramowej, gdzie efekt byłby definiowany i wyceniany w formie zleceń do umowy ramowej?
Mnie osobiście nasuwa się jedna odpowiedź: nowy produkt albo jest opracowany i wymaga implementacji albo jest dopiero opracowywany. W tym drugim przypadku mamy R&D i umowę T&M. W tym pierwszym projekt do realizacji (umowa o dzieło – implementacja). Dodał bym jeszcze drugi element projektów T&M i start-up’ów: owszem, mogę nie mieć pojęcia jaki będzie sam produkt ale zaczynanie tej pracy jest efektem (powinno być) założonej strategii. ta ostatnia wyznacza kierunek (konkretny produkt to taktyka).
Kwestie umowy ramowej, te z jakimi miewam do czynienia i polecam, to raczej SLA zespołu (firmy) realizującej projekt programistyczny. To umowa mówiąca o zasadach zawierania umów konkretnych. Cechą umowy ramowej jest (z reguły) to, że nie rodzi zobowiązać finansowych. Jej kolejną cechą jest to, że zawiera (odnosi się) do metody (procedury) realizowania umów konkretnych. Jeżeli więc uznamy, że umowy z zespołem programistów to będą jednak umowy zlecenia (kolejne umowy konkretne), to umowa ramowa powinna zawierać opis tego co nazwiemy “starannym działaniem” i jak to sprawdzić. Wtedy Zamawiający będzie miał możliwość oceny, czy Wykonawca wywiązuje się z umowy. Nie zawsze możliwe jest “dostarczenie rozwiązania” po 2 tygodniach czy po miesiącu, po drugie dobra umowa z wykonawcą powinna zawierać metodę (opis lub odwołanie) pozwalającą stwierdzić, że usługodawca się z niej wywiązuje (np. metodę audytu, a najlepiej odwołanie do standardów branżowych). Bardzo zła jest sytuacja, w której tylko wykonawca jest w stanie ocenić jakość swojej pracy, a z racji tego tak na prawdę nie istnieje “metoda Agile”, warto to jakoś jednak opisać.
Innym podejściem jest Architektura Korporacyjna: zawiera odniesienie do strategii firmy, zawiera szkielet architektury IT w tym kluczowe wymagania na oprogramowanie. Problem jaki widzę: wiele firm nie ma strategii a działa ad-hoc, jak zawieje na rynku. To firmy, które nazywam rynkowe LOTTO 🙂
Panie Jarosławie zgadam się w 100% ze stwierdzeniem, że nie ma “zwinnych umów”, są umowy zlecenia (na pracę) i umowy o dzieło.
Dorzucę do tego, że są TYLKO takie umowy – wszelkie inne umowy zawierają się w jednym z tych dwóch typów umów.
Co do tego kto jak duże ponosi ryzyko (klient czy dostawca), to nie ma znaczenia typ umowy, tylko jak konkretnie zostały opisane “produkty umowy”.
Jak już miałbym na siłę definiować “umowy zwinne” to wyszedłbym od umowy o dzieło (nastawione na produkt/efekt).
Przykład totalnie ekstremalnej umowy (aby lepiej zobrazować moje podejście): jeśli klient potrzebuje aplikacji, która zmniejszy mu koszty o 20% to umowa powinna zawierać zapis Celu: zmniejszenie kosztów o 20% 🙂
No jest to pomysł… ale rozumiem, że wypłata dopiero po realizacji tego celu :), a jak cel nie wyjdzie to kto komu płaci (czyli kto ile ryzykuje )?
Moje drugie pytanie, i to bardzo poważne bo to słowa Klienta: jakim cudem jakiś programista oferuje mi usługi konsultingu strategicznego w obszarze zarządzania firma (zmniejszenie kosztów)?
Ale jeżeli jednak ktoś wcześniej podjął decyzję, że te koszty obniży “wdrażając jakieś oprogramowanie” to znaczy, że ma na to oprogramowanie jakiś pomysł, opis tego pomysłu to umowa o dzieło: “poproszę mi dostarczyć TAKIE oprogramowanie”, więc tu są jednak wymagania…
Chyba zaszło nieporozumienie – ja zrozumiałem, że chodzi tu o podpisywanie umów przez poważnie traktujących swoje zobowiązania firmy/osoby fizyczne. Jeśli zaś chodziło Panu o “wynajmowanie programistów” – to przepraszam za nieporozumienie 🙂
Co do strategii to każda strona umowy musi podpisywać świadomie na co się zoobowiązuje – jeśli na określenie strategii to na określenie strategii, jeśli na wykonanie modułu to … .
Uprzejmie przypominam, że mój przykład z poprzedniego postu był specjalnie extremalny, aby podkreślić DZIEŁO 🙂
Uściślę: chodzi o firmy oferujące usługi wytworzenia, dostarczenia i wdrożenia oprogramowanie. To czy są poważne czy nie to inna sprawa :). Co do świadomości podpisywanych umów to nie przypadkiem powstał UOKiK.
Ok. W zakresie wytworzeni, dostarczenia i wdrożenia oprogramowania na pewno nie ma przygotowania strategii. Co do np. analizy to już sprawa do doszczegółowienia.
Co do UOKiK to jego główną domeną działalności są prawa konsumentów (B2C), zaś jeśli chodzi umowy międzu firmami (B2B) to jego zadaniem ogranicza się do pilnowania uczciwej konkurencji i działań antymonopolowych.
Organem właściwym co do “świadomości” podpisywania umów jest stosowny Sąd 🙂
To fakt, ale to nie zmienia tego co napisałem 🙂