Kilka przemyśleń o agilu. O rozwiązywaniu problemów, tworzeniu idealnego świata i cierpliwości. O tym, czego projektom nie-agilowym brakuje. O tym, czy analitycy odnajdą się w nowym agilowym świecie. I o rzeczy, która ostatecznie decyduje czy to wszystko działa.

Od czego wychodzimy?

Często patrzymy czarno-biało. Waterfall albo agile. Waterfall jako uosobienie wszystkiego, co najgorsze, sztywne, bezsensowne. Agile jako uosobienie najlepszych wartości. W waterfallu działamy po to, żeby naprodukować dokumentów. „Jakie jest Twoje zadanie, analityku?”. „Ja tworzę dokumenty.”. Dokumenty produkujemy masowo, wyładowujemy taczkami, wstrzymujemy organizację, żeby je czytała. Nawet, jeśli jakimś cudem uda nam się nakłonić klientów i IT do przeczytania wszystkiego, to i tak nie każdy ten analityczno-diagramowy „bełkot” zrozumie. Jaka wartość? Bliska zeru? A softu jak nie widać tak nie widać.

Ja mam też inne doświadczenia. Przemyślenie sprawy nie musi oznaczać sztywności. Może być po prostu racjonalne. Może służyć odpowiadaniu na pytania, doradzaniu we właściwych decyzjach, rozwiązywaniu problemów. Wiadomo, przesada jest zła. I niestety chyba jednak często spotykana. Ale niewłaściwa implementacja agile’a może również te rzeczy utrudniać. Zależy od projektów, firmy, ludzi. Bardzo dużo od ludzi.

Czy wprowadzenie agila rozwiązuje problemy?

Nie. Pojawiają się inne problemy. Zamiast narzekania na za długą, bezsensowną dokumentację, czekanie w nieskończoność, sztywność planów i ludzi ślepo podążających za procedurami, teraz masz inne powody. Możesz teraz narzekać na słabego product ownera (za mało wiedzący, za mało dostępny, za mało decyzyjny), słabą jakość historyjek (nie da się oszacować, nie wnoszą zrozumienia ani wartości, nie dają się dobrze przetestować), na brak architektury (że coś zepsuliśmy na produkcji w innym komponencie, bo nikt nie przewidział, że na siebie wpływają), na brak wiedzy w organizacji (ludzie odeszli, pozapominali, nikt nic nie wie, nikt niczego nigdzie nie zapisał, więc chodzisz od biurka do biurka, od linii kodu do bazy i odkrywasz prehistorię) i na ludzi, którzy nie rozumieją podejścia agilowego i Cię ograniczają. Wybierz te, które występują w Twoim przypadku. Jeden problem się jednak rozwiązuje.

Po wprowadzeniu agile’a, nagle zyskujesz cierpliwość. Nabierasz cierpliwości do siebie, do zespołu, firmy. Jesteś przecież w procesie zmian. Teraz się uczymy, obserwujemy i wyciągamy wnioski. Nie jest idealnie? Wiem, ale to nic. Naprawimy to. Już tyle zmieniliśmy na lepsze. To też z czasem się zmieni, samo się ureguluje. Po roku dochodzimy do czegoś, co jest powszechną dobrą praktyką? OK. Ważne, że do przodu. Czy to można było zrobić lepiej, szybciej? Pewnie tak. Ale ważne, że się rozwijamy, uczymy, zmieniamy na lepsze. „Nie ważne, kim jesteś. Ważne, kim się stajesz”.

Czy ten problem zawsze się rozwiązuje? Nie. Ile się słyszy o robionych retrospekcjach, które nic nie wnoszą? Nic nie zmieniają? Przychodzi się i dyskutuje o tych samych problemach, żeby z nimi później nic nie zrobić i powtórzyć przy następnej okazji. W takim układzie ludzie też tracą zaufanie. A takie retrospekcje zamiast napawać wiarą, to jedynie irytują. Zależy czy zrobisz to dobrze. Zależy od ludzi. Na spotkaniu, które nazywa się po prostu „spotkaniem” można równie dobrze wyciągać wnioski, wprowadzać zmiany, podnosić ludzi na duchu i rozpalać w nich zaangażowanie. Zależy czy tego chcesz, jak to zrobisz i czy w tym wytrwasz z zespołem.

