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

Tym razem kró­ciut­ki wpis. Pragnę pole­cić numer 7/2014 COMPUTERWORLD a w nim (głów­nie, cały numer war­to poznać ;)). Numer ten zawie­ra bar­dzo war­to­ścio­wy arty­kuł Pięć typo­wych błę­dów w umo­wach wdro­że­nio­wych” Pana Marcina Maruty (Kancelaria Radców Prawnych Maruta i Wspólnicy).

Pan Maruta wska­zu­je, jako klu­czo­wą przy­czy­nę wie­lu pro­ble­mów z wdro­że­nia­mi (a kon­kret­nie z kon­trak­ta­mi na ich reali­za­cję) jest źle sfor­mu­ło­wa­ny, a nie raz po pro­stu brak, przed­miot umo­wy. Przyznam, że banan przy moim uśmie­chu na twa­rzy to pikuś, jak pomy­śla­łem, co myślą zwo­len­ni­cy zwin­nych metod” czy­ta­jąc to (cytat w ram­ce). Jeżeli przed­miot umo­wy (jego opis) to tak na praw­dę efekt pierw­sze­go eta­pu reali­za­cji tej umo­wy (czy­li po jej pod­pi­sa­niu) wyko­na­ny przez dostaw­cę, to kło­po­ty nie­mal­że gwarantowane.

Kolejna pla­ga, to for­ma reali­za­cji umo­wy, czy­li meto­dy­ka. Wniosek jest jeden: szu­kasz kło­po­tów to nie zapi­suj tego co uzgad­niasz i co robisz, jak zmie­niasz zakres umo­wy lub har­mo­no­gram (są czę­sto załącz­ni­ka­mi do umów) rób to niedbale.

Ale nie jest tu moim celem stresz­cza­nie tego napi­sał Pan Maruta, raczej sta­ram się zachę­cić do lek­tu­ry tego nume­ru pisma. Wniosek jest jeden: reali­za­cja umo­wy powin­na byś dobrze zarzą­dza­nym i doku­men­to­wa­nym pro­ce­sem. Nikt niko­mu nie życzy pro­ble­mów, ale brak śla­dów” po reali­zo­wa­nych zada­niach, źle opi­sa­ny zakres umo­wy mści się po wie­lo­kroć, tak w sądzie jak i przy pró­bie zawar­cia ugo­dy, w przy­pad­ku jakich­kol­wiek pro­ble­mó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 umo­wach nie jest pro­ble­mem napi­sa­nie cze­goś lub nie, ale brak zro­zu­mie­nia co się podpisuje 😀

    1. Jaroslaw Zelinski

      Prawda, pod­pi­sa­nie umo­wy zawie­ra­ją­cej budżet i ter­min bez opi­su co powsta­nie, fak­tycz­nie świad­czy o kom­plet­nym nie­zro­zu­mie­niu tego co się podpisuje 😉

  2. Arkadiusz Koralewski

    Dlatego wła­śnie według mnie Agile spraw­dza się w 2 przypadkach:
    1. Oprogramowanie wewnętrzne
    2. Jeżeli umo­wy doty­czą kolej­nych sprintów(wtedy zna­my przed­miot umowy)

    Zresztą to jest prze­cież klucz Agile by każ­dy sprint był dzia­ła­ją­cym opro­gra­mo­wa­niem to dla­cze­go nie nadać mu osob­nej umowy?

    1. Jaroslaw Zelinski

      nie trze­ba mu nada­wać nazwy, bo wystar­czy to dzia­ła­ją­ce opro­gra­mo­wa­nie” tak opi­sać, by moż­na było stwier­dzić, że coś nowe­go powsta­ło o co to jest, czy­li dzieło.….

Dodaj komentarz

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