Wprowadzenie

W 2014 roku pisałem o długu 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 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.

źr.: Czym jest dług technologiczny? – Jarosław Żeliński IT-Consulting

W artykule pisałem głównie o technologii. Dług technologiczny, jak każdy dług – prędzej czy później – wymaga spłaty. Co się dzieje gdy nie spłacamy długów? Zaczyna się tak zwana spirala zadłużenia, która w wielu przypadkach kończy się krachem. W inżynierii jest tak samo: przychodzi moment, gdy dług przekroczy wartość zasobów zadłużonego. Innymi słowy koszt aktualizacji poziomu technologii do aktualnego wymaganego, może przewyższyć możliwości organizacji.

16 listopada 2015, na konferencji zorganizowanej przez Stowarzyszenie Jakości Systemów Informatycznych wygłosiłem referat na temat długu informacyjnego. Referat dotyczy przypadków zaniechania analiz i projektowania w projektach informatycznych.

Po ośmiu latach kontynuacja o długu informacyjnym (information depth).

Dług Informacyjny

Dług informacyjny, jako pojęcie, pochodzi z teorii transmisji danych:

Dług informacyjny, wprowadzony przez Martiniana, jest miarą dodatkowych symboli kodowych potrzebnych w dekoderze do zdekodowania wszystkich nieznanych symboli wiadomości.

Innymi słowy poprawne odkodowanie przesłanych informacji wymaga kompletu brakujących danych w nadanym ciągu kodowym, musimy skompletować wszystkie zaległe i nieodebrane dane. Jak sie to ma inżynierii?

Długiem informacyjnym w organizacji i zarządzaniu nazywamy różnicę między posiadaną (czyli udokumentowaną) wiedzą o tym jak określony system działa, a tym jak on faktycznie działa. Najprostszą metodą zaciągania długu informacyjnego jest budowa i rozwijanie systemu bez równoległego dokumentowania podjętych decyzji na temat tego jak ma działać, a potem jak faktycznie działa. Tym systemem może być zarówno cała organizacja, jak i jakiś jej podsystem, np. informatyczny. Obrazowo wygląda to tak:

Jeżeli firma planuje wdrażanie zmian, w tym np. wdrożenie nowego systemu informatycznego, pojawia się problem niwelowania długu informacyjnego i jego koszt: musimy w krótkim czasie uzupełnić brakującą wiedzę. Nazywamy to często analizą biznesową, analizą przedwdrożeniową itp.:

Niestety bardzo często, po wykonaniu tej analizy i zakończeniu wdrożenia, w organizacji zaczyna się proces narastania długu informacyjnego. A bardzo często ten proces zaczyna się zaraz po zakończeniu tej kosztownej analizy i rozpoczęciu wdrożenia, bo dostawca systemu nie dokumentuje efektów swoich prac (a powinien).

Popatrzmy na wykresy poniżej:

Rysunek (a) pokazuje typowe dla inżynierii systemów inwestowanie w przyszłość (, polegające na projektowaniu (czyli także dokumentowaniu) poprzedzającym implementacje już na wczesnych etapach życia projektu, wtedy gdy mamy niższe skumulowane koszty. Większość przyszłych kosztów projektu zostanie poniesiona w wyniku decyzji o charakterze inżynierii systemów i będą to już relatywnie niskie koszty, gdyż “wiemy wszystko” by podejmować kolejne decyzje o rozwoju systemu. Jest to jeden z tradycyjnych argumentów za inwestycjami w inżynierię systemów na wczesnym etapie.

Rysunek (b) dodaje koncepcję długu informacyjnego, który jest jeszcze nie wygenerowaną informacją niezbędną do dostarczenia i potem utrzymania systemu. Wykres ten ilustruje trzy różne scenariusze redukcji długu informacyjnego. Istnieją efektywne koszty “odsetek” płacone przez projekty, które nie spłacają swojego długu informacyjnego wystarczająco wcześnie, a im wyższe ryzyko, tym większej “kary odsetkowej” należy się spodziewać. Scenariusz 3 na Rysunku (b) ilustruje przypadek szczególnie niepokojący dla tradycyjnych inżynierów systemów rozważających metody zwinne: Czy Manifest Agile oznacza, że projekt zakończy się z pozostałym długiem informacyjnym, pozostawiając nas z “działającym systemem”, ale długiem informacyjnym: “ciągłą “karą odsetkową” spowodowaną brakiem potrzebnych informacji?

Rysunek (c) ilustruje, że informacje dotyczące inżynierii systemów (np. wymagania, architektury projektowe, oceny ryzyka itp.) wypracowane i dokumentowane wystarczająco wcześnie w projekcie, to inwestycja zmniejszająca dług informacyjny wystarczająco wcześnie a nawet całkowicie.

Obserwowana jest obawa społeczności agile, że odgórne generowanie dokumentacji, które kojarzą z inżynierią systemów, może wiązać się z własnym ryzykiem: podważaniem “sprzedanej” idei agile, a także ryzyku polegającym na zbyt późnym odkryciu nieporozumień dotyczących potrzeb i oczekiwań interesariuszy, skuteczności podejść projektowych itp. Obie te obawy są uzasadnione i potrzebne są obiektywne środki, aby znaleźć właściwy środek – taki jest cel koncepcji długu informacyjnego. Zmusza nas to do podjęcia decyzji, jakie informacje są naprawdę wymagane w każdym kolejnym cyklu życia systemu .

Podsumowanie

Dług informacyjny jest znacznie groźniejszy niż dług technologiczny. Same zaległości technologiczne jako takie można usunąć bez dużego ryzyka: jest to po prostu upgrade już posiadanej infrastruktury. Dług informacyjny jest znacznie bardziej niebezpieczny, bo to całkowity brak wiedzy o tym jak to zrobić bezpiecznie i co w ogóle zrobić (upgrade czy jednak wymiana systemu na nowy inny).

Dług informacyjny to nie tylko nieudokumentowany system. To nieudokumentowane procesy biznesowe, procedury, reguły biznesowe, to zasoby wiedzy o organizacji jedynie w „głowach pracowników”, te zaś są najczęściej niespójne, niekompletne i bardzo często sprzeczne.

W takiej sytuacji każda istotna decyzja wymaga ogromnego wysiłku (czas i pieniądze) by minimalizować ryzyko błędu z powodu niewiedzy. Jak wspomniano wyżej na przykładzie Lockheed Martin, od wielu lat ma miejsce rewizja sensu podejścia zwanego „agile”, które dając nie raz faktycznie szybkie pierwsze efekty, wpędza jednocześnie organizacje w ogromne koszty spłaty długu informacyjnego w przyszłości, z reguły wielokrotnie większe niż „szybkie oszczędności” uzyskane na początku.

Strategie MVP (Minimum Viable Product) czy Quick Wins (szybki sukces na początku) to sukcesy na pokaz, mszczą się długiem spłacanym z dużą nawiązką, najczęściej już po odejściu sowicie opłaconych konsultantów, którzy te strategie polecali.

Źródła