Czy faktycznie powinieneś wdrożyć kompleksowe oprogramowanie?

O inte­gra­cji i uni­ka­niu kasto­mi­za­cji mono­li­tów poprzez wdra­ża­nie dzie­dzi­no­wych pod­sys­te­mów napi­sa­łem tu wie­le. Tym razem kil­ka komen­ta­rzy do krót­kie­go tek­stu pew­ne­go dostaw­cy mono­li­tu ERP. Tekst krót­ki więc cyto­wa­nie sta­no­wi nie­mal­że jego poło­wę ale cóż, pra­wo cyto­wa­nia tre­ści bez­po­śred­nio komentowanych… 

Artykuł

Choć wyspe­cja­li­zo­wa­ne pod kon­kret­ny obszar sys­te­my ofe­ru­ją sze­ro­kie moż­li­wo­ści i naj­ła­twiej je dopa­so­wać do potrzeb orga­ni­za­cji, może oka­zać się, że wraz z roz­wo­jem fir­my prze­sta­ną być efek­tyw­ne. (źr.: 6 prze­sła­nek, któ­re mogą wska­zy­wać, że powi­nie­neś wdro­żyć kom­plek­so­we opro­gra­mo­wa­nie)

Pierwsze zda­nie to praw­da, a dru­gie (zaczy­na­jąc sie od może”) suge­ru­je, że nie zawsze. Popatrzmy jak autor argu­men­tu­je dru­gie zda­nie, pisząc że sys­te­my wyspe­cja­li­zo­wa­ne wraz z roz­wo­jem fir­my prze­sta­ną być efek­tyw­ne” (wszyst­kie cyta­ty z powyż­sze­go źródła).

1. Nieefektywna inte­gra­cja danych
Stosowanie kil­ku roz­wią­zań infor­ma­tycz­nych wią­że się z koniecz­no­ścią zapew­nie­nia sku­tecz­nej wymia­ny danych pomię­dzy nimi. Zazwyczaj nie jest ona tak efek­tyw­na jak w przy­pad­ku jed­ne­go sys­te­mu z róż­ny­mi modułami. 

Niestety nie jest to praw­da. Poziom stan­da­ry­za­cji inter­fej­sów od daw­na pozwa­la robić to w spo­sób nie­zau­wa­żal­ny dla użyt­kow­ni­ka. Powiem tyl­ko tyle, że każ­dy zgod­ny z pra­wem sys­tem ERP/FK wysy­ła dane (JPK) do sys­te­mów rzą­do­wych, bez potzre­by żad­nej ręcz­nej inte­gra­cji, i nie ma z tym żad­ne­go pro­ble­mu. Dla czy­tel­ni­ków, któ­rzy tego nie wie­dzą, infor­ma­cja: każ­de pobra­nie gotów­ki z ban­ko­ma­tu czy też doko­na­nie płat­no­ści kar­tą płat­ni­czą w skle­pie, to każ­do­ra­zo­wo wynik współ­ra­cy (inte­gra­cja) co naj­mniej kil­ku­na­stu zin­te­gro­wa­nych sys­te­mów co naj­mniej kil­ku firm i insty­tu­cji. Warto też wie­dzieć, że dane z róż­nych dzie­dzin bar­dzo czę­sto nie są moż­li­we do umiesz­cze­nia w jed­nej i tej samej bazie danych (to zresz­tą głów­ne źró­dło pro­ble­mów kasto­mi­za­cji sys­te­mów mono­li­tycz­nych), for­so­wa­nie archi­tek­tu­ry mono­li­tycz­ne jest wręcz wyso­ce szko­dli­we .

Dostęp do wszyst­kich doku­men­tów i danych w jed­nym cen­tral­nym sys­te­mie pozwa­la księ­go­wo­ści na dokład­ną ana­li­zę w cza­sie zbli­żo­nym do rze­czy­wi­ste­go, a to umoż­li­wia lep­sze zarzą­dza­nie finan­sa­mi całej organizacji.

Dowody księ­go­we (pod­sta­wo­we doku­men­ty w FK/ERP) sta­no­wią mniej niż 20% wszyst­kich doku­men­tów ope­ra­cyj­nych, resz­ta i tak jest poza ERP. To co widzi­my jako doku­men­ty w sys­te­mach ERP (np. Faktura) to tak na praw­dę rapor­ty ad-choc z tych baz danych, nie ma tam ŻADNYCH doku­men­tów. Aby były, nale­ży jest dodat­ko­wo archi­wi­zo­wać jako pli­ki PDF i/lub XML. 

2. Błędy i opóź­nie­nia
W przy­pad­ku koniecz­no­ści ręcz­ne­go wpro­wa­dza­nia danych do kil­ku sys­te­mów, przed­się­bior­stwo nara­ża się na opóź­nie­nia, a tak­że błędy. 

Nie ma takiej potrze­by w śro­do­wi­sku zin­te­gro­wa­nym. Integracja kil­ku róż­nych dzie­dzi­no­wych sys­te­mów mię­dzy słu­ży temu, by nie wpro­wa­dzać doku­men­tów wię­cej niż raz. 

3. Systemy od róż­nych dostaw­ców
Choć w codzien­nej pra­cy może nie sta­no­wić to duże­go utrud­nie­nia, w przy­pad­ku jakiej­kol­wiek awa­rii sys­te­mów, fakt, że pocho­dzą od róż­nych dostaw­ców, może być kło­po­tli­wy. Wiąże się bowiem z koniecz­no­ścią skon­tak­to­wa­nia z kil­ko­ma oso­ba­mi, żeby móc roz­wią­zać problem. 

Jest dokład­nie odwrot­nie: jak sie zepsu­je mono­lit to NIC nie dzia­ła. Jak awa­rii ule­gnie jeden z pod­sys­te­mów dzie­dzi­no­wych, resz­ta dzia­ła popraw­nie, co jest dla odmia­ny OGROMNĄ zale­tą roz­pro­szo­nej archi­tek­tu­ry. Kontaktujemy się wyłącz­nie z admi­ni­stra­to­rem tego co nie dzia­ła. Poprawnie wyko­na­na inte­gra­cja to tak­że sepa­ra­cja skut­ków takich awarii. 

4. Utrudnienie dla pra­cow­ni­ków
Korzystanie z kil­ku sys­te­mów może sta­no­wić dodat­ko­we wyzwa­nie dla pra­cow­ni­ków, któ­rzy muszą nauczyć się pra­cy na zróż­ni­co­wa­nym opro­gra­mo­wa­niu, czę­sto z inny­mi funk­cjo­nal­no­ścia­mi, inter­fej­sem i spo­so­bem działania. 

To tak­że nie jest praw­da: sys­te­my dzie­dzi­no­we, jak sama nazwa wska­zu­je, są adre­so­wa­ne do okre­ślo­nych grup zawo­do­wych czy kom­pe­ten­cji. Jeżeli gdzie­kol­wiek poja­wia się wyżej opi­sa­na sytu­acja, to jest to raczej sku­tek bała­ga­nu, któ­ry nale­ży upo­rząd­ko­wać przed wdrożeniem. 

5. Nadmierne obcią­że­nie dzia­łów IT
Korzystając z wie­lu roz­wią­zań infor­ma­tycz­nych, koniecz­ne jest stwo­rze­nie zespo­łu IT, któ­ry będzie miał odpo­wied­nią wie­dzę i doświad­cze­nie w każ­dym z nich. 

