Z Grzegorzem Kuliszewskim, starszym menedżerem w Deloitte & Touche i wiceprezesem Project Management Institute Warsaw, Poland Chapter, rozmawia Andrzej Gontarz.

Na ile jakość systemów informatycznych jest kategorią obiektywną, dającą się wyrazić w bezwzględnych, mierzalnych parametrach, a na ile stanowi pochodną oczekiwań, wymagań, możliwości i zapatrywań użytkownika?

To zależy, czy mówimy o jakości produktu powstającego w wyniku projektu czy procesu produkcyjnego. W procesie produkcyjnym muszą być ustalone pewne mierzalne parametry, aby było wiadomo że powstające seryjnie produkty odpowiadają przyjętym wcześniej założeniom. Może lepiej widać to przy produkcji wyrobów przemysłowych, np. każda schodząca z taśmy nakrętka musi mieć wymiary mieszczące się w określonym zakresie. Zasada jest jednak powszechna i powinna obowiązywać również w przypadku produktów informatycznych.

Problem zachowania jakości systemu IT podczas realizacji pojedynczego, niepowtarzalnego projektu jest bardziej złożony. W tym przypadku jakość jest nierozerwalnie spleciona z innymi - równie ważnymi - parametrami, takimi jak koszt, czas, zakres, ryzyko i satysfakcja klienta. Generalnie jakość systemu określiłbym jako jego zgodność z wymaganiami i użyteczność. W zarządzaniu jakością wyróżniam trzy podstawowe procesy: planowanie, zapewnienie i kontrolę jakości. Kluczowe znaczenie dla sprawnej realizacji projektu ma zapewnianie jakości (quality assurance). Jest to regularna ocena ogólnej wydajności uzyskiwanej w projekcie, pozwalająca upewnić się, że spełni on określone normy jakościowe. Tu nie chodzi o drobiazgową kontrolę realizacji projektu, ale o ciągłe sprawdzanie, czy osiągane rezultaty dają gwarancję spełnienia zatwierdzonych wcześniej, ogólnych wymagań, o upewnienie się, czy realizacja projektu rzeczywiście idzie w dobrym kierunku, czy wyłożone na ten cel fundusze nie zostaną zmarnowane. Takie sprawdzanie powinno być wykonywane przez podmioty zewnętrzne - zewnętrzne wobec zespołu realizującego projekt.

Część tej oceny może być wyrażona w kategoriach mierzalnych, część, np. dotycząca ryzyka, bywa trudna do oszacowania. Użytkownik musi zdecydować sam, w jakim zakresie z jego punktu widzenia dopuszczalny jest element ryzyka. Gdy będziemy mieli przykładowo do czynienia z elektronicznymi gadżetami, to w przypadku błędu najwyżej przestaną działać. W sytuacji, gdy w grę wchodzi ochrona zdrowia czy środowiska naturalnego, skłonność do podejmowania ryzyka jest bardzo mała, a nacisk kładziony na jego ograniczenie znaczny.

Jakie znaczenie ma etap planowania jakości?

Musimy na początku zdefiniować jakość, którą chcemy uzyskać. Musimy określić, do czego dążymy, jakie chcemy osiągnąć korzyści i jakie rozwiązania jesteśmy w stanie zaakceptować. Trzeba dokonać rzeczowej, precyzyjnej analizy kosztów i efektów. Może się wtedy np. okazać, że z punktu widzenia interesów użytkownika jest do zaakceptowania niższa jakość systemu, bo to obniża koszty, a nie wpływa na funkcjonalność. Trzeba to jednak wcześniej zaplanować, zatwierdzić, umówić się co do tego między odbiorcą a wykonawcą. Planowanie jakości to identyfikacja norm, które powinny być wykorzystane w projekcie, oraz ustalenie metod spełnienia tych norm. Musimy uzgodnić, jakie kryteria jakości są wiążące na czas realizacji projektu, aby mieć świadomość tego, co trzeba uzyskać na końcu.

Przeciętnemu człowiekowi jakość kojarzy się zazwyczaj z kontrolą. Planowanie jakości i jej zapewnianie pozostaje całkiem na uboczu. Tymczasem wszystkie te czynniki razem wzięte stanowią dopiero o sukcesie w staraniach o jakość.

Czy są powszechnie uznane, standardowe metody i narzędzia do zapewnienia czy też sprawdzenia jakości w systemach informatycznych?

Tak, ale innych narzędzi należy używać w procesie planowania, innych w procesie zapewnienia jakości, a jeszcze innych w procesie kontroli. Najważniejszy dla etapu zapewnienia jakości jest przegląd jakości, sprawdzenie, czy projekt ma szanse spełnić zakładane cele biznesowe. To musi być robione z punktu widzenia odbiorcy systemu, aby mógł się dowiedzieć, czy wszystko idzie po jego myśli, czy może liczyć na sukces tego przedsięwzięcia. Chodzi o zapewnienie go, że zostaną osiągnięte nakreślone przez niego główne cele biznesowe, nawet jeżeliby okazało się, że konieczne jest przekroczenie budżetu o 5-10%. Z punktu widzenia użytkownika nawet projekt z przekroczonym - w rozsądnych granicach - budżetem czy terminem realizacji może być uznany za sukces, gdy pozwala w konsekwencji na realizację ważnych celów biznesowych.

A co zrobić ze zmianami potrzeb użytkowników pojawiającymi się w trakcie realizacji projektu? Na ile je uwzględniać, na ile trzymać się wcześniej określonych procedur i harmonogramów?

To normalne, że użytkownicy będą zmieniać swoje stanowisko w trakcie projektu. Propozycje zmian czy nowe oczekiwania odbiorców powinny być rozpatrywane przez zespół projektowy. Otwartość na zmiany jest potrzebna dla zachowania użyteczności produktu końcowego.

A jeżeli grozi to niedotrzymaniem terminów lub koniecznością przebudowy znacznej części systemu?

Do rozwiązywania tego typu problemów służą procesy kontroli zmian. Trzeba przeanalizować wniosek i powiedzieć klientowi, jakie będą dokładnie efekty sugerowanych przez niego zmian. Trzeba dostarczyć mu rzetelnych, pełnych informacji, jakie będą skutki wprowadzanych zmian pod każdym względem: kosztów, terminów, funkcjonalności, wymagań technicznych itd. Na tej podstawie komitet sterujący czy też komitet kontroli zmian będzie mógł podjąć decyzję co do dalszych losów proponowanej zmiany i prac nad systemem.

Na ile jakość systemów informatycznych jest związana z kulturą organizacyjną firmy?

Dla uzyskania właściwej jakości w projekcie potrzebne jest duże zaangażowanie użytkownika. Pozwala to uniknąć sytuacji, w której rozwiązanie spełnia wymagania formalne, ale jest nieodpowiednie dla użytkownika. Ważna jest również generalna polityka firmy wobec problematyki jakości, całościowe spojrzenie na jakość. Organizacja musi się uczyć jakości. Nie da się jej zadekretować z dnia na dzień. Różnego typu normy ułatwiają wprowadzenie wysokiej jakości, ale samo ich wdrożenie nie gwarantuje automatycznie jej uzyskania i utrzymania. O jakość trzeba się ciągle starać.

Zrozumienie dla problematyki jakości musi być po obu stronach procesu realizacji projektu. Obie strony muszą być gotowe na jej zapewnienie. Obie strony muszą chcieć też za nią zapłacić. Bo jakość kosztuje, nie da się jej osiągnąć za darmo. Zawsze musimy realnie oszacować, ile możemy na jakość wydać, jaki jest koszt uzyskania oczekiwanej jakości i z jakimi kosztami wynikającymi z wadliwości należy się liczyć. Taka analiza pozwala ocenić, co jest opłacalne i jakie ryzyko przy tej decyzji podejmujemy.

Proszę zauważyć, że nie mówimy tu już o samej jakości projektu informatycznego, lecz o jakości w kontekście ryzyka lub ryzyku w kontekście jakości. Jakość sama w sobie nie istnieje, jest uzależniona od wielu innych, ściśle z sobą powiązanych wskaźników. Dobry projekt powinien - poprzez proces zarządzania nim - uwzględniać wszystkie te parametry.