ReQuest zapowiadało się dobrze – w agendzie pojawiło się wiele znajomych nazwisk. Kolejny plus – do Torunia bliżej niż do Warszawy 🙂 Wyruszyliśmy z Gdańska ze wschodem słońca i byliśmy w domu tego samego dnia.
Toruń to klimatyczne miasto nad Wisłą kojarzące się z Kopernikiem, piernikiem i naleśnikiem 😉 Jeśli nie miałeś okazji poznać go bliżej, to koniecznie zajrzyj przy następnej okazji na rynek, zrób zdjęcie z pomnikiem Kopernika, kup bliskim po pierniku w piernikowym sklepie nieopodal. Na obiad polecam naleśnikarnię Manekin. Rozrosła się na kilka miast, ale początek wzięła właśnie z Torunia, gdzie mają aż 3 restauracje w różnych lokalizacjach (jedna jest na rynku). W cieplejsze miesiące koniecznie zajrzyj do Lenkiewicza na lody (blisko rynku). Jeśli masz więcej czasu, wpadnij do planetarium. Pokazują seanse, w których gwiezdny materiał filmowy pada na cały sufit w kształcie kopuły. Wieczorem można spróbować piernikowej wódki. Nie tak łatwo ją znaleźć, ale warto poznać trochę lokalnej kuchni 😉
Ale miało być o konferencji. Od 7 lat odbywa się konferencja dla testerów TestWarez. Organizatorzy wpadli na pomysł, żeby przygotować też coś dla analityków i sprawdzić, czy będzie zainteresowanie. Na ReQuest przybyło ok. 200 osób. Wychodzili zadowoleni, więc test jak najbardziej udany. Konferencję zorganizowało SJSI (Stowarzyszenie Jakości Systemów Informatycznych) dzięki Karolinie Zmitrowicz.
Agenda przedstawiała się następująco:

Miałam przyjemność być na większości prezentacji i spisać kilka płynących z nich myśli.

Hans Van Loenhoud – Continuous Requirements Engineering – from requirements engineering to requirements engineering

Ta prezentacja otworzyła konferencję. Hans przedstawił m.in. 4 główne nieporozumienia w kwestii analizy i podejścia Agile:

• Uprzednie zaprojektowanie (upfront) to zło

Generalnie w Agile nie poleca się wczesnego projektowania i przeanalizowania z wyprzedzeniem wszystkiego w szczegółach. Jednak przeginaniem w drugą stronę jest to, żeby nie dopuszczać żadnego projektowania i mieć jedynie rozgrzebane skrawki, które zespół musi sam poskładać.

• User Stories wystarczają

User Stories zyskały sobie taką popularność, że zespół często ich wymaga i zdarza się, że nie chce pracować z niczym innym. Hans zwracał uwagę na to, że niektóre informacje warto przygotować też w innej formie, np. wymagania jakościowe, które umieszczone w kryteriach akceptacji jednego user story mogą zniknąć z oczu zespołu w całym systemie. Wymagania w formie User Stories mogą być uzupełniane przez inne informacje i formy ich wyrażania.

• Spisane wymagania idą do kosza

Opisane wymagania nie służą jedynie do jednorazowej komunikacji co należy zrobić. Służą także jako zapis myśli, komunikacja, która przemierza czas, trafiając do nas z przyszłości i do innych osób, które będą tego potrzebować za jakiś czas oraz z którymi jesteśmy oddzieleni różnymi lokalizacjami.

• Nie tylko działające oprogramowanie jest wartością

Tutaj Hans rozprawiał się ze stwierdzeniem, że zespół generuje wartość jedynie w postaci działającego oprogramowania. Ale nie tylko to stanowi wartość dla organizacji. Wyobrażasz sobie sytuacje, w których użytkownicy nie wiedzą jak korzystać z oprogramowania, brakuje informacji o tym, która część systemu wykonuje jakie zadania, jakie są powiązania, jak odwzorowane są w systemie procesy? Ja zgadzam się, że posiadanie samego oprogramowania to nie 100% szczęścia, bo aby pozyskać informacje musimy poświęcać czas na analizę kodu, a nadal nie znajdziemy odpowiedzi na pytania „dlaczego tak to działa” albo „czy to dobrze, że to działa tak, a nie inaczej?”. Oprogramowanie to nie wszystko.
Hans podkreślił, że wartością nie jest opisywanie wymagań, ale zrozumienie:

• Potrzeb
• Kontekstu
• Celu

I o to powinniśmy zadbać ze szczególną troską.
Na koniec Hans uraczył nas „RE (Requirements Engineers) Manifesto”:

