Wprowadzenie

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.

Dług technologiczny

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 online.

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:

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.

___

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)

Na zakoń­cze­nie zapra­szam do kon­ty­nu­acji tego tema­tu w arty­ku­le: Czym jest dług infor­ma­cyj­ny.