Kolejna nie­praw­da: dział IT z zasa­dy zaj­mu­je się admi­ni­stra­cją a nie roz­wo­jem tych apli­ka­cji. Za utrzy­ma­nie i roz­wój odpo­wia­da dostaw­ca pro­gra­mo­wa­nia w ramach sta­łej corocz­nej opła­ty i licencji.

6. Utrudniona orga­ni­za­cja pra­cy z domu
Wciąż wie­le firm pra­cu­je w try­bie home offi­ce, co wyma­ga od przed­się­biorstw zapew­nie­nia dostę­pu do wszyst­kich koniecz­nych do pra­cy sys­te­mów, infor­ma­cji czy doku­men­tów. Nie wszyst­kie apli­ka­cje są dosto­so­wa­ne do pra­cy poza biurem. 

Owszem, sta­re i wie­ko­we sys­te­my ERP w archi­tek­tu­rze klient/serwer się do tego prak­tycz­nie nie nada­ją. Każdy nowo­cze­sny sys­tem, to w cało­ści dostęp­na przez prze­glą­dar­kę apli­ka­cja, z któ­rą pra­co­wać moż­na gdziekolwiek. 

Obserwujemy, że nie­któ­re fir­my oba­wia­ją się zmian, nawet gdy roz­wią­za­nia, z któ­rych korzy­sta­ją, nie w peł­ni speł­nia­ją ich potrze­by lub są już nie­co prze­sta­rza­łe. Często myślą o wyso­kich kosz­tach kom­plek­so­wych sys­te­mów. I choć rze­czy­wi­ście, koniecz­na jest inwe­sty­cja finan­so­wa i cza­so­wa, to utrzy­ma­nie jed­ne­go roz­wią­za­nia zamiast kil­ku mniej­szych jest w dłuż­szej per­spek­ty­wie kosz­to­wo bar­dziej opłacalne. 

To tak­że jest nie­praw­da, choć­by dla­te­go, że wdra­ża­nie dedy­ko­wa­nych pod­sys­te­mów dzie­dzi­no­wych nie wyma­ga żad­nych kasto­mi­za­cji dla­te­go i wdro­że­nie i póź­niej upgra­de są znacz­nie tań­sze niż wdro­że­nie i dosto­so­wa­nie monolitu. 

Podsumowanie

Nie raz myśla­łem, że nie będę już musiał pisać takich arty­ku­łów ale zno­wu jest oka­zja. Nie raz pisa­łem, że dostaw­cy sys­te­mów ERP, bar­dzo czę­sto, bez żad­nych skru­pu­łów wyko­rzy­stu­ją nie­wie­dzę swo­ich klien­tów. Tu mamy kolej­ny taki przy­kład. Nawet jeże­li ist­nie­ją tak złe wdro­że­nia, że arty­kuł ten mówi praw­dę, to jest to tyl­ko opis wyjąt­ko­wych złych wdrożeń. 

Pisanie, że Choć wyspe­cja­li­zo­wa­ne pod kon­kret­ny obszar sys­te­my ofe­ru­ją sze­ro­kie moż­li­wo­ści i naj­ła­twiej je dopa­so­wać do potrzeb orga­ni­za­cji, może oka­zać się, że wraz z roz­wo­jem fir­my prze­sta­ną być efek­tyw­ne.” jest szko­dli­wą manipulacją. 

Źródła

Martin Fowler. (2014). bli­ki: BoundedContext [Martinfowler​.com]. Martinfowler​.Com. https://​mar​tin​fow​ler​.com/​b​l​i​k​i​/​B​o​u​n​d​e​d​C​o​n​t​e​x​t​.​h​tml

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.

Od docflow do workflow, czyli o skutecznym modelowaniu i czynnikach warunkujących sukces wdrożenia

Od lat nie cich­nie dys­ku­sja na temat prze­pły­wu pra­cy i doku­men­tów oraz zarzą­dza­nia pro­ce­sa­mi biz­ne­so­wy­mi zacho­dzą­cy­mi w fir­mach. Nierzadko wie­le pojęć z tego zakre­su sto­su­je­my błęd­nie, dla­te­go war­to usys­te­ma­ty­zo­wać sobie wie­dzę o nich, wska­zać róż­ni­ce mię­dzy nimi i osta­tecz­nie odpo­wie­dzieć na pyta­nie, czy opro­gra­mo­wa­nia wspo­ma­ga­ją­ce ten obszar moż­na z suk­ce­sem wdro­żyć we wszyst­kich przed­się­bior­stwach. To klu­czo­we, jeśli chce­my sku­tecz­nie zarzą­dzać pro­ce­sa­mi w firmie.

Dokumenty i procesy

Demagogią jest twier­dze­nie, że koszt prze­cho­wy­wa­nia doku­men­tu elek­tro­nicz­ne­go to tyl­ko kil­ka mikro­me­trów dys­ku i koszt tego miniob­sza­ru. Prawdziwym kosz­tem prze­cho­wa­nia takie­go doku­men­tu jest bowiem koszt całej infra­struk­tu­ry wraz z jej zabez­pie­cze­niem. Gdyby było ina­czej, każ­dy z nas miał­by już w fir­mie elek­tro­nicz­ne superarchiwum.

Co wię­cej, obieg doku­men­tów to nie ? jak się myl­nie sądzi ? zarzą­dza­nie pro­ce­sa­mi. Dokumenty są tyl­ko jed­nym z ele­men­tów mapy pro­ce­sów orga­ni­za­cji, a zatem sys­te­my obie­gu doku­men­tów to wspar­cie zarzą­dza­nia zorien­to­wa­ne­go na pro­ce­sy, nie zaś sys­te­my zarzą­dza­nia pro­ce­sa­mi biznesowymi.

Wielu utoż­sa­mia poję­cie obie­gu doku­men­tów, obie­gu infor­ma­cji z pro­ce­sa­mi biz­ne­so­wy­mi i ich zarzą­dza­niem. Jest to moim zda­niem klu­czo­we nie­po­ro­zu­mie­nie, żeby nie powie­dzieć błąd.

Proces biz­ne­so­wy to dzia­ła­nie cha­rak­te­ry­zu­ją­ce się przede wszyst­kim wno­sze­niem war­to­ści doda­nej i posia­da­nie papie­ru czy doku­men­tu w wer­sji elek­tro­nicz­nej nie ma tu nic do rze­czy. Na mapie pro­ce­sów biz­ne­so­wych doku­men­ty i ich kolej­ne wer­sje sta­no­wią pro­duk­ty pro­ce­sów (nie­je­dy­ne zresz­tą). Proces pole­ga­ją­cy na pod­ję­ciu decy­zji to pra­ca czło­wie­ka nio­są­ca dużą war­tość doda­ną, ale nie obieg doku­men­tów będą­cych śla­da­mi po nie­któ­rych tyl­ko pro­ce­sach w fir­mie. Dla przy­kła­du pro­ce­sem jest wypro­du­ko­wa­nie pod­ze­spo­łu i nie ma to nic wspól­ne­go z sys­te­mem obie­gu doku­men­tów. Gdzieś po dro­dze powsta­nie doku­men­ta­cja tech­nicz­na, ale jeden z ele­men­tów sys­te­mu zarzą­dza­nia pro­ce­sa­mi w fir­mie, jego podsystem.

Systemy obie­gu doku­men­tów i obie­gu infor­ma­cji są waż­ny­mi ele­men­ta­mi w każ­dej orga­ni­za­cji, ale są to tyl­ko pro­duk­ty i to nie wszyst­kie na mapie pro­ce­sów biz­ne­so­wych fir­my, dla­te­go wła­śnie nazy­wa­nie sys­te­mów, zali­cza­nych do kla­sy work­flow, sys­te­ma­mi BPM (Business Process Management) uwa­żam za poważ­ne nadużycie.