• Genuine empathy over techniques, models and templates
• Creative solution design over comprehensive elicitation
• In-time elaboration over upfront specification
• Shared understanding over proper documentation

Osobiście mam problem z drugim zdaniem, ale na pewno warto poddać pod rozwagę temat analitycznego manifestu.

Agnieszka Kugler – Zarządzanie analizą biznesową – ujęcie praktyczne

Agnieszka po raz kolejny ujęła mnie swoim na wskroś analitycznym podejściem. Tym razem tematem było zarządzanie zespołem analityków. Agnieszka jest od ok. 3 lat managerem i opowiadała nam o tym jak szukała wartości swojej pracy, jakie cele postawiła, jak zabrała się za pracę nad zespołem analityków.
Rozpoczęło się od stwierdzenia, że często szansa na sukces projektu jest odwrotnie proporcjonalna do liczby managerów. Agnieszka zastanawiała się, czy w takim razie może na stanowisku managera przysporzyć jakichś korzyści swojemu zespołowi i firmie? Jakiego managera potrzebują analitycy z jej zespołu? I czy ona takim managerem chce być? Piękne uzasadnienie biznesowe przed podjęciem projektu, nieprawdaż? 😉
Agnieszka szukała inspiracji do określania celów i KPI. Stwierdziła, że liczą się przede wszystkim cztery obszary:

• Rozwój
• Jakość
• Integracja
• Zarządzanie

Rozwój możliwości analityków dostarcza jej najwięcej satysfakcji. Porównywanie, z jakimi problemami radzili sobie analitycy na początku, a jakich obecnie podejmują się zadań, daje wiele radości i napawa dumą z efektów swojej pracy. Warto brać pod uwagę kompetencje i ambicje osób.
Celem było także zapewnienie jakość pracy w sposób systemowy, niezależny od danej osoby, aby klienci zewnętrzni i wewnętrzni nabierali zaufania do pracy analityków.
Integracja polegała na synchronizacji działań różnych zespołów, aby efekty pracy były kompatybilne i dawały w całości zamierzoną wartość.
W kwestii zarządzania Agnieszka ustaliła cele w tematach kontroli jakości, zarządzania zmianą, rozwiązywania problemów i szacowania.
Najważniejszym sprawdzianem samodzielności zespołu jest dla niej jej urlop. Po powrocie patrzy, ile spraw na nią czeka, a z czym zespół poradził sobie samodzielnie.
Agnieszka polecała bliższe poznanie teorii zarządzania sytuacyjnego Blancharda, analizę SWOT zespołu, prace Curtisa, Feyerabenda.
Zapytałam co się stanie, kiedy zespół osiągnie już określony poziom samodzielności? Agnieszka twierdzi, że za każdym razem, kiedy dochodzą do określonego poziomu, ona zauważa nowe możliwości. To by się zgadzało z indywidualnym rozwojem analityka 🙂 Zawsze, gdy idziesz dalej, zauważasz jak wiele jeszcze nie wiesz, jak wiele jeszcze możesz udoskonalić, żeby sprostać coraz większym wyzwaniom.

Elena Zhukova – Przygotuj się do zbierania wymagań. Czy wiesz, czego nie wiesz?

Elena Zhuhova [Lena Żukowa] zajęła się tematem pozyskiwania wymagań i zadała intrygujące pytanie – „czy wiesz, czego nie wiesz?”. Zaczęła od metafory do podróży. Prześledzenie w głowie wycieczki pozwala nam spakować potrzebne rzeczy, zebrać informacje. Kto nie musi dokładniej planować? Ci, którzy mają więcej pieniędzy 😉
Elena przybliżyła nam 3 historie ze swojego doświadczenia zawodowego. Podobnie jak w książce „Inżynieria wymagań. Ujęcie praktyczne” bardzo dokładnie opisała sytuację, w jakiej się znalazła. Podzieliła się wieloma szczegółami. Mogliśmy dokładnie wyobrazić sobie zadania, przed którymi stanęła.
Każde z zadań wydawało się proste – ot, zwyczajna zmiana technologii interfejsu albo kolejny raport. Elena pokazała nam jednak, jak brak uważności i uproszenia mogą wpędzić projekt w kłopoty. Radziła, żeby odkrywać i ciągle powtarzać sobie 3 bardzo ważne rzeczy: cel, użytkownika, proces. Po co robimy zmianę? Co chcemy osiągnąć? Dla kogo przygotowujemy zmianę? Jak działają procesy biznesowe?
Pilnujmy się, żeby się nie zapędzić w działanie, które okazuje się bezsensowne, niedostosowane do odbiorcy lub działania firmy. A przy tym wszystkim zadawajmy trudne pytanie zespołowi (i pewnie też sobie samym): „Czy Wam się podoba to, co zrobiliście?”.
Jak odkrywać to, czego nie wiemy? Elena radzi skupić się na tych 3 rzeczach: celu, odbiorcy, procesie i wyjaśniać je innym (czy nawet samym sobie), żeby one wybrzmiały na głos i okazało się, czy faktycznie wiemy co i po co robimy.

