zmiany vs. stagnacja

Czym jest dług technologiczny?

Dług tech­no­lo­gicz­ny to coś o czym mało się pisze i mówi, a pra­wie każ­dy się z nim bory­ka. W dużym uprosz­cze­niu to jak zmy­wa­nie naczyń: jeże­li robi­my to regu­lar­nie po każ­dym posił­ku, to zaj­mu­je to góra kil­ka­na­ście minut a do wyko­na­nia wystar­czy ście­recz­ka. Jeżeli jed­nak uzna­my, że zmy­je­my naczy­nia dopie­ro jak stat­ki” w zle­wo­zmy­wa­ku zasło­nią okno kuch­ni :), to nie tyl­ko jed­no­ra­zo­wo stra­ci­my znacz­nie wię­cej cza­su, ale dodat­ko­wo zafun­du­je­my sobie wal­kę z zaschnię­tym tłusz­czem i reszt­ka­mi jedze­nia, dla­te­go – co cie­ka­we – czas i wyma­ga­ne środ­ki” potrzeb­ne na rzad­kie pozmy­wa­nie tej góry nagro­ma­dzo­nych naczyń, są zawsze więk­sze niż suma nakła­dów pra­cy na czę­ste drob­ne zmy­wa­nie. Zmywanie naczyń to nie­lu­bia­na a koniecz­na czynność.

Z tech­no­lo­gią w fir­mach jest bar­dzo podob­nie: postęp tech­nicz­ny i ewo­lu­cyj­ne zmia­ny w fir­mach, są jak nara­sta­ją­ca licz­ba brud­nych naczyń: prę­dzej czy póź­niej będzie­my musie­li to upo­rząd­ko­wać (nad­ro­bić) – albo wyrzu­cić i kupić nowe. Jedno i dru­gie kosz­tu­je spo­ro. Dotyczy to w jed­na­ko­wym stop­niu aktu­ali­zo­wa­nia zakre­sów obo­wiąz­ków, doku­men­ta­cji tego jak fir­ma pra­cu­je, ana­liz i pro­jek­to­wa­nia, doku­men­ta­cji archi­tek­tu­ry IT jak i upgra­de­’ów oprogramowania.

Pojęcie ?dłu­gu? w pro­jek­cie śle­dzę od lat. Zjawisko to zna­ne jest od lat 90-tych, przy­kład takie­go dłu­gu opi­su­je E.Yourdon, któ­ry okre­śla go opi­so­wo jako ?brak pro­jek­tu? (pomi­ja­nie eta­pu ana­li­zy i pro­jek­to­wa­nia), w rozu­mie­niu bra­ku cało­ścio­wej kon­cep­cji, i wska­zu­je, że kon­se­kwen­cją zacią­ga­nia tego dłu­gu jest ?usta­wicz­ne prze­ra­bia­nie? opro­gra­mo­wa­nia w takt poja­wia­nia się nowych wyma­gań. Dług ten (archi­tek­to­nicz­ny, tu w rozu­mie­niu archi­tek­tu­ry opro­gra­mo­wa­nia) jest zacią­ga­ny poprzez roz­po­czy­na­nie prac nie zapla­no­wa­nych i nie poprze­dzo­nych pro­jek­to­wa­niem archi­tek­tu­ry cało­ści. Zadziwia mnie to, że nie raz źle piszą o tym dłu­gu tak­że zwo­len­ni­cy metod zwin­nych, któ­re to meto­dy bazu­ją wręcz na zacią­ga­niu tego dłu­gu. Prace pole­ga­ją­ce na odkry­wa­niu wyma­gań meto­da­mi kolej­nych przy­bli­żeń z pomo­cą pro­to­ty­pów, przy prak­tycz­nie zupeł­nym bra­ku eta­pów ana­li­zy i pro­jek­to­wa­nia, np. prze­cięt­ny ?sprint? to góra tydzień, jeże­li to jedy­ne pla­no­wa­nie w pro­jek­cie trwa­ją­cym (pla­no­wa­nym na) rok to jest to mega dług.

Nie zna­czy to, że wszyst­ko w fir­mie musi być koniecz­nie w naj­now­szej wer­sji, to zale­ży od tego jaki cykl życia fun­du­je nam dostaw­ca każ­dej apli­ka­cji z osob­na, jaką stra­te­gię wybie­rze­my My. Każdą nale­ży roz­pa­try­wać nie­za­leż­nie ale świa­do­mie. Z per­spek­ty­wy pro­gra­mi­sty mamy np. tak:

Wiedza o dłu­gu pozwa­la nam rów­nież go zacią­gać świa­do­mie. Moim zda­niem nie wol­no, pod karą chło­sty kla­wia­tu­ra­mi, iść na skró­ty w czę­ściach koro­wych sys­te­mu ale już w deta­lach np. inter­fej­su użyt­kow­ni­ka (KTÓRY NIE POSIADA LOGIKI APLIKACJI I LOGIKI BIZNESOWEJ!!!), może­my sobie cza­sem pozwo­lić na gor­szą jakość. Pójście na skró­ty w pierw­szym przy­pad­ku będzie mia­ło brze­mien­ne skut­ki dla całe­go sys­te­mu, w dru­gim bar­dziej lokal­ne. Jeśli w obu sytu­acjach pój­ście na skró­ty ozna­cza zysk 5h to gdzie lepiej zosta­wić małe lokal­ne pie­kieł­ko? za pomo­cą Dług Technologiczny : arek onli­ne.

Generalnie dług taki doty­czy nie­mal­że każ­de­go obsza­ru dzia­ła­nia orga­ni­za­cji. Warto więc wie­dzieć, że takie zja­wi­sko występuje:

koszty dlugu technologicznego

Ten pro­sty dia­gram obra­zu­je isto­tę dłu­gu tech­no­lo­gicz­ne­go, a raczej nawet uogól­nia­jąc: dłu­gu sta­gna­cji”. Zielona linia obra­zu­je sche­ma­tycz­nie okre­so­we, rela­tyw­nie drob­ne, zmia­ny i ich koszt. Mogą to być zarów­no bie­żą­ce upgra­de­’y (pat­che) opro­gra­mo­wa­nia jak i aktu­ali­za­cja doku­men­ta­cji opi­su­ją­cej: stra­te­gie fir­my, zakre­sy obo­wiąz­ków pra­cow­ni­ków w ich umo­wach, pro­ce­du­ry ISO (i inne) czy po pro­tu pro­jekt w toku. Brak takie­go uak­tu­al­nia­nia powo­du­je, że doku­men­ta­cja szyb­ko sta­je się nie­przy­dat­na (bo jest nie­ak­tu­al­na) a sko­ko­wy jej upgra­de wyma­ga cza­sem nawet prak­tycz­nie powtó­rze­nia całe­go pro­jek­tu wdro­że­nio­we­go (powtór­ne ponie­sie­nie jego dużych kosz­tów). Dodatkowy koszt sko­ko­wy dużej zmia­ny, to efekt mię­dzy inny­mi tego, że: nie mamy na nią zbyt wie­le cza­su więc ponie­sie­my dodat­ko­wy koszt skró­ce­nia tej czyn­no­ści (przy­mu­so­wy zakup zmy­war­ki). Kolejny koszt to sko­ko­wa zmia­na przy­zwy­cza­jeń ludzi, zmia­ny ewo­lu­cyj­ne odby­wa­ją się pły­nie, prak­tycz­nie bez kosz­tów, sko­ko­we to dodat­ko­we szko­le­nia i czas na dosto­so­wa­nie. Taki dług potra­fi w skraj­nych sytu­acjach dopro­wa­dzić fir­mę do upa­dło­ści albo co naj­mniej do znisz­cze­nia jej kon­ku­ren­cyj­no­ści (brak środ­ków na sko­ko­wą zmia­nę tech­no­lo­gii, pod­nie­sie­nie kom­pe­ten­cji kadry itp.).

Klasycznym przy­kła­dem takie­go dłu­gu jest obec­ny pro­blem wie­lu firm, posia­da­czy Windows XP, firm któ­re do tej pory nie wyko­na­ły upgra­de. Czy to dużo firm? No nie­ste­ty jak widać, dużo:

W mar­cu z kom­pu­te­rów z opro­gra­mo­wa­niem Windows XP pocho­dzi­ła bli­sko jed­na czwar­ta ruchu w sie­ci ? wyni­ka z danych fir­my Gemius. Zakończenie wspar­cia dla tego sys­te­mu ope­ra­cyj­ne­go może być pro­ble­mem ? oce­nia­ją eks­per­ci z Akademii Leona Koźmińskiego.

Zdaniem Macieja Madzińskiego, eks­per­ta Akademii Leona Koźmińskiego ds. inno­wa­cji i nowo­cze­snych tech­no­lo­gii, zaprze­sta­nie wspie­ra­nia sys­te­mu Windows XP przez Microsoft będzie pro­ble­mem i będzie wywo­ły­wać, a nawet już wywo­łu­je pew­ne nie­za­do­wo­le­nie. (Koniec Windowsa XP ? pro­blem czy szan­sa? :: Gemius SA).