Kolejną śle­pą ulicz­ką jest trak­to­wa­nie sys­te­mów kla­sy work­flow jako narzę­dzi ści­słej kon­tro­li poczy­nań pra­cow­ni­ków. Nie znam przy­pad­ku wdro­że­nia sys­te­mu zakoń­czo­ne­go suk­ce­sem, któ­re­go głów­nym celem było kon­tro­lo­wa­nie pra­cow­ni­ków (np. cza­su ich pra­cy). Znacznie sku­tecz­niej­sze są sys­te­my infor­ma­tycz­ne zapro­jek­to­wa­ne tak, by poma­ga­ły pra­cow­ni­kom osią­gać ich cele. Takie nie­ja­ko wdra­ża­ją się same. Z kolei sys­te­my kon­tro­li i restryk­cji, nawet jeże­li uda­je się je wdro­żyć, są bar­dzo kosz­tow­ne i czę­sto boj­ko­to­wa­ne przez pracowników.

Jednak coś w tym jest, że obieg doku­men­tów (infor­ma­cji) cza­sa­mi sta­je się mode­lem procesów.

Kiedy i co modelować

Jeżeli cze­goś nie moż­na nary­so­wać, to zna­czy, że to nie ist­nie­je! To stwier­dze­nie odno­si się do isto­ty pro­ce­sów i zarzą­dza­nia nimi. Aby czym­kol­wiek zarzą­dzać, nale­ży to naj­pierw opi­sać, czy­li udo­ku­men­to­wać. Takim opi­sem będzie mapa pro­ce­sów biz­ne­so­wych, któ­ra sta­no­wi model fir­my z per­spek­ty­wy jej funk­cjo­no­wa­nia. Jak ją pra­wi­dło­wo wykonać?

Model fir­my powi­nien w spo­sób jasny i zro­zu­mia­ły dla jej pra­cow­ni­ków opi­sy­wać fir­mę, jej cel ryn­ko­wy oraz wszel­kie jej aktyw­no­ści wewnętrz­ne i zewnętrz­ne. Jest on nie­zbęd­ny do prze­wi­dy­wa­nia zacho­wań fir­my, ale tak­że do przy­go­to­wa­nia jej na wdro­że­nia sys­te­mów informacyjnych.

Cała publi­ka­cja w ostat­nim nume­rze Informacja Zarządcza 18/2019

Dyrektorzy mówią Dość! Biznes wychodzi z objęć monolitycznego systemu ERP

Krótki wstęp

Od cza­su do cza­su są takie momen­ty, że świat pod­su­wa mi goto­we tek­sty do publi­ka­cji. Każdy kto mnie zna i czy­ta wie, że od lat odra­dzam wdra­ża­nie wiel­kich mono­li­tów ERP, uza­sad­nie­nie tego z moich ust naj­czę­ściej jest jed­nak odbie­ra­ne jako moje spe­ku­la­cje (mimo, że zawsze uza­sad­niam swo­je zda­nie a przy­kła­dów nie bra­ku­je). A o tym sądzą dyrek­to­rzy firm?

Czytaj dalej… Dyrektorzy mówią Dość! Biznes wycho­dzi z objęć mono­li­tycz­ne­go sys­te­mu ERP”

Wzorcowe klauzule w umowach IT

Ministerstwo Cyfryzacji opu­bli­ko­wa­ło Wzorcowe klau­zu­le w umo­wach IT, jest to infor­ma­cja do wer­sji pilo­ta­żo­wej (Opublikowano: 22.11.2017).

Klauzule zosta­ły opra­co­wa­ne na zle­ce­nie Ministra Cyfryzacji przez zespół kan­ce­la­rii MARUTA WACHTA Sp. j. pod kie­row­nic­twem mec. Marcina Maruty i mec. Bartłomieja Wachty. Wykorzystano w nich rów­nież uwa­gi pra­cow­ni­ków admi­ni­stra­cji publicz­nej, zarów­no praw­ni­ków, jak i spe­cja­li­stów z dzie­dzi­ny IT. (źr. https://​www​.gov​.pl/​c​y​f​r​y​z​a​c​j​a​/​w​z​o​r​c​o​w​e​-​k​l​a​u​z​u​l​e​-​w​-​u​m​o​w​a​c​h​-it)

Jako, że w pod­pi­sie napisano:

Bardzo mile widzia­ne są wszel­kie dal­sze komen­ta­rze i uwa­gi do klau­zul. Należy je prze­sy­łać na adres: Klauzule@mc.gov.pl

Więc jako wie­lo­let­ni teo­re­tyk i prak­tyk, poczu­łem się w obo­wiąz­ku takie uwa­gi zgło­sić 9zostały wysła­ne na powyż­szy adres, odpo­wie­dzi nie otrzy­ma­łem). Mimo, że to opra­co­wa­nie powsta­ło za pie­nia­dze podatnika…

…zaska­ku­je mnie zapis na stro­nie MC: klau­zu­le nie mogą być wyko­rzy­sty­wa­ne przez przed­się­bior­ców ani oso­by fizycz­ne” (Kancelaria je chro­ni, mimo, że treść doku­men­tu powsta­ła z pie­nię­dzy budżetowych).

Po zapo­zna­niu się z doku­men­tem, uzna­łem, że uwa­gi swo­je ogra­ni­czę do pierw­szej czę­ści: Definicje. Zawiera ona defi­ni­cje klu­czo­wych pojęć wraz z komen­ta­rza­mi. Definicje pojęć są klu­czo­we dla zro­zu­mie­nia umów i inter­pre­to­wa­nia ich zapi­sów w przy­pad­ku spo­rów. Innymi sło­wy, wady tej czę­ści umo­wy czy­nią wadli­wą (ryzy­kow­ną) całą umo­wę. Pozwoliłem więc sobie na kil­ka uwag wyłącz­nie do tej czę­ści opracowania.

Pojęcie ?błąd?

Autorzy reko­men­du­ją jego defi­nio­wa­nie w nastę­pu­ją­cy sposób:

Błąd ? nie­pra­wi­dło­we dzia­ła­nie Oprogramowania, nie­za­leż­nie od przy­czy­ny takiej nie­pra­wi­dło­wo­ści. W szcze­gól­no­ści Błędem jest dzia­ła­nie Oprogramowania nie­zgod­nie z Dokumentacją. Błędom przy­pi­sa­ne są kate­go­rie [opcjo­nal­nie: priorytety ].

W umo­wach bar­dzo czę­sto spo­ty­kam takie poję­cie błę­du, jed­nak rodzi ono wie­le pro­ble­mów. Słownik języ­ka pol­skie­go poda­je definicje:

błąd
1. ?nie­zgod­ność z obo­wią­zu­ją­cy­mi regu­ła­mi pisa­nia, licze­nia, wymo­wy itp.?
2. ?nie­wła­ści­we posu­nię­cie?
3. ?fał­szy­we mnie­ma­nie o czymś?

Są jed­nak jesz­cze w języ­ku pol­skim w uży­ciu pojęcia:

nie­zgod­ny
3. ?będą­cy w sprzecz­no­ści z czymś?
4. ?nie­do­bra­ny w porów­na­niu z czymś innym?

nie­spraw­ny
4. ?źle zor­ga­ni­zo­wa­ny?
5. ?nie­dzia­ła­ją­cy w ogó­le lub dzia­ła­ją­cy wadliwie?

