Okiem analityka
3 pytania do eksperta. Szymon Moskała
Wyobraźcie sobie duży projekt w ogromnej organizacji. Wymagania jasno i klarownie przedstawione, rozwiązania spójne… a jednak – statystyki od dawna pokazują, że duża część projektów IT dostarczana jest z opóźnieniem, już nie wspominając o tym że zaledwie 1/3 organizacji kończy swoje przedsięwzięcia na czas. I co gorsza – problem rzadko, naprawdę rzadko można „zrzucić” na technologię. Najczęściej tkwi w tym, co dzieje się jeszcze przed napisaniem pierwszej linii kodu.
Dlaczego? O tym opowiada nam Szymon Moskała, doświadczony analityk biznesowo-systemowy, który sam był świadkiem niejednej takiej sytuacji.
Co pozwalają unaocznić warsztaty z klientem?
Warsztaty analityczne bardzo często pokazują rozbieżność między przekonaniem klienta o tym, że doskonale zna i rozumie swoje potrzeby, a rzeczywistym stanem wiedzy o procesach, które mają zostać odwzorowane w systemie. Zdarza się, że klient przychodzi z gotowym zestawem wymagań, które na pierwszy rzut oka wyglądają na spójne i przemyślane. Jednak w trakcie warsztatów – gdy zaczynamy zadawać szczegółowe pytania i symulować konkretne scenariusze – koncepcja ta zostaje wystawiona na ciężką próbę.
To moment, w którym na jaw zaczynają wychodzić luki w logice, pewne sprzeczności, niedookreślone reguły biznesowe, a czasem nawet brak wspólnego zrozumienia danego pojęcia wśród osób z tej samej organizacji. Warsztaty często odsłaniają też niespójności między tym, jak różne działy wyobrażają sobie działanie – istniejącego bądź projektowanego – systemu.
Dodatkowo warsztaty umożliwiają wszystkim uczestnikom ustrukturyzowanie i uporządkowanie informacji o rzeczywistych zdarzeniach, które mają miejsce w codziennej pracy. Pomagają wydobyć wiedzę, której nikt wcześniej nie spisał, bo przecież „wszyscy to wiedzą”. Dopiero w trakcie wspólnej analizy okazuje się, jak wiele decyzji operacyjnych opiera się na intuicji, a nie na jasno zdefiniowanych regułach i że wcale nie wszyscy i na pewno nie wszystko – wiedzą.
Krótko mówiąc: warsztaty pozwalają zweryfikować założenia, obnażyć luki w wymaganiach i wspólnie z klientem wypracować możliwe do wdrożenia rozwiązanie.
Jaki był najtrudniejszy proces, z którym się mierzyłeś?
Jednym z najtrudniejszych procesów, z jakim miałem do czynienia, był proces, który na początku został przygotowany przez inny zespół – jako duży, scentralizowany mechanizm obejmujący wiele różnych scenariuszy działania. Na poziomie dokumentacji wyglądało to jak jeden spójny proces. Problem w tym że w rzeczywistości była to synteza kilku niezależnych procesów biznesowych oraz ich wariantów. Wszystko to zostało połączone w jedną strukturę, co miało ułatwić zarządzanie i utrzymanie. Przynajmniej na papierze.
Na początku nie wzbudziło to większych wątpliwości. Opis był spójny, a wdrożenie uproszczone. Jednak w miarę rozwoju projektu ten proces był stale rozszerzany – dochodziły kolejne ścieżki, gałęzie decyzyjne, warunki, wyjątki. Z czasem stało się jasne, że całość zaczyna przypominać pajęczynę: zmiana jednej reguły w jednym miejscu powodowała nieprzewidziane skutki w innym. Utrzymanie takiej struktury stawało się coraz trudniejsze, podobnie jak testowanie czy dalsze rozwijanie funkcjonalności.
Największym wyzwaniem było przekonanie interesariuszy, że pierwotne założenie – czyli traktowanie wszystkiego jako jednego dużego procesu – zaczęło działać na niekorzyść projektu. Zaproponowaliśmy refaktoryzację całego procesu poprzez jego dekompozycję – rozdzielenie na mniejsze, niezależne moduły, które można było oddzielnie rozwijać i utrzymywać.
To doświadczenie nauczyło mnie, że czasem próba ujednolicenia i centralizacji procesów jest pozorna – i że odwaga do zakwestionowania istniejącej koncepcji, nawet jeśli wydaje się ugruntowana, bywa kluczowa dla jakości rozwiązania i dalszej skalowalności systemu.
Jakie są 3 najpopularniejsze błędy, których klienci mogliby uniknąć, a jednak je popełniają?
Zbyt szybkie przechodzenie do rozwiązania
Często klient przychodzi z gotową wizją funkcjonalności, pomijając etap analizy rzeczywistych potrzeb. Zamiast skupić się na tym, co chce osiągnąć i dlaczego, od razu mówi, jak to ma działać. To prowadzi do projektowania systemu pod istniejące przyzwyczajenia zamiast pod realne cele. Lepszym podejściem jest modelowanie potrzeb i procesów najpierw, a dopiero potem – wybór narzędzi i rozwiązań.
Pomijanie priorytetyzacji
Klienci często oczekują wdrożenia całej funkcjonalności na raz, bez priorytetyzacji i podziału na fazy. To ogranicza elastyczność, utrudnia testowanie i sprawia, że trudniej reagować na zmiany lub nowe potrzeby, które pojawiają się w trakcie projektu.
Ślepa wiara w kompletność wstępnej dokumentacji
Wielu klientów zakłada, że skoro przygotowali dokument z wymaganiami, to temat jest zamknięty. Problem polega na tym, że taka dokumentacja bardzo często zawiera luki, uproszczenia albo wręcz nie uwzględnia kontekstu biznesowego. Dopiero rozmowy, warsztaty i wspólna analiza pozwalają wydobyć ukryte założenia, wyjątki, zależności między działami. Bez tego powstaje rozwiązanie „zgodne z dokumentem”, ale niekoniecznie działające zgodnie z rzeczywistością.
