wtorek, 28 października 2014

Umowa wdrożeniowa, czy inżynieria oprogramowania?

1.    Nieporozumienia od samego początku

Już samo określenie „umowa wdrożeniowa”, jednoznaczne dla prawnika, wprawia w osłupienie informatyka, bowiem „wdrożenie”, to po informatycznemu, wyłącznie ostatnia faza projektu IT, kiedy to wcześniej zaprojektowany, zbudowany (albo „zaimplementowany”) i przetestowany system uruchamia się w środowisku docelowym (operacyjnym) tak, aby był w pełni gotowy do działania operacyjnego (albo „produkcyjnego”, „na produkcji”). Dla człowieka, znającego tylko terminologię informatyczną, nazywanie umowy na realizację systemu, umową „wdrożeniową”, ma więc tak samo mało sensu, ile miałoby nazwanie kontraktu na budowę statku, kontraktem na jego „wodowanie” :-).

Podobna niezgodność występuje zresztą także w innych językach, nie tylko po polsku. Na przykład po angielsku, często spotykanym określeniem takich umów, jest „implementation contract”, albo „implementation agreement”, a przecież „implementacja”, tak samo jak „wdrożenie”, to w informatycznym języku tylko jedna z wielu faz projektu tworzącego system.

Co ciekawe, ten językowy kłopot występuje głównie dla umów dotyczących systemów informatycznych. Dla domów, nikt nie powie „umowa na wdrożenie domu”, lecz „umowa na budowę domu”, albo na „wykonanie domu” – to słowa o wiele bardziej intuicyjne i zgodne z językiem codziennym. Inne produkty – na przykład filmy, projekty, zadania – „realizuje się”, albo „stwarza”, a nie „wdraża”.

Być może – nie jestem dostatecznie biegły w sprawach prawniczych, aby to rozstrzygnąć – istnieje jakaś subtelna różnica między „umową na stworzenie systemu”, „umową na wdrożenie systemu” i „umową na zbudowanie systemu”; może użycie różnych słów sygnalizuje inny zakres odpowiedzialności wykonawcy? Tak, czy inaczej, mamy tutaj i ryzyko nieporozumień, i kłopotliwe zawiłości interpretacyjne, i wyraźną rozbieżność między technicznym a prawniczym spojrzeniem, czyli te same symptomy, które widać również w wielu innych miejscach, kiedy przyglądamy się problemom z tworzeniem, negocjowaniem i realizacją umów wdrożeniowych.

Dlatego temat ten nie jest wyłącznie lingwistyczną ciekawostką, a istotnym wyzwaniem: odmienność terminologii, i wzajemna niedostateczna znajomość realiów powoduje, że umowy wdrożeniowe często nie są tak dobre, jak mogłyby być, gdyby te przeszkody usunąć. Mam nadzieję, że ten artykuł może stać się pierwszym krokiem na drodze ich likwidowania.

2.    Legenda odmienności agile

Wielu prawników jest zdania, że umowy na realizację projektów metodami agile powinny być zupełnie inne od umów tradycyjnych, a samo agile cieszy się sławą czegoś niezmiernie dziwnego i trochę nawet podejrzanego: cóż to bowiem za metodyka, która nie pozwala – jak sądzą prawnicy - określić z góry zakresu planowanej pracy, czyli – można ulec takiemu wrażeniu – wyklucza możliwość zapisania przedmiotu umowy, co z punktu widzenia prawa jest zasadniczym mankamentem?

Znaczną część winy za ten stan rzeczy ponoszą metodyki agile, świadomie bardzo mocno akcentujące swoją odmienność i wyjątkowość, zarówno tę prawdziwą, jak i tę pozorną, ideologicznie wyolbrzymianą. Bardzo wielu propagatorów podejścia agile posługuje się stylem pompatycznym, niemal uduchowionym, co nie sprzyja znajdowaniu punktów stycznych ze światem nie-agile, w tym prawniczym, a niewtajemniczonym utrudnia zrozumienie, o co tak naprawdę w tej metodyce chodzi. Piszę o tym dość obszernie w mojej książce „Agile – szansa na skokowy wzrost produktywności” (wydawnictwo „Wiedza i Praktyka” 2014).