Czego często brakuje w projektach nieagilowych

Nazwij to jak chcesz. Retrospektywa, lessons learned, nauka z doświadczeń, empiryzm. Obserwuj, co robisz jako analityk, jako zespół, jako firma. Wyciągaj wnioski. Poprawiaj się małymi kroczkami. Ale ciągle. Bądź coraz lepszy. Dostarczaj coraz więcej wartości.

Uważasz, że masz za dużo bezsensownej dokumentacji? Wyrzuć coś, zmień coś w produktach pracy albo w procesie ich tworzenia. Kto Ci broni? Ktoś broni? Przekonaj go, że warto. Zobacz jak zareagują inni, zespół, firma. Czy to dobra zmiana? Nie? Przywróć to z powrotem. Tak? Zobacz, co jeszcze można wyrzucić. Możesz to zrobić zawsze. Wszędzie. Teraz. Niezależnie od podejścia, w jakim pracujesz. Niezależnie od miejsca, w którym teraz jesteś.

Czy do takiego podejścia potrzebny jest agile, Scrum i wszystko, co w oficjalnie znanym pakiecie? Moim zdaniem nie. To powszechnie znana dobra praktyka. Z jakiegoś jednak powodu w agilu o niej pamiętamy, a w innych układach stosujemy to rzadziej. Kto wie, może w Twoim przypadku to jedyna opcja? Może bez rzucenia hasła, podjęcia szeroko zakrojonej akcji „przechodzimy na agile”, to nie ma szansy się wydarzyć? Może inaczej szefostwo czy ludzie nie będą chcieli się zmienić? Inaczej nie przyjmą, że będą podlegać zmianom, usprawnieniom, ale też będziecie popełniać czasem błędy, bo obierzecie na chwilę niewłaściwą ścieżkę? Może inaczej tego nie zaakceptują.

Czy tworzenie MVP, dostarczanie szybko wartości to równa się agile, backlog i historyjki? Bez względu na podejście mamy dobre praktyki w stylu „przydzielaj priorytety wymaganiom, planuj wydania tworząc optymalne zestawy wymagań dostarczających największą wartość”. Widziałeś gdzieś, żeby pisali „zapisz wszystko na 500 stronach dokumentu i wdrażaj wszystko na raz, bez względu na to, czy to Must-Have czy Nice-To-Have?”. Niech Twój harmonogram spuchnie trzykrotnie od nice-to-have i zarzuć projekt, bo się nie opłaca. Czy tak robimy, czy tak się dzieje, bo tak każe podejście? Czy to może nasz brak umiejętności, brak wiedzy, brak chęci, brak siły, brak zaangażowania? I może też to, że projekty są złożone i trudne przez technologię, wymagania i ludzi? Bo to jest trudne. Ale weź też odpowiedzialność za to, na ile przyczyniasz się do zmiany na lepsze. W agilu też będziesz musiał ją wziąć.

Analityk w agilowym świecie – Jak to zrobić?

Jak mam dobrze robić analizę w agile? Uwielbiam odpowiedzi typu „trzeba rozmawiać”. Nie tyle, że się z nimi nie zgadzam. To generalnie prawda. Ale pamiętam, jak to było, kiedy zaczynałam. „No, ale co? Gdzie? Jak?”. Mamy tu pytanie, może trochę filozoficzne, o podejście do uczenia. Czy uczyć zasad, pokazywać zastosowanie i dobre przykłady? Czy rzucić w głęboką wodę i czekać aż się człowiek odnajdzie?