awa­ria ?uszko­dze­nie maszy­ny lub inne­go urzą­dze­nia technicznego?

Jak widać, tak­że w potocz­nym rozu­mie­niu, popeł­nie­nie błę­du doty­czy zacho­wań (nie­wła­ści­we posu­nię­cie, fał­szy­we mnie­ma­nie, ) lub ich skut­ków (uzy­ska­nie złe­go wyni­ku). Oprogramowanie powsta­je w wyni­ku umo­wy o dzie­ło, któ­re to dzie­ło jest w umo­wie wyspe­cy­fi­ko­wa­ne (opi­sa­ne). Tak więc opro­gra­mo­wa­nie może być nie­zgod­ne z wyma­ga­nia­mi lub opro­gra­mo­wa­nie może gene­ro­wać błęd­ne wyni­ki np. obli­czeń (istot­ne jest to czy powsta­ło coś nie­zgod­nie z wyma­ga­nia­mi czy tyl­ko” jest to ludz­ki błąd kodu, to róż­ni­ca podob­na to zama­wia­nych opra­co­wać: struk­tu­ra tre­ści jest nie­zgod­na z zamó­wie­niem, czy w treść wkra­dły się błędy).

Oprogramowanie sta­no­wi tak­że inte­gral­ną część sys­te­mu infor­ma­tycz­ne­go skła­da­ją­ce­go się tak­że ze sprzę­tu, może nim być nie tyl­ko kom­pu­ter słu­żą­cy do pisa­nia lub księ­go­wa­nia ale tak­że linia pro­duk­cyj­na. Człowiek nigdy nie korzy­sta z same­go opro­gra­mo­wa­nia, zawsze jest to jakieś urzą­dze­nie (kom­pu­ter z edy­to­rem tek­stu, pral­ka z opro­gra­mo­wa­niem zamiast pro­gra­ma­to­ra mecha­nicz­ne­go, linia pro­duk­cyj­na z opro­gra­mo­wa­niem ste­ru­ją­cym, tele­fon komór­ko­wy z opro­gra­mo­wa­niem do pro­wa­dze­nia roz­mów czy korzy­sta­nia z Internetu itp.).

Tak więc z per­spek­ty­wy użyt­kow­ni­ka, korzy­sta on z cało­ści urzą­dze­nia, nie wie on czy winą za stwier­dzo­ną nie­pra­wi­dło­wość nale­ży obcią­żyć aku­rat opro­gra­mo­wa­nie (np. pral­ka nie pie­rze, sys­tem finan­so­wo-księ­go­wy nie księ­gu­je). Brak moż­li­wo­ści sko­rzy­sta­nia z tre­ści stron inter­ne­to­wych może być wyni­kiem awa­rii łącza inter­ne­to­we­go, awa­rii kom­pu­te­ra, błę­du kon­fi­gu­ra­cji sie­ci Wi-Fi itp. Dlatego w umo­wach takich bez­piecz­niej jest użyć poję­cia zro­zu­mia­łe­go dla użyt­kow­ni­ka, gdyż wte­dy, nie będąc spe­cja­li­stą, jest on w sta­nie stwier­dzić nie­zgod­ność dostar­czo­ne­go roz­wią­za­nia z opi­sem w umo­wie lub stwier­dzić awa­rię urzą­dze­nia (sys­te­mu). Po dru­gie jed­no urzą­dze­nie może zawie­rać wię­cej niż jed­ną apli­ka­cję, o czym użyt­kow­nik tak­że może nie wie­dzieć i nie będzie w sta­nie popraw­nie (zgod­nie z umo­wą, sku­tecz­nie) zgło­sić takiej wady. Mając tablet łatwo oce­nić czy korzy­sta­jąc z nie­go uległ on awa­rii czy nie, ale stwier­dze­nie błę­du kon­kret­ne­go opro­gra­mo­wa­nia na nim zain­sta­lo­wa­ne­go, może być nie­moż­li­we dla nieprofesjonalisty.

W mojej oce­nie, wyma­ga­nie od użyt­kow­ni­ka rozu­mie­nia dzia­ła­nia deta­li kon­struk­cyj­nych urzą­dze­nia (wska­zy­wa­nie, któ­ra apli­ka­cja «błęd­nie” dzia­ła), któ­re nabył, jest dużym nad­uży­ciem, gdyż prze­wa­ga mery­to­rycz­na jego dostaw­cy i takie jak zale­ca­ne w recen­zo­wa­nym doku­men­cie (patrz do źró­dła, na koń­cu arty­ku­łu) for­mu­ło­wa­nie uste­rek, powo­du­je trud­ność w dowo­dze­niu przed dostaw­cą tych nie­pra­wi­dło­wo­ści, co auto­rzy sami przy­zna­li w komentarzach.

W kwe­stii two­rze­nia kate­go­rii awa­rii dość powszech­nie przy­ję­tą prak­ty­ką w inży­nie­rii jest trzy­stop­nio­wa oce­na: w wyni­ku awa­rii (1) urzą­dze­nie sta­ło się nie­przy­dat­ne, (2) urzą­dze­nie ma ogra­ni­czo­ne moż­li­wość uży­cia ale zacho­wu­je przy­dat­ność, (3) spadł jedy­nie kom­fort korzy­sta­nia z urzą­dze­nia. Dotyczy to tak­że kom­pu­te­ra z oprogramowaniem.

Pojęcie ?dokumentacja?

Zapewne jest to drob­na spra­wa” ale tyl­ko pozor­nie. W pra­wie ope­ru­je się poję­ciem doku­men­tu (nie tyl­ko elek­tro­nicz­ne­go) a nie ?doku­men­ta­cji? (nie licząc np. pra­wa budow­la­ne­go). Dlatego lepiej jest napi­sać, że ?doku­ment zawierający/opisujący? coś to ?doku­men­ta­cja cze­goś? (doku­men­ta­cja może być doku­men­tem” elek­tro­nicz­nym, papie­ro­wym). Jeżeli mają być sto­so­wa­ne kate­go­rie lub typy doku­men­ta­cji, to logi­ka two­rze­nia tak­so­no­mii naka­zu­je uży­cie typów: doku­men­ta­cja tech­nicz­na, doku­men­ta­cja ana­li­tycz­na, doku­men­ta­cja pro­jek­to­wa. Zamiast więc defi­nio­wać poję­cie ?ana­li­za? lepiej jest for­mu­ło­wać treść zapi­su umo­wy w posta­ci ?doku­ment zawie­ra­ją­cy treść ana­li­zy (jakiej, cze­go)?, bo wte­dy samo ?ana­li­za? nie kwa­li­fi­ku­je ?tego cze­goś? jako doku­men­tu lub ?doku­men­ta­cji?, nie wie­my też czy ana­li­za” jest doku­men­tem czy pra­cą nad jego stwo­rze­niem (przy­ję­te jest w nauce, że ana­li­za i ana­li­zo­wa­nie to pra­ca a nie przed­miot, podob­nie jak ope­ra­cja i operowanie).

Pojęcie oprogramowanie”

Słownik języ­ka polskiego:

opro­gra­mo­wa­nie ?zbiór pro­gra­mów wpro­wa­dzo­nych do kom­pu­te­ra?
pro­gram ?ciąg instruk­cji napi­sa­nych w języ­ku zro­zu­mia­łym dla kom­pu­te­ra?
apli­ka­cja ?kom­pu­te­ro­wy pro­gram użytkowy?

Autorzy wzo­ru jed­nak rekomendują:

Oprogramowanie ? całość lub dowol­ny ele­ment opro­gra­mo­wa­nia dostar­cza­ne­go lub wyko­ny­wa­ne­go w ramach reali­za­cji Umowy.