Drugi problem, to celowo odmienna od tradycyjnej terminologia agile. Nie ma w niej żadnej mistyki – doskonale daję się ją przełożyć na terminologię tradycyjną, tylko trzeba to umieć zrobić.

Miłośnicy historii IT mogą dociec, że jedną z przyczyn skłonności niektórych praktyków agile do niejakiej niefrasobliwości wobec wymogów umów wdrożeniowych, jest współudział tak zwanej ideologii „programowania ekstremalnego” (XP) w tworzeniu zasad agile. XP ma zaś swoje korzenie w drugiej połowie lat dziewięćdziesiątych, w latach ogromnego wzrostu biznesu internetowego, kiedy chodziło o to, aby, cytuję: „wydajnie realizować małe i średnie projekty wysokiego ryzyka, czyli takie, w których nie wiadomo do końca, co się tak naprawdę robi i jak to prawidłowo zrobić” (pl.wikipedia.org/wiki/Programowanie_ekstremalne). Czym takie podejście się skończyło, można przeczytać w innym artykule Wikipedii, na temat „bańki internetowej”.

Ze strony metody agile, zarówno niejaka ideologizacja metodyki, jak i posługiwanie się własną, zamkniętą terminologią, mają jednak nie tylko prestiżowe, ale też najzupełniej merytoryczne uzasadnienie. Trzeba bowiem zdać sobie sprawę, że możliwe wielkie korzyści zastosowania agile (w tym tytułowy, dramatyczny wzrost wydajności) wymagają naprawdę radykalnego porzucenia wielu starych praktyk i mocno utrwalonych, złych przyzwyczajeń, co nie jest łatwe – więc pewien radykalizm może być w tym pomocny.

Aby zlikwidować otaczające agile fałszywe mity, wystarczy tę metodą opisać prostymi słowami, a nieporozumienia – wyjaśnić. Myślę, że prawnikom i innym interesariuszom projektów spoza świata IT bardzo pomocny byłby jednodniowy kurs „agile dla prawników”. Poniżej, próbnie, dokonam paru takich demistyfikacji. Podobnie, do szkoleń dla uczestników, a zwłaszcza dla kierowników projektów agile, warto by dorzucić garść wiedzy o uwarunkowaniach prawnych.

Agile to metoda budowania systemów bez określonych wymagań? Jest wręcz przeciwnie, projekt agile nie może się toczyć bez wymagań na tyle dokładnych, aby jednoznacznie określały, co mają zrealizować programiści.

Prawdą jest natomiast, że agile zakłada możliwość nawet znacznych zmian wymagań niskopoziomowych równolegle z tworzeniem kodu (implementacją), oraz że dopuszcza, wręcz zaleca rozpoczęcie prac nad implementacją gdy tylko choć część wymagań jest dostatecznie doprecyzowana, nie czekając na szczegółowe określenie wszystkich. Z punktu widzenia umowy wdrożeniowej jest to bez znaczenia – wymagania tak szczegółowe nie wchodzą w jej skład, ani nawet w skład załącznika do umowy, zwanego często dokumentem analizy lub specyfikacją funkcjonalną.

  • Kolejne terminologiczne dziwadło – dlaczego specyfikacja wymagań nazywana jest specyfikacją funkcjonalną? A co z kluczowymi wymaganiami poza-funkcjonalnymi (niefunkcjonalnymi): użytecznością, doświadczeniem klienta, wydajnością, zabezpieczeniami – czyżby były nieważne?