Są modele rozwoju kompetencji, które mówią, że młodych stażem trzeba prowadzić krok po kroku po dobrze zdefiniowanych zadaniach – co masz zrobić, jak masz zrobić, co ma z tego powstać. A na końcu ja to jeszcze sprawdzę czy to dobrze zrobiłeś. Później, kiedy widzimy, że ogarnia, to idziemy krok dalej i dajemy wskazówki – już nie tak dokładne instrukcje i już nie tak dokładnie sprawdzamy. Rosną umiejętności i zaufanie. Później mamy coraz bardziej kompetentną osobę. Wiemy, że da sobie radę, mówimy tylko, co jest do zrobienia. A ekspertowi zostawiamy pełną swobodę wyznaczając jedynie cel do osiągnięcia. Jeśli powiesz całkiem nowej w temacie osobie „Weź to zrób. Weź porozmawiaj”, to się biedak może zgubić. Chociaż też by czegoś ciekawego doświadczył i może się nauczył. Ile i jak szybko zależy od jego zdolności obserwacji, wyciągania wniosków, dostosowywania, szukania rozwiązań. Pytanie którędy lepiej? Jak wiele masz czasu i jak wiele ryzyka możesz podjąć?

Na początku potrzebowałam schematu, szablonu, przykładu. Teraz już tego nie potrzebuję. Teraz sięgam od razu po to jedno czy kilka narzędzi, które najlepiej pomogą. Intuicyjnie. W głowie, w pamięci. Czasem łamiąc zasady. No chyba, że przechodzę do nowego projektu, nowej branży, nowej firmy. Wtedy kompetencje są automatycznie mniejsze i potrzebuję to poukładać w głowie od początku – kto jest kim, gdzie jest co, o co tam chodzi.

Jeśli zapytasz osobę, która w danej dziedzinie spędziła już dużo czasu, to często nie potrafi Ci powiedzieć konkretnie dlaczego zrobiła to a nie tamto. Czasem to już wypływa z intuicji. Ale to się dzieje dopiero po jakimś czasie. I po tym, jak już zapoznała się dobrze z dostępnymi możliwościami.

Agile zakłada też dużą dojrzałość i kompetencje. Jesteś w innej sytuacji, kiedy pracujesz w firmie czy branży od zarania dziejów. Wiesz wszystko, znasz wszystkich, potrafisz szybko znaleźć, czego potrzebujesz. Nowym jest trudno. Skąd mają się tego dowiedzieć? Jak mają się nauczyć? Jak mają to zrozumieć? Czy nowy analityk pociągnie taką analizę? A ludzie odchodzą, mówią sprzeczne rzeczy, dokopywanie się do tego jak jest naprawdę w dużej firmie czy systemie, zajmuje dużo czasu. Jeśli umiesz zrobić obliczenie czy wysnuć wniosek w pamięci – good for you. Nie potrafisz, bo to skomplikowane czy ryzykowne? Albo się uczysz? Zrób to krok po kroku wg dobrych praktyk.

Wiele opcji na miejsce dla analityka

Jest wiele opcji. Analityk jako PO. Analityk jako wsparcie PO. Analityk w zespole. I takie tam. Każdy układ ma wady. Każdy „to nie to”. Najlepszy jest PO z biznesu. Niektórzy też mówią, że najgorsza jest opcja „no BA at all” (patrz: doświadczenia z Agile3M).

Jedynym PO jakim mogłabym być w tej chwili to PO produktów dla analityków. To jest branża, którą żyję. Ją znam, interesuję się nią, obserwuję od lat. Wiem, czego potrzeba analitykom albo przynajmniej wiem w jaki sposób zabrać się za sprawdzanie takiej hipotezy.

Nie będę teraz dobrym PO od transportu, piłki nożnej, ubezpieczeń, bo tym nie żyję. I nie będę nigdy, jeśli nie zdecyduję się jakimś tematem żyć. A mając rok doświadczenia w jakiejś branży nie przeskoczysz nagle tych, którzy są w niej bardzo zaangażowani np. od kilkunastu lat. Może Twoją pasją jest jakaś inna dziedzina? Potrafisz powiedzieć „wprowadzimy tę funkcję i rynek oszaleje”! Albo „Wyczytałem wczoraj w nocy, że wprowadzą nowy przepis! Musimy to dodać do systemu i być pierwsi!”. Może potrafisz podejmować dobre decyzje w temacie, którym żyjesz? Byłbyś dobrym PO.

