Wprowadzenie

Od czasu do czasu jestem proszony o audyty dokumentacji projektów. Ma to miejsce, albo gdy jestem angażowany do projektu będącego kolejnym podejściem do wdrożenia, albo w sporach, także przedsądowych, między dostawcą oprogramowania i zamawiającym. Bywa, że jest to już etap pisania opinii dla sądu. Tu razem kilka spostrzeżeń z tych analiz.

Na marginesie. W sporach przedsądowych i sądowych wynik ekspertyzy absolutnie nie może być “zamówiony”, czego niestety często oczekują, nie raz wręcz żądają pod groźbą odmowy zapłaty za tę usługę, zamawiający takie ekspertyzy. Bywa to tym bardziej żenujące, że roszczenia takie wysuwają czasami prawnicy zlecających, czyli osoby znające prawo i – teoretycznie – stosujący zasady etyki w swojej pracy.

Wiele lat uważałem, że winni są dostawcy, którzy powinni wykazać się możliwie najwyższym profesjonalizmem, a tego nie robią. Jakiś czas temu zmieniłem jednak zdanie (nie o profesjonalizmie dostawców).

Poza realizowanymi projektami, prowadzę także szkolenia oraz zajęcia ze studentami studiów niestacjonarnych i podyplomowych: to nie raz doświadczeni praktycy. Na wykładach i ćwiczeniach staram się pokazać “jak to robić dobrze”, jednym z elementów tego “jak to robić dobrze” jest “jak nie robić tego źle” i dyskusje na ten temat.

Dlaczego zmieniłem zdanie?

Zarówno własne doświadczenie, jak i dyskusje ze studentami, przekonały mnie, że generalnie celem dostawcy jest maksymalizacja zysków. Co mi stale mówią uczący się u mnie praktycy? Klient nasz pan, mamy robić wszystko co chce klient bo on za to płaci, a to, czy to co klient chce ma sens, nie ma znaczenia bo to problem klienta (chyba każdy konsultant i programista dostawcy słyszy to od swojego przełożonego raz dziennie).

Jak klient nie wie czego chce, to na jego koszt próbujemy.

W 2018 artykuł o porażce wdrożenia w LID kończyłem słowami:

Dziwi mnie, że wszyst­kie te, doświad­czo­ne poraż­ką, fir­my mają dostęp do tej samej wie­dzy co np. ja, a mimo to zarzą­dy tych firm wie­rzą bez­gra­nicz­nie dostaw­com opro­gra­mo­wa­nia i wie­rzą, że opi­sy­wa­ne od lat przy­czy­ny pora­żek u nich nie wystąpią? (źr.: Porażka za 2 mld zł. Lidl wycofuje się z wdrożenia SAP – Jarosław Żeliński IT-Consulting)

więc winny jest zamawiający…

Umowa efektu a staranne działanie

W prawie cywilnym wyróżniono dwie podstawowe formy świadczenia zamówionej usługi:

1. Umowa o dzieło
2. Umowa zlecenia

Scharakteryzowane zostały w następujący sposób:

Umowa o dzieło

Art. 627. Przez umowę o dzieło przyjmujący zamówienie zobowiązuje się do wykonania oznaczonego dzieła, a zamawiający do zapłaty wynagrodzenia.

Zlecenie

Art. 734. § 1. Przez umowę zlecenia przyjmujący zlecenie zobowiązuje się do dokonania określonej czynności prawnej dla dającego zlecenie.

§ 2. W braku odmiennej umowy zlecenie obejmuje umocowanie do wykonania czynności w imieniu dającego zlecenie. Przepis ten nie uchybia przepisom o formie pełnomocnictwa.

.

W powszechnej i utrwalonej opinii prawników i w orzecznictwie przyjmuje się, że:

“Umowa zlecenia jest umową starannego działania. Zleceniobiorca zobowiązuje się do starannego działania i za to właśnie odpowiada, a nie, jak w przypadku umowy o dzieło, za rezultat pracy. W umowie należy więc dokładnie opisać czynności, jakie ma wykonywać zleceniobiorca, by później można było ocenić, czy zlecenie zostało wykonane oraz czy zostało wykonane w sposób staranny.” . A także, że “…można stwierdzić, iż w zobowiązaniach starannego działania dłużnik zobowiązuje się jedynie do dołożenia należytej staranności w zmierzaniu do ustalonego celu, z tym że jego osiągnięcie pozostaje poza treścią stosunku zobowiązaniowego. Natomiast w przypadku zobowiązania rezultatu na dłużniku ciąży powinność osiągnięcia oznaczonego z góry, sprecyzowanego rezultatu, przy czym ten rezultat to określony fakt, w nastąpieniu którego wierzyciel jest zainteresowany, prawny i ekonomiczny skutek oznaczony w treści zobowiązania, nie zaś sama czynność, którą dłużnik powinien podjąć.” .

Podsumowując można stwierdzić, że

1. Umowa o dzieło to umowa, w której dający zamówienie z góry opisuje to co chce otrzymać (dzieło), a przyjmujący zamówienie zobowiązuje się to dostarczyć (wykonać dzieło).
2. Zlecenie to umowa, w której przyjmujący zlecenie działa w imieniu dającego zlecenie, w konsekwencji za efekt zleconej pracy odpowiada dający zlecenie.

Znakomita większość umów na dostarczenie oprogramowania to, umowy starannego działania, a tak zwane umowy “agile” mają taki charakter z zasady. Tu za uzyskany efekt zawsze odpowiada Zamawiający.

A jeżeli dostawca jest nierzetelny? Jest takie ryzyko, jednak odpowiedzialnością zamawiającego jest także nadzór na pracami wykonawcy!

Proces dostarczenia oprogramowania

Inżynieria oprogramowania, na tle innych obszarów inżynierii, jest młodą dziedziną, która nie wykształciła dedykowanego prawodawstwa, tak jak np. inżynieria budowlana, która ma “swoje” prawo budowlane. Z tego też powodu, jedynym źródłem opisów postępowania są tak zwane dobre praktyki, standardy oraz analogie, stosowane także – w obszarze inżynierii – do prawa budowlanego.

Na diagramie ‘Iteracyjno-przyrostowy proces tworzenia oprogramowania’ zobrazowano standardowy proces dostarczania rozwiązania jakim jest oprogramowanie . Obecnie, z uwagi na tempo zmian w gospodarce, zaleca się by jedna ‘pętla iteracyjna rozwoju i utrzymania’ nie przekraczała w czasie jednego roku budżetowego, jednak preferowanym okresem jest pół roku z uwagi na to, że sztywne uzależnianie wdrażania oprogramowania wspomagającego zarządzanie, od rygorów rocznych okresów budżetowych było by znaczącym utrudnieniem w toku wdrażania zmian w firmach.

Projekty małe to projekty będące pojedynczą iteracją. Dobrą praktyką postępowania dla projektów większych jest dzielenie ich na przyrostowe iteracje (w kolejnych cyklach pętli iteracji wdrażane są kolejne funkcjonalności lub moduły) . Z reguły robi to wtedy wykonawca przyjmujący zamówienie . Co do zasady, za specyfikowanie wymagań i jakość tej specyfikacji, w każdym rodzaju inżynierii, odpowiada zamawiający . Zamawiający jest jedynym tu podmiotem, znającym swój cel biznesowy, jako podmiot zamawia u dostawcy produkt a nie efekt biznesowy jaki ma zamiar osiągnąć, za efekt efekt biznesowy z zasady odpowiada “biznes” . 

W tym miejscu, należy zwrócić uwagę na bardzo ważny fakt: w przypadku umowy efektu, kolejne iteracje to uszczegółowienie i implementacja funkcjonalności opisanych w umowie, a nie kolejne nowe funkcjonalności. Nowe funkcjonalności powstają w toku rozwoju JUŻ WDROŻONEGO I POPRAWNIE DZIAŁAJĄCEGO oprogramowania.

Podsumowanie

Projekty wdrożeniowe (dostarczanie oprogramowania) mogą być realizowane przez bieżące zlecanie konkretnych prac usługodawcy, lub poprzez opisanie oczekiwanego efektu jako wymaganego rozwiązania i zawarcie Umowy o dzieło z przyjmującym zamówienie, co zobrazowano na diagramie Podsumowanie stanu wiedzy. W obu przypadkach Zamawiający ponosi skutki swojej decyzji bo:

1. jako zleceniodawca (umowy T&M) sam ustala co i jak ma zostać wykonane,
2. jako zamawiający określony efekt (umowy o dzieło), sam ustala oczekiwany efekt (produkt) w dniu zawarcia umowy (jako opis przedmiotu zamówienia).

Odpowiedzialność przyjmującego zamówienia polega albo na starannym działaniu, albo na zgodności tego co dostarczy z tym co zamówiono, w rozumieniu oczekiwanego efektu. Jeżeli przedmiotem zamówienia jest oprogramowanie, czyli narzędzie pracy zamawiającego, tylko zamawiający ponosi odpowiedzialność za skutki wdrożenia tego co zamówił . Dostawca odpowiada wyłącznie za przedmiot umowy .

Tak więc zamawiający zawsze dostanie to co chce, ale nie koniecznie to co jest mu faktycznie potrzebne. Innymi słowy, na rynku rządzonym przez dochody i zyski, dostawca oprogramowania zawsze będzie pracował pod dyktando zamawiającego (lub za jego zgodą) i będzie to robił do wyczerpana budżetu zamawiającego.

Bardzo ciekawe są blogi dostawców oprogramowania. Wielu ich autorów faktycznie stara się, ale cóż… jeden z ciekawszych wpisów na ten temat jest zatytułowany “The art (and science) of collecting requirements: top 3 mistakes vendors make“. Autor z perspektywy dostawcy, zwraca uwagę na trzy kluczowe przyczyny porażek: uznanie, że to użytkownik odpowiada za wymagania, mieszanie wymagań z pomysłami na ich realizację, niedoceniania macierzy śladowania. To, popełnianie tych błędów, niestety jest najczęściej spotykaną cechą analiz prowadzanych właśnie przez dostawców oprogramowania, a za wszystko i tak płaci nabywca. W bardziej naukowy sposób (szczególnie krytykując wymagania pisane językiem naturalnym przez zamawiającego) opisali to bardzo dokładnie Šenkýř i Kroha .

Konkluzja jest taka, że za nieudane wdrożenia odpowiada zawsze zamawiający.

Główną winą zamawiającego jest to, że zamawia usługi, których istoty nie rozumie więc pozostawia wykonawcę praktycznie bez nadzoru, oddając mu niemalże nieograniczone uprawnienia co do zakresu projektu. Pierwszym zaś samobójczym krokiem jest zlecenie analizy wymagań i projektowanie wybranemu wcześniej dostawcy oprogramowania. Biorąc pod uwagę rynkowy konflikt interesu dostawcy i odbiorcy (zamawiający maksymalizuje żądania a dostawca maksymalizuje zysk), jest to prosta droga do porażki, jaką jest także znaczne przepłacenie.

Pytani pracownicy dostawców zawsze odpowiadają, że przecież celem jest “dowiezienie projektu”, niestety nie jest jednak żadną sztuką “w końcu dostarczyć oprogramowanie”. Sztuką jest to zrobić zgodnie z obietnicą daną pierwszego dnia projektu, a z własnego wieloletniego doświadczenia wiem, że to możliwe. Sztuką jest także to, by dalszy rozwój i utrzymanie nie były najdroższym projektem świata.

Szanowni państwo: podpisując z dostawcą oprogramowania umowę “czas i materiał”, i zlecając temu dostawcy także analizę wymagań, kopiecie sobie grób.

Za co odpowiada dostawca? Za staranne działanie, jednak stosowanie nieadekwatnych metod nie jest działaniem niestarannym, i dlatego w sądach z reguły przegrywają zamawiający a nie dostawcy oprogramowania. Wykazanie starannego działania przez dostawcę oprogramowania jest bardzo proste: comiesięczne opłacone faktury “za pracę” dostawcy oprogramowania są tak naprawdę uznaniem jego starannego działania przez zamawiającego. Pozostaje tu jedynie kwestia etyki dostawcy, ale to temat na osobne opracowanie.

Tak więc podejmując decyzję o wdrożeniu pomyślcie Państwo o ryzyku:

Kontynuacja wątku: Myślenie życzeniowe….

Źródła