Po prostu niejakiej rewizji musi ulec tradycyjny model, wedle którego etap analizy poprzedza etap realizacji. W podejściu agile (i w ogóle w każdym podejściu tak zwanym iteracyjnym, którego agile jest tylko jednym z wielu przedstawicieli) analiza i realizacja do pewnego stopnia toczą się równolegle, naprzemiennie. Nie powinno być to żadną trudnością do zdefiniowania w umowie wdrożeniowej.

Dla żadnej ze stron umowy nie jest celem, aby zniszczyć drugą stronę umowy karami umownymi, przygwoździć, zmusić do poniesienia strat, tylko celem jest, aby powstał dobry system informatyczny, przynoszący zleceniodawcy biznesową korzyść, a wykonawcy godziwą zapłatę. Strategia na oszukanie i wykorzystanie drugiej strony jest oczywiście bardzo krótkowzroczna, ale… przez to niekiedy kusząca.

Umowy, zakładające realizację metodą agile, szczególnie wymagają oparcia się tej pokusie. Aby projekt naprawdę zakończył się sukcesem, konieczna jest intensywna, partnerska współpraca zamawiającego i wykonawcy. Agile wymaga, aby warunki tej współpracy były szczegółowo opisane w umowie. Pokusa zamawiającego, aby porzucić wykonawcę z niedoskonałymi wymaganiami (załącznikami do umowy) i – licząc na skuteczność sankcji kryteriów odbioru oraz wpisanych do umowy kar – przyjść po gotowy system po, dajmy na to, pół roku, ta pokusa musi być przezwyciężona.

Dlatego umowy pisane pod kątem agile muszą więcej miejsca, niż umowy tradycyjne, poświęcić dość szczegółowym opisom procedur współpracy, oraz sankcji za ich nieprzestrzeganie, łącznie z prawem do odstąpienia od umowy.

Nie jest to jednak żadna radykalna odmienność – artykuł 630 Kodeksu cywilnego przewiduje konieczność odpowiedniej współpracy zamawiającego z wykonawcą, oraz sankcje nie wywiązywania się z niej. Miło pomyśleć, że ustawodawca aż tak uwzględnił potrzeby metodyki agile :-)

W projekcie agile nie ma kierownika projektu? Z powodu odmiennej terminologii, o której już mówiliśmy, nie ma wprawdzie osoby o takim tytule, ale z perspektywy sponsorów projektu, a więc osób będących stroną umowy, funkcję kierownika projektu pełni tak zwany właściciel produktu (ang. Product Owner). W żadnym razie nie jest kierownikiem projektu osoba mająca tytuł „scrum master” – jej funkcja jest zupełnie inna.

Ponadto, nic nie stoi na przeszkodzie, żeby całością projektu, realizowanego w ramach metodyki agile, zarządzał także tradycyjny kierownik projektu. Jego uprawnienia do wewnątrz projektu będą mniejsze, niż zwykle w projektach nie-agile, ale to nas nie interesuje na poziomie umowy.

Agile, to nieustanna i niemożliwa do nadzorowania zmienność? Nieprawda – zmienność w agile można i należy kontrolować. Nie pojawi się ona w ogóle, jeśli zamawiający zna od początku, z góry swoje potrzeby i wymagania tak dobrze, że jest je w stanie bezbłędnie określić. Jeśli ten warunek nie jest spełniony, a prawie nigdy nie jest, bo to poznawcza niemożliwość, wówczas na pewno lepsza jest zmienność planowana i przewidywana przez procedury agile, niż zmienność wprowadzana cichaczem, poprzez tak zwane „wrzutki”, albo „cichociemne CR-y” (autentyczne nazewnictwo!), przy zachowaniu pozorów nienaruszonych założeń, co nagminnie dzieje się w projektach tradycyjnych.

We wszystkich umowach wdrożeniowych, także tych zupełnie nie-agile, przewiduje się możliwość późniejszych zmian, zarówno wymagań, jak ich priorytetów, czy harmonogramu. Do tego celu umowy określają odpowiednie narzędzia i procedury do radzenia sobie z propozycjami zmian (CR). Umowy dla agile tym różnią się od tradycyjnych, że przewidują więcej takich zmian i precyzyjniej regulują tryb zarządzania nimi, podczas trwania całego projektu.

