- 2 czerwca 2023
- Category: Aktualności
Zasadniczo każda organizacja, która prowadzi cyfrową transformację i związane z nią projekty implementacji różnych rozwiązań IT chciałaby, aby każde z tych rozwiązań spełniło potrzeby organizacji w zakresie wydajności, funkcjonalności, potencjału rozwoju, niezawodności oraz efektywności utrzymania. Te potrzeby są oczywiste, jednak jak wiemy z wielu przykładów było i jest wiele projektów, gdzie oczywiste potrzeby nie zostały zaspokojone. Dzieje się tak z różnych przyczyn, ale głównie jest to wynikiem mniejszych lub większych błędów popełnianych na różnych etapach projektu.
Z pomocą przychodzi tutaj zapewnienie jakości (Quality assurance). Zapewnienie jakości jest narzędziem wspierającym projekt w zakresie spełnienia potrzeb organizacji przez produkty tego projektu. Wiele się o nim mówi i pewnie większość zespołów projektowych, powie, że zapewnienie jakości jest ważnym procesem w ich projekcie.
Niestety zazwyczaj działania w tym zakresie ograniczają się do testowania systemu IT. Prace związane z zaplanowaniem testów, stworzeniem scenariuszy, realizacją testowania systemy oraz obsługi wyników wyczerpują w wielu projektach zagadnienia jakości. Część producentów dużych rozwiązań IT dostarcza nawet narzędzia do zapewnienia jakości i zazwyczaj ograniczają się one właśnie do wsparcia zarządzania testami lub automatyzacji testów.
W naszej opinii jest to podejście nie tyle błędne co bardzo ograniczone (techniczne) i w żadnym wypadku nie wspierające kompleksowo sukcesu projektu, czyli spełnienia wymagań.
Popatrzmy jeszcze raz, kluczowe aspekty potrzeb organizacji w zakresie produktu projektu jakim jest wdrożony system IT to: wydajność, funkcjonalność, potencjał rozwoju, niezawodność oraz efektywności utrzymania. Typowe testowanie pomoże jedynie zweryfikować wdrożone w systemie funkcjonalności oraz w jakimś stopniu odnosi się do niezawodności i wydajności.
Jak jednak zapewnić, że system przede wszystkim obejmuje te funkcjonalności których potrzebuje organizacja? Jak dopilnować, żeby rozwiązanie IT było gotowe/możliwe do rozwoju? Jak zadbać, że zaprojektowany i wprowadzony system będzie mógł być bezpiecznie oraz efektywnie kosztowo utrzymywany? Dla wsparcia tych aspektów, samo klasyczne testowanie systemu nie wystarczy.
Z tego właśnie powodu Zapewnienie jakości to tak naprawdę kompleksowe podejście do zapewnienia spełnienia wymagań we wszystkich obszarach i na każdym z etapów projektu. Zapewnienie jakości jest zarówno o dobrze przygotowanych wymaganiach jak i o prawidłowo przeprowadzonych warsztatach analitycznych, o poprawnym podziale odpowiedzialności w projekcje jak i dobrym przygotowaniu testów.
Takie kompleksowe podejście stosujemy i o kilku podstawowych zasadach dobrego zapewnienia jakości na projekcie opowiem w kolejnych wpisach. Nie będę powielał książkowych opowieści jak QA wdrożyć w projekcie, czy jakie są jego fazy ale skupię się na konkretnych wyzwaniach i zagadnieniach jak praktycznie zadbać o jakość na projekcie.
Zapewnienie jakości na projekcie – przygotowanie projektu
W trakcie ogólnie rozumianego fazy/etapu przygotowania projektu, kiedy to określamy parametry jego produktu, uzasadnienie biznesowe, WBS (Work Breakdown Structure), struktura organizacyjna itp. itd., uwzględnienie QA zazwyczaj sprowadza się do napisania o tym zagadnieniu w dokumencie definiującym projekt to jest wskazania, że w projekcie będą procedury zapewnienia jakości i ogólnej informacji na czym polegają.
W mojej jednak opinii zapewnienie jakości powinno już na tym etapie działać w praktyce, to jest zapewnić właściwą jakość produktów tej fazy/etapu projektu.
Nie będę tracił czasu czytelników na formułki skopiowane z metodyk projektowych, dotyczące zapewnienia jakości, zamiast tego zwrócę uwagę na kilka istotnych, praktycznych kwestii związanych z zapewnieniem jakości, żeby przygotowanie projektu sprzyjało temu, aby produkt projektu spełniał potrzeby organizacji w zakresie wydajności, funkcjonalności, potencjału rozwoju, niezawodności oraz efektywności utrzymania, bo o tym są przecież QA.
Elementów, które warto w kontekście QA zaplanować/zweryfikować jest wiele, tutaj skupię się na trzech ważnych w mojej opinii zagadnieniach.
Przede wszystkim warto zweryfikować uzasadnienie biznesowe, czyli ten element, który definiuje tak naprawdę przyczynę, dla której projekt jest realizowany i wskazuje jaką wartość chcemy dla naszej organizacji uzyskać w wyniku jego realizacji. W ramach czynności zapewnienia jakości warto zweryfikować podstawowe parametry i cechy uzasadnienia biznesowego. Czy jest ono zrozumiałem dla stron projektu? Czy jest ono związane z przedmiotem projektu? Czy realnie da się ocenić spełnienie założeń uzasadnienia biznesowego przez produkty projektu? W mojej opinii uzasadnienie biznesowe jest taką trochę konstytucją projektu, bo to do niego powinniśmy się odnieść oceniając zasadność realizacji jakiegoś zadania w projekcie. Warto więc też z perspektywy QA sprawdzić, czy uzasadnienie jest użyteczne tj. czy możemy posłużyć się nim w sytuacji, gdy na projekcie musimy rozstrzygnąć spór lub wątpliwości wobec zakresu. Dobrze jest przygotować listę cech jakie uzasadnienie biznesowe powinno spełnić i zbadać je w tym kontekście. Warto pamiętać o ty, że cały czas występuje ogromna ilość projektów, gdzie uzasadnienie biznesowe jest albo bardzo ogólnie napisane albo bardzo szczegółowe, ale w żaden sposób nie możliwe do wypełnienia przez produkty projektu.
Kolejnym ważnym elementem, wartym zbadania z perspektywy QA, jest specyfikacja wymagań wobec produktów projektu. Wdrożenia IT to są takie ciekawe projekty, gdzie w praktyce często zapomina się o wyspecyfikowaniu mierzalnych parametrów produktu których chcemy uzyskać. Szczególnie dotyczy to wdrożeń rozwiązań typowo biznesowych ERP, CRM, APS itp. Dużo pisze się o organizacji projektu, odbiorach, procedurach zarządzania itp., a zapomina się określić jasną specyfikacje tego co chcemy uzyskać oraz zweryfikować, czy jest ona realna do osiągnięcia. Wprowadzamy do umowy bardzo złożone procedury odbioru i kary, ale nie mamy poprawnie opisanego zakresu cech, które chcemy odbierać, oceniać i testować.
Innym istotnym aspektem organizacji projektu, który warto zbadać pod kątem jego jakości, jest podział odpowiedzialności stron. Kluczowe jest oczywiście to, żeby on istniał, ale ważne jest również to, żeby odnosił się do konkretnego projektu, który chcemy zrealizować. Bardzo często podziały odpowiedzialności są po prostu przekopiowane z metodyki i w żaden sposób nie dostosowane do faktycznego projektu. Dodatkowo często podział odpowiedzialności stron jest niezgodny np. z zapisami w umowie, zakresem projektu czy WBS. Takie podstawowe weryfikacje należy koniecznie wykonać, ponieważ złe rozpisanie odpowiedzialności może być bardzo szkodliwe dla projektu.
Jak wspomniałem, te trzy aspekty to nie wszystko, warto zweryfikować również np. analizę ryzyka, procedury zarządzania zmianami, strukturę organizacyjną, odbiory i samą dokumentację definiująca projekt. Dla wielu z czytelników zalecenia te będą się wydawały oczywiste, ale praktyka pokazuje, że oczywiste rzeczy często są realizowane najgorzej. Może to rutyna zabija czasami projekt? Podejście jakościowe do projektu i weryfikacja wszystkiego jest dla nas często kluczową metodą zapewnienia sukcesu projektu.
Autor: Bartłomiej Żak