Kto winien porażki projektu? Zamawiający!

Od cza­su do cza­su jestem pro­szo­ny o audy­ty doku­men­ta­cji pro­jek­tów. Ma to miej­sce, albo gdy jestem anga­żo­wa­ny do pro­jek­tu będą­ce­go kolej­nym podej­ściem do wdro­że­nia, albo w spo­rach przed­są­do­wych mię­dzy dostaw­cą opro­gra­mo­wa­nia i zama­wia­ją­cym. Tu razem kil­ka spo­strze­żeń z tych analiz.

Na mar­gi­ne­sie. W spo­rach przed­są­do­wych i sądo­wych wynik eks­per­ty­zy abso­lut­nie nie może być zamó­wio­ny”, cze­go nie­ste­ty czę­sto ocze­ku­ją, nie raz wręcz żąda­ją pod groź­bą odmo­wy zapła­ty za tę usłu­gę, zama­wia­ją­cy takie eks­per­ty­zy. Bywa to tym bar­dziej żenu­ją­ce, że rosz­cze­nia takie wysu­wa­ją praw­ni­cy zle­ca­ją­cych, czy­li oso­by zna­ją­ce pra­wo i – teo­re­tycz­nie – sto­su­ją­cy zasa­dy ety­ki w swo­jej pracy.

Wiele lat uwa­ża­łem, że win­ni są dostaw­cy, któ­rzy powin­ni wyka­zać się moż­li­wie naj­wyż­szym pro­fe­sjo­na­li­zmem, a tego nie robią. Jakiś czas temu zmie­ni­łem jed­nak zda­nie (nie o pro­fe­sjo­na­li­zmie dostawców). 

Poza reali­zo­wa­ny­mi pro­jek­ta­mi, pro­wa­dzę tak­że szko­le­nia oraz zaję­cia ze stu­den­ta­mi stu­diów nie­sta­cjo­nar­nych i pody­plo­mo­wych: to nie raz doświad­cze­ni prak­ty­cy. Na wykła­dach i ćwi­cze­niach sta­ram się poka­zać jak to robić dobrze”, jed­nym z ele­men­tów tego jak to robić dobrze” jest jak nie robić tego źle” i dys­ku­sje na ten temat. 

Dlaczego zmie­ni­łem zda­nie? I wła­sne doświad­cze­nie i dys­ku­sje ze stu­den­ta­mi prze­ko­na­ły mnie, że gene­ral­nie celem dostaw­cy jest mak­sy­ma­li­za­cja zysków. Co mi sta­le mówią uczą­cy się u mnie prak­ty­cy? Klient nasz pan, mamy robić wszyst­ko co chce klient bo on za to pła­ci, a to, czy to co klient chce ma sens, nie ma zna­cze­nia bo to pro­blem klien­ta (chy­ba każ­dy pro­gra­mi­sta sły­szy to od swo­je­go prze­ło­żo­ne­go raz dziennie). 

Jak klient nie wie cze­go chce, to na jego koszt pró­bu­je­my.

W 2018 arty­kuł o poraż­ce wdro­że­nia 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 wyco­fu­je się z wdro­że­nia SAP – Jarosław Żeliński IT-Consulting)

więc win­ny jest zamawiający… 

Ten arty­kuł to krót­ka ana­li­za warun­ków praw­nych i prak­tycz­nych reali­za­cji pro­jek­tów wdrożeniowych. 

Umowa efektu a staranne działanie

Poniższy tekst, to treść, któ­rą w róż­nych for­mach umiesz­czam jako wstęp do ekspertyz. 

W pra­wie cywil­nym wyróż­nio­no dwie pod­sta­wo­we for­my świad­cze­nia zamó­wio­nej usługi:

  1. Umowa o dzieło
  2. Umowa zle­ce­nia

Scharakteryzowane zosta­ły w nastę­pu­ją­cy sposób:

Umowa o dzieło

Art. 627. Przez umo­wę o dzie­ło przyj­mu­ją­cy zamó­wie­nie zobo­wią­zu­je się do wyko­na­nia ozna­czo­ne­go dzie­ła, a zama­wia­ją­cy do zapła­ty wynagrodzenia.

