Okiem analityka
3 pytania do eksperta. Katarzyna Stramol
Projekty IT to nie tylko technologia. To przede wszystkim ludzie, relacje i codzienne wyzwania organizacyjne. O tym, co naprawdę decyduje o sukcesie (lub porażce) wdrożeń, jak rozpoznać pierwsze sygnały problemów i dlaczego empatia jest równie ważna jak kompetencje techniczne – opowiada Katarzyna Stramol, doświadczona analityczka biznesowo-systemowa. Dowiedzcie się, jak budować projekty nie tylko „zgodnie z zakresem”, ale przede wszystkim skutecznie i z myślą o ludziach.
Jaką sytuację projektową wspominasz najgorzej i dlaczego?
Nie wskazałabym jednej konkretnej sytuacji, ale raczej powtarzający się wzorzec, który powraca w różnych projektach. To moment, w którym projekt przestaje być wyzwaniem technologicznym, a zaczyna być wyzwaniem ludzkim i organizacyjnym.
W takich przypadkach zespół mierzy się z wieloma nawarstwionymi na siebie trudnościami: przeciążeniem, niejasnym podziałem ról, napiętą komunikacją, brakiem dostępności kluczowych osób czy niewystarczającym wsparciem decyzyjnym. W połączeniu z presją czasu i dużymi oczekiwaniami, nawet najbardziej zaangażowane osoby mogą czuć się przytłoczone.
Z mojej perspektywy – jako analityczki – najtrudniejsze są sytuacje, w których nie ma przestrzeni na prawdziwy dialog. Gdy nie rozmawiamy o celach, ograniczeniach i kontekście, a skupiamy się wyłącznie na „dowiezieniu zakresu”, rośnie ryzyko niezrozumienia, frustracji i utraty jakości.
Triggery, które warto rozpoznać wcześniej:
Choć każda organizacja i projekt są inne, to pewne sygnały ostrzegawcze pojawiają się regularnie:
- Nieprecyzyjnie zdefiniowane role i odpowiedzialności, co prowadzi do rozmycia decyzji lub konfliktów kompetencyjnych,
- Zaniżony budżet w stosunku do zakresu oczekiwań, który prowadzi do narastającej presji czasu i niezadowolenia („płacimy za fiata, ale oczekujemy ferrari”),
- Brak otwartej, partnerskiej komunikacji – zwłaszcza gdy pojawiają się silne emocje lub trudne osobowości w kluczowych rolach
- Zespół, w którym odpowiedzialność faktycznie spoczywa na jednej osobie, co może skutkować wypaleniem i, w konsekwencji, osłabieniem całego projektu
Co Twoim zdaniem przybliża do lepszego zrozumienia potrzeb klienta?
Uważność na ludzi. Zrozumienie klienta nie wynika wyłącznie z analizy dostarczonych wymagań – rodzi się w relacji, w słuchaniu, empatii i zaufaniu. Dobra współpraca to nie tylko rozmowa o zadaniach, ale o celach, obawach i kontekście, w jakim działa organizacja. Wierzę w to, że jeśli już w trakcie pierwszych warsztatów zbudujemy bezpieczną i otwartą atmosferę to jakość, efektywność i zyski z efektów pracy będą niewyobrażalnie większe niż w sytuacji, w której o to nie zadbamy i klient nie ma tego zaszytego w kulturze organizacji. A niestety często nie ma ☹
Uważam, że w trakcie pracy z klientem trzeba zadawać sobie pytania:
O cele i kontekst:
- Co klient chce osiągnąć naprawdę – poza samym wdrożeniem?
- Jak ten projekt wpisuje się w szerszą strategię firmy?
- Co się stanie, jeśli projekt się powiedzie? A co, jeśli nie?
Dotyczące ograniczeń i wyzwań:
- Jakie ograniczenia (czasowe, budżetowe, organizacyjne) widzą interesariusze?
- Jakie wcześniejsze doświadczenia z projektami IT wpłynęły na ich oczekiwania?
- Gdzie według klienta „może zaboleć” – co budzi największe obawy?
O współpracę i komunikację:
- Kto po stronie klienta naprawdę zna temat? Kto podejmuje decyzje?
- Czy zespół czuje się swobodnie w wyrażaniu opinii i zadawaniu pytań?
- Czy klient traktuje projekt jako wspólne przedsięwzięcie, czy tylko „płacimy – wymagamy”?
I, oczywiście, o użytkowników końcowych:
- Kto będzie faktycznym użytkownikiem rozwiązania?
- Jak wygląda ich codzienność? Jakie mają potrzeby, frustracje, nawyki?
- Jakie zmiany w pracy ich czekają ich po wdrożeniu i jak się do nich nastawiają?
Czy wąskie gardła projektowe są częste i czy klienci zdają sobie z nich sprawę?
Zdecydowanie tak – i często pojawiają się wcześniej, niż zdążymy je nazwać. W praktyce to nie zawsze są spektakularne blokady, ale raczej niewidoczne na pierwszy rzut oka przeszkody, które spowalniają postęp i kumulują ryzyko.
Najczęstsze przyczyny blokad, które obserwuję w projektach:
- Ograniczona dostępność osób decyzyjnych – kluczowe decyzje bywają opóźnione lub podejmowane bez kontekstu, co wpływa na jakość i rytm prac.
- Wąskie gardła integracyjne – np. brak środowisk testowych, przeciążony zespół integracyjny po stronie klienta lub brak wiedzy o systemach źródłowych.
- Niewystarczające zaangażowanie osób z wiedzą merytoryczną – nawet najlepiej opisany proces biznesowy traci sens, jeśli nie możemy zderzyć go z praktyką operacyjną.
Zrozumienie tych ograniczeń wymaga empatii i szerszego spojrzenia – klienci często funkcjonują w dynamicznym środowisku, gdzie projekt IT to tylko jedna z wielu aktywności. W takim kontekście łatwo przeoczyć narastające zależności lub przeszacować dostępność zespołu.