3.    Osierocone załączniki merytoryczne

Prawniczy punkt widzenia podkreśla wagę odpowiedniego zdefiniowania przedmiotu umowy, czyli produktu IT, który ma być zrealizowany. Niemniej, zadaniem prawa jest przede wszystkim dbałość o zgodny z jego regułami tryb zawierania umów, nie zaś o ich biznesową sensowność ani nie o techniczną poprawność. Prawnik domaga się, aby do umowy istniały odpowiednie załączniki merytoryczne, określające jej przedmiot, ale nie wnika w ich poprawność, kompletność ani jakość ich uzasadnienia biznesowego. Niemniej, prawnicy bystrze dostrzegają pewne częste błędy, na przykład, kiedy załącznikiem merytorycznym staje zapytanie ofertowe (lub – pośrednio - SIWZ, dla przedsięwzięć objętych prawem o zamówieniach publicznych), albo oferta, bowiem te dokumenty nie stanowią dostatecznej podstawy, są zbyt ogólnikowe, czasem sprzeczne.

Ryzyko podpisywania umowy, której przedmiot jest niedostatecznie określony, jest oczywiste i dotyczy zarówno wykonawcy, jak i zamawiającego. W interesie obu stron jest umowa możliwie prosta i przejrzysta, nie przesadnie szczegółowa, pozwalająca na skuteczną egzekucję jej ustaleń. Aby to osiągnąć, jej załączniki merytoryczne również muszą spełniać te same kryteria.

Istnieje nauka, mogąca nam znakomicie pomóc w tworzeniu dobrych załączników merytorycznych do umów wdrożeniowych – to inżynieria wymagań. Inżynieria wymagań określa zasady, które obowiązują podczas następujących działań:
  • Pozyskiwanie i konsolidacja wymagań – określenie celu biznesowego przedsięwzięcia, identyfikacja zakresu oraz kontekstu systemu, jego interesariuszy, w tym użytkowników, i zdobywanie od nich informacji na temat systemu.
  • Analiza wymagań – badanie, czy znalezione / zdobyte wymagania są zrozumiałe, spójne, dostatecznie szczegółowe, nie zawierają zbędnej redundancji.
  • Specyfikacja wymagań – opisywanie wymagań, w języku naturalnym lub w formie różnych modeli (modelowanie wymagań), tak, aby były jednoznaczne.
  • Walidacja i negocjowanie wymagań – sprawdzanie, czy wymagania spełniają kryteria jakości oraz uzgadnianie wymagań z różnymi interesariuszami lub grupami interesariuszy.
  • Utrzymanie wymagań (także: zarządzanie wymaganiami) – archiwizowanie, wersjonowanie, zarządzanie zmianami wymagań.
Proces inżynierii wymagań częściowo poprzedza proces negocjacji umowy wdrożeniowej (np. określenie celu biznesowego), częściowo wpisuje się w niego (np. negocjowanie wspólnego stanowiska różnych interesariuszy), a w dużej części odbywa się także już po podpisaniu umowy, zwłaszcza w podejściu agile.

Dla prawników, korzystna byłaby znajomość podstaw i centralnych pojęć inżynierii wymagań. Podobnie, osoby pełniące role analityków (rzadsza, choć merytorycznie trafniejsza, nazwa tej funkcji to inżynierowie wymagań), często mają niedostateczną wiedzę w zakresie prawnych uwarunkowań procesu i dokumentacji wymagań. Zapraszam Czytelników do udziału w cyklu darmowych warsztatów on-line na temat inżynierii wymagań: http://cts.com.pl/Aktualnosci/Inzynieria-wymagan---jak-skutecznie-i-sprawnie-zarzadzac-projektami-IT-.