Zlecenie

Art. 734. § 1. Przez umo­wę zle­ce­nia przyj­mu­ją­cy zle­ce­nie zobo­wią­zu­je się do doko­na­nia okre­ślo­nej czyn­no­ści praw­nej dla dają­ce­go zlecenie.

§ 2. W bra­ku odmien­nej umo­wy zle­ce­nie obej­mu­je umo­co­wa­nie do wyko­na­nia czyn­no­ści w imie­niu dają­ce­go zle­ce­nie. Przepis ten nie uchy­bia prze­pi­som o for­mie pełnomocnictwa.

.

W powszech­nej i utrwa­lo­nej opi­nii praw­ni­ków i w orzecz­nic­twie przyj­mu­je się, że:

Umowa zle­ce­nia jest umo­wą sta­ran­ne­go dzia­ła­nia. Zleceniobiorca zobo­wią­zu­je się do sta­ran­ne­go dzia­ła­nia i za to wła­śnie odpo­wia­da, a nie, jak w przy­pad­ku umo­wy o dzie­ło, za rezul­tat pra­cy. W umo­wie nale­ży więc dokład­nie opi­sać czyn­no­ści, jakie ma wyko­ny­wać zle­ce­nio­bior­ca, by póź­niej moż­na było oce­nić, czy zle­ce­nie zosta­ło wyko­na­ne oraz czy zosta­ło wyko­na­ne w spo­sób sta­ran­ny.” . A tak­że, że „…moż­na stwier­dzić, iż w zobo­wią­za­niach sta­ran­ne­go dzia­ła­nia dłuż­nik zobo­wią­zu­je się jedy­nie do doło­że­nia nale­ży­tej sta­ran­no­ści w zmie­rza­niu do usta­lo­ne­go celu, z tym że jego osią­gnię­cie pozo­sta­je poza tre­ścią sto­sun­ku zobo­wią­za­nio­we­go. Natomiast w przy­pad­ku zobo­wią­za­nia rezul­ta­tu na dłuż­ni­ku cią­ży powin­ność osią­gnię­cia ozna­czo­ne­go z góry, spre­cy­zo­wa­ne­go rezul­ta­tu, przy czym ten rezul­tat to okre­ślo­ny fakt, w nastą­pie­niu któ­re­go wie­rzy­ciel jest zain­te­re­so­wa­ny, praw­ny i eko­no­micz­ny sku­tek ozna­czo­ny w tre­ści zobo­wią­za­nia, nie zaś sama czyn­ność, któ­rą dłuż­nik powi­nien pod­jąć.” .

Podsumowując moż­na stwier­dzić, że

  1. Umowa o dzie­ło to umo­wa, w któ­rej dają­cy zamó­wie­nie z góry opi­su­je to co chce otrzy­mać (dzie­ło), a przyj­mu­ją­cy zamó­wie­nie zobo­wią­zu­je się to dostar­czyć (wyko­nać dzieło).
  2. Zlecenie to umo­wa, w któ­rej przyj­mu­ją­cy zle­ce­nie dzia­ła w imie­niu dają­ce­go zle­ce­nie, w kon­se­kwen­cji za efekt zle­co­nej pra­cy odpo­wia­da dają­cy zlecenie.

Znakomita więk­szość umów na dostar­cze­nie opro­gra­mo­wa­nia to, umo­wy sta­ran­ne­go dzia­ła­nia, a tak zwa­ne umo­wy agi­le” mają taki cha­rak­ter z zasa­dy. Tu za uzy­ska­ny efekt zawsze odpo­wia­da Zamawiający.

A jeże­li dostaw­ca jest nie­rze­tel­ny? Jest takie ryzy­ko, jed­nak odpo­wie­dzial­no­ścią zama­wia­ją­ce­go jest tak­że nad­zór na pra­ca­mi wykonawcy!

Proces dostarczenia oprogramowania

