Umowa na projekt Agile - co powinieneś o niej wiedzieć? > Blog Intellect
Wciśnij enter, aby wyszukać
Blog Intellect / Biznes  / Umowa na projekt Agile – co powinieneś o niej wiedzieć?
Umowa

Umowa na projekt Agile – co powinieneś o niej wiedzieć?

Podejście zwinne do wytwarzania oprogramowania wciąż budzi wiele wątpliwości po stronie zlecającego, a samo pojęcie “agile” obrosło wieloma mitami. Praca zwinna wymaga również specyficznej umowy, bazującej na innych przesłankach niż standardowa umowa na pracę w kaskadzie. Mówi się, że umowy podpisuje się na złe czasy – nasza “umowa zwinna” sprawia, że obie strony deal’u podpisują umowę na sukces projektu. 

Umowa powinna w całości odzwierciedlać założenia biznesowe i sposób pracy. To na poziomie biznesowym kreujemy zapisy umowy. Jednak by móc przejść do wytłumaczenia jej ważnych elementów, musimy zrobić parę kroków w stronę świata zwinności i w kilku słowach, po “krakosku” powiedzieć, “czymże jest ten agile” z naszego punktu widzenia.

Umowa

Czym jest i dlaczego agile?

Zwinność (ang: agile) można zdefiniować jako gotowość na zmiany i ciągłą kontrolę jakości. To zdawanie sobie sprawy z tego, że przyszłość, nawet najlepiej przewidziana, wciąż jest nieodkryta, że jedyne, czego możemy się spodziewać na sto procent, to zmian. 

Czym nie jest zwinność? Nie jest pracą ad hoc, to nie definicja elastyczności, to nie praca bez ram budżetowych, harmonogramów, wizji. Zwinność to również nie teoria, lecz podejście oparte na praktyce, doświadczeniu – na empiryzmie. 

Wydawać by się mogło, że zwinność jest czymś nowym, aktualnym trendem czy modą. W rzeczywistości agile ma niemal 70 lat i pochodzi z Japonii, a konkretnie z firmy Toyota. W Polsce istnieje co najmniej od 30 lat, jednak popularność zaczyna zdobywać teraz. Często jednak agile to tylko buzzword, a niezrozumienie idei stojącej za podejściem zwinnym czy błędna implementacja w organizacji, wypaczają jego postrzeganie i tworzą mity.

Transparentność i komunikacja

Wszystko, co dzieje się w obrębie projektu, jest widoczne dla Zleceniodawcy. Jest określony zespół projektowy, który pracuje wyłącznie nad danym projektem – nawet w umowie jego członkowie wpisani są z imienia i nazwiska. Możemy zaglądnąć do narzędzi monitorujących postęp by zobaczyć, nad czym aktualnie pracuje konkretny developer. W każdej chwili możemy się spotkać, przyjechać, porozmawiać, zobaczyć jak wygląda praca. W każdej chwili można bezpośrednio porozmawiać z każdym z członków Zespołu Scrumowego. 

Zespół Scrumowy

Umowa agile bazuje na współpracy i przejrzystości.. Niemożliwe jest osiągnięcie sukcesu projektu bez współpracy zlecającego i wykonawcy. Jako, że nasz sposób wytwarzania opiera się o framework Scrum, w centrum umowy jest Zespół Scrumowy, który składa się z Właściciela Produktu (który jest reprezentantem zleceniodawcy, umocowanym w pełni do zarządzania zakresem i budżetem projektu), Zespołu Developerskiego (na który składają się programiści, specjaliści UX, architekci, analitycy, graficy – słowem wszyscy, którzy są wymagani do wytworzenia oprogramowania) oraz Scrum Mastera (którego można porównać do empatycznego BHP’owca dbającego o higienę pracy, komunikacji, poprawność przebiegu procesu Scrumowego). Wspólna praca Zespołu Scrumowego jest gwarantem sukcesu projektu.  

Sprinty

Praca nad oprogramowaniem przebiega w tzw. sprintach, czyli najczęściej w dwutygodniowych etapach, po których zawsze oddawana jest w pełni funkcjonalna część oprogramowania, potencjalnie możliwa do instalacji i oddania do używania. De facto, po pierwszych dwóch tygodniach można sprawdzić, czy nasz koncept oprogramowania jest prawidłowy i czy nie trzeba wprowadzić korekt do projektu. 

