Organizowana przez nas III Konferencja Jakości Systemów Informatycznych bez wątpienia wyrosła na największe i najważniejsze w Polsce spotkanie poświęcone wieloaspektowemu ujęciu tematyki jakości systemów informatycznych.

Tematyka konferencji - współorganizowanej w tym roku przez Computerworld i Stowarzyszenie Jakości Systemów Informatycznych - obejmuje zagadnienia zarówno z obszaru zapewnienia jakości, jak i zarządzania jakością. W tym roku wiele miejsca poświęcono także jakości prowadzenia projektów. Gościem specjalnym konferencji był Tim Lister z The Cutter Consortium i Atlantic Systems Guild, jeden z najbardziej znanych na świecie ekspertów od ryzyka informatycznego. Jego zdaniem, ryzyko jest stałym i oczywistym składnikiem naszego świata i dążenie do jego całkowitej eliminacji jest nierozsądne i nieuzasadnione. Odpowiednie podejmowanie ryzyka niesie obietnicę odniesienia korzyści i powinniśmy z tego korzystać. Dlatego Tim Lister nazywa głupstwem wywody teoretyków modelu CMM (Capability Maturity Model), że w organizacji znajdującej się na najwyższym, piątym poziomie CMM ryzyko w procesach wytwórczych oprogramowania spada do zera. "Podstawowym problemem w IT jest to, że dokładne określenie przebiegu realizacji projektu zazwyczaj jest niemożliwe, można co najwyżej mówić o prognozowaniu pewnych zjawisk, a każda prognoza obarczona jest ryzykiem błędu" - twierdzi Tim Lister.

Tim Lister ma ponad 30 lat doświadczenia pracy zawodowej w IT (na początku był programistą), wie więc, co mówi, gdy twierdzi, że właściwie nigdy nie spotkał się z nieudanym projektem, w którym przyczyną porażki byłaby jakaś niespodziewana trudność, zjawisko, którego nie dało się wcześniej przewidzieć. "Ich symptomy widać wcześniej i na ogół członkowie zespołu wiedzą o nich i są świadomi nadciągających kłopotów. Tyle tylko, że niewielu menedżerów projektów chce zmierzyć się z prawdą, uznać jej konsekwencje" - uważa Tim Lister. Ryzyka nie można i nie powinno się unikać, ale trzeba być jego świadomym - tymczasem przyjmowana jest dokładnie odwrotna postawa - ryzyka staramy się nie dostrzegać, jednocześnie uznając, że najlepiej będzie przyjąć, że jesteśmy w stanie je wyeliminować. Osobną kwestię stanowi powiązanie ryzyka z jakością. Zdaniem Tima Listera wymagania jakościowe w projekcie muszą spełniać trzy warunki: być racjonalne, dobrze określone i mierzalne. W praktyce okazuje się, że częstokroć mamy kłopoty z każdym z tych warunków, w szczególności z ostatnim z nich.

Jakość po polsku

W praktyce funkcjonowania polskich firm informatycznych zarządzanie jakością wygląda niestety dość różnie. Nierzadko wydaje się wręcz, że całkiem duże podmioty w ogóle nie mają pełnomocnika ds. jakości ani ujęcia kontroli jakości w procesach wytwórczych i wdrożeniowych. Z kolei po stronie dużych użytkowników rozwiązań IT sformalizowane podejście do zarządzania jakością w informatyce stosują zazwyczaj jedynie wybrane instytucje sektora bankowo-finansowego czy firmy telekomunikacyjne.