Inżynieria opro­gra­mo­wa­nia, na tle innych obsza­rów inży­nie­rii, jest mło­dą dzie­dzi­ną, któ­ra nie wykształ­ci­ła dedy­ko­wa­ne­go pra­wo­daw­stwa, tak jak np. inży­nie­ria budow­la­na, któ­ra ma swo­je” pra­wo budow­la­ne. Z tego też powo­du, jedy­nym źró­dłem opi­sów postę­po­wa­nia są tak zwa­ne dobre prak­ty­ki, stan­dar­dy oraz ana­lo­gie, sto­so­wa­ne tak­że – w obsza­rze inży­nie­rii – do pra­wa 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-przy­ro­sto­wy pro­ces two­rze­nia oprogramowania

Na dia­gra­mie «Iteracyjno-przy­ro­sto­wy pro­ces two­rze­nia opro­gra­mo­wa­nia» zobra­zo­wa­no stan­dar­do­wy pro­ces dostar­cza­nia roz­wią­za­nia jakim jest opro­gra­mo­wa­nie . Obecnie, z uwa­gi na tem­po zmian w gospo­dar­ce, zale­ca się by jed­na «pętla ite­ra­cyj­na roz­wo­ju i utrzy­ma­nia» nie prze­kra­cza­ła w cza­sie jed­ne­go roku budże­to­we­go, jed­nak pre­fe­ro­wa­nym okre­sem jest pół roku z uwa­gi na to, że sztyw­ne uza­leż­nia­nie wdra­ża­nia opro­gra­mo­wa­nia wspo­ma­ga­ją­ce­go zarzą­dza­nie, od rygo­rów rocz­nych okre­sów budże­to­wych było by zna­czą­cym utrud­nie­nie w toku wdra­ża­nia zmian w fir­mach. Projekty małe to pro­jek­ty będą­ce poje­dyn­czą ite­ra­cją. Dobrą prak­ty­ką postę­po­wa­nia dla pro­jek­tów więk­szych jest dzie­le­nie ich na przy­ro­sto­we ite­ra­cje (w kolej­nych cyklach pętli ite­ra­cji wdra­ża­ne są kolej­ne funk­cjo­nal­no­ści lub modu­ły) . Z regu­ły robi to wte­dy wyko­naw­ca przyj­mu­ją­cy zamó­wie­nie . Co do zasa­dy, za spe­cy­fi­ko­wa­nie wyma­gań i jakość tej spe­cy­fi­ka­cji, w każ­dym rodza­ju inży­nie­rii, odpo­wia­da zama­wia­ją­cy . Zamawiający jest jedy­nym tu pod­mio­tem, zna­ją­cym swój cel biz­ne­so­wy, jako pod­miot zama­wia u dostaw­cy pro­dukt a nie efekt biz­ne­so­wy jaki ma zamiar osią­gnąć, za efekt efekt biz­ne­so­wy z zasa­dy odpo­wia­da biz­nes” 

W tym miej­scu, nale­ży zwró­cić uwa­gę na bar­dzo waż­ny fakt: w przy­pad­ku umo­wy efek­tu, kolej­ne ite­ra­cje to uszcze­gó­ło­wie­nie i imple­men­ta­cja funk­cjo­nal­no­ści opi­sa­nych w umo­wie, a nie kolej­ne nowe funk­cjo­nal­no­ści. Nowe funk­cjo­nal­no­ści powsta­ją w toku roz­wo­ju JUŻ WDROŻONEGO I POPRAWNIE DZIAŁAJĄCEGO oprogramowania. 

Podsumowanie

Projekty wdro­że­nio­we (dostar­cza­nie opro­gra­mo­wa­nia) mogą być reali­zo­wa­ne przez bie­żą­ce zle­ca­nie kon­kret­nych prac usłu­go­daw­cy, lub poprzez opi­sa­nie ocze­ki­wa­ne­go efek­tu jako wyma­ga­ne­go roz­wią­za­nia i zawar­cie Umowy o dzie­ło z przyj­mu­ją­cym zamó­wie­nie, co zobra­zo­wa­no na dia­gra­mie Podsumowanie sta­nu wie­dzy. W obu przy­pad­kach Zamawiający pono­si skut­ki swo­jej decy­zji bo:

  1. jako zle­ce­nio­daw­ca (umo­wy T&M) sam usta­la co i jak ma zostać wykonane,
  2. jako zama­wia­ją­cy okre­ślo­ny efekt (umo­wy o dzie­ło), sam usta­la ocze­ki­wa­ny efekt (pro­dukt) w dniu zawar­cia umo­wy (jako opis przed­mio­tu zamówienia).

