Wydarzenia,
19 października 2020
Kurs Zdobądź Certyfikat ECBA IIBA – zapisy do 20.10.2020 r.
Zapisz się na II edycję kursu Zdobądź Certyfikat ECBA IIBA. Jaki jest zakres certyfikatu ECBA IIBA? Jakie wnioski wyciągnęliśmy z I edycji
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.
Ta prezentacja otworzyła konferencję. Hans przedstawił m.in. 4 główne nieporozumienia w kwestii analizy i podejścia Agile:
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 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.
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.
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:
I o to powinniśmy zadbać ze szczególną troską.
Na koniec Hans uraczył nas „RE (Requirements Engineers) Manifesto”:
Osobiście mam problem z drugim zdaniem, ale na pewno warto poddać pod rozwagę temat analitycznego manifestu.
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 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 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 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.
Niestety nie miałam okazji wysłuchać tej prezentacji. Jeśli jesteś w stanie przekazać główne myśli – proszę, zapraszam.
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 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:
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.
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:
Aby tworzyć środowisko, które się uczy na błędach:
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 😉
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?
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.
W międzyczasie odbywały się też warsztaty, na których spotkać można było takie osoby:
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?
Jako strategiczny analityk biznesowy na pograniczu zarządzania i IT zapewniam, że projekty i działania w organizacji przynoszą wartość biznesową. Dostarczam kompetencji analitycznych managerom i zarządom z Polski, Niemiec i Szwajcarii przy tworzeniu strategii oraz wdrażaniu jej w kilkuset osobowej międzynarodowej organizacji.
