Z Grzegorzem Kuliszewskim, starszym menadż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 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 wiadomo było, że powstające seryjnie produkty odpowiadają przyjętym wcześniej założeniom. Może lepiej widać to przy produkcji wyrobów przemysłowych, na przykład każda schodząca z taśmy nakrętka musi mieć wymiary mieszczące się w określonym zakresie. Zasada jest powszechna i powinna obowiązywać również w przypadku produktów informatycznych.

Problem zachowania jakości systemu IT podczas realizacji pojedynczego, niepowtarzalnego projektu jest już bardziej złożony. W tym wypadku jakość jest ściśle związana, 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 jakości, zapewnienie jakości i kontrola jakości. Kluczowe znaczenie ma dla sprawnej realizacji projektu zapewnianie jakości (quality assurance). Jest to regularna ocena ogólnej wydajności uzyskiwanej w projekcie, pozwalająca upewnić się, że projekt spełni 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ć robione przez podmioty zewnętrzne – zewnętrzne wobec zespołu realizującego projekt.

Część tej oceny może być wyrażona w kategoriach mierzalnych, część – na przykład 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 na przykład do czynienia z elektronicznymi gadżetami, to w przypadku błędu przestaną najwyżej działać. W sytuacji, gdy w grę wchodzi ochrona zdrowia czy ochrona ś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óra 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 na przykład 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ą systemu. Planowanie jakości, to identyfikacja norm jakościowych, 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 tez 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, moim zdaniem, przegląd jakości, sprawdzenie czy projekt ma szanse spełnić zakładane cele biznesowe. To musi być robione z punktu widzenia użytkownika, 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żeli by się okazało, że konieczne jest przekroczenie budżetu o 5 czy 10 procent. 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ę innych, 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 realizacji 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 on, komitet sterujący czy tez komitet kontroli zamian będzie mógł podjąć decyzję co do dalszych losów proponowanej zmiany i dalszych 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. Bardzo ważna jest również generalna polityka firmy wobec problematyki jakości, całościowe, spojrzenie na jakość w firmie. 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 informatycznego. 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 oraz 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, 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 projektem uwzględniać wszystkie te parametry.