Odpowiedzialność przyj­mu­ją­ce­go zamó­wie­nia pole­ga albo na sta­ran­nym dzia­ła­niu, albo na zgod­no­ści tego co dostar­czy z tym co zamó­wio­no, w rozu­mie­niu ocze­ki­wa­ne­go efek­tu. Jeżeli przed­mio­tem zamó­wie­nia jest opro­gra­mo­wa­nie, czy­li narzę­dzie pra­cy zama­wia­ją­ce­go, tyl­ko zama­wia­ją­cy pono­si odpo­wie­dzial­ność za skut­ki wdro­że­nia tego co zamó­wił . Dostawca odpo­wia­da wyłącz­nie za przed­miot umo­wy .

Tak więc zama­wia­ją­cy zawsze dosta­nie to co chce, ale nie koniecz­nie to co jest mu fak­tycz­nie potrzeb­ne. Innymi sło­wy, na ryn­ku rzą­dzo­nym przez docho­dy i zyski, dostaw­ca opro­gra­mo­wa­nia zawsze będzie pra­co­wał pod dyk­tan­do zama­wia­ją­ce­go (lub za jego zgo­dą) i będzie to robił do wyczer­pa­na budże­tu zamawiającego. 

Bardzo cie­ka­we są blo­gi dostaw­ców opro­gra­mo­wa­nia. Wielu ich auto­rów fak­tycz­nie sta­ra się, ale cóż… jeden z cie­kaw­szych wpi­sów na ten temat jest zaty­tu­ło­wa­ny The art (and scien­ce) of col­lec­ting requ­ire­ments: top 3 mista­kes ven­dors make”. Autor z per­spek­ty­wy dostaw­cy, zwra­ca uwa­gę na trzy klu­czo­we przy­czy­ny pora­żek: uzna­nie, że to użyt­kow­nik odpo­wia­da za wyma­ga­nia, mie­sza­nie wyma­gań z pomy­sła­mi na ich reali­za­cję, nie­do­ce­nia­nia macie­rzy śla­do­wa­nia. To, popeł­nia­nie tych błę­dów, nie­ste­ty jest naj­czę­ściej spo­ty­ka­ną cechą ana­liz pro­wa­dza­nych wła­śnie przez dostaw­ców opro­gra­mo­wa­nia, a za wszyst­ko i tak pła­ci nabyw­ca. W bar­dziej nauko­wy spo­sób (szcze­gól­nie kry­ty­ku­jąc wyma­ga­nia pisa­ne języ­kiem natu­ral­nym przez zama­wia­ją­ce­go) opi­sa­li to bar­dzo dokład­nie Šenkýř i Kroha .

Konkluzja jest taka, że za nie­uda­ne wdro­że­nia odpo­wia­da zawsze zamawiający. 

Główną winą zama­wia­ją­ce­go jest to, że zama­wia usłu­gi, któ­rych isto­ty nie rozu­mie więc pozo­sta­wia wyko­naw­cę prak­tycz­nie bez nad­zo­ru, odda­jąc mu nie­mal­że nie­ogra­ni­czo­ne upraw­nie­nia co do zakre­su pro­jek­tu. Pierwszym zaś samo­bój­czym kro­kiem jest zle­ce­nie ana­li­zy wyma­gań i pro­jek­to­wa­nie wybra­ne­mu wcze­śniej dostaw­cy opro­gra­mo­wa­nia. Biorąc pod uwa­gę ryn­ko­wy kon­flikt inte­re­su dostaw­cy i odbior­cy (zama­wia­ją­cy mak­sy­ma­li­zu­je żąda­nia a dostaw­ca mak­sy­ma­li­zu­je zysk), jest to pro­sta dro­ga do poraż­ki, jaką jest tak­że znacz­ne przepłacenie. 

