Okiem budowniczego

Caspars Jones w książce 'Applied Software Measurements' napisał, że gdyby domy budowano, tak jak systemy informatyczne, to połowa budynków dwudziestopiętrowych byłaby zagrożona katastrofą. Miał na myśli przede wszystkim jakość produktów informatycznych.

Caspars Jones w książce 'Applied Software Measurements' napisał, że gdyby domy budowano, tak jak systemy informatyczne, to połowa budynków dwudziestopiętrowych byłaby zagrożona katastrofą. Miał na myśli przede wszystkim jakość produktów informatycznych.

Od pół roku patrzę na projekty informatyczne z perspektywy firmy budowlanej, w której obecnie pracuję, i muszę z całą stanowczością powiedzieć, że nie dość, że zawaliłyby się budynki stawiane zgodnie z praktyką stosowaną przy projektach informatycznych, to wcześniej zbankrutowałaby firma budowlana, która odważyłaby się tak postępować. W biznesie budowlanym są rygory, których w branży informatycznej raczej się nie stosuje, np. kwoty gwarancyjne, odbiory etapów, kary za niedotrzymanie precyzyjnie sformułowanych warunków kontraktu. Są ustalone procedury i nie można się z nich wyłamywać. Żadnych eksperymentów. Ponadto w budownictwie regułą są niskie marże. Załamanie się projektu natychmiast odbija się na finansach firmy. W informatyce natomiast marże są bardzo wysokie i stąd niepowodzenia w projekcie nie mają takiego druzgocącego skutku dla finansów firmy. Budowy wiążą się z koniecznością zamrożenia dużego kapitału, często z kredytu, i ponoszenia związanych z tym kosztów. Firmy informatyczne mają wprawdzie wysokie koszty stałe, lecz w projekty angażują relatywnie mały kapitał.

Konkludując, branża producentów oprogramowania i usług informatycznych ma na rynku ogromną swobodę. Nie działa pod finansowym rygorem. Nie jest zmuszona przez klientów do profesjonalnego działania, perfekcyjnego prowadzenia każdego projektu, finansowej odpowiedzialności za podjęte działania.

Produkcja bez przygotowania

W projektach informatycznych właściwie nie istnieje etap przygotowania produkcji, czyli w miarę precyzyjne określenie poszczególnych działań przed podjęciem konkretnej pracy. Nie wiadomo dokładnie, ile czasu powinny trwać poszczególne czynności, ile i jakie osoby powinny być w nie zaangażowane, a także w jakim zakresie. Nie ma planowania obciążeń pracą poszczególnych specjalistów. Dostawcy rozwiązań informatycznych podkreślają, że mają do nich metody wdrożenia, ale tak naprawdę nie ma w nich nic poza ogólnikami i chwytem marketingowym.

Firmy wdrożeniowe z jednej strony chcą wykonać jak najwięcej zakontraktowanych godzin u klienta, ale z drugiej brakuje im ludzi do pracy. Konsultanci jeżdżą od projektu do projektu i gaszą pożary. Buntują się przeciwko temu, gdyż z braku owego rozpisania projektu na czynności, czas i osoby, nie wiedzą, czy aktualnie wykonują to, co do nich należy, czy też pracę dodatkową.

To nie jest tylko polski problem. Amerykański konsultant Tom DeMarco ocenia, że 15% projektów informatycznych w USA nie ma w ogóle specyfikacji zadań.

Ryzyko zwielokrotnione

Brak przygotowania produkcji w dziedzinie projektów informatycznych jest szczególnym paradoksem, ta dziedzina bowiem - jak żadna inna - potrzebuje rygorów organizacyjnych i merytorycznych. Otóż już samo określenie rozmiaru, np. funkcji zamierzonego systemu stwarza projektantom nie lada problem. Zwykle planują, że wykonają 100% więcej niż jest to możliwe w konkretnym czasie. Co więcej, projekty informatyczne rosną w miarę dodawania funkcji i uzyskiwania kompleksowości, a każdemu etapowi towarzyszy kilkuprocentowa tzw. inflacja software'owa. W efekcie projekt jest większy i na skutek nierealistycznego planowania, i na skutek obiektywnie występującej inflacji.

Nie trzeba chyba dodawać, że wraz z nie kontrolowanym rozszerzaniem się systemu zwielokrotnia się ryzyko niepowodzeń.

Budowla na ogół jest odzwierciedleniem zamierzenia architektonicznego - z wyjątkiem mieszkaniowego budownictwa socjalistycznego.

Bez wiedzy korporacyjnej

Brak przygotowania produkcji nie mściłby się tak bardzo, jeśli firmy wdrażałyby tylko standardowe rozwiązania. Obecnie jednak oprogramowanie do wspomagania zarządzania przedsiębiorstwem składane jest z modułów bądź mniejszych części, zanim więc przystąpi się do wdrożenia, trzeba tworzyć modele rozwiązania. Do zapewnienia powtarzalnej jakości należy stworzyć procedury zarządzania projektami, a nie liczyć na wdrażanie powtarzalnych pakietów.

Zastanawiające jest to, iż mimo że wszyscy dostawcy negatywnie oceniają proces wdrożeń lub budowy systemu informatycznego, nic w tej sferze się nie zmienia. Wydawałoby się, że przez ostatnie lata zgromadzili dostateczne doświadczenia, aby poprawić zarzą- dzanie projektami. Dlaczego tego nie czynią? Poza wymienionymi wcześniej przyczynami jest jeszcze jedna bardzo ważna i.... niezwykle groźna. W firmach informatycznych nie ma mechanizmów transferu i kumulowania wiedzy. Wdrożeniowcy pracują przy projektach jako reprezentanci swojej firmy, ale wiedza, którą z nich wynoszą, jest ich wiedzą osobistą. Ani nie przekazują jej nikomu w firmie, ani jej nie pozostawiają firmie, gdy z niej odchodzą. Korporacyjna wiedza i know-how właściwie nie istnieje w firmach informatycznych w Polsce. Unicestwia ją ogromna fluktuacja kadr i brak umiejętności zatrzymania wiedzy w firmie.

Opisana sytuacja ma dobre strony. Stymuluje postęp w dziedzinie informatyki. Firmy za pieniądze swoich klientów lokalizują bądź rozwijają systemy. Lecz do czasu. Gdy klienci obudzą się, spadną marże, a dostawcy informatyki zostaną zmuszeni do ustanowienia we własnym interesie standardów pracy i zarządzania projektami.

<hr size=1 noshade>Krzysztof Stańczuk jest dyrektorem Biura Systemów Zarządzania w Exbud SA.

W celu komercyjnej reprodukcji treści Computerworld należy zakupić licencję. Skontaktuj się z naszym partnerem, YGS Group, pod adresem [email protected]

TOP 200