Paradoksy jakości

Gdyby o jakości systemów informatycznych wnioskować na podstawie temperatury dyskusji i zaangażowania uczestników I Krajowej Konferencji Jakości Systemów Informatycznych, moglibyśmy wszyscy być spokojni o przyszłość rozwiązań IT projektowanych przez polskie przedsiębiorstwa.

Gdyby o jakości systemów informatycznych wnioskować na podstawie temperatury dyskusji i zaangażowania uczestników I Krajowej Konferencji Jakości Systemów Informatycznych, moglibyśmy wszyscy być spokojni o przyszłość rozwiązań IT projektowanych przez polskie przedsiębiorstwa.

"Dlaczego jest tak źle z jakością systemów informatycznych i czy mamy szansę ten stan zmienić?" - tak można streścić temat prelekcji i dyskusji odbywających się podczas I Krajowej Konferencji Jakości Systemów Informatycznych, zorganizowanej przez tygodnik Computerworld, przy wsparciu organizacji Information Systems Audit & Control Association i Stowarzyszenia Jakości Systemów Informatycznych.

Nędzne procenty

Przeświadczenie o tym, że projektowanie i wdrażanie systemów informatycznych - zarówno w Polsce, jak i na świecie - mocno kuleje, podzielali niemal wszyscy uczestnicy konferencji. Jak wynika z badań Statistics over IT projects failure przeprowadzonych przez IT Cortex, amerykańską organizację zrzeszającą niezależnych konsultantów i kierowników projektów informatycznych, ponad 31% projektów IT zostaje przerwanych przed terminem, 53% kończy się z opóźnieniem i budżetem przekroczonym średnio o 89%, a zaledwie 16% dobiega końca w terminie i w ramach założonego budżetu.

Co do przyczyn tak słabych wyników nie panowała już jednak jednomyślność. Gros z nich ma bowiem niewiele wspólnego z informatyką. "Wszyscy chętnie porównują inżynierię oprogramowania i realizację projektów informatycznych do innych dziedzin inżynierskich, takich jak projektowanie samochodów i domów. Zapominają przy tym o podstawowej różnicy. W informatyce znamy pełne założenia dopiero w momencie wykonania systemu. To tak jakby architekt projektujący dom na kilka dni przed oddaniem projektu usłyszał - kuchnię przenosimy w ten róg domu, a ten pokój likwidujemy w ogóle" - mówił Wojciech Kozaczyński, jeden z architektów oprogramowania w centrali Microsoftu, wcześniej kierownik projektów w firmie Rational Software.

Tymczasem świadomość konieczności zapewnienia jakości produktom informatycznym w otoczeniu biznesowym jest zatrważająco niska. Nierealne terminy i budżety sprawiają, że nad dużą częścią przedsięwzięć IT widmo klęski wisi już od początku.

Od specyfikacji po dokumentację

Przynajmniej część niepowodzeń można zrzucić na karb lekceważenia zasad zarządzania jakością w projekcie. Błędy zaczynają się już na etapie pisania specyfikacji, która często jest traktowana jako punkt wyjścia do dalszych interpretacji, a w skrajnych przypadkach pisana jest tuż przed oddaniem projektu.

"Musimy pamiętać, że wymagania użytkowników/klientów możemy i powinniśmy zmieniać. Gdyby polegać tylko na tym, czego oni chcą, uzyskalibyśmy wypadkową ich wyobrażeń z mglistym obrazem systemów, z którymi zetknęli się w przeszłości" - podkreślał Grzegorz Kuliszewski, starszy menedżer w Deloitte & Touche i wiceprezes Project Management Institute Warsaw, Poland Chapter. Błędy te są później powielane na etapie realizacji projektu, w procesie zarządzania zmianami oraz podczas kontroli jakości.

Kluczowe dla zapewnienia jakości w projekcie jest całościowe spojrzenie na projekt. Wiele przedsiębiorstw skupia się na kontroli, zapominając, że podstawowym celem jest planowanie jakości. Jednym z najczęstszych błędów jest ścisłe pilnowanie zaledwie wycinka wskaźników albo części obszarów projektu wynikające z przekonania, że lepiej jest szczegółowo kontrolować wybrany obszar, niż mniej dokładnie patrzeć na całość. Tymczasem - przynajmniej w przypadku zarządzania jakością w projekcie - utrata kontroli nad nawet niewielkim wycinkiem realizowanego przedsięwzięcia zagraża powodzeniu całości.

Grzechy główne