Pytani pra­cow­ni­cy dostaw­ców zawsze odpo­wia­da­ją, że prze­cież celem jest dowie­zie­nie pro­jek­tu”, nie­ste­ty nie jest jed­nak żad­ną sztu­ką w koń­cu dostar­czyć opro­gra­mo­wa­nie”. Sztuką jest to zro­bić zgod­nie z obiet­ni­cą daną pierw­sze­go dnia pro­jek­tu, a z wła­sne­go wie­lo­let­nie­go doświad­cze­nia wiem, że to moż­li­we. Sztuką jest tak­że to, by dal­szy roz­wój i utrzy­ma­nie nie były naj­droż­szym pro­jek­tem świata.

Szanowni pań­stwo: pod­pi­su­jąc z dostaw­cą opro­gra­mo­wa­nia umo­wę czas i mate­riał”, i zle­ca­jąc temu dostaw­cy tak­że ana­li­zę wyma­gań, kopie­cie sobie grób. 

Za co odpo­wia­da dostaw­ca? Za sta­ran­ne dzia­ła­nie, jed­nak sto­so­wa­nie nie­ade­kwat­nych metod nie jest dzia­ła­niem nie­sta­ran­nym, i dla­te­go w sądach z regu­ły prze­gry­wa­ją zama­wia­ją­cy a nie dostaw­cy opro­gra­mo­wa­nia. Wykazanie sta­ran­ne­go dzia­ła­nia przez dostaw­cę opro­gra­mo­wa­nia jest bar­dzo pro­ste: comie­sięcz­ne opła­co­ne fak­tu­ry za pra­cę” dostaw­cy opro­gra­mo­wa­nia są tak napraw­dę uzna­niem jego sta­ran­ne­go dzia­ła­nia przez zama­wia­ją­ce­go. Pozostaje tu jedy­nie kwe­stia ety­ki dostaw­cy, ale to temat na osob­ne opracowanie. 

Tak więc podej­mu­jąc decy­zję o wdro­że­niu pomy­śl­cie Państwo o ryzyku:

ryzyko, popper, decyzje
Karl Popper Ryzyko i decyzje

Kontynuacja wąt­ku: Myślenie życze­nio­we.…

Źródła

Wiegers, K. E., & Beatty, J. (2013). Software requ­ire­ments (Third edi­tion). Microsoft Press, s divi­sion of Microsoft Corporation.
Wolak, G. J. (2019). Umowa o dzie­ło jako zobo­wią­za­nie rezul­ta­tu. https://​doi​.org/​1​0​.​3​4​6​9​7​/​2​451 – 0807-SP-2019 – 1‑006
Larman, C. (2005). Applying UML and pat­terns: an intro­duc­tion to object-orien­ted ana­ly­sis and design and ite­ra­ti­ve deve­lop­ment (3rd ed). Prentice Hall PTR, c2005.
Agaronian, A., Freyer, C. W. S., Bierbooms, C. G., Hoeijmakers, T. P. H., Jansen, T., Kafoe, T., Makantasis, I., Mankevic, K., Sinx, R. D., & Smits, I. M. (2019). Software Requirements Document. 133.
Šenkýř, D., & Kroha, P. (2019). Problem of Incompleteness in Textual Requirements Specification: Proceedings of the 14th International Conference on Software Technologies, 323 – 330. https://​doi​.org/​1​0​.​5​2​2​0​/​0​0​0​7​9​7​8​0​0​3​2​3​0​330
Ackoff, R. L., Magidson, J., Addison, H. J., & Ehrlich, A. (2007). Projektowanie ide­ału: kształ­to­wa­nie przy­szło­ści orga­ni­za­cji. Wyższa Szkoła Przedsiębiorczości i Zarządzania im. Leona Koźmińskiego : Wydawnictwa Akademickie i Profesjonalne.
Dennis, A., Wixom, B. H., & Roth, R. M. (2012). Systems ana­ly­sis and design (5th ed). John Wiley.

Rola analizy w umowie wdrożeniowej

Na stro­nie por­ta­lu analizawymagań.pl uka­zał się bar­dzo inte­re­su­ją­cy i war­to­ścio­wy wpis: wywiad z praw­ni­kiem, Łukaszem Węgrzynem. Zaczyna się tak:

Jakie są naj­częst­sze przy­czy­ny pro­ble­mów w umo­wach wdro­że­nio­wych i jakie są ich skut­ki z punk­tu widze­nia spo­rów sądo­wych na pol­skim ryn­ku IT?

Stosunkowo naj­częst­szym powo­dem spo­rów jest legen­dar­ny już zakres, a kon­kret­nie trud­ność w odpo­wie­dzi na pyta­nie o co tak napraw­dę się umówiliśmy.

Powodów takie­go sta­nu rze­czy jest wie­le. Jednym z nich jest mię­dzy inny­mi nie­wła­ści­wie wyko­na­na ana­li­za przed­wdro­że­nio­wa. Analiza to jeden z pod­sta­wo­wych załącz­ni­ków umo­wy wdro­że­nio­wej, wyzna­cza­ją­cy jej zakres, a zatem to, co ma zostać w wyni­ku pod­pi­sa­nia umo­wy zrealizowane.

Nierzadko ana­li­zy przed­wdro­że­nio­we posłu­gu­ją się gene­ral­ny­mi poję­cia­mi lub poję­cia­mi, któ­rych zna­cze­nie nie jest wystar­cza­ją­co jasno i pre­cy­zyj­nie okre­ślo­ne. Taka sytu­acja skut­ku­je z kolei dużą dowol­no­ścią inter­pre­ta­cyj­ną, a tym samym powo­du­je, że stro­ny umo­wy wcho­dzą w spór co do wła­ści­we­go brze­mie­nia kon­kret­nych zapi­sów ana­li­zy, któ­re decy­du­ją o zakre­sie umo­wy, czy­li o tym, co zosta­nie lub nie zosta­nie w wyni­ku umo­wy zrealizowane. 

Kolejna przy­czy­na pro­ble­mów nie jest zwią­za­na z tym ?CO? mamy zro­bić, ale ?JAK? to mamy zro­bić. W prak­ty­ce spro­wa­dza się do sytu­acji, w któ­rej stro­ny nie­wy­star­cza­ją­co jasno i pre­cy­zyj­nie opi­sa­ły w umo­wie poszcze­gól­ne eta­py prze­bie­gu wdro­że­nia. To bar­dzo czę­sty pro­blem, w rezul­ta­cie któ­re­go stro­ny zaczy­na­ją się prze­rzu­cać odpo­wie­dzial­no­ścią co do reali­za­cji kon­kret­nych dzia­łań nie­zbęd­nych dla wła­ści­wej, a co naj­waż­niej­sze efek­tyw­nej reali­za­cji pro­jek­tu wdro­że­nio­we­go. Stad już tyl­ko krok do eska­la­cji spo­ru i cał­ko­wi­tej klę­ski pro­jek­tu. (Źródło: Rola ana­li­zy w umo­wie wdro­że­nio­wej- wywiad z Łukaszem Węgrzynem)

W powyż­szym cyta­cie (a gorą­co pole­cam cały wywiad) wytłu­ści­łem kil­ka klu­czo­wych tez.

Zakres pro­jek­tu to fak­tycz­nie klucz, przede wszyst­kim MUSI być zamknię­ty. Zaraz ode­zwą się zwo­len­ni­cy zwin­ne­go Agile.. ale poję­cie zamknię­ty zakres pro­jek­tu” to nie żaden wodo­spad, zamknię­ty zakres pro­jek­tu ozna­cza tyl­ko i wyłącz­nie to, że ist­nie­je (zawar­to w umo­wie) kry­te­ria pozwa­la­ją­ce stwier­dzić, że (czy?) umo­wę wykonano.

Niewłaściwie wyko­na ana­li­za przed-wdro­że­nio­wa” to nic inne­go jak doku­ment mają­cy wady opi­sa­ne wyżej i poni­żej w dal­szej części.

Bardzo waż­ne: nie tyl­ko CO ale tak­że JAK. Z [[BABoK]] wie­my, że poza tak zwa­nym opi­sem pro­duk­tu jako czar­nej skrzyn­ki (nasze CO chce­my), war­to wyko­nać tak­że opis tak zwa­ne bia­łej skrzyn­ki czy­li opi­sać Jak to ma dzia­łać”. Bez tego ska­zu­je­my się na masę nie­ja­sno­ści brak kry­te­rium odbio­ru (co testować??).

