Czy projekty realizowane w Agile wymagają zwinnych umów? To pytanie retoryczne. Oczywiście, że tak. W przeciwnym wypadku będą zwinne tylko z nazwy albo – cytując klasyka – będziemy mieli do czynienia z dwiema prawdami: prawdą umowy i prawdą projektu. Pytanie tylko, co to znaczy, że umowa jest zwinna i jakie są cechy charakterystyczne dla tego typu kontraktów?
Reagowanie na zmiany
Rzeczą pewną dla większości projektów informatycznych jest to, że będą zmiany. W czasie projektu zmieni się prawdopodobnie jego zakres. Pojawią się także dodatkowe wymagania, a to z kolei wpłynie na zmianę harmonogramu, w efekcie zmieni się budżet, i tak dalej… Taka jest rzeczywistość projektów informatycznych. Można udawać, że się jej nie widzi albo ją zaakceptować i dostosować do tej rzeczywistości umowę.
Umowa zwinna, to taka która pozwala jej stronom na te zmiany reagować. Ta reakcja powinna być szybka, oparta o prostą i odformalizowaną procedurę. Procedurę pozbawioną wielostopniowych akceptacji, posiedzeń ciał opiniodawczych, pisemnych wniosków etc. Procedurę, która nie wymaga dla każdej zmiany umowy podpisywania przez strony pisemnego aneksu. Jak to zrobić? Oprzeć procedurę na komunikacji elektronicznej, wyznaczyć terminy, w jakich mają być podejmowane decyzje oraz udzielić kierownikom projektu odpowiednio wysokich pełnomocnictw. Doświadczenie podpowiada, że znakomita większość decyzji podejmowanych w ramach projektu, i to zarówno tych o charakterze operacyjnym, jak i tych modyfikujących ustalenia umowne, nie musi, a wręcz nie powinna być za każdym razem podejmowana przez tzw. top management. Osoby z tego szczebla nie mają ani wiedzy projektowej pozwalającej na podjęcie dobrej decyzji, ani możliwości organizacyjnych (czyt. czasu) aby takie decyzje podejmować. Osobami właściwymi do podejmowania takich decyzji są kierownicy projektu. To oni mają pełną i aktualną wiedzę na temat statusu prac oraz kierunku, w jakim zmierza projekt. A zatem to właśnie oni wiedzą najlepiej czy wnioskowana zmiana umowy jest konieczna czy nie. I to oni takie decyzje powinni podejmować.
To samo doświadczenie uczy, że wymaganie formy pisemnej dla każdej zmiany umowy, jako formy teoretycznie bardziej trwałej i użytecznej dowodowo od formy elektronicznej, nie spełnia swej funkcji (dokument łatwiej zgubić niż e-mail), co więcej istotnie spowalnia proces decyzyjny, wpływając negatywnie na projekt i dynamikę jego realizacji. Znakomita większość ustaleń może zostać podjęta przez strony w formie elektronicznej. Prawo nie wymaga, aby wszystkie decyzje dotyczące umowy, w tym jej zmiany, były podejmowane w formie pisemnej. Wymóg formy pisemnej, podobnie jak podejmowanie decyzji przez wyższą kadrę zarządzającą, należy ograniczyć do tych decyzji, które mają dla projektu znaczenie strategiczne np. istotne zwiększenie budżetu, zmiany harmonogramu ramowego czy decyzje co do ewentualnego zakończenia projektu. W pozostałym zakresie – odpowiednio wysokie pełnomocnictwa dla osób kierujących projektem oraz uproszczenie, w tym odformalizowanie procesu decyzyjnego, pozwolą istotnie zwiększyć zwinność kontraktu.
Na zakończenie, pamiętajmy aby proces decyzyjny ograniczyć ustalonymi w umowie terminami. Niewiele rzeczy tak stymuluje do działania jak termin, który został wspólnie ustalony przez strony, nawet jeśli ma on charakter czysto porządkowy i nie jest objęty żadną sankcją.
Kontrola realizacji projektu
Kolejnym z czynników, decydujących o zwinności umowy, jest wyposażenie jej w zapisy określające zasady współpracy stron. Zarówno na wybranych obszarach realizacji projektu, jak i w ramach bieżącego współdziałania.
Pośród wybranych obszarów powinniśmy precyzyjnie określić między innymi zasady odnoszące się do:
- komunikacji i obiegu informacji (w jakim języku się komunikujemy, z jakich narzędzi komunikacyjnych będziemy korzystać, kto odpowiada za koordynację przepływu informacji, jak często organizujemy spotkania statusowe, kto ma brać udział w takich spotkaniach itp.),
- testowania (kto przeprowadza testy – zamawiający, dostawca, podmiot zewnętrzny, jak przebiega procedura testowa, jak często weryfikujemy/testujemy rezultaty prac dostarczone przez dostawcę, czy określamy zamkniętą listę metod testowych, czy pozwalamy w tym zakresie na pełną dowolność, kto decyduje o scenariuszach testowych itp.),
- odbiorów (jak ma przebiegać prezentacja rezultatów prac dostarczonych przez dostawcę, jak określamy kryteria akceptacji, kto podejmuje decyzje o odbiorze prac dostarczonych przez dostawcę itp.).
Opisując te obszary, powinniśmy korzystać z wypracowanych już zwinnych metodyk projektowych i twórczo adaptować je do wymogów konkretnego projektu oraz umowy. Scrum, Kanban to coś, co już istnieje. Nie ma potrzeby wymyślania czegoś od nowa. Wystarczy zrozumieć istniejące już mechanizmy i twórczo przenieść je do umowy.
Podsumowując ten wątek – umowa zwinna, to umowa wyposażona w mechanizmy pozwalające szybko dostrzec problem i zarządzić ryzykiem z tym problemem związanym. Im szybciej zlokalizujemy problem, tym więcej mamy czasu na jego nomen omen zwinne ominięcie.
Projekty robią ludzie
Obszarem często pomijanym w tradycyjnych kontraktach IT, jest obszar związany z personelem dostawcy. To niezwykle zastanawiające, gdyż to właśnie czynnik ludzki jest tym, który ma istotne znaczenie dla powodzenia lub katastrofy projektu. Zwinność projektu zależy w dużej mierze od zwinności zespołu go realizującego. Z kolei zwinność zespołu może zależeć od wymagań, jakie określimy w umowie. Zwinny kontrakt powinien precyzyjnie określić, czego spodziewamy się od personelu dostawcy. Poza oczywistymi wymaganiami, co do kompetencji, doświadczenia i portfolio projektów dotychczas zrealizowanych przez poszczególnych członków personelu, warto również rozważyć te, które odnoszą się do interdyscyplinarności (samowystarczalności), tj. posiadania przez zespół pełnego zestawu kompetencji, pozwalającego na realizację projektu, bez konieczności korzystania z zasobów zewnętrznych oraz międzyfunkcjonalności tj. kompetencji pozwalającej członkom zespołu się wzajemnie zastępować.
Podsumowując, właściwie opisany obszar umowy dotyczący zespołu dostawcy jest jednym z kluczowych czynników zwinności w kontraktach IT. Pominięcie tego obszaru lub potraktowanie go w sposób pobieżny istotnie wzmacnia ryzyko niepowodzenia projektu.
Zakończenie współpracy
Umowa zwinna, to umowa, która umożliwia obydwu stronom wyjście z projektu na z góry określonych warunkach, w oparciu o ustaloną procedurę zakończenia współpracy. Świadomość możliwości wyjścia z kontraktu wraz z określeniem konsekwencji takiego kroku, to wbrew pozorom element, który pozytywnie wpływa na poziom współpracy stron, w tym ich elastyczność w ramach realizacji projektu. Z drugiej strony, trudno znaleźć czynnik bardziej usztywniający stanowiska stron, niż fakt, że z formalnego punktu widzenia są one na siebie skazane, a ewentualne wyjście z umowy będzie okupione krwawym rozstaniem. Sama świadomość, że możemy w sposób kontrolowany wyjść z umowy powoduje, że przed podjęciem tego ostatecznego kroku, jesteśmy bardziej skłonni szukać alternatywnych rozwiązań. To mechanizm psychologiczny, ale sprawdza się również na polu prawnym. Oczywiście, nie chodzi o to, aby każda ze stron, w każdym czasie, mogła wyjść z umowy. To wyjście możemy uzależnić od wystąpienia konkretnych okoliczności, spełnienia określonych przez strony warunków itd. Rzecz w tym, aby możliwość wyjścia z umowy była otwarta dla obydwu stron. Po drugie, pamiętajmy aby precyzyjnie określić konsekwencje będące efektem zakończenia współpracy stron. Opiszmy między innymi co dzieje się z prawami autorskim po zakończeniu współpracy, jak będziemy rozliczać prace będące w toku, jak wygląda kwestia przekazania dokumentacji, wydania kodu źródłowego lub transferu know-how do zamawiającego. To obszary, o których nie możemy zapomnieć w umowie. Nie wystarczy sama świadomość, że możemy wyjść z kontraktu. Musimy jeszcze wiedzieć, co będzie konsekwencją takiego kroku.
Konkluzja
Zawarte w artykule wyliczenie nie ma oczywiście charakteru zamkniętego, ale jest dobrym początkiem dla dalszej analizy tzw. czynników elastyczności/czynników zwinności (flexibility factors/agility factors) w umowach IT. Są to elementy, których obecność lub brak w umowie, decyduje o jej zwinności, a tym samym o zwiększeniu szans powodzenia projektu, którego umowa dotyczy. Oczywiście, żaden ze wspomnianych powyżej czynników zwinności, nie wyklucza obecności w umowie pozostałych, standardowych już dla umów IT (i nie tylko) postanowień dot. rozliczeń, zasad odpowiedzialności, poufności itp. Natomiast brak tych czynników w umowie, nie pozwala nazwać umowy zwinną.
Specjalista z zakresu prawa nowych technologii oraz własności intelektualnej. Wcześniej pracował między innymi jako prawnik wewnętrzny dla Agora S.A., MTV Networks oraz członek zespołu TMT (Technology – Media – Telecomunications) międzynarodowej kancelarii prawnej „Bird & Bird”. Aktualnie pracuje w Kancelarii Prawnej Maruta Wachta sp.j. Wykładowca na Wydziale Matematyki, Informatyki i Mechaniki Uniwersytetu Warszawskiego. Absolwent Wydziału Prawa i Administracji Uniwersytetu Jagiellońskiego oraz podyplomowych studiów na kierunku „Prawo Nowoczesnych Technologii” prowadzonych przy Polskiej Akademii Nauk. Kontakt: lwegrzyn@maruta.pl