(źr. COMPUTERWORLD 7/2014)
(źr. COMPUTERWORLD 7/2014)

Tym razem króciutki wpis. Pragnę polecić numer 7/2014 COMPUTERWORLD a w nim (głównie, cały numer warto poznać ;)). Numer ten zawiera bardzo wartościowy artykuł „Pięć typowych błędów w umowach wdrożeniowych” Pana Marcina Maruty (Kancelaria Radców Prawnych Maruta i Wspólnicy).

Pan Maruta wskazuje, jako kluczową przyczynę wielu problemów z wdrożeniami (a konkretnie z kontraktami na ich realizację) jest źle sformułowany, a nie raz po prostu brak, przedmiot umowy. Przyznam, że banan przy moim uśmiechu na twarzy to pikuś, jak pomyślałem, co myślą zwolennicy „zwinnych metod” czytając to (cytat w ramce). Jeżeli przedmiot umowy (jego opis) to tak na prawdę efekt pierwszego etapu realizacji tej umowy (czyli po jej podpisaniu) wykonany przez dostawcę, to kłopoty niemalże gwarantowane.

Kolejna plaga, to forma realizacji umowy, czyli metodyka. Wniosek jest jeden: szukasz kłopotów to nie zapisuj tego co uzgadniasz i co robisz, jak zmieniasz zakres umowy lub harmonogram (są często załącznikami do umów) rób to niedbale.

Ale nie jest tu moim celem streszczanie tego napisał Pan Maruta, raczej staram się zachęcić do lektury tego numeru pisma. Wniosek jest jeden: realizacja umowy powinna byś dobrze zarządzanym i dokumentowanym procesem. Nikt nikomu nie życzy problemów, ale brak „śladów” po realizowanych zadaniach, źle opisany zakres umowy mści się po wielokroć, tak w sądzie jak i przy próbie zawarcia ugody, w przypadku jakichkolwiek problemów z jej realizacją.

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. jacek2v

    W umowach nie jest problemem napisanie czegoś lub nie, ale brak zrozumienia co się podpisuje 😀

    1. Jaroslaw Zelinski

      Prawda, podpisanie umowy zawierającej budżet i termin bez opisu co powstanie, faktycznie świadczy o kompletnym niezrozumieniu tego co się podpisuje 😉

  2. Arkadiusz Koralewski

    Dlatego właśnie według mnie Agile sprawdza się w 2 przypadkach:
    1. Oprogramowanie wewnętrzne
    2. Jeżeli umowy dotyczą kolejnych sprintów(wtedy znamy przedmiot umowy)

    Zresztą to jest przecież klucz Agile by każdy sprint był działającym oprogramowaniem to dlaczego nie nadać mu osobnej umowy?

    1. Jaroslaw Zelinski

      nie trzeba mu nadawać nazwy, bo wystarczy to „działające oprogramowanie” tak opisać, by można było stwierdzić, że coś nowego powstało o co to jest, czyli dzieło…..

Dodaj komentarz

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