Pozostaje też opcja „na prezesa” czy „na prezydenta”. Nikt się przecież nie zna na wszystkim, więc możesz mieć od tego ludzi. Eksperta dziedzinowego, dopóki sam się lepiej tej branży nie nauczysz. Człowieka od badań rynku. Profesjonalnego Product Managera, dla którego zarządzanie produktem to jego fach. Jeśli Cię stać, to szalej, a co tam. Jeśli nie, poszukaj wersji budżetowych. Pamiętaj jednak, że to wymaga dodatkowych kompetencji – np. szybszego podejmowania decyzji, rozdzielania pracy innym, delegowania. Części to pasuje, innym nie.

A jeśli nie PO, to pozostaje Ci to, co ze wszystkim innym w życiu – wybrać jedną z pozostałych opcji dla analityka, która ma wady i pogodzić się z nimi. Minimalizować negatywne skutki i maksymalizować korzyści. Może kolejne lata dadzą nam nowe doświadczenia i naukę z doświadczeń. Możesz też pójść w stronę analizy strategii, architektury biznesowej. Wtedy jednak stracisz nieco bliski kontakt z ekranami, szynami i bazami, który też pewnie lubisz. Albo możesz jeszcze pójść tam, gdzie firma dobrze czuje się w innym podejściu, gdzie analityk ma dobrze określone miejsce.

Po co jest ten analityk?

Umiemy pomagać ludziom określać problemy i cele. Czasem nie potrafią zadać sobie właściwych pytań, jasno stwierdzić odpowiedzi albo przekazać innym. Umiemy określić możliwe rozwiązania, ocenić je, pomóc wybrać najlepsze. Umiemy pomagać definiować i rozwiązywać problemy biznesu. Tłumaczyć, komunikować, łączyć fakty i ludzi. Wielu tego właśnie potrzebuje.

„Analityk w agilu jest niepotrzebny”. Może gdzieś nie jest potrzebny. Może developerzy, którzy mają bardzo dobre kompetencje analityczne występują gdzieś nie w sztukach, ale w niezwykłej kumulacji i stanowią większość zespołu. Może gdzieś jest biznes, który doskonale radzi sobie z określaniem celów, przekazywaniem potrzeb i komunikacją z IT. Sami się dogadają i sobie świetnie poradzą. OK. Może gdzieś poradzą sobie może nie świetnie, ale wystarczająco dobrze. Może gdzieś średnio lub kiepsko, ale organizacja jest w stanie ponieść takie konsekwencje. OK. Ilu takich jest? Ile zespołów i firm z takich osób złożymy?

To fakt, że Scrum jest w bardzo wielu, coraz większej liczbie firm. Scrum lub „Scrum”. Widać jednak trend i przemianę. Widać jednak także, że analityków jest coraz więcej. Nie wiem czy pamiętasz czasy 5-10 lat temu. Ile było ofert? Ile osób pytało „a co robi analityk”? A ile jest tego teraz? Firmy szukają, zatrudniają i płacą za analityków. Jest jakiś popyt, który rynek zaspokaja. To jest również fakt. Często też Polacy patrzą na zachód. Jak na zachodzie? Ano są i mają się dobrze. Jak będzie za kilka lat? Zestarzejemy się i sami zobaczymy.

No, ale też trzeba się przyjrzeć sobie. Sami często jesteśmy sobie winni marudzenia na „kwity”. Jakim jestem analitykiem? Co uważam za swoje zadania? Za wartość, jaką wnoszę? Jeśli jestem po to, żeby robić dokument, to coś jest nie tak. Na koniec dnia to nie dokument zmienia biznes. Dokument nie zmienia niczego. To czasem środek do celu. A co jest celem? Zrozumienie. Określenie potrzeby. Zarekomendowanie rozwiązania. Pomoc w podjęciu decyzji. Przekazanie informacji. Utrwalenie wiedzy. Jeśli zrobiłeś dokument, a nie rozumiesz, nie potrafisz wyjaśnić innym, nie wiesz „dlaczego?”, nie wiesz co z tym zrobić, nie wiesz, która opcja będzie najlepsza dla biznesu, to nie zrobiłeś zadania. Nie zrobiłeś analitycznej roboty. Jeszcze raz. Masz pomagać biznesowi zrozumieć jego potrzeby i pomóc w rozwiązaniu problemów najlepszym sposobem. Robisz to w locie, w 5 minut, jednym telefonem i bez żadnego dokumentu? Jeśli w Twoim przypadku to korzyść w krótkiej i dłuższej perspektywie, to OK. Zadanie spełnione.