Nie rozu­miem powo­dów, dla któ­rych w umo­wie, któ­ra w trak­cie spo­ru, będzie z zasa­dy inter­pre­to­wa­na w języ­ku pol­skim, ale też w tym języ­ku intu­icyj­nie będzie pro­wa­dzo­na kore­spon­den­cja pomię­dzy stro­na­mi umo­wy, zmie­nio­no defi­ni­cję słow­ni­ko­wą. Wprowadzanie typów opro­gra­mo­wa­nia: apli­ka­cyj­ne, sys­te­mo­we, dedy­ko­wa­ne, itp.. (bra­ku­je jed­nak dla kon­se­kwen­cji nie­de­dy­ko­wa­ne­go) nie sta­no­wi żad­nej war­to­ści, wręcz zaciem­nia obraz, a o roli tego opro­gra­mo­wa­nia decy­du­ją cechy użyt­ko­we a nie nada­na mu nazwa (np. z per­spek­ty­wy admi­ni­stra­to­ra ser­we­ra apli­ka­cje wspo­ma­ga­ją­ce jego pra­cę są apli­ka­cja­mi użyt­ko­wy­mi, dla prze­cięt­ne­go czło­wie­ka są to ?pro­gra­my admi­ni­stra­cyj­ne?). Po dru­gie wpro­wa­dza­nie takich nazw nie poma­ga a prze­szka­dza w sto­so­wa­niu poję­cia błędu/niezgodności/awarii.

Pojęcie system”, a może jednak rozwiązanie”

I w tym momen­cie wręcz kurio­zal­ne wyda­je się wpro­wa­dze­nie poję­cia sys­tem w brzmieniu:

System ? Oprogramowanie dosto­so­wa­ne do wyma­gań Umowy, w tym wyma­gań funk­cjo­nal­nych i pozafunkcjonalnych

Czyżby opro­gra­mo­wa­nie goto­we z pudeł­ka”, będą­ce przed­mio­tem umo­wy nie było by sys­te­mem (albo jego czę­ścią)? Pojęcie sys­tem w inży­nie­rii ma dość pre­cy­zyj­ne i ogól­niej­sze zna­cze­nie, słow­nik języ­ka pol­skie­go podaje:

sys­tem
1. ?układ ele­men­tów mają­cy okre­ślo­ną struk­tu­rę i sta­no­wią­cy logicz­nie upo­rząd­ko­wa­ną całość?
2. ?zespół wie­lu urzą­dzeń, dróg, prze­wo­dów itp., funk­cjo­nu­ją­cych jako całość?

Tak więc kom­pu­ter z opro­gra­mo­wa­niem, nowo­cze­sna linia pro­duk­cyj­na itp. To są sys­te­my, czę­ścią każ­de­go z nich jest wie­le róż­nych apli­ka­cji, każ­da z nich to pro­gram kom­pu­te­ro­wy. Pojęcie system„od wie­lu lat ma zde­fi­nio­wa­ne, zarów­no nauko­we i bran­żo­we zna­cze­nie: dowol­ny twór poję­cio­wy lub fizycz­ny, skła­da­jąc się z czę­ści wza­jem­nie powią­za­nych i oddzia­ły­wa­ją­cych na sie­bie” (Bertalanffy, Ackof), zbiór ele­men­tów i związ­ków mię­dzy nimi zdol­ny to reali­zo­wa­nia okre­ślo­nych celów” (www​.omg​.org, Model Driven Engineering).

Autorzy piszą, że ?System sta­no­wi dzie­ło w rozu­mie­niu prze­pi­sów kodek­su cywil­ne­go?. Kodeks Cywilny podaje:

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.

KC nie defi­niu­je poję­cia dzie­ło, jed­nak słow­nik języ­ka pol­skie­go wyda­je się wystar­cza­ją­co precyzyjny:

dzie­ło
1. ?utwór lite­rac­ki, nauko­wy lub arty­stycz­ny, zwłasz­cza dużej war­to­ści?
3. ?efekt czy­jejś pra­cy lub jakichś procesów?

Ustawa Prawo autor­skie… stwierdza:

Przedmiot pra­wa autor­skie­go
Art. 1. 1. Przedmiotem pra­wa autor­skie­go jest każ­dy prze­jaw dzia­łal­no­ści twór­czej o indy­wi­du­al­nym cha­rak­te­rze, usta­lo­ny w jakiej­kol­wiek posta­ci, nie­za­leż­nie od war­to­ści, prze­zna­cze­nia i spo­so­bu wyra­że­nia (utwór).

Tak więc w pro­sty spo­sób wywo­dzi­my, że każ­dy utwór to dzie­ło (ale uwa­ga: nie każ­de dzie­ło to utwór). Tak więc dzie­łem jest zarów­no doku­men­ta­cja jak i opro­gra­mo­wa­nie (patrz Ustawa o pra­wach autor­skich ?). Jako, że dostar­cze­nie dzia­ła­ją­ce­go sys­te­mu? jest okre­ślo­nym efek­tem, dzia­łać może dopie­ro opro­gra­mo­wa­nie zain­sta­lo­wa­ne na kom­pu­te­rze, wyko­na­nie opro­gra­mo­wa­nia (utwór) i dostar­cze­nie lub zain­sta­lo­wa­nie go na kom­pu­te­rze (dopie­ro) jest dzie­łem (samo opro­gra­mo­wa­nie jako utwór, to tak­że – odręb­ne – dzie­ło). O ile tyl­ko ten efekt (dzie­ło) został pre­cy­zyj­nie opi­sa­ny w doku­men­ta­cji sta­no­wią­cej Opis Przedmiotu Zamówienia (czy­li w umo­wie) jest on przed­mio­tem tej umo­wy. Opis ten musi być jed­nak na tyle pre­cy­zyj­ny, by zama­wia­ją­cy był w sta­nie stwier­dzić ewen­tu­al­ne nie­zgod­no­ści z tym opi­sem, a tak­że stwier­dzić wystą­pie­nie ewen­tu­al­nej awa­rii, czy­li jest w sta­nie stwier­dzić, że dostaw­ca wywią­zał się nale­ży­cie z umowy.

Jak więc nazwać przed­miot umowy? 

Autorzy szu­ka­ją nazwy dla poję­cia Oprogramowanie dosto­so­wa­ne do wyma­gań Umowy, w tym wyma­gań funk­cjo­nal­nych i poza­funk­cjo­nal­nych”. Rzecz w tym, że przed­mio­tem umo­wy może być (i z regu­ły jest) coś znacz­nie bar­dziej zło­żo­ne­go niż opro­gra­mo­wa­nie, bo opro­gra­mo­wa­nie – jak już wyżej napi­sa­no – nigdy samo z sie­bie nie jest czymś dzia­ła­ją­cym”. Nie da się stwier­dzić popraw­no­ści dzia­ła­nia opro­gra­mo­wa­nia bez jego uru­cho­mie­nia na kom­pu­te­rze (w jakimś środowisku), 

dla­te­go samo opro­gra­mo­wa­nie NIGDY nie powin­no być przed­mio­tem umowy!

W bran­ży inży­nier­skiej, w IT tak­że, mówi się o roz­wią­za­niach infor­ma­tycz­nych, któ­re są sys­te­ma­mi (ale sys­tem to poję­cie szer­sze, bo może­my mówić o sys­te­mie ochro­ny zdro­wia, któ­re­go małą czę­ścią będzie oprogramowanie).