W efek­cie fir­my te nie tyl­ko w koń­cu i tak ponio­są koszt tej aktu­ali­za­cji. Poniosą tak­że kosz­ty sko­ko­wej aktu­ali­za­cji wie­lu innych pro­duk­tów (przej­ście na now­szą wer­sje Windows, w wie­lu przy­pad­kach wyma­ga aktu­ali­za­cji wie­lu apli­ka­cji, sys­te­mów zarzą­dza­nia sie­cią, ich powtór­ne wdra­ża­nie itp.). Niektórzy eks­per­ci oce­nia­ją, że w nie­któ­rych fir­mach będą to kosz­ty więk­sze w porów­na­niu z kosz­ta­mi pro­ble­mu roku 2000”. Przytoczę teraz cytat z inne­go bloga:

Na blo­gu Szymona Błochowicza umiesz­czo­na jest taka defi­ni­cja dłu­gu tech­no­lo­gicz­ne­go: ?Cokolwiek co czy­ni Twój pro­dukt trud­nym do zmia­ny w przy­szło­ści jest dłu­giem tech­no­lo­gicz­nym ? możesz albo zapła­cić peł­ną cenę tech­no­lo­gicz­ną teraz zro­bić od razu roz­wią­za­nie ela­stycz­ne albo zacią­gnąć dług i spła­cić go póź­niej zro­bić roz­wią­za­nie szyb­kie ale nie­ela­stycz­ne a przy pierw­szej koniecz­no­ści zmia­ny mieć trud­ność z bra­kiem ela­stycz­no­ści?. Najczęściej dług tech­no­lo­gicz­ny koja­rzo­ny jest ze spo­so­bem kodo­wa­nia, doku­men­to­wa­nia czy też testo­wa­nia. Ale Arkadiusz Bendedykt na swo­im blo­gu wska­zu­je rów­nież, że ?dług tech­no­lo­gicz­ny to nie tyl­ko pój­ście na skró­ty pod­czas kodo­wa­nia, to rów­nież zanie­cha­nie prze­cho­dze­nia na naj­now­sze wer­sje narzę­dzi pro­gra­mi­stycz­nych oraz nie wspie­ra­nie naj­now­szych sys­te­mów ope­ra­cyj­nych?. Jeszcze dalej idzie Jan Rychter, któ­ry wska­zu­je że: ?gdy doty­czy to [tj. pój­ście na skró­ty – przy­pis A.S.] poje­dyn­czych funk­cji w kodzie, dług jest nie­wiel­ki. Gdy jed­nak mówi­my o decy­zjach archi­tek­tu­ral­nych [wolał­bym uży­wać okre­śle­nia decy­zje archi­tek­to­nicz­ne – przy­pis A.S.], może być olbrzy­mi i pocią­gać za sobą koniecz­ność prze­ra­bia­nia kie­dyś całych sys­te­mów?. (źr. Czym jest dług archi­tek­to­nicz­ny? | Architektura Korporacyjna).

Tak więc sta­gna­cja szko­dzi, są to krót­ko­trwa­łe zyski, podob­ne do nie­za­pła­ce­nia rachun­ku za ener­gie elek­trycz­ną: za mie­siąc będzie dwu­krot­nie wyż­szy plus odset­ki. Bieżące, dobrze zapla­no­wa­ne aktu­ali­za­cje” (opro­gra­mo­wa­nia, doku­men­ta­cji pro­jek­to­wej, ana­li­zy i pla­no­wa­nia, itp.) to rela­tyw­nie małe kosz­ty, a dla fir­my istot­ne są nie tyle kwo­to­we chwi­lo­we wydat­ki (oszczęd­no­ści) co płyn­ność finan­so­wa i dłu­go­ter­mi­no­wa ren­tow­ność. Dlatego per­ma­nent­ni dłuż­ni­cy zawsze pła­ca wię­cej a cza­sa­mi ban­kru­tu­ją. Tu pole­cam mój wpis z przed roku: Utopia – czy­li model ide­ału poma­ga w pro­jek­tach.

zmiany vs. stagnacja

___

Rok póź­niej:

A na koniec pole­cam to:

Zasady panu­ją­ce na ryn­ku pro­duk­tów i usług IT wyda­ją się przej­rzy­ste: klient wyda­je pie­nią­dze na jakiś pro­dukt, ocze­ku­jąc w zamian okre­ślo­nych korzy­ści. Jak wyni­ka z udo­stęp­nio­nych przez Gartner Inc. ana­liz, fir­my reali­zu­ją przy oka­zji swo­ją stra­te­gię, o któ­rej wola­ły­by klien­tom nie mówić. Jakie są ich cele? […] Omawiając stra­te­gie firm, Gaughan pod­kre­ślił rów­nież zna­cze­nie dzia­ła­ją­cych przy nich ośrod­ków badaw­czych. Ich nad­rzęd­nym celem jest two­rze­nie inno­wa­cji w takich spo­sób, aby ? zacho­wu­jąc pozo­ry roz­wo­ju ? utrzy­my­wać ist­nie­ją­cy stan rze­czy tak dłu­go, jak to tyl­ko moż­li­we.(źr. Czego naj­więk­sze fir­my tech­no­lo­gicz­ne nie mówią swo­im klien­tom?. oraz ory­gi­nał: What Microsoft, Oracle, IBM, And SAP Don’t Tell Customers)