Każdy sprint kończy się protokołem odbioru sprintu. Jeśli sprint jest odebrany, wystawiamy fakturę VAT. Tak, rozliczamy się za każdy sprint, a kwoty za sprinty są stałe. Sytuacje, w której kwota za sprint może się zmienić są dwie: nieobecność developera (koszt maleje, ale równocześnie mniej w sprincie wytwarzamy) lub dołączenie do zespołu dodatkowych developerów (koszt rośnie, więcej wytwarzamy w sprincie). 

Z założenia sprinty następują po sobie bez żadnych odstępów czasowych, jednakże Zespół Scrumowy może podjąć decyzję o wstrzymaniu prac np. w okresie urlopowym i cały Zespół Scrumowy udaje się na urlop.

Dżentelmeńska umowa dwutygodniowa

Po stronie zlecającego i wykonawcy powstają zobowiązania, które wpływają na jakość pracy i budowanie relacji. Wychodząc z założenia, że obie strony są profesjonalistami w swojej dziedzinie, zobowiązujemy się do sumiennego wypełniania swoich zadań – wykonawca do zrealizowania w najwyższej jakości oprogramowania gotowego do wydania po zakończeniu sprintu, zleceniodawca do terminowego regulowania należności za sprint. Ustalenie zasad, w obrębie których prowadzimy grę zespołową, zwaną wytwarzaniem oprogramowania w Scrum, gwarantuje niezakłóconą ciągłość realizacji. 

Licencje, prawa autorskie majątkowe

W większości przypadków pracujemy nad dedykowanymi rozwiązaniami, w związku z tym przekazujemy pełnię praw autorskich majątkowych zleceniodawcy. Przekazujemy również wszelkie licencje na oprogramowanie, które zostało użyte do wytworzenia rozwiązania dla klienta. Domyślnie opieramy się na rozwiązaniach Open Source – każde odstępstwo od tej zasady jest konsultowane z klientem.

Koszt sprzedaży praw autorskich majątkowych zawiera się w cenie developmentu, jednakże prawa za wytworzone oprogramowanie w ramach sprintu przekazywane są dopiero po uregulowaniu należności za sprint.  

Fixed price, 

czyli mam potrzeby, specyfikację i nieprzekraczalny budżet więc nie mogę pracować zwinnie.

Oczywiście, że możemy to robić zwinnie! Przeważająca ilość projektów ma założony zakres i budżet. Pierwszym “łamaczem” standardowego podejścia i tzw. odwrotnym myśleniem kierującym nas na tory agile, jest spojrzenie na oprogramowanie od strony wartości biznesowych, które ma dostarczyć a nie suchych funkcji, jakie mają być zaimplementowane. Zrewidowanie projektu pod względem korzyści biznesowych dość często skutkuje tym, że budżet weryfikowany jest raz jeszcze, zaprojektowane rozwiązania są zestawiane z potrzebami, a użytkownicy końcowi otrzymują funkcje, które są użyteczne. 

Posiadane blueprinty, specyfikacje czy wymagania projektowe są uzupełnieniem wizji oprogramowania. To wizja zapewnia spójność projektu i w jej obrębie powinniśmy się poruszać przy wytwarzaniu produktu, na bieżąco weryfikować warunki biznesowe, budżet i wartość biznesową oprogramowania. 

Dla zleceniodawcy zwinność jest lekiem na niedokończone i niepotrzebne/nieadekwatne produkty. Zleceniodawca w takim podejściu może liczyć na to, że Software House będzie uczestniczył w tworzeniu oprogramowania na poziomie eksperckim, konsultacyjnym, partnerskim, a nie wykonywał prac opisanych sztywną specyfikacją, podążał za zapisami harmonogramu czy definicjami odległych celów. Ważna jest świadomość, że oprogramowanie to droga do celu, a nie cel sam w sobie. Gotowość na zmiany pozwoliła wielomilionowym projektom wyjść bez szwanku na użyteczności i dostarczyć wartość biznesową w sytuacji covidowej. Przy zamrożonej specyfikacji, celach dalekosiężnych, oprogramowanie stałoby się nieaktualne jeszcze przed momentem wdrożenia. 

Specyfikacja

“Walking on water and developing software from a specification are easy if both are frozen.”

To cytat z książki Edwarda V. Berarda, pt “Essays on object-oriented software engineering” z 1993 roku. To jeden z ulubionych cytatów koderów, którzy nigdy nie mieli kontaktu z biznesem, specyfiką jego działania. To jeden z cytatów, które leżą u podwalin umowy kaskadowej (lub inaczej waterfall), którą najczęściej chcą podpisywać zleceniodawcy.