Christophe Debou z niemieckiej firmy konsultingowej KuglerMaag (do niedawna członek zarządu w Comarchu) przybliżył przyczyny niepowodzeń programów poprawy jakości. W sytuacji, gdy inicjatywa nie jest dostatecznie wspierana przez kierownictwo przedsiębiorstwa, gdy z niecierpliwością czeka się wyłącznie na certyfikat określający stopień dojrzałości organizacji lub spełnienie wymagań jednego z powszechnie uznanych standardów, najczęściej zapomina się o właściwych celach biznesowych, które przyświecały programowi poprawy jakości. Przedsiębiorstwa, które mają problemy finansowe, często decydują się na drastyczne obniżenie kosztów działalności - nie zaś na inwestycje w poprawę jakości i zwiększenie produktywności. Dzieje się tak, bo w zakresie jakości zbyt rzadko umiemy posłużyć się konkretnymi wartościami liczbowymi, nie definiujemy mierzalnych celów, a tym samym nie udaje się przekonać kierownictwa do słuszności inicjatyw mających na celu poprawę jakości. Dokładne i precyzyjne miary ilościowe uzupełnione metrykami jakościowymi powinny istotnie przyczynić się do sukcesu programu poprawy jakości, a w konsekwencji do poprawy ekonomicznej firmy informatycznej.

Piotr Krzysztofik, dyrektor Pionu Wsparcia Biznesu z ośrodka R&D Siemensa we Wrocławiu (Communications Software Development Center) przekonywał, że takiemu ośrodkowi nie wystarczy już dzisiaj posiadanie jedynie certyfikatu na zgodność z normą ISO 9001. Atutem może okazać się przemyślane połączenie tej normy z modelem CMMI, określającym sposób prowadzenia projektów IT i - podobnie jak standard ISO 9001 - bazującym na podejściu procesowym. Integracja obu systemów pozwala z jednej strony (ISO 9001) na wzmocnienie pozycji konkurencyjnej przedsiębiorstwa na rynku lokalnym, wewnętrzne uporządkowanie organizacji (m.in. opisane procedury, role, odpowiedzialności, udokumentowanie działań, jasne określenie wizji organizacji i jej polityki jakości), wsparcie komunikacji oraz ciągłe doskonalenie organizacji poprzez analizę stanu istniejącego, z drugiej zaś (CMMI) na przeniesienie najlepszych praktyk modelu do projektów i organizacji, a w konsekwencji również znaczące skrócenie czasu przeznaczonego na testy i integrację systemów.

O miarach oprogramowania mówił Richard Taylor z firmy SIA "Do IT Well". Podczas prezentacji zaprezentowany został zestaw metryk służących do oceny stanu i postępu prac na etapach przygotowywania oraz wykonywania testów, a także przydatnych do określenia stopnia dojrzałości produktu podlegającego testowaniu. Warto pamiętać o tym, że mierząc odsetek wykonanych przypadków testowych, które nie wskazały na żaden błąd, liczbę znalezionych błędów czy różnicę pomiędzy usuwanymi a nowymi błędami, nie powinniśmy skupiać się wyłącznie na wartościach bezwzględnych, a raczej na śledzeniu trendu zmian i ekstrapolacji. Chcąc ukazać trend, trzeba posługiwać się wykresami, a nie tabelkami, które nie ukazują wprost kierunku zmian. Sama częstotliwość pomiarów zależy od potrzeb konkretnego projektu - zazwyczaj stosuje się pomiary cotygodniowe, może się jednak zdarzyć, że konieczne będą obserwacje dzienne.

Jakość jest również pojęciem względnym, zwłaszcza z perspektywy klienta, dla którego jest ona różnicą między poziomem oczekiwań a percepcją otrzymanego produktu. "W tym sensie jakość jest tym, co dzieje się w głowach klientów, dlatego pomimo miar i wymiernych współczynników, istotną rolę w ocenie jakości pełni nadal marketing i poziom relacji dostawców z klientami" - twierdzi Emil Konarzewski, partner firmy Audytel.

Komunikacja najważniejsza