Słownik języ­ka pol­skie­go mówi:

roz­wią­za­nie ?pro­jekt i reali­za­cja zało­żeń archi­tek­to­nicz­nych, kon­struk­cyj­nych, pla­stycz­nych itp.?

Skoro więc uznać, że sys­te­my infor­ma­tycz­ne są i do cze­goś słu­żą”, że są wdra­ża­ne z okre­śla­ne­go, czę­sto biz­ne­so­we­go, powo­du, nale­ży więc mówić o roz­wią­za­niach”, bo wyma­ga­nia biz­ne­so­we opi­su­ją roz­wią­za­nie biz­ne­so­we­go pro­ble­mu. Rozwiązaniem” pro­ble­mu (cel biz­ne­so­wy) jest wdro­że­nie opro­gra­mo­wa­nia czy­li jego wytwo­rze­nie, dostar­cze­nie, uru­cho­mie­nie oraz dosto­so­wa­nie do nie­go ist­nie­ją­cych pro­ce­dur, prze­pro­wa­dze­nie szko­leń użyt­kow­ni­ków. Trudno sobie wyobra­zić poważ­ną umo­wę na dostar­cze­nie opro­gra­mo­wa­nia w posta­ci przy­sła­nia pudeł­ka z kodem na nośni­ku. Autorzy wspo­mi­na­ją o SLA, czy­li z góry zakła­da­ją, że przed­mio­tem umo­wy jest wła­śnie całe roz­wią­za­nie” (lub znacz­na jego część) a nie tyl­ko opro­gra­mo­wa­nie dosto­so­wa­ne do wyma­gań Umowy, w tym wyma­gań funk­cjo­nal­nych i pozafunkcjonalnych”.

Tak wiec przed­mio­tem umo­wy, poję­ciem uży­tym do jego nazwa­nia, opi­su­ją­cej nie­try­wial­ny pro­jekt tech­nicz­no-orga­ni­za­cyj­ny, raczej powin­no być sło­wo roz­wią­za­nie.

Na zakończenie

Autorzy piszą:

Definicje są jed­nym z naj­trud­niej­szych do opra­co­wa­nia ele­men­tów umo­wy. Nie ist­nie­ją wypra­co­wa­ne jed­no­znacz­ne stan­dar­dy, defi­ni­cje róż­nią się w zależ­no­ści od pro­jek­tu, a wie­lu pojęć nie da się zde­fi­nio­wać w peł­ni pre­cy­zyj­nie. Podane pro­po­zy­cje powin­ny być dokład­nie zwe­ry­fi­ko­wa­ne i zmo­dy­fi­ko­wa­ne na potrze­by kon­kret­nej umowy.

Należy się zgo­dzić z tym, że defi­nio­wa­nie pojęć jest bar­dzo trud­ne, jed­nak teza, że nie ist­nie­ją stan­dar­dy nie jest praw­dą (auto­rzy w doku­men­cie, prze­cząc sobie, przy­wo­łu­ją stan­dard jakim jest ITIL). Teza, że pew­nych pojęć nie da się zde­fi­nio­wać pre­cy­zyj­nie, jest w moich oczach nad­uży­ciem, gdyż albo w umo­wie poję­cie defi­niu­je­my, co pozwa­la użyć go w celu zacho­wa­nia jed­no­znacz­no­ści tre­ści zapi­sów umo­wy, albo nie nale­ży sto­so­wać tych defi­ni­cji. Definicje pojęć, popraw­nie zbu­do­wa­ne, sta­no­wią kry­te­rium pozwa­la­ją­ce jed­no­znacz­nie zakla­sy­fi­ko­wać np. zda­rze­nie jako awa­rię. Jeżeli defi­ni­cja na to nie pozwa­la, sku­tecz­ne zgło­sze­nie awa­rii sta­je się wąt­pli­we (nie­moż­li­we?).

Wielu auto­rów ksią­żek, nie tyl­ko w bran­ży IT, stan­da­ry­zu­je poję­cia jakich uży­wa w swo­ich opra­co­wa­niach, każ­da bran­ża ma swo­je, wypra­co­wa­ne jako stan­dar­dy lub zale­ce­nia, defi­ni­cje pojęć, część ma swo­je źró­dło w opra­co­wa­niach nauko­wych. Prowadzę i ja taki słow­nik, jest opu­bli­ko­wa­ny, poma­ga mi w komu­ni­ka­cji, tak­że na tym blo­gu: Słownik pojęć. O two­rze­niu defi­ni­cji pojęć pisa­łem tak­że tu: Słownik pojęć biz­ne­so­wych: naj­bar­dziej pod­sta­wo­we wyma­ga­nie.

Projekty inży­nier­skie to pro­jek­ty mul­ti­dy­scy­pli­nar­ne, opi­sa­nie przed­mio­tu umo­wy w pro­jek­tach inży­nier­skich jest trud­ne, dla­te­go moim zda­niem nale­ży przy­kła­dać ogrom­ną wage do pre­cy­zji for­mu­ło­wa­nia tre­ści takich umów. Jestem zda­nia, że podob­nie jak to ma miej­sce w innych dzie­dzi­nach inży­nie­rii, tu (inży­nie­ria opro­gra­mo­wa­nia) tak­że nale­ży sto­so­wać uzna­ne meto­dy opi­su dzie­ła w posta­ci sche­ma­tów blo­ko­wych, gdyż sło­wa­mi nie zawsze łatwo (nie raz jest to wręcz nie­moż­li­we) opi­sać inży­nier­ską kon­struk­cję (sys­tem). Projekty infor­ma­tycz­ne cechu­ją się coraz więk­szą zło­żo­no­ścią. Myślę, że nikt w dzi­siej­szych cza­sach nie wyobra­ża sobie zawar­cia umo­wy na wyko­na­nie inwe­sty­cji budow­la­nej, z uży­ciem wyłącz­nie tek­stu jako opi­su dzie­ła. Jest to prak­tycz­nie nie­moż­li­we. Dlatego brnię­cie w opi­sy tek­sto­we przed­mio­tów umów na dostar­cza­nie nie­try­wial­nych (auto­rzy wspo­mi­na­ją o pro­jek­tach wyso­kiej war­to­ści) sys­te­mów infor­ma­tycz­nych nale­ży dzi­siaj uznać za poważ­ny błąd. Oprogramowanie ma tak­że swo­ją spe­cy­fi­kę: jest to byt wir­tu­al­ny, dla­te­go tym bar­dziej pre­cy­zja sto­so­wa­nych pojęć sta­je się klu­czo­wa dla powo­dze­nia tych projektów.

Dokument recen­zo­wa­ny:
https://​www​.gov​.pl/​d​o​c​u​m​e​n​t​s​/​3​1​3​0​5​/​0​/​u​m​o​w​a​_​w​d​r​o​z​e​n​i​o​w​a​_​z​_​u​s​l​u​g​a​m​i​_​u​t​r​z​y​m​a​n​i​a​_​-​_​w​z​o​r​c​o​w​e​_​k​l​a​u​z​u​l​e​_​k​o​m​e​n​t​a​r​z​_​c​z​_​i​.​pdf

P.S.

Jako ciąg dal­szy pole­cam arty­kuł Opis Przedmiotu Zamówienia ? instruk­cja nie tyl­ko dla praw­ni­ków.

Praca grupowa czyli Syndrom Sztokholmski w projekcie