Praca kaskadowa, ze szczegółowym planem wykonania, przewidzianą architekturą i niemal chirurgiczną wyceną co do minuty, jest możliwa – ale definiuje ona pracę, która już kiedyś została wykonana, posiadamy doświadczenie w tworzeniu “klonów” oprogramowania, możemy taśmowo produkować oprogramowanie. Ta bardzo szczegółowa instrukcja, recepta, wynika wyłącznie z precyzyjnego, ciągłego opisu (czy może spisu) wytwarzania konkretnego rozwiązania. Zapisuje się tylko te kroki, które zakończyły się sukcesem, by później odtworzyć takie oprogramowanie w sposób identyczny. 

Jednak inżynieria oprogramowania to poruszanie się w nieprzewidywalnym środowisku, odkrywanie wizji i ciągła kontrola środowiska i jego zachowania. Oprogramowanie w biznesie najczęściej opisuje procesy, automatyzuje je, optymalizuje wydajność czy redukuje koszty. Ciągła kontrola, czy to co wytwarzamy przystaje do dzisiejszych realiów powoduje, że jesteśmy w stanie dostarczyć oprogramowanie, które z pewnością będzie funkcjonalne a wdrożenie zakończy się sukcesem. 

Zapominanie o zmienności założeń projektowych można przyrównać do zamykania oczu na drodze i udawaniu, że nie ma zakrętów, skrzyżowań czy innych uczestników ruchu. Tworząc oprogramowanie bez przerwy spotykamy się z nieprzewidzianymi sytuacjami. Podróż od konceptu do realizacji przebiegnie sprawnie i bezpiecznie, jeśli sterować projektem będziemy uważnie. Wtedy zauważymy autostrady, malownicze skróty, niebezpieczne zakręty, śliskie nawierzchnie, czy załamania pogody. Obserwując aktualną drogę, będziemy patrzeć na nawigację i przewidywać zatory, zamknięte drogi i kosztowne przeprawy. Do celu wiedzie wiele ścieżek, warto o tym pamiętać.

Wyspecyfikowanie projektu liczonego w setkach tysięcy, to próba przewidzenia wszystkich czynników w nieznanej przyszłości. Specyfikacja to bardzo przydatna mapa i drogowskaz, lecz zamrożenie developmentu w obrębie specyfikacji stwarza zagrożenie wytworzenia produktu, który jest już bezużyteczny lub nie przystaje do aktualnych realiów. 

Tworzenie oprogramowania z zamrożonej specyfikacji jest fantastyczne dla programistów – odwrotnie odczuwa to biznes. Jedyne co jest pewne w przyszłości to zmiana. Agile jest dla Klienta.

Poufność, zakaz konkurencji

Tworzymy rozwiązania dedykowane. Znamy ich wartość. Znamy ich wpływ na biznes Klienta. I często zdarza się, że podpisujemy umowę NDA, która zobowiązuje nas do poufności. Jednak musimy pamiętać, że jesteśmy software housem, jesteśmy specjalistami do bardzo złożonej i często skomplikowanej roboty. Chcemy chwalić się, że współpracujemy z różnymi firmami z różnych branż. Chcemy móc używać logo firmy Klienta w naszym portfolio i jesteśmy wdzięczni za referencje. W ten sposób zyskujemy nowych Klientów. 

Gwarancja, wsparcie powdrożeniowe

Każde rozwiązanie stworzone przez nas otrzymuje roczną gwarancję. Gwarancja obejmuje wady, których bezpośrednie przyczyny tkwią w kodzie wytworzonym przez nas. Jeśli Twoje oprogramowanie działa błędnie z powodu problemów oprogramowania innych podmiotów lub błędów po stronie Twojej infrastruktury – nie obawiaj się, pomożemy rozwiązać Ci ten problem odpłatnie, informując Cię wcześniej o szacowanym czasie i kwocie rozwiązania problemu. 

Możesz również rozszerzyć jej zakres podpisując z nami umowę na wsparcie powdrożeniowe, które może obowiązywać nawet po zakończeniu gwarancji. W ramach takiej umowy możesz otrzymać błyskawiczne czasy reakcji na zgłoszenia, monitoring 24h/dobę, wsparcie BOK itp. 

Dalszy rozwój oprogramowania

Jeśli chcesz rozwijać z nami produkt dalej, podpiszemy umowę, którą już znasz, jak dla nowego projektu. Nic Cię nie zaskoczy. 

Marcin Szczurek

CEO Intellect Software House


Brak komentarzy

Napisz komentarz