Inne artykuły na podobny temat

Komentarze

  1. Sławomir Sobótka 12 maja 2014 at 11:48

    Jest jesz­cze jeden aspekt dłu­gu tech­no­lo­gicz­ne­go, któ­ry zaczy­na być dotkli­wy już w Polsce: utra­ta pra­cow­ni­ków i nie­moż­ność pozy­ska­nia nowych, któ­rzy chcie­li­by sprzą­tać po przod­kach” – skła­da się na to wie­le czyn­ni­ków: demo­gra­fia, zapo­trze­bo­wa­nie i prze­mia­na poko­leń http://​en​.wiki​pe​dia​.org/​w​i​k​i​/​S​t​r​a​u​s​s​?​H​o​w​e​_​g​e​n​e​r​a​t​i​o​n​a​l​_​t​h​e​ory

    • Jaroslaw Zelinski 12 maja 2014 at 13:21

      o to fakt, o tym nie pomy­śla­łem… ale to też chy­ba woda na młyn zwo­len­ni­ków two­rze­nia dokumentacji.….

  2. __karamba__ 23 października 2014 at 20:22

    Nie zgo­dzę się z tym, że to za dziw­ną powin­no sie uzna­wać dez­apro­ba­tę dłu­gu tech­no­lo­gicz­ne­go przez zwo­len­ni­ków meto­dyk zwin­nych. To brzmi jak nie­uda­na pró­ba zawłasz­cze­nia dla sie­bie przez zwo­len­ni­ka bar­dziej kon­ser­wa­tyw­nych metod roli twór­cy praw­dzi­we­go opro­gra­mo­wa­nia. Otóż dług tech­no­lo­gicz­ny może wystę­po­wać przy zasto­so­wa­niu dowol­nej meto­do­lo­gii. Jest od niej nie­za­leż­ny. Dług tech­no­lo­gicz­ny poja­wia się tam, gdzie poja­wia się nie­dba­łość, spo­wo­do­wa­na cza­sa­mi bra­kiem kom­pe­ten­cji pro­gra­mi­stów, ale znacz­nie czę­ściej, lub nawet pra­wie zawsze, złym, nie­od­po­wie­dzial­nym zarzą­dza­niem pro­jek­tem. Nawet prze­cięt­ny pro­gra­mi­sta jest w sta­nie po sobie posprzą­tać, jed­nak jeże­li pro­duct owner widzi tyl­ko nowe funk­cjo­nal­no­ści, a pro­ject mana­ger nie jest wsta­nie wyne­go­cjo­wać czas na spła­tę dłu­gu tech­no­lo­gicz­ne­go, sku­tek jest opłakany.

  3. Jaroslaw Zelinski 25 października 2014 at 10:51

    Kontekst zwin­ne­go podej­ścia w powsta­wia­niu dłu­gu tu nie doty­czy tech­no­lo­gii, a zanie­cha­nia bie­żą­ce­go doku­men­to­wa­nia” (lub doku­men­to­wa­nia w ogó­le), a to tak­że rodzaj dłu­gu tech­no­lo­gicz­ne­go. Cytowany autor blo­ga sku­piał się na dłu­gu w kon­tek­ście narzę­dzi i tech­no­lo­gii, ja wska­za­łem ana­lo­gię w kon­tek­ście wie­dzy o pro­duk­cie” (doku­men­ta­cji opi­sją­cej orga­ni­za­cję, dzi­siaj nazy­wa­nej archi­tek­tu­rą biz­ne­so­wą lub kor­po­ra­cyj­ną) czy­li tak na praw­dę jego doku­men­ta­cji. Wiedzę o fir­mie i jej IT moż­na na bie­żą­ca kon­ser­wo­ać (aktu­ali­zo­wać) lub sko­ko­wo pozy­ski­wać w momen­cie roz­po­czy­na­nia kolej­ne­go wdrożenia…Lub pro­wa­dzić pro­jekt «zwin­nie” nie dys­po­nu­jąc wie­dzą inną niż ta ad-hoc pozy­ska­na od użyt­kow­ni­ków (z regu­ły naj­niż­szej jako­ści nie­ste­ty, bo pozba­wio­na kon­tek­stu całości).

Dodaj komentarz

Twój adres email nie zostanie opublikowany

System komentarzy służy także do uzyskania konsultacji u autora tekstu, w przedmiocie treści artykułu.

Identyfikator *
E-mail *
Witryna internetowa

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