Od wie­lu lat lat, pro­duk­tem mojej pra­cy są doku­men­ty opi­su­ją­ce w obiek­tyw­ny spo­sób dzia­ła­nie orga­ni­za­cji, zawie­ra­ją­ce reko­men­da­cje zmian do popra­wy sytu­acji, tak­że wyma­ga­nia na sys­te­my infor­ma­cyj­ne. Po opra­co­wa­niu roz­wią­za­nia i pomo­cy w wybo­rze jego dostaw­cy, pro­wa­dzę nad­zór autor­ski nad reali­za­cją opra­co­wa­ne­go roz­wią­za­nia. [1] Po latach pra­cy nasu­wa mi się dość cie­ka­wy wnio­sek z obser­wa­cji: Zamawiający dzia­ła­ją na swo­ją szkodę!

Typowy pro­jekt zwią­za­ny z wdra­ża­niem nowych roz­wią­zań to real­ne potrze­by Zamawiającego. Członkowie zespo­łu Zamawiającego mają nad sobą ter­mi­ny i nie­uchron­ność” kary za nie­po­wo­dze­nie. W efek­cie Dostawca szyb­ko sta­je się Panem pro­jek­tu”, bo to on dostar­cza roz­wią­za­nie, zna się, a bywa że szan­ta­żu­je. Przewaga mery­to­rycz­na Dostawcy nad Zamawiającym jest tak wiel­ka, że ten ostat­ni w zasa­dzie nie jest w sta­nie pano­wać nad pro­jek­tem. Powoli rynek to dostrze­ga i dla­te­go od kil­ku lat nie­mal­że każ­da moja umo­wa na pro­jek­to­wa­nie zawie­ra tak­że nad­zór autor­ski (to for­ma kon­tro­li efek­tów pra­cy dostawcy).

Nadal bar­dzo czę­sto Dostawca two­rzy jed­nak pew­ną atmos­fe­rę: to my reali­zu­je­my Wasz pro­jekt i wszyst­ko – Wy tak­że – od nas zale­ży, nad­zór autor­ski psu­je Wam har­mo­no­gram bo my musi­my te doku­men­ty czy­tać i two­rzyć”. Dwa razy w ostat­nich pię­ciu lat zda­rzy­ło mi się, że fak­tycz­nie Zamawiający zre­zy­gno­wał z nad­zo­ru autor­skie­go, bo człon­ko­wie zespo­łu zaczę­li trzy­mać stro­nę Dostawcy”, mimo infor­ma­cji o szko­dli­wo­ści zmian wpro­wa­dza­nych przez z Dostawcę. Oba pro­jek­ty skoń­czy­ły się nie­ste­ty klę­ską (mam kon­takt z prak­tycz­nie każ­dym byłym klientem).

Projekt wdro­że­nio­wy bez nad­zo­ru mery­to­rycz­ne­go, to bar­dzo czę­sto rów­nia pochy­ła: od pod­pi­sa­nia umo­wy na wdro­że­nie z dostaw­cą jest już tyl­ko coraz gorzej, bo Dostawca uprasz­cza logi­kę sys­te­mu, pomi­ja trud­ne do reali­za­cji wyma­ga­nia, sta­le orga­ni­zu­je spo­tka­nia, na któ­rych legi­ty­mi­zu­je te zmia­ny w pro­sty spo­sób spo­sób: to co macie w doku­men­ta­cji wyma­gań jest złe (nie da się, nikt tak nie robi itp.), nasz sys­tem reali­zu­je to ina­czej, zrób­my to pro­ściej i szyb­ciej a też będzie dobrze”. Zamawiający z regu­ły nie ma po swo­jej stro­nie żad­nych kom­pe­ten­cji by oce­nić skut­ki takich pro­po­zy­cji” i na spo­tka­niach godzi się na to, pod­pi­su­jąc kolej­ne notat­ki pro­jek­to­we z takich warsz­ta­tów”, mały­mi krocz­ka­mi funk­cjo­nal­ność dostar­cza­ne­go pro­duk­tu odda­la się od fak­tycz­nych potrzeb i wyma­gań. Projekt koń­czy się tak, że Zamawiający dostał dokład­nie to co chciał a nie to co jest mu potrzeb­ne”. Statystyki pro­jek­tów IT są bez­li­to­sne: ok. 2/3 pro­jek­tów to nadal pro­jek­ty nie­uda­ne. [2]

Tam gdzie mój pro­jekt był kolej­nym podej­ściem, po poprzed­nim nie­uda­nym, wyżej opi­sa­na sytu­acja była prak­tycz­nie zawsze przy­czy­ną wcze­śniej­szej poraż­ki. Paradoksalnie jest to – poraż­ka – wręcz stan­dar­do­wa sytu­acja, gdy Zamawiający naj­pierw wybie­ra Dostawcę a potem zle­ca mu ana­li­zę wyma­gań i kie­ro­wa­nie projektem.

Zjawisko to zawsze koja­rzy mi się ze zna­nym w psy­cho­lo­gii efek­tem nazy­wa­nym Syndrom Sztokholmski. Jest to sytu­acja, w któ­rej ofia­ra, wbrew zdro­we­mu roz­sąd­ko­wi, zaczy­na sym­pa­ty­zo­wać ze swo­im oprawcą.

[Syndrom Sztokholmski] …ofia­ra porwa­nia czy zakład­nik tra­ci kry­ty­cyzm wobec swo­jej sytu­acji, zaczy­na wie­rzyć, ze jej opraw­ca dzia­ła w słusz­nym celu, i darzyć go sym­pa­tią. Jak twier­dzi ame­ry­kań­ska psy­cho­log, dr Natalie de Fabrique, zaj­mu­ją­ca się bada­niem tego syn­dro­mu, syn­drom sztok­holm­ski poja­wia się u ofiar nie­świa­do­mie, to instynk­tow­ny, psy­cho­lo­gicz­ny mecha­nizm obron­ny, dzię­ki któ­re­mu łatwiej jest im odna­leźć sens tego, co się dzie­je, i unik­nąć zała­ma­nia ner­wo­we­go. [3]

W wie­lu pro­jek­tach wdro­że­nio­wych mamy podob­ną sytu­ację: pra­cow­ni­cy zama­wia­ją­ce­go, zamiast dzia­łać na rzecz sie­bie czy swo­je­go pra­co­daw­cy, zaczy­na­ją trzy­mać stro­nę Dostawcy, któ­ry żali się, że ma pro­blem z ter­mi­na­mi i prze­rzu­ca winę za to na swo­je­go klien­ta. Po pew­nym cza­sie docho­dzi do tego, że zespół Zamawiającego tak się zżył z pra­cow­ni­ka­mi Dostawcy”, że zaczy­na ich bro­nić przed wła­sny­mi prze­ło­żo­ny­mi. Są Dostawcy, któ­rzy celo­wo stwa­rza­ją takie sytu­acje (np. orga­ni­zu­jąc wyjaz­do­we szko­le­nia i warsz­ta­ty z noc­le­ga­mi), ale nie raz dzie­je się samo­ist­nie”. Popatrzmy na poniż­szą listę, czy nie przy­po­mi­na Wam to czegoś?