Jacek Woynarowski, Natalia Czerwiak – Repozytorium analityczne – proste narzędzie do trudnych dyskusji

Jacek i Natalia przedstawili podejście analityczne, jakie wypracowali i wdrożyli w firmie Atena. Szanuję ludzi, którym coś nie pasuje w firmie i postanawiają zmienić to na lepsze. Prelegenci przekonali zarząd, HR, wywalczyli zasoby, żeby wprowadzić podejście w firmie, przeszkolić analityków a nawet certyfikować ich wewnętrznie ze znajomości metody. W firmie obywa się też Akademia Analityka, która skupia się na poszerzaniu umiejętności miękkich, wiedzy biznesowej i warsztatu analitycznego.
Metodyka Eureka bazuje na modelach w narzędziu Enterprise Architect. Widać, że poznali wiele możliwości tego „kombajnu”. Obecnie są w procesie pozbywania się dokumentów, ale póki co generują jeszcze Wordy/PDFy korzystając z narzędzia eaDocx. Nie znam szczegółów funkcjonowania tego narzędzia i jego dodatkowych zalet, natomiast z samego EA też na pewno można generować dokumenty.
Jacek i Natalia zaprzęgli też Enterprise Architecta m.in. do szacowania wielkości pracy w projekcie przy użyciu metody punktowej opartej na przypadkach użycia. Przedstawili ekran, na którym wprowadzają liczbę przypadków użycia w szacowanym projekcie, a narzędzie oblicza przewidywaną pracochłonność projektu korzystając z danych historycznych z poprzednich projektów. Otrzymują wyniki z odchyleniem nawet 10% (przekroczenie czasu faktycznego o ok. 10% od szacowanego). Metodę punktów zaczerpnęli z bloga Michała Wolskiego.
Też szacowałam kiedyś projekty na tej zasadzie. Metoda sprawdza się dobrze, kiedy pracujemy w podobnym środowisku, dla podobnych klientów, w podobnym składzie zespołu o podobnych kompetencjach i zaangażowaniu czasowym. Przestałam ją stosować, kiedy przeszłam do innej firmy, gdzie nie znałam z początku dziedziny, a analitycy byli na zupełnie różnych poziomach doświadczenia. Pewnie warto w takim modelu uwzględniać zmiany w tych czynnikach. I co najważniejsze – śledzić efektywność, czyli porównywać faktyczny zarejestrowany czas pracy z szacowanym, aby kalibrować współczynniki wzorów przeliczających przypadki użycia na roboczogodziny.

Mateusz Holewski – Jak pracować z wymaganiami w metodykach Agile?

Niestety nie miałam okazji wysłuchać tej prezentacji. Jeśli jesteś w stanie przekazać główne myśli – proszę, zapraszam.

Jarosław Żeliński – Analityk biznesowy jako Product Owner, czyli co ma sens a co sensu nie ma

Niestety nie miałam okazji wysłuchać tej prezentacji, choć słyszałam, że był dobry wstęp rodem z Dr House’a 🙂 Jeśli jesteś w stanie przekazać główne myśli – proszę, zapraszam.

Łukasz Łosin – UX, Lean Startup i inne umiejętności – czyli jak zaprojektować produkt satysfakcjonujący klienta

Łukasz dzielił się z nami swoim silnym backgroundem UX-owym. Wg niego UX = analityk + psycholog. Na przykładzie paradoksu wyboru, pokazywał nam, że lepiej dawać klientom ograniczone możliwości. I z drugiej strony – że czasem warto dać opcje nadmiarowe, których i tak nikt nie kupuje, tylko po to, by korzystniej w ich otoczeniu wypadała inna pozycja w ofercie. Myślę, że praca z produktami dla klientów indywidualnych, strony ofertowe, sprzedażowe to ogromne pole do popisu dla UXa/produktowca, które wymagają dodatkowych kompetencji niż tylko logiczna analiza. Zachowania klientów są nieprzewidywalne, dlatego też strony walczące o ich uwagę i pieniądze powinny być doskonalone, a różne pomysły weryfikowane w systematycznym podejściu.
Łukasz przytoczył też podział MVP (Minimum Viable Product) na 3 odsłony:

• Earliest Testable Product – najwcześniejszy product, który możemy przetestować
• Earliest Usable Product – najwcześniejszy product użyteczny dla klientów
• Earliest Loveable Product – najwcześniejszy product, który klienci pokochają

W pracę UX w szczególności wplata się psychologia motywacji. Czy pracowników najbardziej motywują pieniądze? Muszą być one na odpowiednim poziomie (czynnik higieny), ale kiedy jest ich wystarczająco, to na pierwszy plan wychodzą czynniki takie jak: rozwój, praca zespołowa, wpływ i sens. W branży IT można zaobserwować jak ludzie zmieniają firmy czy projekty, bo chcą się uczyć nowych technologii, brać udział w bardziej wymagających projektach. Szczególnie mi bliski jest czynnik sensu J Jako analitycy w szczególności jesteśmy odpowiedzialni za zapewnienie wartości biznesowej dla klientów, opłacalności pod kątem korzyści z rozwiązania i działania zgodnego z celami firmy. Praca zespołowa i wpływ dobrze realizują się w środowisku bliskiej współpracy i otwartości na sugestie co do rozwiązania.
Padł temat Scruma. Łukasz wspomniał początki tego podejścia, kiedy w 1984 roku to hasło padło po raz pierwszy w artykule Harvard Business Review. Z początku stosowały je takie firmy jak Xerox czy Honda pracując w zespołach składających się ze specjalistów z różnych dziedzin nad innowacyjnymi produktami. Innowacja = coś, czego jeszcze nigdy dotąd nie było. Łukasz zwrócił uwagę, że często nasze zespoły nie tworzą innowacji i być może Scrum nie jest najlepszym rozwiązaniem do wszystkiego.

Jarosław Łojewski – O fuckupach na poważnie. Śmiertelnie poważnie

Jarek zaczął z grubej rury pokazując statystyki przypadków śmiertelnych na skutek pracy pilotów i lekarzy. Lekarze bili pilotów na głowę. Czy to znaczy, że są czyhającymi na nas mordercami, czy chodzi o coś innego?
Jarek przedstawił różnice w kulturze tych dwóch środowisk i ich reakcje na popełnianie błędów. W lotnictwie normalną rzeczą jest zgłaszanie popełnionych błędów, szukanie przyczyn i wprowadzanie procedur, które zapobiegną katastrofom w przyszłości. Błędy medyczne nie są przyjmowane tak ochoczo. Przez długi czas lekarze byli zostawiani sami sobie, jeśli padł pozew ze strony rodziny pacjenta. Nie było również dobrze przyjmowane wytykanie błędów wyżej postawionym lekarzom. Wiele ludzi akceptowało też ryzyko śmierci i nikt nie szukał przyczyn.
Boimy się porażek i przyznawania do nich, bo sądzimy, że zostaną źle odebrane przez innych, podważą nasz autorytet, ludzie przestaną nam ufać, będziemy musieli ponieść konsekwencje. Czy słysząc o katastrofach lotniczych przestaliśmy latać samolotami? Często tym, co nas uspokaja są statystyki – katastrofa lotnicza jest obecnie dużo mniej prawdopodobna niż wypadek w innym środku transportu.
Jarek twierdzi, że istnieje dobra porażka. To nieumyślny błąd, z którego zostały wyciągnięte wnioski i zastosowano działania zapobiegawcze.
Stosujmy 4xZ:

• Zidentyfikuj porażkę
• Zrozum, z czego wynika
• Zaplanuj akcje naprawcze/zapobiegawcze
• Zrealizuj je

Aby tworzyć środowisko, które się uczy na błędach:

• Nie wyciągaj konsekwencji nieumyślnych błędów
• Mówcie o porażkach otwarcie
• Stawiajcie na komunikację, nie hierarchię

Uczenie się na błędach. Ileż to razy o tym słyszeliśmy? A jednak wystąpienie Jarka wybrzmiało świeżo i inspirująco. I założę się, że także niejeden z Was w tym momencie zapisał sobie, że kiedy wróci do pracy, to zrobi… no właśnie 😉

Jarosław Świątek – Rozum jako iluzja dnia powszedniego – czy istnieją narzędzia skutecznego myślenia?