W opinii uczestników dyskusji panelowej "Dylematy produktywności", nie powinien istnieć konflikt między jakością a produktywnością. Szybciej, taniej, więcej nie musi oznaczać gorzej i słabiej. Pod warunkiem, że jest dobra komunikacja między użytkownikiem a dostawcą. Wtedy wiele rzeczy można wynegocjować, ustalić. Potrzebny jest dialog, dyskusja, wspólne dochodzenie do satysfakcjonujących rozwiązań. "Gdy dobrze zdefiniujemy oczekiwania i jasno określimy możliwości ich zrealizowania, to nic nie powinno blokować pracy nad projektem" - uważa Wiesław Grabowski, dyrektor Działu Konsultingu Technologicznego w Oracle Polska. Jego zdaniem, jakość to spełnienie wymagań, a mogą one mieć różny charakter. Dla jednych priorytetem będzie czas, dla innych najniższe koszty. Trzeba to jednak jasno na początku określić. Tylko przez współpracę można dojść do satysfakcjonujących obie strony ustaleń i osiągnięcia zadowalającej jakości.

Czy jest to realne? Wszak odbiorca chce dostać jak najwięcej za jak najmniejszą cenę, a dostawca chce jak najdrożej sprzedać. "Gdy się przyjmie istniejący w rzeczywistości konflikt interesów za rzecz naturalną, to można dojść do porozumienia" - uważa Rafał Hanys z Urzędu Miasta Wrocławia. Jednej i drugiej stronie zależy bowiem na uzyskaniu rozwiązania, którym będzie mogła się potem pochwalić. To powoduje, że szuka się satysfakcjonujących dla wszystkich rozwiązań.

Krzysztof Kardaś, członek zarządu Prokom Software, mówił o jakości we wdrożeniach systemów IT realizowanych przez tę firmę, np. Koncernu Energetycznego Energa. Trwająca w tym przedsiębiorstwie restrukturyzacja utrudnia określenie na obecnym etapie docelowego kształtu systemu informatycznego, więc we wdrożeniu trzeba stosować elastyczne podejście i wzorce branżowe, pozwalające na dopełnienie wiedzy, tam gdzie klient nie potrafi przekazać informacji. To w szczególności wzorce procesów biznesowych, których przebieg trzeba zaimplementować w systemie IT (np. w przemyśle chemicznym to CIDX, a w energetyce IEC91638, w telekomunikacji zaś TM Forum).

Z kolei Włodzimierz Szymański, senior Project Manager w Pionie Produktów i Usług w Softbanku zauważył, że łatwo mówić o konieczności prowadzenia przeglądów jakościowych w projekcie, a znacznie trudniej wprowadzić je w praktyce. "Takie przeglądy muszą być integralną częścią procesów wytwórczych. W przypadku gdy będą tylko elementem dodatkowym, prawie na pewno nie będzie się prowadzić takich przeglądów" - mówi. O praktycznym podejściu do jakości w realizowanych projektach mówił także Maciej Smagacz z Ericpol Telecom, jednego z największych polskich eksporterów IT, firmy związanej z wytwarzaniem i wdrażaniem oprogramowania na potrzeby operatorów telekomunikacyjnych. Firma ta, na bazie własnych doświadczeń, dopracowała się metodyk pozwalających na dobre szacowanie złożoności projektów i problemów oraz błędów, które mogą pojawić się w trakcie ich realizacji. "Nasze doświadczenia wskazują na to, że znacznie lepiej na początku projektu przeznaczyć do niego więcej osób, aby później zredukować ich liczbę, jeżeli harmonogram na to pozwala, niż postępować na odwrót" - twierdzi Maciej Smagacz.

Narzędzia jakości

Istotną część naszej konferencji zajęła prezentacja informatycznego i organizacyjnego wsparcia pozwalającego na zapewnienie i utrzymanie wysokiej jakości w produktach IT. Mówili o tym przedstawiciele firm IBM, Compuware, Borland i Mercury - czołówki dostawców narzędzi związanych z systemami zapewniania jakości.

<hr>Współpraca: Andrzej Gontarz i Joanna Nowakowska, wiceprezes Stowarzyszenia Jakości Systemów Informatycznych