Okiem analityka
3 pytania do eksperta. Szymon Moskała
Wyobraźcie sobie duży projekt w ogromnej organizacji. Organizacja jasno określa wymagania, a rozwiązania wydają się spójne. Mimo to wiele projektów IT kończy się opóźnieniem. Co więcej, tylko około jedna trzecia organizacji realizuje swoje przedsięwzięcia zgodnie z harmonogramem. 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 często ujawniają rozbieżność między przekonaniem klienta a rzeczywistą wiedzą o jego potrzebach. Klient jest przekonany, że dobrze rozumie swoje procesy, ale w praktyce okazuje się, że nie są one jeszcze jasno opisane. 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 przypadków, z jakimi się spotkałem, był proces zaprojektowany wcześniej przez inny zespół. Zbudowano go jako duży, scentralizowany mechanizm obsługujący wiele różnych scenariuszy. 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 przygotowanie dokumentu z wymaganiami zamyka temat. 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ą.