Objawy i symp­to­my syn­dro­mu sztok­holm­skie­go to:
– pozy­tyw­ne uczu­cia ofia­ry wobec sprawcy;
– zro­zu­mie­nie przez ofia­rę moty­wów i zacho­wań spraw­cy i podzie­la­nie jego poglądów;
– pozy­tyw­ne uczu­cia spraw­cy wzglę­dem ofiary;
– pomoc­ne zacho­wa­nia ofia­ry wobec sprawcy;
– nega­tyw­ne uczu­cia ofia­ry wobec rodzi­ny, przy­ja­ciół, auto­ry­te­tów pró­bu­ją­cych ją ratować;
– nie­zdol­ność zaan­ga­żo­wa­nia się w zacho­wa­nia, któ­re mogły­by dopro­wa­dzić do jej uwol­nie­nia od sprawcy.
Syndrom sztok­holm­ski nie doty­czy wszyst­kich osób dotknię­tych tra­gicz­ny­mi zda­rze­nia­mi. By zaist­niał, muszą wystą­pić okre­ślo­ne warun­ki. Ofiara:
– spo­strze­ga, że jej prze­ży­cie zale­ży od dobrej woli sprawcy;
– nie widzi moż­li­wo­ści ucieczki;
– dostrze­ga drob­ne uprzej­mo­ści ze stro­ny sprawcy;
– jest izo­lo­wa­na od per­spek­tyw odmien­nych od per­spek­ty­wy sprawcy.
[4]

Popatrzmy zatem na pro­jekt wdro­że­nio­wy, w którym:

  1. Zespól Zamawiającego wie­rzy, że być albo nie być” fir­my, zale­ży od powo­dze­nia projektu,
  2. Zespół Zamawiającego nie widzi alter­na­ty­wy dla tego wdrożenia,
  3. Zespół Zamawiającego widzi, że Dostawca od cza­su do cza­su idzie mu na rękę (reali­zo­wa­nie drob­nych zachcia­nek Zamawiającego w zakre­sie projektu),
  4. Zespół Zamawiającego jest izo­lo­wa­ny od innych per­spek­tyw i spoj­rze­nia na reali­zo­wa­ny pro­jekt (sil­ne dąże­nie Dostawcy do wyeli­mi­no­wa­nia zewnętrz­ne­go nad­zo­ru mery­to­rycz­ne­go, audy­tów, nad­zo­ru autorskiego).

Psycholodzy co do jed­ne­go są zgod­ni: czło­wiek nie jest w sta­nie bro­nić się przed swo­imi emo­cja­mi, dla­te­go czę­sto jedy­nym spo­so­bem obro­ny przed mani­pu­la­cją jest uni­ka­nie kon­tak­tu z mani­pu­lan­tem. Nie ma tu zna­cze­nia czy to mani­pu­la­cja celo­wa czy nieuświadomiona.

Lekarstwo na sytu­acje, takie jak wyżej opi­sa­na, jest tyl­ko jed­no: zre­zy­gno­wać z warsz­ta­tów gru­po­wych z Dostawcą! Jak to komuś mówię to ma miej­sce prze­ra­że­nie i pada­ją sło­wa Ale prze­cież pra­ca gru­po­wa jest naj­efek­tyw­niej­sza! Tak uczy­li na szko­le­niu i mówi­li na kon­fe­ren­cjach”. W lite­ra­tu­rze nie raz spo­ty­ka­łem się z podej­ściem odra­dza­ją­cym warsz­ta­ty gru­po­we i burze mózgów z uwa­gi a ich duże kosz­ty i nie­efek­tyw­ność. Nie jest jed­nak takich opi­nii zbyt wie­le, bo mit efek­tyw­no­ści pra­cy gru­po­wej jest wiecz­nie żywy (mimo tego, że bada­nia nauko­we poka­zu­ją, że pra­ca gru­po­wa jest mniej efek­tyw­na niż pra­ca samodzielna).

Praca gru­po­wa, mity i fak­ty.

Jednak od cza­su do cza­su spo­ty­kam się książ­ka­mi czy wpi­sa­mi na blo­gach, że odej­ście od idei JAD (ang. Joint Application Development) wydat­nie popra­wi­ło jakość pro­jek­tów (sam IBM pro­po­nu­je w to miej­sce cał­ko­wi­te zastą­pie­nie warsz­ta­tów ana­li­zą doku­men­tów źró­dło­wych a potem pisem­ne for­mu­ło­wa­nie uwag i zarzą­dza­nie zakre­sem pro­jek­tu z uży­ciem ści­słej pro­ce­du­ry, co para­dok­sal­nie trwa kró­cej, jest tań­sze i daje znacz­nie lep­sze efekty).

Co cie­ka­we, idea taka poja­wi­ła się w np. tak zwa­nej zwin­nej meto­dzie zarzą­dza­nia pro­jek­tem SCRUM, w posta­ci roli Product Ownera (PO) jako oso­by prak­tycz­nie cał­ko­wi­cie sepa­ru­ją­cej zespół zama­wia­ją­ce­go od zespo­łu Dostawcy (busi­ness vs. developers):

There are seve­ral aspects abo­ut this role which I think are cri­ti­cal to under­stand: Product owners brid­ge the com­mu­ni­ca­tion betwe­en the team and the­ir sta­ke­hol­ders. As Figure 1 shows, in prac­ti­ce the­re pro­ves to be two cri­ti­cal aspects to this role: first as a sta­ke­hol­der pro­xy within the deve­lop­ment team and second as a pro­ject team repre­sen­ta­ti­ve to the ove­rall sta­ke­hol­der com­mu­ni­ty as a whole.[…]

The role of Product Owner (Scott Ambler, Agile Modeling)

Źródło: The Product Owner Role: A Stakeholder Proxy for Agile Teams

Ciekawe jest to, że więk­szość zna­nych mi zespo­łów dekla­ru­ją­cych pra­cę zgod­ną ze SCRUM, to zespo­ły deve­lo­per­skie, któ­re prak­tycz­nie cał­ko­wi­cie rezy­gnu­ją z praw­dzi­wej roli PO. Jak? Po pro­stu wyzna­cza­ją na PO jed­ne­go z pośród człon­ków zespo­łu deve­lo­per­skie­go, co jest pogwał­ce­niem zasad SCRUM. Skutek jest taki, że oso­ba, któ­rej pod­sta­wo­wą rolą jest zarzą­dza­nie funk­cjo­nal­no­ścią pro­duk­tu i sepa­ro­wa­nie Developera od Zamawiającego, pra­cu­je na rzecz deve­lo­pe­ra i godzi się na każ­dą zmia­nę korzyst­ną dla swo­je­go zespo­łu. Niestety w pro­jek­tach pro­gra­mi­stycz­nych jest to nie­mal­że regu­ła. W pro­jek­tach budow­la­nych (set­ki lat doświad­czeń) dla odmia­ny jest to praw­nie zaka­za­ne: nie wol­no łączyć roli nad­zo­ru autor­skie­go (archi­tekt i pro­jek­tant) ani z rolą wyko­naw­cy ani z rolą inwestora.

Na koniec pole­cam cie­ka­wy arty­kuł na podob­ny temat:

Polacy kupu­ją miesz­ka­nia bez usług i zie­le­ni. Wybierają szczel­nie ogro­dzo­ne beto­no­we pusty­nie bez przed­szko­li, pla­ców zabaw i komu­ni­ka­cji. A obok roz­wią­zań praw­nych to wła­śnie decy­zje kon­su­men­tów ukształ­tu­ją nam prze­strzeń na kolej­ne dzie­się­cio­le­cia. (żr. Ufamy dewe­lo­pe­rom bar­dziej niż leka­rzom. Przypomina to syn­drom sztok­holm­ski).

Bibliografia

[1]
J. Żeliński, ?Moja rola w pro­jek­tach,? IT-Consulting. [Online]. Available: https://it-consulting.pl//metoda-prowadzenia-analiz-i-standardy/
[3]
?Syndrom Sztokholmski,? Newsweek. [Online]. Available: 
[4]
?Syndrom Sztokholmski,? Niebieska linia. [Online]. Available: