Podczas jed­nej z wie­lu moich dys­ku­sji na forach na tema­ty wyso­kich nakła­dów na ana­li­zę i pro­jek­to­wa­nie” :), padło stwierdzenie:

Mam jed­nak wra­że­nie, że zna­cze­nie może tu mieć ska­la pro­jek­tu o któ­rym ja pisze. Nie jest to jakiś wiel­ki sys­tem. Jest to pro­sta apli­ka­cja webo­wa w php. Myślę, że to w jakiś spo­sób uspra­wie­dli­wia pew­ne uprosz­cze­nia i skró­ty. Czy się mylę?

Obawiam się, że nie­ste­ty tak. Znaczenie ma, nie wiel­kość pro­jek­tu, a cykl jego życia. Jeżeli pla­no­wa­ne jest stwo­rze­nie efe­me­ry­dy, czy­li powsta­nie apli­ka­cja, któ­rą wywa­li­my do kosza po kwar­ta­le uży­wa­nia np. apli­ka­cja obsłu­gu­ją­ca jed­ną kam­pa­nię pro­mo­cyj­ną, po któ­rej potrzeb­ne są potem tyl­ko dane, pro­gram któ­ry je zbie­rał leci do kosza, jest już niepotrzebny.

Jeżeli jed­nak pla­no­wa­na jest apli­ka­cja, któ­ra ma przed sobą kil­ka lat życia, to jed­no jest pew­ne: poja­wią się nowe wyma­ga­nia, o któ­rych dziś nie mamy bla­de­go poję­cia… taka apli­ka­cja musi być maj­stersz­ty­kiem pro­jek­to­wym, bo popra­wia­nie cze­goś nie­po­pra­wial­ne­go” jest bar­dzo kosz­tow­ne… Należy pamię­tać, że nawet
wiel­ka efe­me­ry­da wyma­ga mniej pra­cy ana­li­tycz­no-pro­jek­to­wej niż malut­ka apli­ka­cja na kil­ka lat…

Podstawową rze­czą, jaka nale­ży okre­ślić pod­czas ana­li­zy biz­ne­so­wej, powin­no być jed­no z klu­czo­wych wyma­gań jako­ścio­wych(!) jest nim wła­śnie zapla­no­wa­nie cyklu życia apli­ka­cji (pro­duk­tu). Poniżej pro­sty diagram:

Na osi pio­no­wej mamy kosz­ty, oś pozio­ma to czas życia apli­ka­cji (opr. wła­sne autora).

Czerwona linia cią­gła to pro­jekt ” na żywioł”. Ograniczono do mini­mum ana­li­zę i pro­jek­to­wa­nie apli­ka­cji, wytwo­rze­nie jej nie było więc zbyt kosz­tow­ne a samo admi­ni­stro­wa­nie jest zawsze kosz­tem niskim. Jednak każ­da inge­ren­cja w zmia­nę (w tym roz­bu­do­wę) funk­cjo­nal­no­ści to nie­mal­że kolej­ny pro­jekt o ska­li czę­sto porów­ny­wal­nej z pier­wot­nym wytwo­rze­niem. Linia prze­ry­wa­na obra­zu­je nara­sta­ją­ce w cza­sie kosz­ty pono­szo­ne na utrzy­ma­nie przy życiu” takie­go produktu.

Brak pier­wot­ne­go pro­jek­tu powo­du­je, że wyma­ga­nia są iden­ty­fi­ko­wa­ne poprzez kolej­ne pro­to­ty­py (są nimi kolej­ne wer­sje). Projekty na żywioł” tak­że wiec powsta­je dłu­go”. Wymaga dodat­ko­we­go cza­su na te ite­ra­cje i raczej nigdy nie są odda­wa­ne do użyt­ku apli­ka­cje w pierw­szej wersji.

Linia zie­lo­na, to ana­li­za i pro­jek­to­wa­nie nasta­wio­ne na opty­ma­li­za­cję archi­tek­tu­ry, przy­szłe zmia­ny i roz­wój. Tu koszt wytwo­rze­nia, poprze­dzo­ne­go ana­li­zą i pro­jek­to­wa­niem, jest wyż­szy, bywa, że nawet dwu­krot­nie. Co cie­ka­we jed­nak, z regu­ły nie trwa to dłużej,bo czę­sto opro­gra­mo­wa­nie jest odda­wa­ne do użyt­ku w pierw­szej, góra dru­giej ite­ra­cji. Linia prze­ry­wa­na obra­zu­je, ana­lo­gicz­nie, nara­sta­ją­ce kosz­ty utrzy­ma­nia i roz­wo­ju w cza­sie, tak powsta­łej aplikacji.