Inne ważne zagadnienie, ale spoza zakresu tego artykułu, to sytuacja, gdy względy prawne dotyczą nie tylko umowy, także do samego produktu IT. Wówczas prawnicy są istotnymi interesariuszami, których zalecenia wchodzą w skład wymagań.

4.    Odbiory, kryteria i testowanie

Podstawowym komponentem umowy wdrożeniowej jest opis kryteriów, procedury i metod odbioru produktu IT. Zwłaszcza, jeśli załącznik merytoryczny opisany w poprzednim akapicie, czyli dokument analizy, specyfikacja wymagań, czy jakkolwiek go nazwiemy, jest niedostateczny, opis kryteriów odbioru staje się jego uzupełnieniem, rozstrzygającym dla prób stwierdzenia, czy i na ile dostarczony produkt spełnia warunki umowy. Rozważamy tutaj przede wszystkim tak zwany odbiór jakościowy; odbiór ilościowy jest prostszy i niczym nie różni się od zasad odbioru innych produktów, niż informatyczne.

W praktyce, umowy wdrożeniowe, jako główne kryterium i zarazem metodę odbioru jakościowego przewidują testy: załącznikiem merytorycznym do umowy jest więc często zestaw scenariuszy testowych, których wykonanie z wynikiem pozytywnym traktuje się potem jako dowód zgodności dostarczonego systemu z wymogami umowy.

W rzeczywistości, pojawia się tutaj mnóstwo wątpliwości, trudności i nieporozumień, które komplikują proces odbioru, w najgorszym razie mogą doprowadzić do kosztownych sporów w sądzie, a w każdym razie, powodują chaos i marnotrawstwo środków zarówno po stronie zamawiającego, jak i dostawcy. Podstawową przeszkodą jest z jednej strony niemal zupełna nieznajomość metod „testologii”, czyli istniejącej obszernej nauki o testowaniu, wśród prawników, a z drugiej strony, zupełne pomijanie potrzeb i realiów umów wdrożeniowych w licznych książkach i szkoleniach dla specjalistów testowania, w tym w popularnej serii certyfikatów ISTQB (istqb.org). Słowo „odbiór” jest niemal nieznane wśród specjalistów testowania, zastępuje je pojęcie „testów akceptacyjnych”.

Tematy, ważne z punktu widzenia umów wdrożeniowych, takie jak sposoby weryfikacji (nie tylko testy!), weryfikacja a walidacja, moment rozpoczęcia korzystania produkcyjnego a odbiór, możliwość odbioru warunkowego, jednostronny odbiór, podział testów między zamawiającego a wykonawcę, wreszcie wymagana staranność testów odbiorczych, wszystko to można by interesująco naświetlić z punktu widzenia zasad testowania, ale minimum, to nie artykuł, lecz jednodniowe szkolenie „testowanie dla prawników”, które może uda mi się kiedyś zrealizować. Tutaj ograniczę się do jednego przykładu, mam nadzieję, że przekonywującego, pokazującego korzyści łącznia prawa umów wdrożeniowych i zasad testowania.

Otóż testy odbiorcze („akceptacyjne” w terminologii testowej) można znacznie skrócić i przyśpieszyć, a także istotnie zmniejszyć ich dramatyczność, spowodowaną wielką liczbą wykrywanych przez nie w ostatniej chwili błędów, gdyby wykorzystać, powszechnie znaną analitykom testowym, zasadę znacznego udziału testowania wcześniejszego w procesie odbioru. Ze strony zamawiającego, wymagałoby to współudziału w projekcie. Metoda agile, zakładająca przyrostowe (po kawałku) dostawy produktu, może być dobry sposobem na realizację tego postulatu.

5.    Co dalej?

Myślę, że temat warto drążyć dalej i (1) zapraszam do dyskusji – bogdan.bereza@victo.eu; (2) myślę, że nie od rzeczy byłoby jakieś przedsięwzięcie o takim profilu, wspólnie zorganizowane przez prawników oraz informatyków. Spróbujemy!

Brak komentarzy:

Prześlij komentarz