Za zakończenie czekała na nas prezentacja Jarosława Świątka – psychologa społecznego. Odkrywał przed nami zakamarki ludzkiego umysłu. Głównym przeslaniem prezentacji było to, że przyczyny wielu decyzji, które podejmujemy są przez nas nieuświadamiane. Albo w ogóle nie potrafimy wskazać przyczyny albo podajemy przyczyny przez nas racjonalizowane (wymyślane, żeby uzasadnić sobie jakoś swój wybór). Od razu wyrwały się z sali głosy niedowiarków, że oni tak nie mają 🙂 Za słowami pana Jarka stoi natomiast wiele badań naukowych i prace Kahnemana – człowieka, który dostał nobla.
Jakie wnioski pojawiały się w prezentacji?

• Częściej wybieramy osoby/zdjęcia o rozszerzonych źrenicach, bo świadczy to o zainteresowaniu
• Jeśli na stronie pojawiają się skojarzenia z komfortem, wybieramy produkty bardziej luksusowe, a jeśli pieniądze – produkty tańsze
• Jeśli elementy niczym się nie różnią, to chętniej sięgamy po te po prawej stronie, bo prawe oko przesyła sygnał do lewej półkuli mózgowej, która odpowiada za podejmowanie decyzji
• Rzeczy, o których mamy więcej (częstszy dopływ) informacji wydają nam się bardziej prawdopodobne

Wkraczamy w erę, w której algorytmy zaczynają lepiej od ludzi oceniać ludzkie cechy (prelegent polecał prace Michała Kosińskiego), emocje czy np. przewidywać kto popełni samobójstwo (algorytm ok. 80%, człowiek ok. 50%).Każdy interpretator (czy to ludzie czy algorytmy) jest jednak tak dobry jak dane, które posiada.

Warsztaty

W międzyczasie odbywały się też warsztaty, na których spotkać można było takie osoby:

• Rafał Borowiec, Miłosz Musialik „Pozyskiwanie i modelowanie wymagań w projektach IT”
• Kasia Gottfired, Tomasz Furgalski „Analityk w zmieniającym się świecie”
• Łukasz Łosin „Nauka szybkiego prototypowania aplikacji mobilnych i desktopowych”
• Aleksandra Kornecka „Walidacja wymagań w fazie eksploracyjnej projektu”
• Jarek Łojewski „Coaching w analizie”
• Hanna Tomaszewska „Przewodnik po analizie dla zdezorientowanych – jak właściwie zabrać się za analizę i przejść zielonym lub czarnym szlakiem”
• Olivier Denoo „Mission Impossible – the social warfare”

Czy warto jeździć na konferencje?

Od czasów studiów odczuwałam dziką radość, kiedy szykowało się jakieś wydarzenie, na którym spotykali się analitycy. Czułam potrzebę spotkania z innymi ludźmi, którzy zajmują się tym samym. Tym bardziej, że na początku bywałam w firmie jedynym analitykiem i zwyczajnie nie było z kim porozmawiać na te tematy. Na początku każdą taką prezentację traktowałam jako inspirację, źródło wiedzy, możliwość posłuchania bardziej doświadczonych osób. Podczas takich spotkań nawiązywało się wiele znajomości, które z czasem przynosiły niespodziewane korzyści. A to robiło się później jakieś wspólne inicjatywy, czy nawet projekty, znajdowało przyszłego współpracownika, znajomego do pogadania o analizie, kogoś, kto Ci opowie jak jest w danej firmie i czy warto tam iść albo najzwyczajniej dobrych kolegów, z którymi łączy Cię więcej niż tylko analiza.
Z czasem proporcje się nieco odwróciły – mniej przynoszę z konferencji wiedzy, rzeczy, o których nie słyszałam, ale nadal całe strony w notesie pełne są inspiracji. Każda osoba patrzy z niepowtarzalnej – swojej własnej perspektywy. Nagle wpadasz na pomysł, że rzecz, którą znasz od 100 lat można zastosować teraz w Twojej sytuacji w taki a taki sposób. Często raczej spotka się „starych znajomych” i to wspaniała okazja do podtrzymania relacji, ale też nadal poznaje się nowe osoby, które zaskakują podczas wymiany zdań swoimi spostrzeżeniami czy umiejętnościami, które można by połączyć we wspólnej inicjatywie.
Analityk biznesowy to nie stan, bardziej droga. I na tej drodze nigdy nie wiesz już wszystkiego i nie jesteś maksymalnie dobry. Dlatego trzeba się wrzucać w takie sytuacje, które pobudzają do rozwoju, nowych zastosowań i podważania tego, co już potrafisz.
Zdecydowanie warto 🙂
Jak tam Twoje wrażenia i złote myśli?