Każdy pro­jekt (efe­me­ry­da vs. long life”), porów­nu­jąc dwa powyż­sze sce­na­riu­sze, ma próg ren­tow­no­ści. Najczęściej jest to moment pierw­szej poważ­nej zmia­ny lub roz­sze­rze­nia (sza­ry obszar na dia­gra­mie to czas prze­pła­ca­nia dla wer­sji czer­wo­nej na żywioł”). Niestety, gdy to odkry­je księ­go­wość (kon­tro­ling) jest za póź­no, bo rezy­gna­cja na tym eta­pie jest jako decy­zja bar­dzo trud­na a tak­że kosz­tow­na. Nie zmie­nia to fak­tu, że rezy­gna­cja na tym eta­pie jest naj­czę­ściej naj­roz­sąd­niej­szym wyj­ściem, tu jed­nak działa

sta­ra zasa­da mani­pu­la­cji, tak zwa­na niska pił­ka: łatwo (małym kosz­tem) roz­po­czę­ty pro­jekt o szyb­ko rosną­cych kosz­tach w cza­sie jest men­tal­nie trud­ny do zarzu­ce­nia a rosną­ce kosz­ty są uspra­wie­dli­wia­ne i racjo­nal­ne myśle­nie jest odkła­da­ne. Dostawcy opro­gra­mo­wa­nia sto­su­ją nie raz tę meto­dę mani­pu­la­cji z peł­ną pre­me­dy­ta­cją,

nie raz jed­nak to nabyw­ca sam się mani­pu­lu­je” wie­rząc na począt­ku, że moż­na bar­dzo tanio i bar­dzo dobrze. Potem ma już miej­sce tyl­ko obro­na wła­sne­go hono­ru”, co z racjo­nal­nym zarzą­dza­niem kosz­ta­mi nie ma nic wspól­ne­go. Tu win­ny jestem uwagę:

pro­jek­ty na żywioł znacz­nie czę­ściej mają prze­kra­cza­ne ter­mi­ny i budże­ty (bada­nia mówią, że 75% pro­jek­tów ma prze­kro­czo­ny budżet śred­nio o 60% z winy źle okre­ślo­nych wyma­gań) niż pro­jek­ty pro­wa­dzo­ne meto­dycz­nie”.

Jak więc zaradzić dużym kosztom utrzymania oprogramowania?

Jest tyl­ko jeden spo­sób: pla­no­wać ren­tow­ność i czas życia każ­de­go pro­jek­tu i jego pro­duk­tu. Warto zwró­cić uwa­gę, że poja­wia się tu [[róż­ni­ca pomię­dzy pro­jek­tem a programem]]).

Aplikacje zapla­no­wa­ne jako efe­me­ry­dy, to pro­duk­ty pro­jek­tów, nale­ży bez lito­ści i sen­ty­men­tów wyrzu­cać je jak zro­bią swo­je”. Zmiana pla­nów z ich wyrzu­ce­nia na dal­szy roz­wój to naj­czę­ściej krach finan­so­wy pro­jek­tu. W takich wypad­kach, na bazie doświad­czeń z eks­plo­ata­cji efe­me­ry­dy, naj­le­piej zapro­jek­to­wać nowy sys­tem z pla­nem na kil­ka lat eksploatacji.

Aplikacje pla­no­wa­ne jako narzę­dzia pra­cy na lata, bez­względ­nie dobrze pro­jek­to­wać i poprze­dzać ana­li­zą biz­ne­so­wą przed ich wytwa­rza­niem, bo wte­dy mamy już do czy­nie­nia nie z pro­jek­tem a wła­śnie z programem.

Podstawowym błę­dem, moim zda­niem, jest trak­to­wa­nie zaku­pu lub wytwo­rze­nia opro­gra­mo­wa­nia pla­no­wa­ne­go na dłu­gie uży­wa­nie” jako pro­jek­tu pro­gra­mi­stycz­ne­go. To nie pro­jekt, to pro­gram! Projektem jest wytwo­rze­nie pier­wot­nej wer­sji, potem pro­jek­ta­mi są kolej­no wpro­wa­dza­ne nowe funk­cjo­nal­no­ści lub zmia­ny. Całość to program.

A teraz pro­szę sobie wyobra­zić, że więk­szość opro­gra­mo­wa­nia ERP czy CRM na naszym ryn­ku, to pro­duk­ty, któ­re pier­wot­nie powsta­ły na potrze­by jed­ne­go kon­kret­ne­go zama­wia­ją­ce­go a potem, jak się uda­ło wdro­żyć w jed­nej fir­mie, ktoś docho­dził do wnio­sku: to może sprze­da­waj­my to kolej­nym klien­tom”… resz­tę sami Państwo sobie dopowiedzcie.