Z czego wynika powszechne wśród informatyków lekceważenie zasad zarządzania jakością? Najważniejszych przyczyn jest co najmniej kilka. Jedną z podstawowych jest - zdaniem uczestników naszej konferencji - niewiedza będąca następstwem gwałtownego rozwoju informatyki i napływu do przedsiębiorstw osób pozbawionych nie tylko gruntownego wykształcenia informatycznego, ale nawet elementarnej wiedzy inżynierskiej.

Kolejnym problemem jest arogancja prezentowana zwłaszcza przez dostawców aplikacji, którzy zdają sobie sprawę, że użytkownicy często nie mają wyjścia i muszą kupić dany produkt. "Czy któraś ze światowych firm produkujących oprogramowanie zbudowała swój sukces na jakości dostarczanych produktów?" - pytał retorycznie Marcin Sikorski, kierownik Zakładu Ergonomii i Eksploatacji Systemów Technicznych Politechniki Gdańskiej.

Jednym z ostatnich powodów lekceważenia zasad zarządzania jakością jest niewiedza klientów, dzięki której firmy IT mogą przerzucić dużą część kosztów związanych właśnie z zapewnieniem jakości na barki odbiorców swoich produktów. "Informatyka to jedyny sektor, w którym umowa na zakup produktu zawiera klauzulę wyłączającą odpowiedzialność dostawcy" - mówił Andrzej Blikle, prezes zarządu firmy A. Blikle sp. z o.o.

Ile kosztuje jakość?

Najważniejszym czynnikiem jest jednak nieświadomość kosztów zapewnienia jakości. Są one równie często przeszacowane i niedoszacowane. Ogromnym przeszacowaniom podlegają zwłaszcza koszty wdrożenia norm i certyfikatów zarządzania jakością, uznawanych za horrendalnie drogie i nieprzydatne. Tymczasem koszt ich implementacji jest odwrotnie proporcjonalny do stopnia zaawansowania kultury organizacyjnej przedsiębiorstwa. Tam, gdzie kultura jest na odpowiednio wysokim poziomie, a wszystkie procesy są dobrze zidentyfikowane i opisane, koszt uzyskania certyfikatów nie wykracza znacząco poza honorarium za kilkudniowy odnawialny audyt i certyfikat. W firmach, które przy okazji ubiegania się o certyfikat jakości planują gruntowne porządki w procesach, koszt organizacyjny może być jednak kilkadziesiąt razy wyższy.

Jak obiektywnie szacować koszty zapewnienia jakości? "Najprostszą drogą do ich określenia jest obliczenie sumy nakładów poniesionych na zapewnienie odpowiednich standardów" - mówiła dr inż. Katarzyna Skroban z Instytutu Organizacji Systemów Produkcyjnych Politechniki Warszawskiej. W wielu firmach są one traktowane jako inwestycja w produkt, z której zwrot następuje wraz ze wzrostem sprzedaży.

Niestety, w przypadku systemów informatycznych sprawa jest bardziej skomplikowana. Przy szacunkach trzeba brać pod uwagę korzyści biznesowe płynące z zapewnienia lub wręcz stałego podnoszenia jakości. "O ile nie tak trudno oszacować koszty ponoszone na zapewnienie jakości, o tyle określenie zysku płynącego z dbałości o jakość jest już bardzo trudne" - oceniał Bogdan Bereza-Jarociński, niezależny konsultant, specjalista od metodyk tekstowych oraz inżynierii wymagań. Aby rachunek ekonomiczny był pełny, trzeba w nim uwzględnić przyszły zysk utracony ze względu na uchybienia jakości. To jeden z najbardziej nieuchwytnych czynników rachunku kosztów, bez którego jednak jakiekolwiek szacunki mogą być obarczone ogromnym błędem.

Skoro oszacowanie pełnych kosztów zapewnienia jakości jest takie trudne, czy warto zabiegać o stałe jej podnoszenie? Uczestnicy I Krajowej Konferencji Jakości Systemów Informatycznych zgodnie odpowiadają, że warto chociażby ze względu na wzrost wiedzy i doskonalenie organizacji, a wraz z nią zwiększanie efektywności przedsiębiorstwa. Nie można jednak traktować jakości jako wartości samej w sobie. Nawet zapewnienie najwyższej jakości realizowanego projektu czy wykonanego systemu nie gwarantuje zadowolenia użytkowników. "Jakość musi być ściśle dopasowana do oczekiwań klientów i użytkowników. Przede wszystkim zaś musi być mierzona i zarządzana. Bardzo łatwo wydać 2 mln zł na poprawę jakości i nic dzięki temu nie zyskać" - konkludował Jakub Chabik z Departamentu Informatyki w GE Capital Banku.

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

TOP 200