Dlaczego analityk musi być liderem (nawet jeśli nie ma tego w umowie)?
Cześć.
Zapewne wszyscy byliśmy na tych pięknych, certyfikowanych szkoleniach. Prowadzący w klimatyzowanej sali odpala rzutnik i rysuje na tablicy idealny, gładki proces. Biznes dokładnie wie, czego chce i potrafi to wyartykułować.
Ty, jako analityk, elegancko to modelujesz w UML-u. Deweloperzy kodują bez zająknięcia, testerzy piją kawę, bo nie ma bugów, a na koniec wszyscy trzymają się za ręce. Scrum Guide i BABOK w czystej postaci.
A potem kończy się szkolenie i wracasz do biura, do swojego projektu.
Rzeczywistość uderza w twarz szybciej, niż zdążysz odpalić Enterprise Architecta. Zwinność w Twojej firmie oznacza nagle:
nie wiemy, co robimy, ale robimy to w dwutygodniowych sprintach.
Twój projekt to klasyczny Water-Scrum-Fall, czyli wodospad łez lekko przykryty tablicą w Jirze.
Interesariusze mają sprzeczne wizje, a szukanie Właściciela Biznesowego na etapie UAT (User Acceptance Testing) przypomina szukanie Yeti – wszyscy o nim słyszeli, nikt go nie widział.
Noo właśnie. Wojskowi mają na to bardzo trafne określenie: Mgła Wojny. Co robimy, gdy metodyki na papierze wyglądają super, ale w prawdziwym projekcie lądujemy w samym środku chaosu?
Temat skomplikowany, niewygodny, niewielu chce się chwalić, że realizuje takie projekty. To jednak dla ogromu z nas codzienność. Kilka lat temu czytałem książkę Ekstremalne przywództwo i w tym roku (zaraz po przeczytaniu książki Cel snajpera, która jest ciekawym urozmaiceniem obu książek) trafia do moich rąk kontynuacja czyli Równowaga przywództwa (chociaż ja wolę angielską nazwę Dychotomia). Książka ta przypomniała mi pewne rzeczy z 1 części i wysuwam teorię, że znam odpowiedź, która jest prosta, choć dla wielu niewygodna:
Musisz stać się liderem!
Dziwnie to brzmi, bo nie masz tego w stopce? Czytaj dalej.
Analityk jako Lider bez Tytułu
Czasami słyszę:
„To nie mój problem, to robota Project Managera”,
albo
„Biznes znów zmienia zdanie, to ich wina, ja tylko spisuję wymagania”.
Znasz ten moment, gdy na spotkaniu statusowym zapada niezręczna cisza, PM pyta
„to co teraz robimy?”
, a projekt płonie jasnym czerwonym płomieniem na tablicy problemów zarządu?
W takich sytuacjach chowanie się za metodyką to po prostu zbrodnia. Mówienie „to nie mój zakres” w momencie, gdy deweloperzy kodują na ślepo, a biznes traci pieniądze, jest drogą donikąd. Analiza w chaosie przestaje być procesem zbierania i spisywania wymagań. Staje się aktem przywództwa dla projektu.
Wielu twierdzi, że analitycy są mostem między światami biznesu i IT.
Stwierdzam, że jako analityk jesteś mózgiem operacji. Jesteś Liderem bez tytułu, który musi wytyczyć ścieżkę w dżungli niepewności i niewiedzy. Zauważyłem, że w takich sytuacjach najlepiej sprawdzają się koncepcje przeniesione wprost z pola walki. Konkretnie: zasady dowódców Navy SEALs.
Filary Extreme Ownership w pracy Analityka
Wbrew bajkom sprzedawanym w bootcampach dla IT, nasza praca to nie jest bajka pełna jednorożców i miłych, pomocnych krasnali. Jako analityk musisz przetrwać w projektowych okopach i realnie dowozić wartość,. Polecam Ci przenieść na nasz analityczny grunt filary Extreme Ownership (Ekstremalnego Przywództwa). Wybrałem i przełożyłem na nasz projektowy świat kilka z tych filarów, jednak pamiętaj, że metoda ta to nie mały ołtarz, a cała rzymska świątynia, w której filarów jest dużo więcej.
1. Ekstremalna Odpowiedzialność (Extreme Ownership)
Zasada jest brutalna w swojej prostocie: nie ma złych projektów, są tylko źli liderzy. Jako analityk bierzesz 100% odpowiedzialności za to, czy IT zrozumiało biznes, a biznes zrozumiał IT.
Kiedy deweloper zakoduje coś źle, jaka jest pierwsza myśl?
„Nie czytają wymagań ze zrozumieniem!”.
Zasada ta zmusza do zmiany optyki na:
„To moja wina. Opisałem to w sposób, który dało się źle zinterpretować”.
Słyszałeś kiedyś sformułowanie „wymagania były jasne”? To oczywiście nasz ulubiony branżowy oksymoron. Zamiast obwiniać interesariuszy, że nie wiedzą, czego chcą (bo w 90% przypadków nie wiedzą), weź odpowiedzialność za to, by z nich tę wiedzę wydobyć.
Pamiętam mój projekt bankowy, gdzie wymienialiśmy system legacy. Kod sprzed 15 lat, zero dokumentacji. Zamiast czekać na wytyczne, wziąłem odpowiedzialność za ten chaos: narzuciłem iteracyjne prototypowanie, wrzucałem im szybkie makiety i mówiłem: „udowodnijcie mi, gdzie się mylę”. Podziałało.
2. Wiara w misję
Nie możesz skutecznie zbierać wymagań i tłumaczyć ich deweloperom, jeśli sam nie wierzysz (lub nie rozumiesz), po co w ogóle budujecie ten system lub wprowadzasz zmianę w organizacji. Musisz znać i czuć wartość biznesową (ROI, cele strategiczne), by móc zarazić nią zespół.
Dlatego niezwykle ważne jest iść w górę łańcucha dowodzenia i zrozumieć cel waszej pracy. Zyskasz dzięki temu również szerszą perspektywę, wykraczającą poza wprowadzaną zmianę i powiązania z innymi elementami układanki w organizacji. Pamiętaj, że jako projekt realizujecie misję, od której może zależeć powodzenie misji również innego zespołu.
3. Ofensywa (Zawsze krok do przodu)
W wojsku mówi się, że jeśli stoisz w miejscu, jesteś łatwym celem. W analizie jest tak samo. Nie możesz czekać w open space, aż wymagania same spłyną na Twojego maila w pięknej tabelce w Excelu. Musisz przejść do ofensywy.
Gdy oficjalne spotkania i warsztaty zawodzą, stosuję „Analizę Partyzancką”.
Zamiast organizować dwugodzinne spotkanie komitetu sterującego, łapię kluczowego interesariusza przy kawie, rysuję proces na serwetce i wyciągam decyzję. Bądź proaktywny. Jeśli sytuacja tego wymaga, twórz „kukły” (Straw Man Proposals) – celowo błędne, szybkie szkice procesów, które dajesz ludziom do rozszarpania. Są momenty, gdy ludzie nie potrafią stworzyć czegoś z niczego, ale uwielbiają krytykować. Wykorzystaj to, by napędzać projekt do przodu.
Tylko w tym wszystkim pamiętaj, że „Partyzancka analiza” działa tylko wtedy, gdy masz plan. Zanim wejdziesz na spotkanie z interesariuszami, musisz mieć przygotowaną agendę, zidentyfikowane ryzyka i plan B, jeśli poprzednie plany zawiodą (partyzantka taka to ostateczność, nigdy plan A!).
4. Priorytetyzacja i Działanie (Prioritize & Execute)
Mój ulubiony scenariusz:
Projekt nowego sklepu e-commerce, miesiąc do Black Friday. Zarząd codziennie biega po korytarzu z nowymi funkcjami. „To tylko mała zmiana. Zróbmy to szybko…” – znasz te słynne ostatnie słowa przed ważnym wdrożeniem, prawda? Nagle wszystko ma priorytet „Critical P1”. A jak wiemy, gdy wszystko jest priorytetem, nic nim nie jest.
Co jako analityk-lider robisz pod takim ostrzałem? Wchodzisz w tryb selekcji!
Zatrzymujesz machinę. W tamtym projekcie zbierasz cały zespół i mówisz:
Naszym jedynym celem jest to, żeby klient mógł opłacić koszyk. Jak maile z podziękowaniem wyjdą brzydkie – trudno. Koszyk musi działać.
Odcinasz szum. Redukujesz zakres, a zapłakanym interesariuszom tłumaczysz,
że zakres się nie zmienił, on się po prostu… uszczegółowił o 500 godzin pracy w dół.
Znajdź jeden główny problem, rozwiąż go, przejdź do następnego.
5. Prostota i Intencja Dowódcy (Keep It Simple)
Tworzenie stukilometrowych dokumentów to ślepa uliczka. Wiele firm ma wybitną dokumentację na Confluence.
Działa ona dokładnie jak Arka Przymierza z Indiany Jonesa – nikt jej nie otwiera, bo jak zajrzysz do środka, topi Ci twarz. Skomplikowane plany zawodzą jako pierwsze.
Twoim obowiązkiem jest upraszczać. Zredukuj 50-stronicowe BRD (Business Requirements Document) do jednego jasnego diagramu bezpośrednio związanego z realizowanym zadaniem.
Zamiast pisać laboraty, używaj Intencji Dowódcy (Commander’s Intent). W każdym User Story, na samej górze wpisz absolutny, ostateczny cel biznesowy.
Nawet jeśli specyfikacja stanie się nieaktualna, czy nikt jej nie przeczyta jest duża szansa że cel biznesowy zostanie zrealizowany (choć może totalnie inaczej).
Dychotomia Przywództwa: Balansowanie na linie
Żeby jednak nie było tak kolorowo, w byciu analitycznym liderem jest pewien haczyk. Przywództwo to nie jest ślepe podążanie w jednym kierunku. To sztuka ciągłego balansu, znana jako Dychotomia Przywództwa.
Jako analityk ciągle balansujesz na linie. Musisz być bardzo blisko zespołu deweloperskiego, schodzić w detale logiki biznesowej, tabel bazodanowych i API.
Ale uwaga – jeśli wpadniesz w mikrozarządzanie i będziesz narzucać programistom, jak mają napisać każdą linijkę kodu, po prostu ich zablokujesz (i znienawidzą Cię szybciej, niż rzucisz hasło „re-estymacja” – na co reagują zazwyczaj jak wampiry na czosnek).
Musisz wiedzieć, kiedy wejść w detale, a kiedy zrzucić z siebie potrzebę kontroli, dać im jasny kontekst biznesowy i odpuścić, pozwalając zespołowi działać samodzielnie (Zdecentralizowane Dowodzenie).
Z drugiej strony, musisz zarządzać relacjami z górą (Leading Up).
W jednym z projektów, gdzie budowaliśmy system dla pewnych specjalistów, komunikacja leżała. Specjaliści nie mieli czasu z nami rozmawiać, a programiści kodowali na ślepo. PM wysyłał pasywno-agresywne maile, co pomagało tyle, co gaszenie pożaru benzyną. Musiałem zbalansować presję. Poszedłem do dyrekcji, uderzyłem w stół twardymi danymi o stratach wywołanych brakiem czasu specjalistów na wywiady. Wywalczyłem ten czas, chroniąc zespół IT przed robieniem rzeczy do kosza. To jest właśnie dychotomia – twardo wobec biznesu, wspierająco wobec zespołu.
Morderczy trening, czyli dlaczego nie możesz wyrzucić BABOK-a do kosza
Zanim jednak wpadniesz jutro do biura z zamiarem wywrócenia całego procesu analizy do góry nogami, musimy sobie coś raz na zawsze wyjaśnić!
Jocko Willink często powtarza, że w jednostkach specjalnych nie ma miejsca na czystą, niczym niepopartą improwizację.
Kiedy oddział SEALs wchodzi do budynku, każdy doskonale wie, jak sprawdzić kąty i jak strzelać. Zanim stali się zabijakami łamiącymi schematy na polu bitwy, spędzili tysiące godzin na morderczym treningu opanowując podstawy.
Jak to się ma do analizy? Jeśli po przeczytaniu tego artykułu pomyślałeś: „Świetnie, koniec z nudnymi metodykami, od teraz wpadam na calle i rządzę chaosem”, to popełniasz ogromny błąd. Żeby móc skutecznie łamać zasady i improwizować w chaosie projektowym, musisz najpierw te zasady doskonale znać.
To, że w kryzysie rysujesz z biznesem proces na wymiętej serwetce, zadziała tylko wtedy, jeśli masz w głowie perfekcyjnie wyryte reguły BPMN-a czy UML-a, i wiesz, o jakie wyjątki zapytać. Twoją amunicją w walce z trudnymi interesariuszami i w negocjacjach z deweloperami
jest Twój twardy warsztat.
Techniki facylitacji, umiejętność bezbłędnego rozbijania problemów na Use Case’y, znajomość pryncypiów projektowania architektury – to wszystko buduje Twoją przewagę.
Materiały takie jak BABOK, sylabusy IREB, dobre książki, blogi czy cała baza wiedzy, którą buduje nasza analityczna społeczność – to nie są nudne, akademickie zbiory makulatury. To Twój poligon. Sam spędziłem i wciąż spędzam długie godziny nad szlifowaniem mojego analitycznego warsztatu. Ponieważ im więcej potu wylejesz na opanowanie warsztatu analitycznego w czasie „pokoju”, tym mniej krwi stracisz, gdy projekt nagle zapłonie. Twoje narzędzia muszą być ostre jak brzytwa.
Lektura obowiązkowa, czyli co czytać jako uzupełnienie?
Napisałem ten artykuł wybierając jedynie kilka z wielu zasad, które przedstawiają autorzy tej metody i zdecydowanie nawet jej nie liznąłeś tym artykułem. Dlatego jeśli chcesz zadbać o swoją postawę jako analityk – mam dla Ciebie zadanie domowe. Sięgnij po dwie książki autorstwa wspomnianych Jocko Willinka i Leifa Babina:
- „Extreme Ownership” (Ekstremalne Przywództwo)
- „The Dichotomy of Leadership” (Równowaga Przywództwa)
Dlaczego polecam je każdemu analitykowi?
Bo chociaż Panowie piszą o wojnie w Iraku i okolicach, to czytając każdą kolejną stronę, będziesz widział przed oczami swój własny open space, swoich zagubionych interesariuszy, roszczeniowych dyrektorów i płonący backlog. Te książki w kapitalny sposób uczą, jak zachować zimną krew, odzyskać sprawczość i przewodzić z tylnego siedzenia.
Podsumowanie. To zależy!
Czy to oznacza, że w każdym projekcie trzeba od razu wchodzić w tryb komandosa z Navy SEALs, rzucać granatami i wyrzucać Scrum Guide’a za okno?
Jak zawsze na tym blogu odpowiedź brzmi: to zależy.
Dobre ramy, poukładany proces, określony sposób zarządzania projektem są niezwykle potrzebne. One dają nam struktury. Ale w prawdziwym życiu IT mapa bardzo często przestaje zgadzać się z terenem. Wtedy żadna sucha regułka nie uratuje Twojego wdrożenia.
W takich kryzysowych momentach wszystko zależy od jednej rzeczy: od Twojej odpowiedzialności. Od tego, czy korzystając ze swojego doskonale wyćwiczonego warsztatu, zrzucisz z siebie wygodny płaszcz ofiary „złych wymagań”, wyjdziesz do ludzi i powiesz: „Słuchajcie, mamy chaos, ale ja to ogarnę. Biorę to na siebie”.
Przestańmy być tylko biernymi skrybami, którzy czekają na idealne procesy. Zostańmy liderami, którzy potrafią zbalansować twardy, analityczny rygor z dowodzeniem w kryzysie. Dowoźmy wartość.
A jak to wygląda w Waszych projektach? Częściej macie luksus działania według utartych, spokojnych procesów, czy jednak codzienna „analiza partyzancka” i zarządzanie w chaosie to Wasz chleb powszedni? Dajcie znać w komentarzach!
Grafiki: Ilustracje koncepcyjne: AI Gemini
