Wstęp

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, tak­że przed­są­do­wych, mię­dzy dostaw­cą opro­gra­mo­wa­nia i zama­wia­ją­cym. Bywa, że jest to już etap pisa­nia opi­nii dla sądu. 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ą cza­sa­mi 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 zmieniłem zdanie? 

Zarówno wła­sne doświad­cze­nie, jak 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 kon­sul­tant i pro­gra­mi­sta dostaw­cy 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… 

Umowa efektu a staranne działanie

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­niem w toku wdra­ża­nia zmian w firmach. 

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

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. https://​repo​zy​to​rium​.kozmin​ski​.edu​.pl/​p​l​/​p​u​b​/​3​442
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
Dennis, A., Wixom, B. H., & Roth, R. M. (2012). Systems ana­ly­sis and design (5th ed). John Wiley.

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 two­rzy­my apli­ka­cje na zamó­wie­nie. Otrzymujemy jed­no zapy­ta­nia na tydzień. Nie zda­rzy­ło nam się jesz­cze otrzy­mać doku­men­ta­cji wyko­na­nej przez fir­mę zewnętrz­ną. Zgłaszają się do nas fir­my małe, śred­nie i wielkie.

    1. Jarosław Żeliński

      Od pra­wie 20 lat robię takie doku­men­ty dla zama­wia­ją­cych, przy­zna­je, że mało firm korzy­sta z tej usłu­gi. Przyznaję, że mało ludzi w ogó­le robi takie doku­men­ty, ale nie jestem jedy­ny któ­ry takie doku­men­ty opra­co­wu­je (tam, gdzie fir­my na praw­dę dba­ją o swo­je know-how i pra­wa autor­skie, powsta­ją one ZAWSZE :), ma moim blo­gu jest wie­le odno­śni­ków do innych stron o podob­nych cha­rak­te­rze, do lite­ra­tu­ry). Moimi klien­ta­mi są fir­my: małe, śred­nie i nawet wiel­kie (np. KGHM SA). 

      Polecam rapor­ty Chaos Report: 90% pro­jek­tów łącz­nie: śred­nich i dużych, to poraż­ki ter­mi­nów i kosz­tów. Ja (moi klien­ci) od 20 lat nie mam pora­żek, zda­rza sie, że roz­wią­zu­je umo­wę przed cza­sem, gdy klient łamie warun­ki zawar­tej umo­wy. Samo dowie­zie­nie pro­jek­tu” to żaden sukces.

      Od lat sły­szę, że:
      – dostaw­cy nie chcą takich doku­men­tów bo oni by to zro­bi­li ina­czej” (narzu­cam dość ostre rygo­ry na kom­pe­ten­cje dostaw­cy i technologię),
      – dostaw­cy nie chcą takich doku­men­tów bo to wymu­sza na nich umo­wę o dzie­ło, a pro­gra­mi­ści wolą na koszt klien­ta eks­pe­ry­men­to­wać i się uczyć.

      Moje doświad­cze­nie:
      – w zasa­dzie w 100% przy­pad­ków jestem anga­żo­wa­ny do dru­gie­go, nie raz trze­cie­go, podej­ścia do wdro­że­nia (poprzed­nie to zarzu­co­ne lub wstrzy­ma­ne projekty),
      – w 100% kolej­na reali­za­cja, z dobry­mi doku­men­ta­mi, zawsze oka­zu­je się, jako całość, dla klien­ta i tań­sza i szyb­sza, mimo tego, że trze­ba mi zapła­cić za ana­li­zę i pro­jek­to­wa­nie, a potem za nad­zór autor­ski (lista na pierw­szej stro­nie bloga).
      – w 90% przy­pad­ków deve­lo­per podej­mo­wał pró­by usu­nię­cia mnie z pro­jek­tu lub pomi­nię­cia, bo mu prze­szka­dzam”, uda­ło się to tyl­ko dwa razy w mojej karie­rze, oba te pro­jek­ty mia­ły potem kło­po­ty z ochro­ną know-how i kosz­tem utrzy­ma­nia i roz­wo­ju aplikacji. 

      Jest w tym kra­ju kil­ku deve­lo­pe­rów, któ­rzy pole­ca­ją mnie swo­im klien­tom, bo jed­nak wolą wdro­że­nia reali­zo­wa­ne w pla­no­wa­nym ter­mi­nie i zakre­sie usta­lo­nym na począt­ku. Zapraszam :).

      To oczy­wi­ście nie opi­nia o Pana fir­mie, bo nie znam ani Pana ani Pana fir­my, ani Pana klien­tów. Opisałem tu zna­ne mi z lite­ra­try nauko­wej wyni­ki badań oraz moje doświad­cze­nie. Tak, uwa­żam że nie­uda­ne wdro­że­nia do wina zama­wia­ją­ce­go, że poszedł do dostaw­cy i prze­ka­zał mu w 100% pałecz­kę, mimo tego, że dostaw­ca ma kon­flikt inte­re­su. To czy dany dostaw­ca robi to świa­do­mie czy nie, nie wiem.

      (co i w jakiej tech­no­lo­gii tworzycie?) 

    2. Jarosław Żeliński

      Dodam jesz­cze, że: to czy dana fir­ma deve­lo­per­ska robi coś dobrze, nie zale­ży od tego czy dowo­zi pro­jek­ty”, a od tego jak ich reali­za­cje wyglą­da­ją kosz­to­wo i ter­mi­no­wo na tle innych. Mało kto ma moż­li­wość wyko­na­nia tego same­go pro­jek­tu na dwa róż­ne spo­so­by, ja zawsze (bo z regu­ły robię po kimś to samo jesz­cze raz)… Po dru­gie, jeże­li w odpo­wie­dzi na iden­tycz­ne doku­men­ty (zapy­ta­nie) otrzy­mu­ję od róż­nych deve­lo­pe­rów, wyce­ny róż­nią­ce się nawet o rząd wiel­ko­ści, to wie­le to mówi i o ryn­ku i o tych dewe­lo­pe­rach. Jeżeli ktoś w 2020 roku klei” wszyst­ko cze­go się zła­pie, meto­da rela­cyj­na baza danych, język SQL i resz­ta kodu” to zna­czy, że archi­tek­to­nicz­nie nadal tkwi na prze­ło­mie lat 80/90-tych ubie­głe­go wieku. 

Dodaj komentarz

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