Celem moim jest dzi­siaj przede wszyst­kim zachę­ce­nie Państwa do lek­tu­ry tego wywia­du i tyl­ko trosz­kę uzu­peł­nie­nie i słów Pana praw­ni­ka. Wywiad koń­czy się zaś tak:

Proszę o 5 klu­czo­wych rad dla osób, któ­re zaj­mu­ją się przy­go­to­wy­wa­niem umów wdrożeniowych.Z oczy­wi­stych wzglę­dów będzie to wyso­ko­po­zio­mo­we spojrzenie.
1.Po pierw­sze im jaśniej i pro­ściej tym lepiej.
2.Po dru­gie nie tyl­ko ?CO? ale rów­nież ?JAK.
3.Po trze­cie wła­ści­wy opis pro­ce­dur współ­dzia­ła­nia stron. Nie zosta­wiaj­my sza­rych stref, wzglę­dem któ­rych trud­no okre­ślić któ­ra ze stron jest za nie odpowiedzialna.
4.Po czwar­te kary umow­ne powin­ny sty­mu­lo­wać, nie para­li­żo­wać. Dobrze opi­sa­ny mecha­nizm kar umow­nych, opar­ty na obiek­tyw­nie wyli­czal­nych para­me­trach to napraw­dę rzad­kość w kon­trak­tach wdrożeniowych.
5.I po pią­te, pisz­my kon­trak­ty któ­re odpo­wia­da­ją zało­że­niom biz­ne­so­wym. Tak co do zakre­su pro­jek­tu, jak i spo­so­bu jego reali­za­cji. W prze­ciw­nym wypad­ku przy­go­tuj­my się na szu­fla­dy peł­ne umów.

(Źródło: Rola ana­li­zy w umo­wie wdro­że­nio­wej- wywiad z Łukaszem Węgrzynem)

Dodam od siebie:

1. umo­wa nie może być nie­zro­zu­mia­ła, żad­ne tłu­ma­cze­nia i bran­żo­wym (tak praw­ni­czym jak i infor­ma­tycz­nym) języ­ku nie są dopusz­czal­ne, w razie potrze­by słow­nik pojęć acz­kol­wiek ja oso­bi­ście pre­fe­ru­ję jasne wysła­wia­nie się i defi­nio­wa­nie listy trud­nych słów i korzy­sta­nie z nich w umowie.

2. Z moje­go doświad­cze­nia: nie lista wyma­gań na set­ki pozy­cji a pro­jekt, dokład­nie tak jak zama­wia się budow­le: kró­ki opis i rysun­ki tech­nicz­ne (w IT sko­men­to­wa­ne dia­gra­my UML).

3. Podstawa to plan komu­ni­ka­cji w pro­jek­cie i narzu­co­ne narzę­dzia (nie mail a współ­dzie­lo­ne na rów­nych pra­wach repo­zy­to­rium dokumentów).

4. Wysokie kary umow­ne budu­ją wyłącz­nie ase­ku­ra­cyj­ne, pozba­wio­ne samo­dziel­ne­go dzia­ła­nia pro­jek­ty, koń­czą­ce się w sty­ku każ­dy zro­bił co miał zro­bić tyl­ko, że nie nie mamy”. Osobiście pre­fe­ru­ję umo­wy bez żad­nych kar umow­nych ale z pra­wem wypo­wie­dze­nia przez każ­da ze stron w dowol­nym momen­cie za roz­li­cze­niem prac wykonanych.

5. Umowa powin­na być rela­tyw­nie pro­sta, opar­ta na celach biz­ne­so­wych wdro­że­nia, każ­dy pro­jekt to odkry­wa­nie pro­ble­mów w toku prac, biz­ne­so­wy cel pro­jek­tu bywa cza­sem jedy­nym świa­teł­kiem w tunelu”.

Przedmiot umowy – największy z pięciu problemów

(ź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ą.