Powyższe nasu­wa od razu kolej­ny wnio­sek: zama­wia­ją­cy naj­czę­ściej for­mu­łu­ją zapy­ta­nia w spo­sób pozwa­la­ją­cy dostaw­com skła­dać ofer­ty na pierw­szy etap, pole­ga­ją­cy tyl­ko na dostar­cze­niu i wdro­że­niu. Jak widać z zasa­dy wygry­wa­ją tu pro­jek­ty na żywioł”. Żądanie od dostaw­ców uję­cia kosz­tów utrzy­ma­nia (tak zwa­ny main­te­nan­ce”) nicze­go nie zmie­nia bo to tyl­ko sta­ła opla­ta admi­ni­stra­cyj­na. Jedynym spo­so­bem na rze­tel­ne porów­na­nie ofert jest ope­ro­wa­nie kosz­tem cyklu życia dostar­czo­ne­go produktu.

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. Albert Dabinski

    Zgadzam sie w peł­ni z teza, ze powo­dze­nie pro­jek­tu nie jest pochod­ną jego wiel­ko­ści. Przeprowadzone w Polsce bada­nia to potwier­dza­ją, zachę­cam do zapo­zna­nia sie row­nież z inny­mi wyni­ka­mi zamiesz­czo­ny­mi w rapor­cie http://​www​.pmre​se​arch​.pl.
    Jeżeli cho­dzi o ope­ro­wa­nie kosz­tem cyklu życia to widzę tutaj pro­blem jak go obiek­tyw­nie wyzna­czyć, aby fak­tycz­nie odpo­wia­dał rze­czy­wi­stym kosz­tów zmian. Osobiście kie­ro­wal­bym sie ku kosz­tom typo­wych ele­men­tów zmian – dodat­ko­wy ws, dodat­ko­wy ekran, dodat­ko­wy atry­but itd – bo prze­cież same zmia­ny leżą w sfe­rze zapo­trze­bo­wan zama­wia­ja­ce­go i trud­no je w calo­sci przewidzieć 🙂

    1. Jarek Żeliński

      Bardzo cie­ka­we bada­nie, pole­cam każ­de­mu kto sie­dzi” w tej bran­ży (zacy­to­wa­łem w kolej­nym swo­im arty­ku­le). Do auto­rów bada­nia mam pyta­nie: jak zde­fi­nio­wa­no meto­dy­kę Agile na potrze­by badania?

  2. Marek Kuszneruk

    Spojrzenie na cały cykl życia opro­gra­mo­wa­nia wydłu­ża per­spek­ty­wę cza­so­wą. Dlaczego w kon­tek­ście ERP/CRM jest to nie­zbęd­ne? Patrząc z per­spek­ty­wy krót­ko­okre­so­wej (pro­jek­tu) widzi­my tyl­ko uży­wa­nie sys­te­mu” i na tym zwy­kle sie koń­czy. Patrząc z per­spek­ty­wy dłu­go­okre­so­wej (pro­gra­mu) któ­ra jest zbież­na z cyklem życia opro­gra­mo­wa­nia, naj­waż­niej­sze są korzy­ści biz­ne­so­we tj. mie­rzal­na popra­wa efek­tyw­no­ści pro­ce­sów (np. uwol­nie­nie czę­ści kapi­ta­łu obro­to­we­go). To dru­gie umy­ka, kie­dy poprze­sta­je­my na myśle­niu krótkookresowym.

    1. Jacek Ledworowski

      Re: Marek Kuszneruk dnia 22 mar­ca 2012 o 09:15
      (…) Patrząc z per­spek­ty­wy dłu­go­okre­so­wej (pro­gra­mu) któ­ra jest zbież­na z cyklem życia opro­gra­mo­wa­nia, naj­waż­niej­sze są korzy­ści biz­ne­so­we tj. mie­rzal­na popra­wa efek­tyw­no­ści procesów (…) 

      … i zosta­ła zro­bio­na choć migaw­ka” sta­nu począt­ko­we­go (przed­wdro­że­nio­we­go), okre­śla­ją­ca cało­kształt – stan i oce­nę zaan­ga­żo­wa­nia zaso­bów w reali­za­cję pro­ce­sów, aby moż­na było doko­nać jakiejś oce­ny opar­tej o te same kry­te­ria po jakimś czasie.
      Bo co z tego, że uwol­ni­my kapi­tał obro­to­wy, albo zwięk­szy­my pro­duk­tyw­ność, jak nie­wi­docz­nym w krót­kim okre­sie kosz­tem będzie np. zwięk­szo­na rota­cja per­so­ne­lu, skut­ku­ją­ca kosz­ta­mi szko­leń, albo wyż­sza absen­cja cho­ro­bo­wa, wyni­ka­ją­ca z zawy­żo­nych wyma­gań wobec użyt­kow­ni­ków i bra­ku dzia­łań dosto­so­waw­czych (wyni­ka­ją­cych ze struk­tu­ry wie­ko­wej pracowników).
      Czy każ­dy mene­dżer IT ma obraz takich kon­se­kwen­cji wdra­ża­jąc sys­tem, czy patrzy tyl­ko przez pry­zmat swo­je­go ogródka?

Dodaj komentarz

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