Wprowadzenie

W 2014 roku pisa­łem o dłu­gu technologicznym:

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 czyn­ność. 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.

źr.: Czym jest dług tech­no­lo­gicz­ny? – Jarosław Żeliński IT-Consulting

W arty­ku­le pisa­łem głów­nie o tech­no­lo­gii. Dług tech­no­lo­gicz­ny, jak każ­dy dług – prę­dzej czy póź­niej – wyma­ga spła­ty. Co się dzie­je gdy nie spła­ca­my dłu­gów? Zaczyna się tak zwa­na spi­ra­la zadłu­że­nia, któ­ra w wie­lu przy­pad­kach koń­czy się kra­chem. W inży­nie­rii jest tak samo: przy­cho­dzi moment, gdy dług prze­kro­czy war­tość zaso­bów zadłu­żo­ne­go. Innymi sło­wy koszt aktu­ali­za­cji pozio­mu tech­no­lo­gii do aktu­al­ne­go wyma­ga­ne­go, może prze­wyż­szyć moż­li­wo­ści organizacji. 

Dzisiaj powie­my co nie­co o innym i gor­szym dłu­gu: o dłu­gu infor­ma­cyj­nym (infor­ma­tion depth).

Dług Informacyjny

Dług infor­ma­cyj­ny, jako poję­cie, pocho­dzi z teo­rii trans­mi­sji danych:

Dług infor­ma­cyj­ny, wpro­wa­dzo­ny przez Martiniana, jest mia­rą dodat­ko­wych sym­bo­li kodo­wych potrzeb­nych w deko­de­rze do zde­ko­do­wa­nia wszyst­kich nie­zna­nych sym­bo­li wiadomości.

Innymi sło­wy popraw­ne odko­do­wa­nie prze­sła­nych infor­ma­cji wyma­ga kom­ple­tu bra­ku­ją­cych danych w nada­nym cią­gu kodo­wym, musi­my skom­ple­to­wać wszyst­kie zale­głe i nie­ode­bra­ne dane. Jak sie to ma inżynierii?

Długiem infor­ma­cyj­nym w orga­ni­za­cji i zarzą­dza­niu nazy­wa­my róż­ni­cę mię­dzy posia­da­ną (czy­li udo­ku­men­to­wa­ną) wie­dzą o tym jak okre­ślo­ny sys­tem dzia­ła, a tym jak on fak­tycz­nie dzia­ła. Najprostszą meto­dą zacią­ga­nia dłu­gu infor­ma­cyj­ne­go jest budo­wa i roz­wi­ja­nie sys­te­mu bez rów­no­le­głe­go doku­men­to­wa­nia pod­ję­tych decy­zji na temat tego jak ma dzia­łać, a potem jak fak­tycz­nie dzia­ła. Tym sys­te­mem może być zarów­no cała orga­ni­za­cja, jak i jakiś jej pod­sys­tem, np. infor­ma­tycz­ny. Obrazowo wyglą­da to tak:

Jeżeli fir­ma pla­nu­je wdra­ża­nie zmian, w tym np. wdro­że­nie nowe­go sys­te­mu infor­ma­tycz­ne­go, poja­wia się pro­blem niwe­lo­wa­nia dłu­gu infor­ma­cyj­ne­go i jego koszt: musi­my w krót­kim cza­sie uzu­peł­nić bra­ku­ją­cą wie­dzę. Nazywamy to czę­sto ana­li­zą biz­ne­so­wą, ana­li­zą przed­wdro­że­nio­wą itp.:

Niestety bar­dzo czę­sto, po wyko­na­niu tej ana­li­zy i zakoń­cze­niu wdro­że­nia, w orga­ni­za­cji zaczy­na się pro­ces nara­sta­nia dłu­gu infor­ma­cyj­ne­go. A bar­dzo czę­sto ten pro­ces zaczy­na się zaraz po zakoń­cze­niu tej kosz­tow­nej ana­li­zy i roz­po­czę­ciu wdro­że­nia, bo dostaw­ca sys­te­mu nie doku­men­tu­je efek­tów swo­ich prac (a powinien). 

Popatrzmy na wykre­sy poniżej:

Rysunek (a) poka­zu­je typo­we dla inży­nie­rii sys­te­mów inwe­sto­wa­nie w przy­szłość (, pole­ga­ją­ce na pro­jek­to­wa­niu (czy­li tak­że doku­men­to­wa­niu) poprze­dza­ją­cym imple­men­ta­cje już na wcze­snych eta­pach życia pro­jek­tu, wte­dy gdy mamy niż­sze sku­mu­lo­wa­ne kosz­ty. Większość przy­szłych kosz­tów pro­jek­tu zosta­nie ponie­sio­na w wyni­ku decy­zji o cha­rak­te­rze inży­nie­rii sys­te­mów i będą to już rela­tyw­nie niskie kosz­ty, gdyż ​„wie­my wszyst­ko” by podej­mo­wać kolej­ne decy­zje o roz­wo­ju sys­te­mu. Jest to jeden z tra­dy­cyj­nych argu­men­tów za inwe­sty­cja­mi w inży­nie­rię sys­te­mów na wcze­snym etapie. 

Rysunek (b) doda­je kon­cep­cję dłu­gu infor­ma­cyj­ne­go, któ­ry jest jesz­cze nie wyge­ne­ro­wa­ną infor­ma­cją nie­zbęd­ną do dostar­cze­nia i potem utrzy­ma­nia sys­te­mu. Wykres ten ilu­stru­je trzy róż­ne sce­na­riu­sze reduk­cji dłu­gu infor­ma­cyj­ne­go. Istnieją efek­tyw­ne kosz­ty ​„odse­tek” pła­co­ne przez pro­jek­ty, któ­re nie spła­ca­ją swo­je­go dłu­gu infor­ma­cyj­ne­go wystar­cza­ją­co wcze­śnie, a im wyż­sze ryzy­ko, tym więk­szej ​„kary odset­ko­wej” nale­ży się spo­dzie­wać. Scenariusz 3 na Rysunku (b) ilu­stru­je przy­pa­dek szcze­gól­nie nie­po­ko­ją­cy dla tra­dy­cyj­nych inży­nie­rów sys­te­mów roz­wa­ża­ją­cych meto­dy zwin­ne: Czy Manifest Agile ozna­cza, że pro­jekt zakoń­czy się z pozo­sta­łym dłu­giem infor­ma­cyj­nym, pozo­sta­wia­jąc nas z ​„dzia­ła­ją­cym sys­te­mem”, ale dłu­giem infor­ma­cyj­nym: ​„cią­głą ​„karą odset­ko­wą” spo­wo­do­wa­ną bra­kiem potrzeb­nych informacji? 

Rysunek © ilu­stru­je, że infor­ma­cje doty­czą­ce inży­nie­rii sys­te­mów (np. wyma­ga­nia, archi­tek­tu­ry pro­jek­to­we, oce­ny ryzy­ka itp.) wypra­co­wa­ne i doku­men­to­wa­ne wystar­cza­ją­co wcze­śnie w pro­jek­cie, to inwe­sty­cja zmniej­sza­ją­ca dług infor­ma­cyj­ny wystar­cza­ją­co wcze­śnie a nawet całkowicie. 

Obserwowana jest oba­wa spo­łecz­no­ści agi­le, że odgór­ne gene­ro­wa­nie doku­men­ta­cji, któ­re koja­rzą z inży­nie­rią sys­te­mów, może wią­zać się z wła­snym ryzy­kiem: pod­wa­ża­niem ​„sprze­da­nej” idei agi­le, a tak­że ryzy­ku pole­ga­ją­cym na zbyt póź­nym odkry­ciu nie­po­ro­zu­mień doty­czą­cych potrzeb i ocze­ki­wań inte­re­sa­riu­szy, sku­tecz­no­ści podejść pro­jek­to­wych itp. Obie te oba­wy są uza­sad­nio­ne i potrzeb­ne są obiek­tyw­ne środ­ki, aby zna­leźć wła­ści­wy śro­dek – taki jest cel kon­cep­cji dłu­gu infor­ma­cyj­ne­go. Zmusza nas to do pod­ję­cia decy­zji, jakie infor­ma­cje są napraw­dę wyma­ga­ne w każ­dym kolej­nym cyklu życia sys­te­mu .

Podsumowanie

Dług infor­ma­cyj­ny jest znacz­nie groź­niej­szy niż dług tech­no­lo­gicz­ny. Same zale­gło­ści tech­no­lo­gicz­ne jako takie moż­na usu­nąć bez duże­go ryzy­ka: jest to po pro­stu upgra­de już posia­da­nej infra­struk­tu­ry. Dług infor­ma­cyj­ny jest znacz­nie bar­dziej nie­bez­piecz­ny, bo to cał­ko­wi­ty brak wie­dzy o tym jak to zro­bić bez­piecz­nie i co w ogó­le zro­bić (upgra­de czy jed­nak wymia­na sys­te­mu na nowy inny). 

Dług infor­ma­cyj­ny to nie tyl­ko nie­udo­ku­men­to­wa­ny sys­tem. To nie­udo­ku­men­to­wa­ne pro­ce­sy biz­ne­so­we, pro­ce­du­ry, regu­ły biz­ne­so­we, to zaso­by wie­dzy o orga­ni­za­cji jedy­nie w ​„gło­wach pra­cow­ni­ków”, te zaś są naj­czę­ściej nie­spój­ne, nie­kom­plet­ne i bar­dzo czę­sto sprzeczne.

W takiej sytu­acji każ­da istot­na decy­zja wyma­ga ogrom­ne­go wysił­ku (czas i pie­nią­dze) by mini­ma­li­zo­wać ryzy­ko błę­du z powo­du nie­wie­dzy. Jak wspo­mnia­no wyżej na przy­kła­dzie Lockheed Martin, od wie­lu lat ma miej­sce rewi­zja sen­su podej­ścia zwa­ne­go ​„agi­le”, któ­re dając nie raz fak­tycz­nie szyb­kie pierw­sze efek­ty, wpę­dza jed­no­cze­śnie orga­ni­za­cje w ogrom­ne kosz­ty spła­ty dłu­gu infor­ma­cyj­ne­go w przy­szło­ści, z regu­ły wie­lo­krot­nie więk­sze niż ​„szyb­kie oszczęd­no­ści” uzy­ska­ne na początku. 

Strategie MVP (Minimum Viable Product) czy Quick Wins (szyb­ki suk­ces na począt­ku) to suk­ce­sy na pokaz, msz­czą się dłu­giem spła­ca­nym z dużą nawiąz­ką, naj­czę­ściej już po odej­ściu sowi­cie opła­co­nych kon­sul­tan­tów, któ­rzy te stra­te­gie polecali.

Źródła