Informatyk i jego zapora

W felietonie powrót do kwestii związanych z wydawaniem pieniędzy społecznych na wielkie informatyczne przedsięwzięcia

Każdy normalnie zdrowy inżynier ma niejako w genach klasyczny cykl realizacji każdego przedsięwzięcia technicznego: koncepcja, projekt, symulacja, prototyp, wdrożenie, produkcja. Niektóre etapy podlegają sformalizowanemu odbiorowi, nierzadko przy udziale niezależnych ekspertów, i bywają regulowane przez prawo, jak na przykład inspekcje budowlane, służby sanitarne, dozór dozymetryczny itp., itp. W przypadku sporu wykonawcy ze zleceniodawcą z reguły z góry wiadomy jest sposób jego rozwiązywania, łącznie z adresem i kompetencjami komisji arbitrażowej, do której trzeba będzie się udać.

Wie to i zna z codziennej praktyki każdy inżynier – oprócz inżyniera informatyka.

Żywym dowodem braku tradycyjnej, zdroworozsądkowej kultury prowadzenia projektu w świecie informatyki jest los wielkich informatycznych projektów rządowych, których pokrętne losy tak bardzo ostatnio zajmują łamy prasy nie tylko komputerowej.

Już pobieżna, dziennikarska analiza historii tych projektów prowadzi do co najmniej dwóch ważnych wniosków. Po pierwsze, tak głębokie niepowodzenie, jakie nagminnie przydarza się rządowym projektom informatycznym, to rzecz niespotykana w innych dyscyplinach inżynierskich. Buduje się przecież budynki użyteczności publicznej, drogi, zapory wodne, szpitale i mnóstwo innych rzeczy. I choć bywa, że nie wszystko do końca klapuje, to jednak w nowej siedzibie urzędu kłębią się petenci (przeklinając niezgulstwo urzędników), droga się wije wśród pól (choć jakby trochę szybko się zużywa pod kołami samochodów), zapora wodna porusza turbiny (choć wokół niej wyrasta osiedle willi z „wygospodarowanych” materiałów), w szpitalu zaś leżą pacjenci (chorzy i tak zawsze będą narzekać).

Całkowicie zawalony wielki projekt rządowy to niemal wyłączna domena informatyków. Ma rację prezes Izby Informatyki i Telekomunikacji, ostrzegając przed narastaniem społecznej dezaprobaty dla informatyzacji kraju, bo od czasu uwolnienia rynku ludzie coraz bardziej stają się uczuleni na racjonalność wydawania publicznego grosza (i bardzo dobrze).

Druga cecha łącząca, a właściwie dzieląca poszczególne historie klęski, jest analogiczna do tego, co – według opinii Johna Majora – najgłębiej dzieli Anglików i Amerykanów: wspólny język. Niby w każdym przypadku mamy do czynienia z podobną, niemal tą samą materią – systemem obsługi rozproszonej bazy danych – a jednak każda historia jest zupełnie inna, niepodobna do pozostałych.

Trudno oprzeć się wrażeniu, że oba wymienione zjawiska mają wspólny korzeń, pozostając w jakimś związku przyczynowo-skutkowym.

Nieco światła na naturę problemu rzuciła przeprowadzona w gronie wielu kompetentnych osób z kręgów zarówno wykonawców, jak i inwestorów dyskusja, która odbyła się na XIII Forum Technologii Informatycznych, które odbyło się pod koniec maja w krakowskim hotelu Piast. Oto okazuje się na przykład, że informatycy wcale nie są zgodni, czym jest w istocie duży projekt informatyczny. Padały opinie, że jest on czymś analogicznym do: (1) produktu tworzonego na miarę, podobnie jak spodnie szyte u krawca, (2) budowania domu, (3) świadczenia usługi, (4) leczenia. O dziwo, najwięcej zwolenników miał pogląd (4), co chyba potwierdza dość szeroko rozpowszechnione mniemanie, że coś tu jest chore. Godną odnotowania wypowiedzią był też apel jednego z uczestników o zwiększony poziom zaufania pomiędzy zamawiającym i wykonawcą, bo życie jest pełne niespodzianek i nie da się wszystkiego skodyfikować (jak to między lekarzem i pacjentem…).

Co gorsza, okazuje się, że w rządowych projektach informatycznych nie jest zazwyczaj do końca jasne, kto w istocie jest klientem i co jest przedmiotem kontraktu. Na przykład jest na porządku dziennym, że do koordynowania pracy desygnuje się urzędników z centrali, natomiast opinie realnych użytkowników, rozproszonych po całym kraju, nie są brane pod uwagę. Nieszczęście gotowe, bo podczas wdrażania protesty ofiar systemu sypią się tak obficie, że klient formalny odmawia przyjęcia pracy. Ale są też przypadki odwrotne – centrala mnoży problemy wobec wykonawców, tymczasem szeregowi użytkownicy domagają się niezwłocznego wdrożenia systemu, który już zdążyli poznać i polubić.

Na tym tle wydaje mi się godna przemyślenia wypowiedziana na OFTI uwaga Marka Jędrzejczaka z ComputerLandu, że – poza wszystkimi mniej czy bardziej naturalnymi ułomnościami profesjonalnymi i charakterologicznymi osób zaangażowanych w projekt – informatyka systemowa jest jeszcze bardzo niedojrzała jako dyscyplina inżynierska. Nie stosuje bowiem jednolitych reguł działania znanych każdemu elektrykowi, nie jest unormowana, tak jak np. energetyka, nie korzysta z oczywistych dla majstra budowlanego metod weryfikacji postępu prac, nie potrafi definiować celów przedsięwzięcia z precyzją wykwalifikowanego hydraulika i nawet nie zawsze wie, kto naprawdę jest jej klientem.

Czyż w powyższym kontekście nie przypominają się opowieści o wykształconych szaleńcach, którzy budują niebezpieczną broń, nie zdając sobie sprawy z możliwych skutków jej działania? A dr Frankenstein, który genialnie przeniknąwszy tajemnicę życia spowodował serię nieszczęść? No i jeszcze ten uczeń czarnoksiężnika… Wszystkie te godne pożałowania afery (na szczęście pozostające w sferze fantazji) nie były przecież niczym innym jak skutkami projektów prowadzonych bez dokładnie określonych celów, właściwych procedur i zabezpieczających przed niepowodzeniem mechanizmów weryfikacyjnych.

Andrzej Horodeński – redaktor naczelny Magazynu Rynku Komputerowego

0
Zamknij

Choć staramy się je ograniczać, wykorzystujemy mechanizmy takie jak ciasteczka, które pozwalają naszym partnerom na śledzenie Twojego zachowania w sieci. Dowiedz się więcej.