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 (Dennis et al., 2012). 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 utrudnienie 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) (Larman, 2004). Z reguły robi to wtedy wykonawca przyjmujący zamówienie(Maciaszek, 2001). Co do zasady, za specyfikowanie wymagań i jakość tej specyfikacji, w każdym rodzaju inżynierii, odpowiada zamawiający (Hay, 2003). 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ąć (Ackoff i in., 2007). W tym miejscu, należy zwrócić uwagę na bardzo ważny fakt, że w przypadku umowy efektu, kolejne iteracje to uszczegółowienie i implementacja funkcjonalności opisanych w umowie, a nie kolejne nowe funkcjonalności.
Iteracyjno-przyrostowy proces tworzenia oprogramowania

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:

ryzyko, popper, decyzje
Karl Popper Ryzyko i decyzje

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

Źródła

Jarosław Żeliński

Jarosław Żeliński: autor, badacz i praktyk analizy systemowej organizacji: Od roku 1991 roku, nieprzerwanie, realizuje projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzi samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzi wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie.) Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów. Prawa autorskie: Zgodnie z art. 25 ust. 1 pkt. 1) lit. b) ustawy o prawie autorskim i prawach pokrewnych zastrzegam, że dalsze rozpowszechnianie artykułów publikowanych w niniejszym serwisie jest zabronione bez indywidualnej zgody autora (patrz Polityki Strony).

Ten post ma 4 komentarzy

  1. Marcin

    Od 7 lat tworzymy aplikacje na zamówienie. Otrzymujemy jedno zapytania na tydzień. Nie zdarzyło nam się jeszcze otrzymać dokumentacji wykonanej przez firmę zewnętrzną. Zgłaszają się do nas firmy małe, średnie i wielkie.

    1. Jarosław Żeliński

      Od prawie 20 lat robię takie dokumenty dla zamawiających, przyznaje, że mało firm korzysta z tej usługi. Przyznaję, że mało ludzi w ogóle robi takie dokumenty, ale nie jestem jedyny który takie dokumenty opracowuje (tam, gdzie firmy na prawdę dbają o swoje know-how i prawa autorskie, powstają one ZAWSZE :), ma moim blogu jest wiele odnośników do innych stron o podobnych charakterze, do literatury). Moimi klientami są firmy: małe, średnie i nawet wielkie (np. KGHM SA).

      Polecam raporty Chaos Report: 90% projektów łącznie: średnich i dużych, to porażki terminów i kosztów. Ja (moi klienci) od 20 lat nie mam porażek, zdarza sie, że rozwiązuje umowę przed czasem, gdy klient łamie warunki zawartej umowy. Samo “dowiezienie projektu” to żaden sukces.

      Od lat słyszę, że:
      – dostawcy nie chcą takich dokumentów bo “oni by to zrobili inaczej” (narzucam dość ostre rygory na kompetencje dostawcy i technologię),
      – dostawcy nie chcą takich dokumentów bo to wymusza na nich umowę o dzieło, a programiści wolą na koszt klienta eksperymentować i się uczyć.

      Moje doświadczenie:
      – w zasadzie w 100% przypadków jestem angażowany do drugiego, nie raz trzeciego, podejścia do wdrożenia (poprzednie to zarzucone lub wstrzymane projekty),
      – w 100% kolejna realizacja, z dobrymi dokumentami, zawsze okazuje się, jako całość, dla klienta i tańsza i szybsza, mimo tego, że trzeba mi zapłacić za analizę i projektowanie, a potem za nadzór autorski (lista na pierwszej stronie bloga).
      – w 90% przypadków developer podejmował próby usunięcia mnie z projektu lub pominięcia, bo mu “przeszkadzam”, udało się to tylko dwa razy w mojej karierze, oba te projekty miały potem kłopoty z ochroną know-how i kosztem utrzymania i rozwoju aplikacji.

      Jest w tym kraju kilku developerów, którzy polecają mnie swoim klientom, bo jednak wolą wdrożenia realizowane w planowanym terminie i zakresie ustalonym na początku. Zapraszam :).

      To oczywiście nie opinia o Pana firmie, bo nie znam ani Pana ani Pana firmy, ani Pana klientów. Opisałem tu znane mi z literatry naukowej wyniki badań oraz moje doświadczenie. Tak, uważam że nieudane wdrożenia do wina zamawiającego, że poszedł do dostawcy i przekazał mu w 100% pałeczkę, mimo tego, że dostawca ma konflikt interesu. To czy dany dostawca robi to świadomie czy nie, nie wiem.

      (co i w jakiej technologii tworzycie?)

    2. Jarosław Żeliński

      Dodam jeszcze, że: to czy dana firma developerska robi coś dobrze, nie zależy od tego czy “dowozi projekty”, a od tego jak ich realizacje wyglądają kosztowo i terminowo na tle innych. Mało kto ma możliwość wykonania tego samego projektu na dwa różne sposoby, ja zawsze (bo z reguły robię po kimś to samo jeszcze raz)… Po drugie, jeżeli w odpowiedzi na identyczne dokumenty (zapytanie) otrzymuję od różnych developerów, wyceny różniące się nawet o rząd wielkości, to wiele to mówi i o rynku i o tych deweloperach. Jeżeli ktoś w 2020 roku “klei” wszystko czego się złapie, metoda “relacyjna baza danych, język SQL i reszta kodu” to znaczy, że architektonicznie nadal tkwi na przełomie lat 80/90-tych ubiegłego wieku.

Dodaj komentarz

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.