Choć odsetek udanych projektów IT stale rośnie(co prawda powoli), to dyskusje dotyczące niezawodności rozwiązań informatycznych od lat toczą się wokół tych samych spraw i nic nie wskazuje na to, by mogło się to zmienićw przewidywalnej przyszłości.

Ponad połowa ankietowanych przez nas uczestników konferencji "Jakość systemów informatycznych", zorganizowanej przez tygodnik Computerworld w czerwcu br., odpowiedziała twierdząco na pytanie, czy ich zdaniem poprawia się jakość wdrażanych rozwiązań informatycznych. To optymistyczne przekonanie potwierdzają wyniki badań prowadzonych przez Standish Group. Firma ta od 10 lat prowadzi regularne badania (powtarzane co 2 lata) "Chaos Chronicles" dotyczące ilościowej oceny powodzenia realizowanych projektów informatycznych (na bazie analizy ok. 13,5 tys. projektów IT realizowanych w Stanach Zjednoczonych). W ub.r. sukcesem zakończyło się 34% projektów. Pozornie mało, lecz tak naprawdę to ponad dwa razy lepiej niż w trakcie pierwszego badania. Podobnie dwa razy zmalała liczba projektów jednoznacznie nieudanych (do 15%). Reszta to projekty, w których znacząco przekroczony został czas realizacji albo budżet, bądź też takie, w których w dużym stopniu nie zrealizowano zakładanej funkcjonalności.

Słowem "jest całkiem dobrze, aczkolwiek nie beznadziejnie". Dyskusje dotyczące jakości i niezawodności systemów informatycznych na ogół toczą się wokół tych samych zagadnień - dylematów, czy praca informatyka jest nauką, inżynierią, sztuką, rzemiosłem czy wszystkim po trochu; kreślenia analogii pomiędzy budową mostów czy samochodów a realizacją projektów IT oraz narzekaniami na młodość, niedojrzałość, a zarazem gorączkowy rozwój dziedziny, której przychodzi mierzyć się ze stale rosnącą złożonością.

Analogie i tak zawodzą, bo TO, czyli IT, jest czymś zupełnie innym od wszystkich dziedzin, które znaliśmy do tej pory. Skądinąd wiadomo, że dwa różne zespoły informatyków, ale o podobnym zasobie kompetencji i doświadczenia, mające te same narzędzia i ten sam problem do rozwiązania w tym samym czasie, przygotują kompletnie różne rozwiązania. Jest to nie do pomyślenia w innych dyscyplinach inżynierskich.

To stan trochę podobny do tego, jaki reprezentowało rzemiosło w średniowieczu. Ale z uwagi na tempo rozwoju, nastawienie na postęp technologiczny i wagę powiązań pomiędzy biznesem a IT trudno tutaj mówić o średniowieczu. Informatyka w zasadniczej mierze istnieje w świecie abstrakcji, a nieciągłość połączeń tego świata z rzeczywistością zdaje się stanowić podstawowe źródło problemów.

Słabe ogniwo

Jak wskazują badania prowadzone przez British Computer Society, główną przyczyną niepowodzeń projektów jest zasadniczo błędna analiza wymagań, a nie niewystarczające testowanie czy jego całkowity brak. Przynajmniej w tym obszarze nikt z ankietowanych kierowników projektów nie lokalizował przyczyny niepowodzenia projektu.

Tymczasem wciąż zbyt wiele uwagi w procesach wytwórczych oprogramowania poświęca się na jego dalsze fazy kosztem tych początkowych. To z jednej strony pewna "informatyczna niecierpliwość" polegająca na dążeniu do jak najszybszego zajęcia się konkretną robotą (a faza specyfikacji wymagań za taką nie jest na ogół uważana), z drugiej zaś wyraźny brak wśród personelu firm informatycznych osób o "miękkich umiejętnościach", a więc przygotowaniu psychologicznym czy społecznym, które stanowi ogromną pomoc na etapie rozmów z przyszłymi użytkownikami systemu i odgadywaniu ich rzeczywistych potrzeb. To również trudności w nawiązaniu równorzędnego dialogu użytkownika z informatykiem - obu stronom zazwyczaj brakuje wiedzy o przedmiocie działalności partnera takiego dialogu.

To zaś może oznaczać, że paradoksalnie wyrafinowane testowanie oprogramowania z zastosowaniem zaawansowanych technologii zwyczajnie się nie opłaca. Lepiej czas i środki zainwestować w co innego. Liczy się bowiem to, czy system w ogóle spełnia minimalne wymagania użytkowe. Być może na tym w dużej mierze polegał sukces Microsoftu, który wprowadzał na rynek oprogramowanie wyraźnie niedotestowane, niepozbawione wydawałoby się zupełnie elementarnych błędów, lecz za to dobrze odpowiadające na zestaw pewnych podstawowych potrzeb masowego użytkownika. Testy zaś zawsze można traktować jako narzędzie pomiarowe.

Nóż w zęby

Dobrym przykładem prowadzonych debat może być dyskusja panelowa, która miała miejsce w trakcie I Konferencji Stowarzyszenia Jakości Systemów Informatycznych w listopadzie br. Tytuł dyskusji "Good enough software" zaczerpnięty został ze słynnego artykułu Jamesa Bacha "The Challenge of Good Enough Software" opublikowanego jeszcze w 1995 r. Autor postawił w nim kontrowersyjną tezę, iż praktyka wskazuje na to, że optymalna jest taka organizacja procesów wytwórczych systemów IT i aplikacji, by celem nie było uzyskiwanie jak najwyższej jakości i niezawodności, lecz jakości wystarczająco dobrej. Co to znaczy? Ową wystarczającą jakość można rozumieć jako różnicę między tym, co stanowi minimalny próg wymagań klienta a maksymalnym pułapem jego wyobrażeń.

Klient (użytkownik) ma swoje wymagania i oczekiwania. Wymagania muszą być spełnione, jeśli klient w ogóle ma być zadowolony, natomiast oczekiwania są dla klienta czymś oczywistym i brak ich realizacji potraktuje on raczej wrogo. Natomiast poziom satysfakcji podnieść może coś ekstra - coś "fajnego", czego klient nawet nie oczekiwał ani nie wymagał (tego rodzaju różne dodatki ma np. oprogramowanie biurowe Microsoftu). Jak łatwo zauważyć, jakość nie jest tutaj celem, w ogóle nie jest istotne dążenie do doskonałości. W tym podejściu jakością jest to, co klient kupi.