Mam jednak wrażenie, że ciągle wielu z nas nie wie, jakie ma możliwości. Potwierdza to oglądanie dokumentów w firmach, rozmawianie z nawet bardzo doświadczonymi analitykami, którzy nie znają podstawowych dobrych praktyk. 41% programistów, testerów, kierowników projektów, itp., powiedziało w ankiecie, że brakuje nam wiedzy w, uwaga!, analizie biznesowej, inżynierii wymagań. Zaskakujące? Przerażające? Wyobrażasz sobie, żeby 41% analityków powiedziało, że głównym brakiem programistów jest brak wiedzy o programowaniu? Jesteśmy jako grupa mało wykwalifikowani. Czy myślisz, że przejście na Scruma nagle sprawi, że to nie będzie problem? Słyszałam jakiś czas temu opinię, że często najlepsi agilowi analitycy to tacy, którzy pisali wcześniej tradycyjne dokumenty a później zmienili podejście. Może wiedzą po prostu, które informacje są ważne i potrafią je teraz sobie poukładać i przedstawić innym w dowolnej formie, w dowolnym podejściu?

Coś na co zawsze będzie zapotrzebowanie

Tak naprawdę to chodzi o wartości. Czy je wyznajesz i czy wg nich postępujesz. Współpraca. Rozwiązywanie problemów. Skupienie na celu. Skupienie na rozwiązaniu zamiast szukaniu winnych. Skupienie na możliwościach a nie na przeszkodach. Działanie. Zaangażowanie. Inicjatywa. Dostarczanie wartości klientom, użytkownikom, kolegom. Pomaganie sobie. Branie odpowiedzialności. Dbanie, żebyś Ty przychodząc do mnie, wychodził z rozwiązanym problemem albo chociaż poczuciem, że zrobię co mogę, by go rozwiązać, żeby Ci w tym pomóc. Że robimy to wspólnie. Że to ma sens. Że nam zależy. Że mamy wpływ. Że to ważne. Że się da. Chodzi o kulturę, czyli współdzielenie tych wartości w zespole i w firmie.

Cześć! 7 lat temu odkryłam, że analiza biznesowa to genialna rzecz. Od tamtej chwili zbieram doświadczenia w różnych firmach, branżach i projektach. Analizuję, prowadzę bloga, piszę artykuły, kursy, prezentuję, uczę na uczelniach i robię szkolenia. Przygotowuję także procesy analizy w firmach. Badając rynek szukam odpowiedzi na pytania: jak zostać dobrym analitykiem? Co to oznacza dla różnych odbiorców - kolegów z zespołu, managerów i klientów? Jak analitycy powinni się rozwijać? Po godzinach uczę się czegoś nowego i biegam do morza i z powrotem. Jestem ciekawa Twoich doświadczeń, wyzwań i problemów. Zostaw komentarz o sobie :)

3 KOMENTARZE

  1. Dla mnie naprawde dobra lektura/podsumowanie. Pewnie dlatego że mam podobne doświadczenia. Myślę że puenta dotycząca „współpracy” jest kluczowa. Co więcej wydaje się że rozwinięcie tego tematu może przenieść nas do „nieco” innych obszarów… być może temat na dodatkowe przemyślenia.
    Pozdrawiam,
    Mariusz

      • Dobre, analityczne pytanie do enigmatycznego komentarza:). Jakość współpracy jest „jakoś” zależna od zaufania,więzi ludzkich … Tym samym czegoś co nazwę trochę górnolotnie – „kapitału społecznego”. W niekoniecznie „szególnych” przypadkach zespoły „agile-owe” w procesie ewolucji mogą stać się silosami, unikającymi transparencji. Dla mnie transparencja jest jedną z głównych lub pochodnych wartości metodyk zwinnych (formalnie mogę coś tu kręcić:). Dlatego temat kultury [i] współpracy z wysoce „autonomicznymi i zwinnymi” zespołami jest elektryzujący – przynajmniej dla mnie.

ZOSTAW ODPOWIEDŹ