Sklep

Oferta edukacyjna

Już dziś zainwestuj w kompetencje jutra.
Wyniki: 45
Brak danych o cenie
IREB ® i REQB ® łączą siły- co to zmienia w certyfikacji?
Zapisy wkrótce

W artykule: „Główne trendy analizy biznesowej w 2017 roku” w części: „Tytuł stanowiska zobowiązuje” pisałam o tym, że w 2017 roku możemy spodziewać się usytematyzowania nazewnictwa w zakresie analizy biznesowej i inżynierii wymagań. Nie musieliśmy długo czekać na pierwszy milowy krok w promowaniu tematu inżynierii wymagań na świecie.

18 stycznia 2017 na kartach historii IT zapisze się jako fuzja dwóch największych systemów certyfikacji z zakresu inżynierii wymagań:

IREB ® (International Requirements Engineering Board)

REQB ® (Requirements Engineering Board).

Obie organizacje powstały w Niemczech w 2006 roku. Celem każdej z nich jest budowanie ogólnoświatowej certyfikacji inżynierii wymagań jako standardu w pracy inżyniera wymagań.

Syllabusy, na podstawie których kandydat przygotowuje się do certyfikatu są bardzo podobne, więc tym bardziej nie dziwi fakt, iż po kilku latach postanowiono połączyć siły w imię promowania inżynierii wymagań na świecie.

Różnicą między certyfikatem IREB oraz REQB była głównie popularność danego certyfikatu w Polsce. Dotychczas wybór certyfikatu podyktowany był głównie tym, z jakim klientem docelowo będziemy pracować:

  • praca głównie za granicami Polski – bardziej rozpoznawalny i rozpowszechniony był certyfikat IREB,
  • praca w Polsce – bardziej rozpoznawalny certyfikat REQB.

Co zmienia fuzja?

  1. Po pierwsze certyfikaty REQB zostaną zintegrowane z certyfikatami IREB.
  2. Wszyscy członkowie REQB mogą stać się członkami organizacji IREB oraz zasilić istniejące grupy lokalne IREB.
  3. Kontynuowany będzie system certyfikacji pod marką IREB w oparciu o IREB CPRE. W praktyce oznacza to, że od 1 października 2017 roku po kursie REQB otrzymasz certyfikat IREB CPRE.
  4. Wszystkie certyfikaty REQB zachowują swoją ważność, ośrodki szkoleniowe REQB mogą oferować szkolenia IREB.
  5. Jeśli posiadasz certyfikat REQB możesz bezpłatnie go zarejestrować w systemie certyfikacji IREB, dzięki czemu będziesz mógł kontynuować ścieżkę rozwoju już według certyfikacji IREB. Wystarczy, że zgłosisz taką chęć u dostawcy certyfikatu REQB: info@gasq.org.

(artykuł powstał na podstawie informacji ze strony: https://www.ireb.org/en)

Powiadom mnie o zapisach

Dowiesz się, gdy tylko ruszą.

Szczegóły
Brak danych o cenie
Studia podyplomowe dla analityka
Zapisy wkrótce

We wrześniu wielu z nas podejmuje decyzję o rozpoczęciu kolejnego etapu edukacji, jakim są studia podyplomowe.

Czym się kierować przy wyborze studiów podyplomowych? Co tak naprawdę oferowane jest w cenie studiów? Na co szczególnie zwrócić uwagę w programie? Czy pracując jako typowy analityk biznesowy powinno unikać się ofert z politechnik?

Zapraszam na przegląd ofert studiów podyplomowych w Polsce wraz ze swoim komentarzem.

Krok 1: Na co dzień pracuję jako…

W pierwszej kolejności musisz odpowiedzieć sobie na podstawowe pytanie – czym zajmujesz się w swojej pracy – wykonujesz analizę biznesową czy inżynierię wymagań? A może jedno i drugie?

Nie sugeruj się proszę tytułem swojego stanowiska, ponieważ w wielu firmach jeszcze pokutuje przekonanie, że analityk biznesowy to osoba, która przygotowuje dokumentację dla programistów. Nic bardziej mylnego. Zdziwiony? Jeśli tak, to ten artykuł jest na pewno dla Ciebie.

Zgodnie z definicją BABOK :

„Analityk biznesowy to osoba odpowiedzialna za identyfikację potrzeb biznesowych klientów i zainteresowanych stron w celu określenia rozwiązań problemów biznesowych”.

Analityk biznesowy powinien przede wszystkim rozumieć cele biznesowe projektu, po czym zdefiniować wymagania użytkowników, wymagania funkcjonalne oraz pozafunkcjonalne (jakościowe), co pozwoli zespołom oszacować oraz zaplanować projekt. Analityk powinien wskazywać funkcje oraz funkcjonalności, jakie powinien spełniać system. W praktyce oznacza to, że w większej mierze analityk biznesowy skupia się na tym CO system powinien robić a nie JAK. Bardzo dobrym przykładem dokumentacji opisującej CO system ma robić, jakie funkcje i funkcjonalności zawierać jest dokument przygotowany przez Jarosława Żelińskiego dla kancelarii senatu: Dokument- SIWZ.

Rolą analityka biznesowego nie jest definiowanie, jakie elementy należy zaprogramować w systemie, aby korzystać z niego w sposób oczekiwany przez Klienta. Dokumentacja tworzona przez analityka biznesowego dostarczana jest do dostawcy, który z kolei dekomponuje wymagania na zadania do wykonania w systemie. Praca ta najczęściej była wykonywana przez programistów, czasem architektów. Do momentu, kiedy dostawcy zaczęli zatrudniać analityków biznesowych chcąc lepiej zrozumieć oczekiwania klientów. Wraz z upływem czasu okazało się, że umiejętności analityka biznesowego to za mało, aby zespół dostał precyzyjną informację, co dokładnie musi przygotować w systemie. Pojawiła się nowa potrzeba na rynku, którą pracodawcy postanowili zaspokoić poprzez stworzenie nowego stanowiska: „analityk IT”, „analityk biznesowo-systemowy” czy po prostu: „analityk”, „architekt biznesu”, rzadziej w naszych rodzimych stronach można spotkać: „inżyniera wymagań”. Przyglądając się zadaniom jakie są wykonywane przez osoby zatrudnione na tym stanowisku okazuje się, że wykonują one inżynierię wymagań. W dokumentach bowiem można zobaczyć już prototypy okien z dokładnym opisem typu danych jakie zostały tam użyte. Znajdziemy tak czasem relacyjne bazy danych, diagramy klas, czy również elementy procesu biznesowego, aby dokumentacja była spójna dla obu stron.

Dlatego rozmawiając z analitykami nigdy nie pytam się o stanowisko, lecz zakres obowiązków, jakie na nim wykonuje. Dzięki temu łatwiej jest mi zrozumieć również problemy, z jakimi się styka na co dzień.

Rynek pracy wymusza na nas ciągłe doskonalenie się. Pojawia się zatem pytanie – które studia wybrać, skoro wszystkie są dla „analityków biznesowych”. A jak sam już zdążyłeś się przekonać mówiąc: „analityk biznesowy” osoba może pracować: po stronie biznesu bądź IT, ale:

A- jej głównym zadaniem jest przygotowanie oferty, bądź opisu biznesowego funkcji i funkcjonalności, jakie powinien zawierać docelowy system – patrz przykład opisu przygotowanego przez Jarosława Żelińskiego (nazwiemy ich analitykami biznesowymi),

B- jej głównym zadaniem jest dekompozycja wymagań biznesowych na zadania, jakie powinny być przygotowane przez zespół, np. opis przycisków w oknie dialogowym, czyli rozpoczyna pracę po przygotowaniu opisu biznesowego (nazwiemy ich inżynierami wymagań).

Powstaje pytanie – które studia podyplomowe wybrać, skoro uczelnie zasypują nas ofertami studiów podyplomowych dla analityków biznesowych. Która propozycja będzie najlepsza dla mnie? Na co zwrócić uwagę?

Wykorzystując wcześniejsze rozważania podzielę oferty uczelni na te, które kierowane są do: analityków biznesowych (opisanych w punkcie A) oraz inżynierów wymagań (opisanych w punkcie B).

Krok 2: O czym warto pamiętać przy wyborze studiów?

Rozpoczęcie studiów podyplomowych jest jednym ze sposobów na zdobycie specjalistycznej wiedzy, ale również możliwość kontaktu z osobami z branży, co jest cenione szczególnie przez osoby chcące przekwalifikować się na „analityka”.

Studia podyplomowe to również szansa dla wszystkich tych, którzy nie ukończyli studiów technicznych, a mimo to chcą uczestniczyć w analizie projektów IT.

Oto 5 wskazówek czym kierować się przy wyborze studiów podyplomowych:

Wskazówka 1 – Renoma uczelni

Podjęcie studiów podyplomowych to nie tylko Twój czas, ale przede wszystkim zainwestowane pieniądze. Wbrew opiniom nie wystarczy skończyć jakąkolwiek uczelnie, ponieważ nadal pracodawcy zwracają uwagę na to, w której uczelni zdobywamy wiedzę.

Pozycja uczelni w rankingach publikowanych co roku stanowi gwarancję jakości kształcenia.

Dlatego warto sprawdzić na którym miejscu znajduje się uczelnia, w której chcesz zdobywać wykształcenie. Polecam: Ranking Perspektywy 2017 (link).

Wskazówka 2 – Kadra i edycje studiów

Sprawdź kadrę wykładowców. Zwracaj uwagę czy dana uczelnia nawiązuje współpracę z różnymi firmami, które obecnie są cenione na rynku.

Dzięki temu masz gwarancję zdobywania praktycznej wiedzy, którą od razu będziesz mógł wykorzystać w obecnej, bądź przyszłej pracy.

Pamiętaj, firmy nawiązują współpracę z uczelniami, ponieważ cenią sobie wartości, które dane uczelnia oferuje. Dla firm jest to również okazja do pozyskania potencjalnych pracowników, a dla Ciebie być może okazja zmiany na lepsze, bądź podjęcia stażu po zakończeniu studiów.

Sprawdź czy kierunek, który własnie wybrałeś realizowany jest po raz pierwszy, czy jest to kolejna edycja. Dzięki temu masz większą pewność, że uczelnia z każdą edycją dostosowuje swój program, bądź formę prowadzenia zajęć do potrzeb uczestników.

Wskazówka 3 – Łączna liczba godzin studiów

Studia podyplomowe to nie tylko teoria, ale przede wszystkim praktyka. Dlatego ważne jest, aby sprawdzić łączną liczbę godzin zajęć w ramach danego kierunku. Pamiętaj, że temat analizy jest dość obszerny. Jeśli chcesz poznać, uporządkować wiedzę oraz zweryfikować ją w praktyce sprawdź czy któraś z ofert uczelni w zakresie liczby godzin przeznaczone na zajęcia znacznie nie odbiega od pozostałych. Jeśli liczba godzin dydaktycznych jest mniejsza niż 150- warto zastanowić się czy jest to czas wystarczający na teorię i praktykę.

Wskazówka 4 – Program studiów

Przeanalizuj program studiów. Zwróć uwagę na formę zajęć: wykłady, warsztaty, ćwiczenia.

Jeśli jesteś początkującym analitykiem zwróć uwagę w jaki sposób ułożony jest program, czy stanowi po prostu zbiór przedmiotów, czy odwierciedla proces, w którym na co dzień będziesz uczestniczył.

Sprawdź co kryje się pod nazwą danego przedmiotu – takiej informacji powinien udzielić Tobie kierownik studiów (o ile nie została opublikowana na stronie).

A co z kwestiami technicznymi dla analityka?

Jeśli jeszcze nie wiesz czy chcesz pójść w stronę analizy biznesowej, czy rozwijać się w kierunku inżynierii wymagań skorzystaj z ofert, które kierowane są do obu tych grup. Nie bój się politechnik J Obecnie wiele z nich kieruje swoje programy do analityków biznesowych wprowadzając dodatkowe przedmioty, tak aby dostarczyć kompleksową wiedzę z zakresu analizy w projekcie IT.

Nie bój się, że sobie nie poradzisz. Wszelkie projekty, w jakich będziesz uczestniczyć są prowadzone w grupach ze wsparciem prowadzącego. Studia mają na celu wyjaśnienie Tobie wszystkich aspektów, jakie są potrzebne w analizie biznesowej, ale również systemowej. Pamiętaj, że studia podyplomowe na niektórych uczelniach mają formę warsztatów, więc swoją formułą bardziej zbliżone są do szkoleń, co powoduje, że przyswajanie wiedzy jest łatwiejsze.

Sprawdź czy program zawiera elementy umożliwiające podejście do certyfikatu. Jeśli nie ma takiej informacji oficjalnie na stronie, zapytaj bezpośrednio kierownika studiów.

Wskazówka 5 – Cena

Na cenę składa się wiele czynników:

– łączna liczba godzin dydaktycznych

– kadra

Im bardziej renomowana uczelnia, tym cena za studia może być wyższa (choć nie jest to regułą). Należy pamiętać, że im mniej godzin dydaktycznych, tym cena może być niższa.

Sprawdź czy dana uczelnia dopuszcza uiszczenie opłaty w ratach, które są mniejszym obciążeniem dla portfela Twojego, bądź firmy. Jeśli takiej informacji nie ma – zapytaj kierownika studiów, bądź osobę wskazaną do kontaktów.

Zestawienie propozycji studiów podyplomowych

Poniżej lista uczelni publicznych oraz niepublicznych, na których możesz znaleźć ofertę studiów podyplomowych kierowanych do analityków biznesowych, bądź inżynierów wymagań.

– Warszawa –

1. Politechnika Warszawska

Ranking uczelni – 3 miejsce wśród uczelni wyższych, 1 miejsce wśród uczelni technicznych,

Wydział Elektryczny

Inżynieria procesów biznesowych. Business Intelligence

Kierownik studiów: dr inż. Włodzimierz Dąbrowski

Łączna liczba godzin dydaktycznych: 188

Cena: 7950 zł ( możliwa płatność w 2 ratach)

Edycja: 4

Kontakt: sekretariat: Dorota Barańska, tel. 22 234 7615, e-mail: podyplomowe@isep.pw.edu.pl

Dla kogo:

Studia kierowane do analityków biznesowych, inżynierów wymagań oraz wszystkich tych, którzy rozpoczynają swoją przygodę z analizą w projektach IT. Jest to kompleksowe przygotowanie do pracy w zawodzie analityka biznesowego, ale również inżyniera wymagań.

Po ukończeniu studiów zdobędziesz wiedzę umożliwiającą podejście do certyfikatu: REQB poziom podstawowy (obecnie IREB) bez konieczności korzystania z dodatkowych szkoleń.

Studia adresowane są do osób, które zajmują się opisem, dokumentowaniem lub wsparciem procesów biznesowych oraz analityką biznesową i analizą danych w biznesie i chciałyby pogłębić swoją wiedzę, umiejętności i poznać narzędzia analizy biznesowej.

Studia są prowadzone metodami projektowymi z bardzo dużą liczbą warsztatów. Z tego powodu zajęcia prowadzone są w niewielkich grupach.

Wybrane zajęcia odbywają się metodą zdalną z wykorzystaniem platformy edukacyjnej. Student może dzięki temu dobrać tempo, czas pracy i zakres do własnych potrzeb.

Od kandydatów nie oczekiwana jest wiedzy baza ani doświadczenie informatyczne.

Ramowy program studiów: 

Temat l.godzin
Wprowadzenie do analizy biznesowej i inżynierii wymagań 16
Identyfikacja wymagań w projekcie 12
Opracowanie wymagań w projekcie 20
Modelowanie procesów biznesowych z wykorzystaniem BPMN 2.0 24
Opisywanie wymagań za pomocą notacji UML 32
Odkrywanie danych i wiedzy 16
Bezpieczeństwo danych w biznesie 12
SOA i rozwiązanie w chmurze 8
Optymalizacja procesów i decyzji biznesowych 8
Zastosowanie i projektowanie hurtowni danych 12
Seminarium dyplomowe 12
Wprowadzenie do baz danych 16
RAZEM 188

Współpraca:

Microsoft, Microstrategy,IBM, Stowarzyszenie Inżynierii Wymagań

Dodatkowe informacje:

W czasie studiów studenci mogą uczestniczyć w programach studenckich Microsoft MSDN AA, Oracle – Academy, IBM Academic Initiative, SAS, MicroStrategy

 

2. SGH

Analityk biznesowy – profesjonalista na styku IT i biznesu

Ranking uczelni – 12 miejsce wśród uczelni wyższych, 1 miejsce wśród uczelni ekonomicznych

Kierownik studiów: dr Przemysław Polak

Łączna liczba godzin dydaktycznych: 176

Cena: 7900 zł (możliwość płatności w 2 ratach)

Edycja: 9

Współpraca: brak informacji

 

3. Akademia Leona Koźmińskiego w Warszawie

Ranking uczelni – 15 miejsce wśród uczelni wyższych, 1 miejsce wśród uczelni niepublicznych

Zarządzanie wymaganiami i analiza biznesowa w projektach

Koordynator merytoryczny: dr Marcin Żmigrodzki

Łączna liczba godzin dydaktycznych: 180

Cena: 7900 (możliwość płatności w 2 ratach)

Współpraca:

OCTIGO

– Wrocław – 

1. Wyższa Szkoła Bankowa we Wrocławiu

Ranking uczelni –24 miejsce wśród uczelni niepublicznych

Zarządzanie wymaganiami i analiza biznesowa

Koordynator merytoryczny: dr Marcin Żmigrodzki

Łączna liczba godzin dydaktycznych: 128

Cena: 5300 zł (możliwość płatności w ratach)

Edycja: 4

Współpraca:

OCTIGO

– Gdańsk –

1. Politechnika Gdańska

Wydział zarządzania i ekonomii

Ranking uczelni – 10 miejsce wśród uczelni wyższych, 4 miejsce wśród uczelni ekonomicznych

Analiza procesów biznesowych w projektach IT

Kierownik studiów podyplomowych: prof. dr hab. Ewa Grzegorzewska-Mischka

Łączna liczba godzin dydaktycznych: 170

Cena: 3600 zł (możliwość płatności w 2 ratach)

Edycja: brak informacji

Współpraca: brak informacji

2. Wyższa Szkoła Bankowa w Gdańsku

Analiza biznesowa w IT

Ranking uczelni – 16 miejsce wśród uczelni niepublicznych

Opiekun merytoryczny: Karolina Zmitrowicz

Łączna liczba godzin dydaktycznych: 188

Cena: 3860 zł (możliwość płatności w ratach)

Edycja: brak informacji

Współpraca: brak informacji

– Poznań –

1. Wyższa Uczelnia Bankowa

Ranking uczelni – 17 miejsce wśród uczelni niepublicznych

Analityk biznesowy

Kierownik studiów podyplomowych: brak informacji

Łączna liczba godzin dydaktycznych: 168

Cena: 4150 zł (możliwość płatności w ratach)

Edycja: brak informacji

Współpraca: SII

 

 

Jeśli znasz kierunek, który tutaj nie został wymieniony – wpisz w komentarzu. Niech powstanie baza, z której każdy będzie mógł skorzystać. 

 

Powiadom mnie o zapisach

Dowiesz się, gdy tylko ruszą.

Szczegóły
Brak danych o cenie
Zarządzanie interesariuszami w projekcie – #1: Psychologia tłumu
Zapisy wkrótce

Interesariusz w projekcie jest osobą kluczową, bowiem to od niego zależy, jakie wymagania ostatecznie znajdą się w projekcie. Myśląc o najczęstszych błędach w analizie  w pierwszej kolejności będziesz szukał błędów w wymaganiach, zamiast zastanowić się jakie jest źródło błędu. I nie – nie jest to interesariusz. To ile mamy wymagań w danym projekcie, jakiej są jakości w dużej mierze (choć nie tylko) zależy właśnie od interesariuszy. Jak zebrać wymagania od interesariuszy, którzy nie chcą współpracować?

Interesariusze – są to osoby lub inne organizacje, które uczestniczą w tworzeniu projektu (biorą czynny udział w jego realizacji) lub są bezpośrednio zainteresowane wynikami jego wdrożenia. Interesariusze mogą wywierać wpływ na daną organizację” (Encykopedia zarządzania)

W swojej praktyce nie spotkałam się z sytuacją, kiedy na warsztatach analitycznych znaleźli się nieodpowiedni interesariusze. Owszem zdarzały się sytuacje, kiedy na warsztaty analityczne wysyłani byli zastępcy zastępców, bez możliwości podejmowania decyzji. Takie warsztaty nie będą efektywne, ponieważ ustalenia i tak trzeba będzie ponownie omówić z decyzyjnymi osobami. Najczęściej skończy się to ponowną analizą wymagań. Zdarzają się również sytuacje, kiedy na spotkaniu możesz porozmawiać jedynie z managerem działu, w którym modyfikowany będzie proces biznesowy. W pierwszej chwili Twoja radość nie ma końcu – przecież można będzie szybko podjąć decyzję co do rozwiązania zidentyfikowanego problemu. Radość bardzo szybko zamieni się w rozpacz, kiedy okaże się, że ów manager nigdy nie pracował operacyjnie i nie ma bladego pojęcia o szczegółach pracy jego podwładnych.

Jak rozmawiać, na co zwracać uwagę, aby spotkanie było efektywne? Jakie błędy popełniamy najczęściej?

#1: Diagnoza: Psychologia tłumu

Objaw 1: Nikt się nie zgadza z decyzją, ale wszyscy głosują za tym pomysłem

Przeprowadzasz spotkanie z interesariuszami – idzie Ci świetnie, głównie Ty mówisz, stawiasz tezy, których nikt z zebranych nie kwestionuje. Przechodzicie sprawnie przez kolejne punkty agendy spotkania (bo ją posiadasz prawda?), akceptując kolejne prezentowane przez Ciebie rozwiązania.

Kto ma dzieci ten wie, że jeśli w domu jest cicho to powinniśmy zacząć się martwić.

Taki sposób myślenia powinien mieć również analityk. Jeśli nikt nie poddaje w wątpliwość stawianych przez Ciebie tez, bez dyskusji proponowane rozwiązanie jest akceptowane możesz mieć do czynienia z dwoma przypadkami:

Przypadek 1: Interesariusz kompletnie nie rozumie co do niego mówisz

I wówczas jego aprobata wygląda tak:

Przypadek 2: Masz do czynienia z paradoksem Abilene.

Paradoks Abilene to sytuacja, kiedy grupa podejmuje decyzję, którą każdy z nich osobiście uważa za błędną, nawet szkodliwą, z którą się nie zgadza. Paradoks Abilene to nic innego jak psychologia tłumu. Taki interesariusz boi się ponieść ryzyko wyłamania się z grupy, która się zgodziła z rozwiązaniem.

W 1974 roku Jerry Harvey po raz pierwszy użył określenia „paradoks Abilene”. Pojawienie się artykułu wywołało dużą burzę w całej Ameryce. Harvey obserwując pewną sytuację rodzinną zauważył, że sytuacje, w których nie chcemy w ogóle uczestniczyć żyją własnym życiem. Zauważył, że podobny efekt możemy zauważyć również w korporacjach, kiedy strach przez odrzuceniem przez grupę jest silniejszy od pracy nad dostarczeniem wartości biznesowej dla projektu. Przez co organizacje takie skazują się na porażkę tracąc czas na projektu, które nikomu nie służą.

Antidotum:

W pierwszej sytuacji, kiedy nie masz pewności, że interesariusz, bądź interesariusz Cię zrozumiał wykonaj następujące kroki:

  1. Poproś o parafrazę Twoich słów, aby upewnić się, że na pewno się rozumiecie
  2. Rozmawiaj i wyjaśniaj interesariuszowi tak długo póki nie będziesz mieć pewności, że myślicie i mówicie o tym samym.
  3. Pamiętaj, aby używać zwrotów, słów, które interesariusz dobrze zna. Skorzystaj ze słownika pojęć, bądź zbuduj go wspólnie z interesariuszem.

W drugiej sytuacji, kiedy podejrzewasz, że działa psychologia tłumu podczas spotkań wykorzystaj jeden ze sposobów:

  1. Anonimowe głosowanie w czasie podejmowania decyzji
  2. Zaproponowanie kilka rozwiązań z koniecznością wyboru jednego z nich
  3. Przed spotkaniem zadaj interesariuszom pytania wspierające:
    1. Jak wygląda twoja praca- wypisz krok po kroku, jakie zadania musisz wykonać. Jeśli możesz wskaż aktywności wykonywane przez system.
    2. Co w procesie obecnie sprawia Tobie największą trudność, z czym masz najwięcej problemów?
    3. Czy istnieją czynności, dla których nie ma funkcjonalności w systemie, a musisz wykonywać je regularnie?
    4. Kto korzysta z wyników twojego działania?
    5. Czy do wykonania swojego zadania musisz czekać na wynik pracy kogoś z twojego działu, bądź innego pracownika firmy? Jeśli tak wskaż dział i co musisz otrzymać, aby rozpocząć swoje zadanie.

Powyższe pytania pozwolą Tobie uniknąć sytuacji stresującej interesariuszy podczas spotkania. Podczas spotkania możesz bazować na wynikach takiej ankiety. Od razu możesz zdiagnozować czy pojawiły się sprzeczne wymagania, czy na podstawie przekazanych informacji jesteś w stanie rozrysować proces biznesowy?
Powiadom mnie o zapisach

Dowiesz się, gdy tylko ruszą.

Szczegóły
Brak danych o cenie
Zarządzanie interesariuszami w projekcie -#2 Trudny interesariusz
Zapisy wkrótce

W poprzednim artykule z cyklu: “Zarządzanie interesariuszami w projekcie” przedstawiliśmy 5 roków jak radzić sobie w sytuacji, kiedy mimo wewnętrznego sprzeciwu interesariusze zgadzają się ze swoim przedmówcą.

W tym artykule poruszymy temat ogólnie pojętego “trudnego interesariusza”.

#2: Diagnoza: Trudny interesariusz

Sztuką nie jest zidentyfikowanie wymagań od interesariuszy silnie nakierowanych na cel. Celem takim może być usprawnienie swojego procesu biznesowego poprzez wdrożenie nowych funkcjonalności w istniejącym systemie, bądź wdrożenie nowego rozwiązania. Przyjemnie współpracować z interesariuszami, którzy są gotowi odpowiedzieć na każde zadane przez nas pytanie, dostarczają pełne opisy procesów biznesowych, są cały czas dostępni, a na spotkaniach bardzo aktywni.  Jak sobie poradzić z „trudnym” interesariuszem?

Objaw 1: Dominator

Osoba, która chce pokazać, że jej wymagania są ważniejsze od wymagań innych uczestników spotkania. Często przerywa rozmowę, narzuca swoje rozwiązania. Czasem jest to osoba, która jest hakerem excela i trudno jej zrozumieć, że aplikacja nie działa tak jak excel, który tak żmudnie tworzył przez lata, aby innym żyło się lepiej. Dominator często przerywa wypowiedzi innych uczestników spotkania, ostatnie słowo należy do niego. Przy takim uczestniku, pozostali nie mają już takiej śmiałości w wygłaszaniu swoich oczekiwań, o krytyce naszego dominatora nie wspominając.

Antidotum:

Wykorzystaj jedną z metod:

  1. Podziękuj za cenne informacje wzbogacające dyskusję

Jeśli zadamy kolejne pytanie grupie interesariuszy i po raz kolejny w pierwszej kolejności odpowie dominator  – podziękuj mu za cenne informacje i zwróć się bezpośrednio do innej osoby z pytaniem: „A co Ty o tym sądzisz?”. Możemy zapytać grupę, bądź poszczególne osoby.

Jednak jeśli zobaczymy, że interesariusze są jeszcze bardziej wycofani, skorzystaj z metody 2:

  1. Ruch wyprzedzający

Wyprzedź ruch naszego dominatora zadając bezpośrednie pytanie interesariuszowi, bądź grupie interesariuszy . Jeśli zachowanie interesariuszy będzie analogiczne jak w metodzie 1, pozostaje nam metoda 3:

  1. Dobrodziejstwo technik identyfikacji wymagań

Skorzystaj z dobrodziejstwa wielu technik identyfikacji wymagań. Skoro 2 metody zawiodły, oznacza to, że być może warsztaty analityczne nie są w tym przypadku najlepszym rozwiązaniem. Rozmawiaj z każdą grupą z osobna. Uwaga! Grupę z naszym hakerem zostaw na końcu. Jeśli poznasz oczekiwania pozostałych interesariuszy, łatwiej Ci będzie zrozumieć o co chodzi naszemu dominatorowi, bądź przekonać go do racji większej grupy interesariuszy. Jeśli istnieje taka możliwość to rozmawiaj z dominatorem bez grupy (zastosuj technikę przeprowadzenia wywiadu, obserwacji jego pracy).

Najczęściej okazuje się, że pokazywane przez dominatora sposoby działania mają swoje uzasadnienie, dlatego pozwól mu się wypowiedzieć podczas takiej indywidualnej sesji, aby lepiej zrozumieć co chce nam faktycznie przekazać.

Objaw 2: “Wiecznie w niedoczasie”

To osoba, która spóźnia się na spotkania. Samo spóźnianie się na spotkania oprócz tego, że jest okazaniem braku szacunku do pozostałych uczestników spotkania nie jest zbrodnią z punktu widzenia prowadzącego owe spotkanie. Problemem jest to, że w trakcie spotkania „spóźnialski” rozprasza grupę zadając pytania o elementy omawiane podczas jego nieobecności.

Antidotum:

W zależności od tego czy spotkania są cykliczne czy jednorazowe możesz skorzystać z kilku metod:

  1. Spotkania jednorazowe:
    1. Na początku spotkania sprawdź kogo z zaproszonych interesariuszy nie ma na spotkaniu,
    2. Sprawdź czy osoba, której nie ma jest kluczowa w tej fazie omawiania procesu:
      1. Jeśli jest kluczowa spróbuj omówić (o ile to możliwe) etapy, w których uczestniczą obecni interesariusze,
      2. Jeśli nie jest to kluczowa osoba – przeprowadź spotkanie zgodnie z przygotowaną przez Ciebie agendą. Kiedy „spóźnialski” pojawi się na spotkaniu przekaż krótko informację na jaki temat rozmawiacie. Jasno zaznacz, że omawiane procesy nie dotyczą go bezpośrednio, więc jeśli ma pytania będzie mógł je zadać podczas przerwy.
    3. Spróbuj się skontaktować z tą osobą, aby dowiedzieć się ile wyniesie spóźnienie, jeśli możesz poczekać 5 minut, spróbuj wprowadzić interesariuszy w temat, rozpocznij omawianie agendy, zasad prowadzenia spotkania. Jeśli spóźnienie będzie dłuższe niż 5 minut sprawdź elementy wg pkt b).
  2. Spotkania cykliczne:
    1. Umów się z interesariuszami o tyle minut wcześniej, ile potrzebuje nasz „spóźnialski” na dotarcie na spotkanie. Dzięki temu będzie on na czas, a ty będziesz w stanie rozpocząć punktualnie spotkanie,
    2. Poproś, aby „spóźnialski” miał swojego „skrzydłowego”, czyli osobę z działu, która również będzie uczestniczyć w spotkaniu. Dzięki temu nie masz obawy, że jakieś wymagania zostaną pominięte. Dodatkowo „skrzydłowy” będzie w stanie szybko przekazać o czym mowa używając skrótów dobrze znanych biznesowi.

Objaw 2: “Zadaniowiec”

Osoba, która nie rozstaje się z telefonem, laptopem nawet podczas spotkań. Sprawdza maile, odpisuje, odrzuca połączenia telefoniczne, bądź co gorsza co chwilę wychodzi ze spotkania, bo otrzymała „pilny telefon”. Najlepiej byłoby nie zapraszać takiej osoby na spotkania, ale najczęściej jest to osoba kluczowa w omawianym procesie.

Antidotum:

W pracy z taką osobą wykorzystaj kilka metod (metody ułożone w kolejności intensywności „nacisku”):

  1. Cisza

Staraj się robić dłuższe przerwy w wypowiedziach, aby zwrócić uwagę „zadaniowca”. Przynajmniej na jakiś czas „zadaniowiec” oderwie się od pilnych zadań. Jeśli sytuacja się nie poprawi przejdź do kroku 2.

  1. „Jesteś blisko mnie”

Jeśli spotkanie wymaga od Ciebie stania – super! Podchodź do naszego „zadaniowca”, staraj się „ krążyć” wokół niego. Jeśli mimo niewerbalnego „nacisku” sytuacja się nie poprawi przejdź do kroku 3.

  1. „Im mniej tym lepiej”

Poproś o odłożenie oraz wyciszenie telefonu, nie korzystanie z laptopa podczas spotkania (jeśli wysyłane są e-maile), ponieważ rozprasza to grupę. Zaproponuj, że możesz zaprosić tą osobę na część, w trakcie której będą omawiane zagadnienia bezpośrednio jej dotyczące.

Objaw 4: „Milczek”

Osoba, która wykazuje minimalną aktywność podczas spotkania, bądź nie wykazuje jej wcale. Nie zajmuje żadnego stanowiska, jest wycofany.

Antidotum:

Czasem milczenie wynika z charakteru danej osoby, postaraj się bezpośrednio zwracać się do „milczka” z konkretnym pytaniem. Jeśli nadal będzie wycofany spróbuj zorganizować z nim dodatkowe spotkanie np. przy jego biurku, aby pokazał Ci, jakie czynności wykonuje w danym procesie. Być może takiej osobie łatwiej jest pokazać czynności niż o nich opowiedzieć. Staraj się nawiązywać kontakt niewerbalny z taką osobą – uwierz mi uśmiech może zdziałać cuda !

 

A Ty z czym masz najczęściej problem w pracy z interesariuszami? Może masz nowe typy osobowości, których nie ma na liście? Podziel się przemyśleniami w komentarzu.
Powiadom mnie o zapisach

Dowiesz się, gdy tylko ruszą.

Szczegóły
Brak danych o cenie
Identyfikacja interesariuszy
Zapisy wkrótce

Mówiąc o „interesariuszu”/”Użytkowniku” możemy mówić o pojedynczej osobie, roli, bądź grupie użytkowników. Każdy interesariusz nie jest wolnym elektronem, który samodzielnie funkcjonuje w organizacji. Jest powiązany z innymi interesariuszami, którzy korzystają z jego wyników pracy, bądź sami dostarczają mu dane wejściowe umożliwiające realizację jego podstawowych czynności.

Na spotkaniu z Klientem można usłyszeć: „Użytkownik powinien mieć możliwość……”, „System powinien powiadomić Użytkownika o…..”. Czy zawsze chodzi o tego samego użytkownika? Ilu tak naprawdę użytkowników mamy w projekcie? W jaki sposób ich zidentyfikować, aby nikogo nie pominąć?

(więcej…)

Powiadom mnie o zapisach

Dowiesz się, gdy tylko ruszą.

Szczegóły
Brak danych o cenie
Kompetencje analityka wg. modelu T
Zapisy wkrótce

Zawód inżyniera wymagań (analityka biznesowo-systemowego) wymaga kompetencji miękkich, ale również technicznych. Trudno oczekiwać od inżyniera wymagań, że dobrze będzie pełnił swoją rolę w projekcie bez odpowiedniego doświadczenia, umiejętności oraz wiedzy.

Nie będzie on w stanie dobrze wykonać swojej pracy, co więcej będzie ona prowadziła do coraz większej frustracji. Inżynier wymagań musi wiedzieć jakie techniki identyfikacji wymagań zastosować w zależności od projektu, czy Klienta. Musi umieć zaprezentować wymagania tak, aby były one zrozumiałe dla Klienta, programisty, testera. Nie zawsze bowiem język naturalny oddaje to, co chcemy przekazać w dokumencie z listą wymagań.

Czym jest model kompetencji T?

Model ten wspomaga budowanie interdyscyplinarnego zespołu IT, poprzez łączenie ludzi z wzajemnie uzupełniającymi się kompetencjami.

Koncepcja kompetencji według litery “T” po raz pierwszy została zaproponowana przez Davida Guesta w 1991 roku. Później była popularyzowana przez Tim’a Browna- CEO firm IDEO. Model kompetencji “T”  jest odpowiedzią na liczne problemy ówczesnego świata z wąskim zakresem specjalizacji bez kompetencji tzw. “Miękkich”, co znacznie utrudniało skuteczną komunikację między zespołami. Od tamtej pory powstały rozszerzenia litery “T”, które są dostosowywaniem modelu to coraz większych wyzwań na rynku.

umiejętności analityka
Opracowanie własne, www.analizawymagan.pl, Kliknij, aby powiększyć

Model “T” posiada dwa elementy:

  • Część pionowa– reprezentuje rdzeń, specjalistyczne zdolności oraz umiejętności, które tworzą specjalizację w danej dziedzinie. W tej części rozwijamy się w kierunku juniora, starszego analityka i seniora w zależności od wiedzy oraz lat doświadczenia.
  • Część pozioma– reprezentuje szerszy zakres umiejętności zastosowania wiedzy w różnych sytuacjach. Umiejętności te możemy podzielić na 2 grupy:
    • Umiejętności indywidualne wynikające z naszych naturalnych predyspozycji:  radzenie sobie ze stresem, zdolności poznawcze (myślenie, rozumienie, przetwarzanie danych, koncentracja czy pamięć), empatia.
    • Umiejętności dyscyplinarne, czyli ogólne umiejętności umożliwiające ich zastosowanie w różnych sytuacjach. Są to umiejętności głównie nabyte.

W 2001 roku przez Morten Hansen oraz Bolko von Oetinger, którzy zaproponowali model zarządzania w kształcie litery T. Stwierdzili bowiem, że najbardziej skuteczni dyrektorzy firmy to osoby, które w swojej specjalizacji (”core”- pionowa część) mieli wiedzę z zarządzania organizacją. Posiadali również ogólną wiedzę o działalności organizacji, czyli analizę biznesową, dzięki czemu pozwoliła im skuteczniej działać (pozioma część litery T).

Kompetencje programowania, testowania i analizowania w jednym

T_analityk_tester
Kliknij, aby powiększyć

Na rysunku możemy zaobserwować, że w przypadku analityka (tutaj w rozumieniu inżyniera wymagań) ogólnymi umiejętnościami jest testowanie oraz predyspozycje do programowania. Jedna i druga umiejętność jest ściśle związana z analizowaniem, zatem oznacza to, że przy silnych umiejętnościach testerskich, może ona zastąpić w pewnym stopniu testera.

Zależność ta również pozwala testerowi na przejęcie zadań analitycznych, bądź programistycznych. Nie mówimy tylko i wyłącznie o zastępowaniu, ale głównie o wykorzystywaniu tych umiejętności w zespole. Model ten szczególnie widoczny jest w zespołach zwinnych, gdzie nie mamy roli analityka, testera czy programisty lecz mamy osoby o umiejętnościach analitycznych, testerskich czy programistycznych.

Koncepcja modelu umiejętności w kształcie litery “T” została nie tylko zastosowana do wielu ról, ale powstało wiele jej wariantów. Inne rozszerzenia profilu w kształcie litery “T” to kształt litery “Pi”- osoba z dwoma głębokimi specjalizacjami, bądź “Grzebień” (litera M),  gdzie tych specjalizacji jest więcej niż w przypadku “Pi”. Osobą w modelu “Pi” jest właśnie inżynier wymagań, ponieważ posiada on 2 specjalizacje: analiza biznesowa oraz inżynieria wymagań. Jego ogólnymi umiejętnościami mogą być umiejętności jak w przypadku klasycznego modelu: “T”.

Kompetencje wg. modelu E

E-shape
Kliknij, aby powiększyć

Od 2010 roku mamy do czynienia z modelem “E”, w ramach którego łączy się doświadczenie, wiedzę, eksplorację i realizację. Eksploracja rozumiana jako ciekawość, bez której trudno mówić o innowacyjnych rozwiązaniach. Eksploracja jest wpisana w DNA analityka biznesowego oraz inżyniera wymagań, ponieważ szukamy odpowiedzi na pytanie: “Dlaczego tak się dzieje”. Następnie szukamy coraz lepszych rozwiązań na realizację danego zagadnienia, usprawniamy procesy, proponujemy innowacyjne rozwiązania.

Dlaczego ważne jest równomierne rozwijanie kompetencji “T”?

W firmach zatrudniamy różne osoby o różnych umiejętnościach. Największy problem pojawia się wtedy, kiedy zaczynamy łączyć te osoby w zespoły, aby wspólnie rozpracowały problem. W przypadku zatrudnienia osób wyspecjalizowanych jedynie w swojej specjalizacji (część pionowa) trudno będzie im osiągnąć współpracę, ponieważ nie mają rozwiniętych, bądź mają słabo rozwinięte umiejętności facylitacji, empatii, radzenia sobie ze stresem. Każda osoba z takiego zespołu reprezentuje wówczas swój punkt widzenia, który w zależności od swojej pozycji w firmie, bądź braku kontrargumentów jest w stanie przeforsować w zespole. Prowadzi to do uzyskania rozwiązań ze średniej półki. W facylitacji powiedzielibyśmy, że taka grupa jest dysfunkcyjna.

Podobna sytuacja jest w przypadku, kiedy umiejętności ogólne (część pozioma) są rozwinięte, lecz doświadczenia brak, bądź jest niewielkie (część pionowa). Trudno w takim przypadku oczekiwać spektakularnych rezultatów, jeśli brakuje w grupie doświadczenia, czy dobryk praktyk. W takiej sytuacji same chęci nie wystarczą. W takiej sytuacji takie osoby mogą pełnić rolę facylitatora w grupie. Nie jest on specjalistą z danej dziedziny, ale ma wysoko rozwinięte umiejętności komunikacyjne, pracy z grupą, empatię oraz jest w stanie tak pracować z grupą, aby sama wypracowała najlepsze rozwiązanie.

Dlatego tak ważne jest równomierne rozwijanie kompetencji specjalistycznych, ale również tzw. miękkich.

Kompetencje stanowiące rdzeń- specjalizację

Umiejętności rdzeń
Kliknij, aby powiększyć

Część pionowa oznaczająca rdzeń mówi o głębokiej wiedzy w wąskim obszarze, naszym autorytecie w danej dziedzinie, wieloletniego doświadczenia popartego praktyką. Suma tych elementów składa się na postrzeganie nas jako niezbędnych w firmie.

Do tej grupy należą:

  • ANALIZA PRZEDSIĘBIORSTWA
  • MODELOWANIE PROCESÓW BIZNESOWYCH
  • PLANOWANIE I MONITOROWANIE
  • IDENTYFIKACJA WYMAGAŃ
  • IDENTYFIKACJA POTRZEB INTERESARIUSZY
  • ANALIZOWANIE WYMAGAŃ
  • ZARZĄDZANIE WYMAGANIAMI
  • WALIDACJA ROZWIĄZANIA
  • DOKUMENTOWANIE WYMAGAŃ
  • ŚLEDZENIE POWIĄZAŃ

Kompetencje ogólne- profesjonalne

ogólne umiejętności
Kliknij aby powiększyć

 

Wiedza to nie wszystko, bardzo ważne są umiejętności tzw. “miękkie”. Umiejętność przekazywania wiedzy, czy negocjacji, dobierania odpowiedniego sposobu formułowania przekazu są niezwykle kluczowe w pracy analityka biznesowego, czy inżyniera wymagań. W kompetencjach ogólnych, czyli części pionowej w modelu “T” znajdujemy grupę umiejętności – umiejętności profesjonalne. Są to umiejętności dyscyplinarne związane z poziomami inteligencji emocjonalnej: samoświadomość, samozarządzanie, świadomość sytuacyjna, zarządzanie relacjami. Są to kluczowe umiejętności dla każdej grupy zawodowej.

Na tej liście znajdziemy następujące kompetencje:

  • INTELIGENCJA EMOCJONALNA
  • FACYLITACJA
  • NEGOCJACJA
  • ROZWIĄZYWANIE PROBLEMÓW
  • PRZEKAZYWANIE WIEDZY
  • ZARZĄDZANIE ZMIANĄ
  • ZARZĄDZANIE INTERESARIUSZAMI
  • UMIEJĘTNOŚCI PREZENTOWANIA WYNIKÓW
  • ZARZĄDZANIE RYZYKIEM
  • KOMUNIKACJA

Dzięki umiejętnościom inteligencji emocjonalnej jesteśmy w stanie znaleźć kompromisy, wywierać wpływ oraz zarządzać konfliktami.

Kompetencje ogólne- indywidualne

indywidualne
Kliknij, aby powiększyć

Stres, nadmiar zadań to główne czynniki uniemożliwiające efektywne wykorzystanie umiejętności specjalizacyjne (pionowa część, “core”). Tempo pracy nad projektami wymusza uaktywnienie się wśród niektórych zachwianie balansu między pracą I życiem prywatnym. Z jednej strony kończymy pracę, lecz odpowiadamy na maile firmowe nawet po godzinach pracy, problem przetwarzamy nawet po zakończeniu pracy. Jeśli dodamy do tego czas pracy możemy powiedzieć, że ciągle jesteśmy w pracy, co powoduje, że ostatecznie jesteśmy nieefektywni. Z drugiej strony ze względu na to, że mamy silnie wykształcone umiejętności specjalizacyjne (część pionowa), nie możemy być tak łatwo zastąpieni w pracy. Dlatego tak ważne jest rozwijanie umiejętności ogólnych z dwóch obszarów: indywidualnych predyspozycji oraz umiejętności profesjonalnych.

Na liście tej znajdziemy następujące kompetencje:

  • EMPATIA
  • KREATYWNE MYŚLENIE
  • UMIEJĘTNOŚĆ RADZENIA SOBIE ZE STRESEM
  • KONCENTRACJA
  • ZDOLNOŚCI ANALITYCZNE
  • UMIEJĘTNOŚĆ UCZENIA SIĘ
  • SPOSTRZEGAWCZOŚĆ
  • ZDOLNOŚCI ORGANIZACYJNE
  • ZARZĄDZANIE EMOCJAMI
  • UMIEJĘTNOŚĆ PODEJMOWANIA DECYZJI

 

Zatem nasz model kompetencji “T” analityka, inżyniera wymagań prezentuje się następująco (kliknij, aby powiększyć).

model T kompetencji analityka

 

 

 

Rola analityka biznesowego się zmienia, rola inżyniera wymagań jest coraz bardziej widoczna w projektach. Dlatego tak ważne jest rozpoznanie umiejętności, jakie są potrzebne do odniesienia sukcesu w projektach.

O ile umiejętności techniczne jesteśmy w stanie szybko przyswoić, o tyle umiejętności miękkie to lata pracy nad sobą. Jednak dopiero równomierne rozwijanie kompetencji z części pionowej oraz poziomej modelu “T” powodują, że stajesz się ekspertem wysokiej klasy.

Powiadom mnie o zapisach

Dowiesz się, gdy tylko ruszą.

Szczegóły
Brak danych o cenie
Jak zostać analitykiem biznesowym?
Zapisy wkrótce

Jak zostać analitykiem biznesowym? Pytanie to każdy z nas zadał sobie chociaż raz w życiu, jeśli interesował się analizą w projektach, bądź chciał się przekwalifikować.

Kariera analityka biznesowego jest dobrym początkiem, jeśli chce się wejść w świat technologii, szczególnie w przypadku, kiedy jesteśmy na początku kariery tuż po ukończeniu uczelni wyższej.
Według barometru zawodowego prognozującego zmianę zapotrzebowania na pracowników- “analitycy, testerzy” na rok 2018 tylko w 3 województwach mamy stały poziom zapotrzebowania, w pozostałych województwach następuje wzrost, bądź szybki wzrost zapotrzebowania na te zawody. Oznacza to, że zawód ten należy do grupy zawodów deficytowych, czyli takich, dla których w najbliższym roku nie powinno być trudności ze zalezieniem pracy, ponieważ zapotrzebowanie pracodawców będzie w ich przypadku duże.

Najlepsi analitycy biznesowi mają różne wykształcenie oraz rozmaite doświadczenie zawodowe. Aby stać się analitykiem należy zdobywać wiedzę, wykorzystywać ją w praktyce oraz , rozwijać swoje umiejętności .
W artykule przedstawiam pierwsze kroki, które są wskazówką w staniu się analitykiem.

Krok 1: WIEDZA: Zrozum rolę analityka biznesowego w projekcie

Zgodnie z definicją BABOK (przyp. A Guide to the Business Analysis Body of Knowledge):

“Analityk biznesowy to osoba odpowiedzialna za identyfikację potrzeb biznesowych swoich klientów i zainteresowanych stron w celu określenia rozwiązań problemów biznesowych.”

Wychodząc od tej definicji mamy opis roli analityka biznesowego w projekcie. Niestety na przestrzeni lat rozumienie roli analityka biznesowego w projektach IT mocno zostało zniekształcone. Dlatego pojawiły się niejasności czym tak naprawdę analityk biznesowy zajmuje się w projekcie.

Potrzeba lepszego zrozumienia potrzeb biznesu i wspierania zespołu deweloperskiego w zrozumieniu jakie zmiany w systemie należy stworzyć spowodowało powstanie nowych stanowisk: “analityk systemowy”, “architekt biznesu”, “analityk IT” czy “analityk biznesowo-systemowy”. Ten ostatni to określenie inżyniera wymagań, czyli osoby, która podobnie jak analityk biznesowy łączy świat biznesu i świat IT. W przeciwieństwie do analityka biznesowego dobrze rozumie logikę systemów, zna relacyjne bazy danych, dzięki czemu łatwiej mu się porozumieć z programistami.

Analityk biznesowy odpowiada na pytanie CO system powinien robić, inżynier wymagań dodatkowo szuka odpowiedzi na pytania: JAK ta funkcja ma działać oraz W JAKI SPOSÓB system ma być skonstruowany. Oczywiście inżynier wymagań nie powie programiście jakiej funkcji użyć do napisania linijki kodu, lecz będzie skupiał się na dostarczeniu rozwiązania dla Klienta.

Dlatego tak ważne jest, aby w pierwszym kroku zastanowić się, która droga jest Tobie bliższa. Główną rolą analityka biznesowego jest analiza procesów biznesowych w firmie, identyfikacja bieżących oraz potencjalnych problemów oraz działanie jako pomost między klientem a innymi zainteresowanymi stronami.
Odgrywa on centralną rolę w gromadzeniu oraz przekazywaniu informacji o produkcie. Analityk powinien przede wszystkim rozumieć cele biznesowe projektu, po czym zdefiniować wymagania użytkowników, wymagania funkcjonalne oraz pozafunkcjonalne, co pozwoli oszacować oraz zaplanować projekt. To co jest ważne to fakt, iż analityk biznesowy NIE JEST odpowiedzialny za określenie implementacji rozwiązania, czyli tego co zostanie zaprogramowane w systemie, aby korzystać z niego w sposób oczekiwany przez Klienta.
Analityk biznesowy wspiera biznes w osiąganiu celów, które dekomponuje na wymagania biznesowe, funkcjonalne oraz ograniczenia, inżynier wymagań wkracza później, ponieważ skupia się na doprecyzowaniu wymagań systemowych.

Jeśli zatem Twoją mocną stroną nie są systemy, nie czujesz się w tej tematyce jak ryba w wodzie, ale lubisz dreszczyk emocji związany z pozyskiwaniem informacji od Klienta, wspólne wypracowanie co system ma wykonywać, lubisz wspólnie z klientem zastanawiać się nad mocnymi i słabymi stronami produktu to zapewne Twoją drogą jest analiza biznesowa.

Jeśli lubisz dodatkowo wgryzać się w zawiłości systemów, lubisz analizować zależności w bazach danych, sprawia Ci radość sprawdzanie jak nowa funkcjonalność systemowa wpływa na dotychczasowe funkcje, to z dużym prawdopodobieństwem Twoją drogą jest bycie inżynierem wymagań, czyli analitykiem biznesowo-systemowym.

Bez względu na to, którą ścieżkę wybierzesz będziesz ANALITYKIEM w projekcie 🙂 Różnica między analitykiem biznesowym a inżynierem wymagań sprowadza się do poziomu szczegółowości w analizie projektu, bowiem zadania wykonują takie same.

KROK 2: WIEDZA: Zapoznaj się z zadaniami analityka

Analityk biznesowy powienien w pierwszej kolejności rozumieć cele biznesowe projektu, dzięki czemu będzie potrafił zdefiniować wymagania użytkowników, wymagania funkcjonalne oraz pozafunkcjonalne.

Poniżej zaprezentowanych zostało 10 podstawowych zadań analityka biznesowego:

1. Identyfikowanie interesariuszy projektu
2. Pozyskiwanie wymagań
3. Definiowanie wymagań biznesowych
4. Analiza wymagań
5. Dokumentowanie wymagań
6. Dostosowywanie sposobu przekazywania wymagań
7. Walidacja wymagań
8. Wspieranie zespołu w priorytetyzacji wymagań
9. Zarządzanie wymaganiami
10. Planowanie podejścia do wymagań

Krok 3: UMIEJĘTNOŚCI: Sprawdź, jakie masz umiejętności

Zawód analityka wymaga kompetencji technicznych, ale również miękkich. Nie możemy oczekiwać, że będziemy dobrzy tylko na podstawie tego, że nie mamy problemu z nawiązaniem konwersacji. To niestety bardzo często nie wystarcza. Analityk powinien wiedzieć jakie techniki identyfikacji wymagań dobrać w zależności od rodzaju interesariusza.

W jaki sposób zaplanować podejście do analizy wymagań, aby efektywnie wykorzystać zaplanowany przez kierownika projektu czas. Dlatego tak ważne jest zrozumienie, jakie umiejętności powinien posiadać analityk.

Zapoznaj się z nimi i sprawdź, które z nich musisz uzupełnić, bądź rozwinąć.

1. Umiejętność słuchania
2. Umiejętność rozmawiania i zadawania pytań
3. Umiejętność szybkiego podejmowania decyzji
4. Zdolności analityczne
5. Myślenie w kategoriach systemów
6. Umiejętność uczenia się
7. Umiejętności facylitacji
8. Zdolności przywódcze
9. Spostrzegawczość
10. Umiejętności komunikacyjne
11. Zdolności organizacyjne
12. Umiejętność tworzenia modeli
13. Kreatywność
14. Umiejętności interpersonalne

Jeśli jesteś subskrybentem uzupełnij kwestionariusz z predyspozycjami umiejętności, który otrzymałeś na maila po uzupełnieniu i odesłaniu go otrzymasz indywidualną analizę oraz wskazówki, które z umiejętności uzupełnić, bądź rozwijać.

Krok 4: WIEDZA, UMIEJĘTNOŚCI: Rozwijaj swoje kompetencje poprzez konferencje, spotkania biznesowe

Nie wystarczy poznać swoje umiejętności, czy przeczytać BABOK. Chcąc poznać pracę od podszewki staraj się rozwijać i dowiadywać jak z problemami radzą sobie inni analitycy. Taka nauka jest cenna szczególnie od tych, którzy pracują w tym zawodzie co najmniej 5 lat. Obecnie dla analityków organizowanych jest sporo darmowych wydarzeń, z których można skorzystać. Większość organizowanych wydarzeń dostępnych jest na platformie FB.
Jeśli śledzisz nasz kanał na FB to w sekcji: “Wydarzenia” zbieram te wydarzenia, na które warto pójść.

Warto włączyć się również w aktywne działanie społeczności analityków w Polsce. Będąc w stowarzyszeniu nie tylko poznajesz innych analityków, ale przede wszystkim tworzysz społeczność. W Polsce od 2014 roku aktywnie działa pierwsze stowarzyszenie skupiające analityków biznesowych, ale również inżynierów wymagań- Stowarzyszenie Inżynierii Wymagań (www.siw.org.pl).

SIW logo
Stowarzyszenie jako pierwsze w Polsce zorganizowało Konferencję Inżynierii Wymagań i Analizy Biznesowej (www.kiwab.pl), która co roku skupia ponad 100 uczestników na warsztatach i prelekcjach.

Od tego czasu powstały inne konferencje, czy wydarzenia kierowane dla analityków, m.in konferencja beIT organizowana w Gdańsku, czy ReQtest organizowana przez SJSI.

Krok 5: Zdobądź certyfikat, bądź ukończ szkolenie potwierdzające Twoją wiedzę i umiejętności

Jeśli pracujesz już jako analityk Twoje doświadczenie stanowi Twoją przewagę. Jeśli chcesz zostać analitykiem biznesowym dobrze zainwestować w kurs poświadczający Twoją wiedzę, bądź certyfikat.
W przypadku certyfikatów dla analityków biznesowych na porządkującym podstawy mamy:

  • IQBBA 

Certyfikacja wg. IIBA (przyp. IIBA to ogólnoświatowa organizacja skupiająca analityków biznesowych):

  • Certification of Competency in Business Analysis (CCBA)
  • Certified Business Analysis Professional (CBAP).

Powyższe certyfikaty porządkują wiedzę z zakresu analizy biznesowej.

Dla inżynierów wymagań (analityk biznesowo-systemowy) to obecnie jedna ścieżka certyfikacyjna- IREB.

Na początek wystarczy, że po prostu ukończysz kurs, który poświadczy Twoją wiedzę. Na pewno jest to mniejszy wydatek niż certyfikat.

Dobrym rozwiązaniem jest również ukończenie studiów podyplomowych dla analityków biznesowych.

Oferujemy szkolenia z zakresu:

Krok 6: DOŚWIADCZENIE: Znajdź firmę, w której możesz się uczyć i rozwijać

Mając już ukończony kurs, bądź zdobyty certyfikat warto znaleźć firmę, która wspiera rozwój swoich pracowników. Wsparcie nie tylko poprzez szkolenia, ale przede wszystkim poprzez wewnętrzne spotkania dla analityków. W ramach takich spotkań analitycy wymieniają się swoim doświadczeniem, ale również wspólnie np. Przygotowują się do certyfikatów, czy doskonalą swoje umiejętności.

Firmy stosujące takie praktyki: Asseco Poland, Asseco Data Systems, Comarch, Pentacomp, Comarch, Roche.
Jeśli znasz ich więcej koniecznie napisz o nich w komentarzu.

Pierwsze kroki wydają się proste, ale najtrudniej wykonać pierwszy krok, dlatego do dzieła !

 

Ten artykuł otwiera cykl artykułów poświęconych pierwszym krokom w zostaniu analitykiem. Jeśli jesteś ciekawy dalszego ciągu zapisz się do newslettera, bądź napisz, które tematy dla Ciebie będą najbardziej interesujące.

Powiadom mnie o zapisach

Dowiesz się, gdy tylko ruszą.

Szczegóły
Brak danych o cenie
Tworzenie produktów bez udziału interesariuszy- historia WoobyKids
Zapisy wkrótce

Tworzenie produktów bez udziału interesariuszy to wyzwanie dla wielu firm. Jak wygląda proces identyfikacji wymagań, kto tak naprawdę odbiera taki produkt? Czy produkt to tylko działające oprogramowanie czy też coś więcej? O tym rozmawiam z Szymonem Węsierskim autorem wyjątkowego produktu na polskim rynku: „WoobyKids”.

1. Czym jest WoobyKids?

WoobyKids to edukacyjne kolorowanki wykorzystujące rozszerzoną rzeczywistość. Można zamówić oprawioną książeczkę z naklejkami, ciekawostkami o zwierzątkach lub też wydrukować kolorowankę samemu z pliku PDF. Potrzebna jest również aplikacja mobilna, która jest darmowa na platformach iOS oraz Android. Kierując kamerą na kolorowankę widzimy zwierzaka w 3D, który się rusza i wydaje dźwięki oraz jest w identycznych kolorach jakich dziecko użyło na kartce.

Jeśli chcesz zobaczyć na czym dokładnie to polega zajrzyj:

2. Skąd pewność, że produkt będzie cieszył się powodzeniem?

Według mnie nigdy nie ma takiej pewności. Budowanie produktów polega na ciągłym pozyskiwaniu feedbacku od użytkowników i wdrażanie kolejnych iteracji w produkcie. Połączyliśmy coś klasycznego, czyli kolorowanki z nowoczesną technologią rozszerzonej rzeczywistości, która coraz częściej znajduje zastosowanie w różnych branżach. Już teraz widzimy możliwość rozbudowania produktu. Jednak gdybyśmy nie uruchomili produktu w jak najprostszej formie, nie nauczylibyśmy się wielu cennych lekcji. To doświadczenie, które zostaje na całe życie i można wykorzystywać je w kolejnych projektach.

3. Jak tworzy się produkt dla tak wymagającej grupy jaką są dzieci? Korzystaliście z person? Jak to wyglądało?

Na bardzo początkowym etapie nawiązaliśmy współpracę z jednym z Gdańskich przedszkoli, gdzie mogliśmy zrobić swoje beta testy 🙂 Rozmawialiśmy z rodzicami i pytaliśmy, co ich dzieci najchętniej kolorują i ile przeciętnie wydają miesięcznie na kolorowanki, edukacyjne książeczki. Dodatkowo zauważyliśmy, że coraz więcej dzieci spędza czas oglądając bajki na Youtube lub grając w gry, które nie rozwijają ich umiejętności.  Naszą misją była alternatywna forma użycia urządzenia mobilnego, które miało być przeniesieniem klasycznych kolorowanek na inny poziom. Absolutnie nie zamierzaliśmy rezygnować z rozwijania małej motoryki u dzieci, którą doskonale rozwija kolorowanie. Podczas rozmów z rodzicami dowiedzieliśmy się też, że często dzieci niechętnie kolorują lub po prostu rysunki są niestaranne. Jak potem się okazało, nie wiedzieliśmy, że tutaj tak bardzo rozszerzona rzeczywistość może pomóc!

woobykids_1

4. Jak wyglądało budowanie zespołu- kto był odpowiedzialny za analizę?

Przede wszystkim należy wspomnieć, że Wooby to wewnętrzny produkt naszej Agencji UX/UI EFEKT Agency na co dzień zajmujemy się budowaniem produktów dla naszych klientów. Dzięki temu na pewno łatwiej było nam zrealizować swój projekt. W produkt był zaangażowany cały zespół. Zmotywowało to nas wszystkich do pracy nad „czymś swoim”. Zdecydowanie pozytywnie to wpłynęło na całą naszą Agencję 🙂

5. Jak wyglądała faza identyfikacji wymagań, a później ich analizowania?

W myśl stwierdzeniu „better run than perfect”, chcieliśmy jak najszybciej wypuścić do testów produkt w jak najprostszej formie Zrobiliśmy priorytetyzację wymagań. Wiedzieliśmy, że nie chcemy zaimplementować wszystkiego ponieważ start produktu odwlekałby się w czasie. Zależało nam na jak najszybszym wejściu w rynek, aby zebrać feedback użytkowników. Stworzyliśmy wymagania, następnie wireframe (wstępny szkic) aplikacji mobilnej. Klikalny prototyp (używając Invision) bez użycia linijki kodu był zdecydowanie pomocny w wyłapaniu wszelkich martwych punktów albo nieścisłości pod względem UX. Niektóre funkcjonalności, które sugerowały dzieci lub osoby pracujące w przedszkolu wciąż są w backlogu 😊

6. Czy podczas pracy nad projektem było coś co stwarzało dla Was największą trudność?

Na pewno odkrywanie technologii rozszerzonej rzeczywistości. Musieliśmy wielu rzeczy uczyć się metodą prób i błędów. Jednym z przykładów było skanowanie markerów ( czyli kartek, które wyzwalają model 3D). Musieliśmy zadbać, o poprawne zczytywania pomimo zakreślonych, zamazanych konturów kolorowanek. Kolejną rzecz, którą pamiętam było poprawne teksturowanie modeli 3D, ponieważ kolor z kartki, jest przekładamy na model 3D. Zwierzak jest kolorowany na kartce w 2D, dlatego należało odpowiednio zaprogramować kwestię przełożenia tego na 3D.

7. Czego nauczyliście się podczas projektu? Czy stosujecie jakieś techniki, które ułatwiają Wam pracę przy obecnych projektach, których nauczyliście się przy Wooby?

Zdecydowanie Wooby pozytywnie wpłynął na wizerunek naszej Agencji. Pokazujemy klientom, że sami potrafimy zbudować działający produkt. Nasza wiarygodność jest zdecydowanie wyższa i traktujemy Wooby jako success story. Klienci też są zaciekawieni naszym rozwiązaniem i najlepszym prezentem jakim możemy im przekazać to kolorowanki dla ich dzieci 🙂 Nauczyliśmy się również tego, aby nie bać się ukazywaniu produktu, który może mieć pewne braki. Nasi pierwsi klienci pomogli nam w budowaniu contentu oraz świadomości Wooby wśród innych rodziców.

8. Jak wyglądało wprowadzenie produktu na rynek od strony marketingowej?

Jest to obszerny temat. Stworzyliśmy prosty landing page, tłumaczący idee oraz formularz zapisu z zaproszeniem do beta testów (w momencie dodania aplikacji na AppStore oraz GooglePlay, osoby te dostały od razu dostęp do aplikacji wraz z darmową kolorowanką w formie PDF). Pozwoliło nam to na zebranie feedbacku od tzw. „early adopters”, osób, które były w stanie zrozumieć ewentualne niedociągnięcia. Jednym z większych niewiadomych było, jak zachowa się aplikacja na przeróżnych modelach telefonów, nawet tych 4-5 letnich.

Stworzyliśmy notkę prasową, którą przesłaliśmy do przeróżnych portali, co zaowocowało w kilka wzmianek, wywiadów. Nawiązaliśmy współpracę z “Wielką Fabryką Elfów”, cyklicznym eventem organizowanym w okresie świątecznym w 3 miastach w Polsce. Wykorzystaliśmy technologię rozszerzonej rzeczywistości do “ożywienia” ich kolorowanek. Dzięki czemu, ponad 30 0000 odwiedzających to wydarzenie, mogło zapoznać się z aplikacją Wooby.

Kolejnym krokiem było wprowadzenie Wooby do sieci księgarni „Bookszpan”, jednak sprzedaż kanałem offline okazała się poniżej naszych oczekiwań. Klienci bez dodatkowych informacji, jak to działa, nie byli w stanie odróżnić naszej kolorowanki od zwykłej. Zdecydowanie kanał online jest dla nas lepszy, gdyż możemy pokazać video.

9. Jak obecnie wygląda praca nad tym produktem? Czy planujecie jego rozwój?

Pracujemy obecnie nad kolejną serią kolorowanek. Poprawiliśmy znacząco jakość modeli 3D. Postacie również będą opowiadały ciekawostki, zamiast tylko wydawać dźwięki. Kolorowanka będzie bardziej książeczką do kolorowania ubraną w historię. Zdecydowanie też powiększymy ilość stron. Zatrudniliśmy jedną osobę od marketingu, która dba o social media oraz kontakt z naszymi klientami oraz innymi instytucjami. Również realizujemy projekt ściśle B2B, gdzie wykorzystujemy nasz know-how tworząc kolorowanki dla jednego z wydawnictw.

10. Według raportu: “Polskie startup” głównym modelem finansowania jest bootstrapping, czyli własne oszczędności oraz reinwestowanie przychodów. Jak wyglądało to w przypadku Wooby? Skąd pozyskiwaliście pieniądze na realizację prac?

Dokładnie tak jak mówisz. Były to nasze własne środki poprzez zysk wygenerowany przez naszą Agencję.

11. Coraz częściej czytamy, że średni czas życia startup to 2-3 lata. Wasza aplikacja Wooby została wydana w 2017 roku, nie obawiacie się, że boom minie?

O takiej statystyce nie słyszałem 🙂 Wiem, że średnio 90 % firm upada po 2-3 latach. Wg mnie właśnie potencjał rozszerzonej rzeczywistości będzie coraz szerzej wykorzystywany w codziennych produktach Performance telefonów również stale się polepsza. Dzięki temu coraz większy procent użytkowników, może w pełni skorzystać z tej technologii. Jest dosyć popularne określenie, że „ Budowanie firmy to maraton, a nie sprint.” Podpisuje się pod tymi obiema rękami.

Powiadom mnie o zapisach

Dowiesz się, gdy tylko ruszą.

Szczegóły
Brak danych o cenie
Najczęstsze problemy analityka- jak ich uniknąć
Zapisy wkrótce

Niektórzy twierdzą, że największym problemem w projekcie jest Klient. Wielu z nas narzeka na pracę z klientem ponieważ nie zawsze mówi nam o wszystkich swoich potrzebach. Spotkania z nim to niekończąca się lista życzeń, a I do dokumentu czasem ma uwagi.

Jak poradzić sobie w tych sytuacjach, czyli słów kilka o największych koszmarach analityka.

Problem #1: Niechęć klienta do dzielenia się informacjami

Wyobraź sobie taką sytuację: jesteś na spotkaniu, Klient bez większego problemu opowiada Tobie o swoim biznesie. Bez Twoich dodatkowych pytań mówi o tym co chce osiągnąć, jak będzie działał jego biznes po wdrożeniu zmian. Rozrysował nawet za Ciebie proces, przygotował listę wymagań biznesowych. Przy każdym z nich dopisał mierzalny cel biznesowy. Brzmi jak marzenie każdego analityka 🙂

Sytuacje, w których klient nie opowiada o wszystkich swoich wymaganiach to normalność w każdym projekcie. Musimy w pierwszej kolejności zrozumieć powody, dla których użytkownicy niechętnie nam o wszystkim mówią. Ale mieć na uwadze również fakt, że klient nie zawsze zdaje sobie sprawę z tego, że taka informacja może być dla nas ważna.

Sprawdź czy interesariusz:

  •  jest przyzwyczajony do określonego sposobu pracy I dlatego jest odporny na zmiany.
  •  wie jakie czynności wykonywane są w omawianym procesie biznesowym
  •  posiada informacje kto wykonuje te czynności, a kto nie powinien mieć do nich dostępu.
  •  rozumie co za pomocą danej funkcjonalności chce osiągnąć

Pamiętaj, aby w pierwszej kolejności zapytać klienta o tym CO funkcja ma robić, a dopiero w drugiej kolejności JAK ma działać. Nie myśl od razu o rozwiązaniu, lecz o tym w jaki sposób interesariusz będzie z niej korzystał. Pomocny w tym przypadku będzie rozrysowany proces biznesowy.

Dzięki niemu łatwiej będzie Tobie zadać pytania, np:

  • Czy wykonanie tego zadania wymaga decyzji innych osób?
  • Z jakich danych musisz skorzystać, aby wykonać swoje zadanie?
  • Kto je przygotowuje?
  • Na którym etapie powstają te dane?
  • Komu musisz wysłać wynik swojej pracy?
  • Czy kolejność wykonywanych działań ma znaczenie?
  • Jak system powinien się zachować w określonej sytuacji?
  • Co musi się stać, aby wykonanie tej operacji nie było możliwe?
  • Czy ktoś spoza działu ma mieć dostęp do tej operacji?

Problem #2: Niezrozumiały dokument

Tester, programista, klient- żadna ze stron nie rozumie tego co zostało zapisane w dokumencie. Twoje zdziwienie jest tym większe, jeśli sam jesteś zadowolony z tego “dzieła”. W końcu poświęciłaś na stworzenie tego dokumentu wiele tygodni.

W innym przypadku masz wrażenie, że klient opowiada to samo co już opisałeś tylko innymi słowami, a Ty nie wiesz co zrobić?

Musisz zrozumieć, że dokumentu nie tworzysz dla siebie. Zatem to czy według Ciebie dokument jest dobry czy nie, nie ma większego znaczenia. Tworzysz go dla klienta, programisty, testera. Dlaczego więc nie pytasz tych interesariuszy projektu czego oczekują od Twojego opisu w tym projekcie? Na co szczególnie powinieneś zwrócić uwagę?

Oczekiwaniem klienta jest sprawdzenie czy dobrze została jego potrzeba. Nie interesuje go rozwiązanie, chyba, że jest to wymaganie względem systemu wynikające np. z zapisów w Księdze Identyfikacji Wizualnej Firmy. Klienta interesuje opis, w ramach którego będzie wiedział co funkcja robi, jakie są jej ograniczenia oraz czy będzie mógł jej użyć w osiągnięciu celu biznesowego.

Takim przykładem może być: “ Umożliwienie Klientowi dodawania książki do koszyka zamówień”. Klienta nie interesuje w pierwszym momencie jak będzie wyglądał mechanizm dodawania. W pierwszej kolejności jako Klient muszę znać odpowiedzi na pytania:

  • Czy po dodaniu książki mogę ją usunąć z koszyka? Na którym etapie tego procesu usunięcie nie będzie możliwe?
  • Czy po dodaniu książki mogę modyfikować zamówienie, np. Dodać liczbę sztuk książki?
  • Czy po dodaniu książki będę widzieć, że została dodana?

Powyższe pytania są skontruowane według skrótu: C,R,U,D ( C- create, R- read, U-update, D-delete).

Pamiętaj, że Klient testuje biznesowo, zatem musisz spytać klienta w jaki sposób sprawdzi, że funkcjonalność będzie działać prawidłowo. W odpowiedzi mogą być zawarte tzw. “ukryte wymagania”.

Oczekiwaniem testera jest otrzymanie jasno opisanych zasad działania funkcji, warunków początkowych oraz końcowych. Interesuje go przede wszystkim wynik funkcji, o którym niestety często zapominamy w opisach.

Oczekiwaniem programisty jest otrzymanie dokładnych wskazówek co ma być zaprogramowane. Zastanów się co należy wykonać w systemie, aby użytkownik mógł pracować w sposób przez siebie oczekiwany.

Problem #3: Nieefektywne warsztaty

Po spotkaniu masz poczucie, że niewiele udało Ci się osiągnąć? Zrobiłeś 2 kroki w przód i 3 kroki w tył? A może nie potrafiłeś zapanować nad grupą podczas dyskusji?

Takie sytuacje mają miejsce, jeśli Twoje przygotowanie do spotkania sprowadza się do przygotowania merytorycznego.

Przygotowanie do spotkania to również odpowiedź na kilka podstawowych pytań:

  • Jaki jest cel spotkania? Dlaczego spotkanie jest konieczne lub potrzebne?
  • Co będzie wynikiem spotkania: wiedza, zmiana w myśleniu, decyzja? Czy uwzględniłeś to w agendzie?
  • Czy istnieje inna forma przekazania informacji, która będzie skuteczniejsza?
  • Co powoduje, że klient się angażuje na spotkaniu (narzędzia, forma przekazywania informacji)?

Problem #4: Chaos podczas dyskusji

Jesteś moderatorem spotkania, zatem to na Tobie ciąży odpowiedzialność weryfikowania czy dyskusja nie odbiega od głównego tematu. Użyj parafrazy, aby to zweryfikować: “Jeśli dobrze Pana zrozumiałam mówimy o……czy mógłby Pan pomóc mi zrozumieć, dlaczego ten aspekt jest istotny z punktu widzenia naszego tematu, w którym….”.

Możesz również poprosić Twojego rozmówcę, aby wyjaśnił jak wątek, który właśnie poruszył łączy się z tematem: “Dziękuję za Pana wypowiedz. Jak wątek, który Pan poruszył łączy się z tematem?”. Jeśli trudno Tobie nadążyć nad zrozumieniem tego co Klient do Ciebie mówi, spróbuj rozrysować to jako mapę myśli, bądź powiązać pojęcia, które wypowiada Klient model pojęciowy.

Jeśli masz problem z chaosem wypowiedzi użyj jednej z wielu technik facylitacji. Jedną z propozycji jest technika udzielania głosu oraz koordynowania dyskusji.

Technikę udzielania głosu stosuje się, aby pomóc w uporządkowaniu dyskusji kiedy wszyscy jej uczestnicy chcą mówić jednocześnie.

Krok 1 – Proszę, aby wszystkie osoby, które chcą się wypowiedzieć, podniosły ręce

Krok 2 – Widzę, że głos chcą zabrać 2 osoby: wymień z imienia. Właśnie w takiej kolejności będziecie się wypowiadać. Najpierw X, potem Y.

Krok 3 – Gdy X skończy, teraz Y, zapraszam…..

Krok 4 – gdy Y skończy. Czy ktoś jeszcze chcę się wypowiedzieć w tej sprawie?

Koordynowanie dyskusji oznacza wydzielanie i nazywanie poszczególnych wątków z dyskusji. Technikę tą możemy również stosować

profilaktycznie. Zapobiegamy powstaniu u kogoś niepokoju, że „jego sprawa” nie jest ważna, nie interesuje nikogo poza nim.

Podsumuj wątki i wypowiedzi na „tu i teraz” oraz sprawdź, czy tak jest w istocie.

Powiedz: „Wygląda na to, że mamy tu 3 równoległe rozmowy, bo po pierwsze, wypowiadacie się o….. po drugie rozmawiamy o…, po trzecie rozmowa dotyczy…. Czy coś pominęłam, bądź źle zinterpretowałam?

Pamiętaj, aby po każdych warsztatach zrobić retrospekcję. Pozwoli ona na krytyczne spojrzenie na warsztaty, które poprowadziłeś. Dzięki temu będziesz w stanie wypisać:

  • ZACZĄĆ: punktualne przychodzenie,wysyłanie zrzutów ekranowych przed sesją
  • PRZESTAĆ: grzebać w przeszłości, zmienić nastawienie, wierzyć w dobre intencje
  • ZWIĘKSZYĆ: podsumowania uwag i komentarzy, korzystanie z „czerwonych kartek”
  • KONTYNUOWAĆ: punktualne zaczynanie krótkich przerw na przekąski
  • ZMNIEJSZYĆ: ilość okien z nieprawdziwymi danymi
Powiadom mnie o zapisach

Dowiesz się, gdy tylko ruszą.

Szczegóły
Brak danych o cenie
Pytania rekrutacyjne na stanowisko analityka- część 1- podstawowa wiedza
Zapisy wkrótce

Czym zajmuje się analityk biznesowy? Jaka jest jego rola w projekcie? Jakie umiejętności powinien mieć analityk? To tylko kilka pytań, z którymi możesz spotkać się podczas rozmowy rekrutacyjnej.

W dzisiejszym artykule odsłona pierwszej części pytań wraz z odpowiedziami. Rozpoczynamy od sekcji: “Podstawowa rola analityka”.

Lista pytań:

#1 Jaka jest różnica między analizą biznesową a analityką biznesową?
#2 Co to jest analiza modelu biznesowego?
#3 Dlaczego analityk biznesowy jest ważny w projekcie?
#4 Wymień kluczowe według Ciebie umiejętności każdego analityka biznesowego
#5 Jakie najczęstsze problemy może napotkać analityk w projekcie?

ODPOWIEDZI:

#1 Jaka jest różnica między analizą biznesową a analityką biznesową?

Odpowiedź:
Analiza biznesowa bazuje na analizie procesów oraz poszukuje rozwiązań problemów biznesowych. Osoba wykonująca analizę biznesową – analityk biznesowy.

Analityka biznesowa jest związana z danymi i raportowaniem. Obejmuje między innymi analizę statystyczną lub ilościową, eksplorację danych. Wspiera proces planowania biznesowego. W analityce biznesowej występuje architektura informacji oraz architektura danych. Analityka biznesowa pozwala poprawić wydajność biznesową poprzez analizowanie raportów czy metryk, wskaźników KPI w celu identyfikacji problemów.
Osoba wykonująca analitykę biznesową- analityk danych.

#2 Co to jest analiza modelu biznesowego?

Odpowiedź:
Definicja modelu biznesowego:
“Model biznesowy opisuje przesłanki stojące za sposobem, w jaki organizacja tworzy wartość oraz zapewnia i czerpie zyski z tej wytworzonej wartości.”

Zatem analiza modelu biznesowego będzie techniką pozwalającą przeanalizować czy biznes jest opłacalny z punktu widzenia ekonomicznego, ale przede wszystkim czy istnieje taka potrzeba na rynku. Analiza modelu biznesowego stanowi podstawę wszelkich wymaganych zmian modelu biznesowego i jest kluczem do innowacji w organizacji. Analiza modelu biznesowego to w skrócie przekładanie planów biznesowych na procesy biznesowe niezbędne do prowadzenia działalności operacyjnej.

W trakcie analizy modelu biznesowego kluczowi są klienci, ponieważ szukasz odpowiedzi na pytania:
“Jakiego rodzaju zadania mają do wykonania moi kliencie I w jaki sposób mogę im pomóc, ułatwić te czynności?”
“Czego oczekują moi klienci, jak możemy to osiągnąć?”
“Jaką formę kontaktu preferują nasi klienci?”
“Za co jest w stanie zapłacić mój klient?”

#3 Dlaczego analityk biznesowy jest ważny w projekcie?

Odpowiedź:
Analityk biznesowy to osoba, która bardzo dobrze rozumie potrzeby biznesu I potrafi je właściwie zinterpretować oraz przekazać zespołowi deweloperskiemu. Najważniejszym celem analityka biznesowego w projekcie jest usprawnienie komunikacji pomiędzy biznesem a IT. Dobry analityk biznesowy skupia się na problemie biznesu, stara się znaleźć rozwiązanie problemu biznesowego- czasem jest to przeorganizowanie samego procesu biznesowego, bądź jego zbudowanie.
Uwaga! W zależności od firmy, w której starasz się o pracę nie zawsze będzie chodziło o analityka biznesowego. Dlatego takie ważne jest zapoznanie się z profilem firmy przed rozmową.
Czasem firma poszukuje inżyniera wymagań (analityka biznesowo-systemowego), wówczas twoja odpowiedź powinna być poszerzona o następujące kwestie:
Analityk biznesowo-systemowy dodatkowo poszukuje rozwiązania systemowego, który będzie zaspokajał potrzebę biznesową.

Definicje:

Analityk biznesowy- osoba odpowiedzialna za identyfikację potrzeb biznesowych swoich klientów I zainteresowanych stron w celu określenia rozwiązań problemów. [BABOK]

Inżynier wymagań (analityk biznesowo-systemowy) – osoba odpowiedzialna za współpracę z zainteresowanymi stronami projektu I użytkownikami końcowymi w celu uzyskania, zrozumienia, przeanalizowania I udokumentowania wymagań systemu w celu rozwiązania danego problemu biznesowego.

Pamiętaj! “Każdy inżynier wymagań jest analitykiem biznesowym, nie każdy analityk biznesowy jest inżynierem wymagań” (M.Perendyk).

Zestawienie dwóch ról przeczytasz we wstępie do artykułu: “Jak zostać analitykiem”

Osoba odpowiedzialna za wymagania w projekcie (analityk biznesowy, bądź analityk biznesowo-systemowy) jest bardzo ważna dla projektu, szczególnie w fazie początkowej (przy waterfallu) ale również podczas całego procesu tworzenia produktu (podejście zwinne).

Prześledźmy udział tej roli w całym procesie wytwarzania oprogramowania:
1. Inauguracja projektu– faza, w ramach której interesariusze projektu najczęściej zadają pytania techniczne. Definiują swoje wymagania poprzez język rozwiązania, zamiast skupiać się na potrzebie biznesowej. Wówczas analityk jest w stanie pokierować dyskusją w taki sposób, aby skupić się w pierwszej kolejności na odkryciu potrzeb biznesu, a w drugiej kolejności rozmawiać o zaletach wspomnianego przez biznes rozwiązania. Brak osoby analizującej potrzeby biznesu, programista skupiałby się na dostarczeniu rozwiązania, który prosi biznes. Niestety bardzo często biznes po otrzymaniu rozwiązania jest rozczarowany, ponieważ ich problem nie został rozwiązany.

2. Analiza luk i procesów biznesowych – jest to kluczowa faza w projekcie, ponieważ analityk musi sprawdzić czy przekazane przez biznes wymagania wzajemnie się nie wykluczają. Jest to moment, kiedy weryfikuje jak wymagania wpływają na proces biznesowy, który został zamodelowany.

3. Testowanie rozwiązania – analityk w projekcie jest niejako przedstawicielem biznesu, którego nie mamy pod ręką. Najlepsze rezultaty przynosi włączenie analityka w fazę przygotowania scenariuszy testowych przez testera. Dzięki temu minimalizujemy ryzyko pominięcia kroków w scenariuszu testowym, na który warto szczególnie zwrócić uwagę. Warto w tym momencie wspomnieć, iż dobrze wykonana analiza pozwala testerowi wyłapać wszystkie wymagania, które powinny być przetestowane. Dobry opis to taki, dzięki któremu tester otrzymuje informację, w jaki sposób użytkownik będzie korzystał z rozwiązania oraz jak będzie działać funkcja i jaki rezultat otrzymamy po jej wykonaniu.

#4 Wymień kluczowe według Ciebie umiejętności każdego analityka biznesowego

Odpowiedź:
W artykule: “Kompetencje analityka” znajdziesz opis umiejętności analityka.

#5 Jakie najczęstsze problemy może napotkać analityk w projekcie?

Odpowiedź:
W artykule: “Najczęstsze problemy analityka” znajdziesz opis nie tylko najczęstszych problemów analityka, ale również jak ich uniknąć.

Powiadom mnie o zapisach

Dowiesz się, gdy tylko ruszą.

Szczegóły
Brak danych o cenie
Proces rekrutacji analityka biznesowego z punktu widzenia firmy
Zapisy wkrótce

Według barometru zawodów rola analityka w projektach ulega coraz większemu umocnieniu. Pracodawcy coraz częściej szukają wykwalifikowanych specjalistów, którzy będą jednocześnie multidyscyplinarni. Często możemy spotkać się z opisem, że analityk biznesowy zmienia swoją rolę w projekcie. Obserwując rynki międzynarodowe obserwuję przeciwny trend, z którym się w 100% zgadzam. Trend ten polega na ustaleniu jasnej granicy między kompetencjami analityka biznesowego a inżyniera wymagań (analityka biznesowo-systemowego). Taki podział pozwala obu stronom: kandydatom oraz pracodawcom na wzajemne się odnalezienie, ale przede wszystkim na odpowiednie wykorzystanie umiejętności takiego kandydata.

O tym jak wygląda proces rekrutacji analityka biznesowego oraz biznesowo-systemowego (inżynier wymagań), jakich umiejętności szuka firma u takiego kandydata, o czym pamiętać podczas rekrutacji oraz jakie możliwości rozwoju ma taka osoba po przyjęciu do firmy rozmawiam z firmą Pentacomp. Odpowiedzi na pytania z ramienia firmy udzielili: Patryk Lewkiewicz oraz Sławomir Kończyk – główni analitycy IT, organizatorzy spotkań analitycznej grupy kompetencyjnej w firmie Pentacomp.

1. Patrząc na ogłoszenia pracy po wpisaniu hasła: analityk otrzymujemy ponad 2 tys. ofert pracy. Wśród nich: analityk biznesowy, analityk IT, analityk biznesowo-systemowy, architekt biznesu. Nazwa to jedno, natomiast każda z ofert prezentuje różny zakres obowiązków. Kandydatowi czasem trudno się zorientować która oferta opisuje to, co chce robić przez dłuższy okres czasu. Kogo szuka Wasza firma: analityka biznesowego, czy analityka biznesowo-systemowego? Jaka jest różnica w postrzeganiu przez Waszą firmę kandydatów na oba stanowiska?

Patryk Lewkiewicz: Może lepiej jak zacznę od końca. W naszej opinii analityk biznesowy jest osobą, która potrafi określić potrzeby organizacji i/lub interesariuszy oraz zaproponować rozwiązanie dla klienta, które dostarczy mu określoną wartość. Stąd analityk biznesowy powinien posiadać podstawową wiedzę biznesową. Wiedza ta ma zapewnić mu możliwość sformułowania wymagań funkcjonalnych względem produktu, który zamawia klient.

Z kolei obowiązki analityka biznesowo-systemowego schodzą trochę niżej. Powinien on dodatkowo znać proces wytwarzania oprogramowania i określać szczegółowo w jaki sposób od strony rozwiązania informatycznego zrealizować wymagania klienta.

Osoba taka powinna znać dobre praktyki projektowania systemów oraz ściśle współpracować z programistami w trakcie procesu wytwórczego.

Odpowiadając na pytanie kogo szuka nasza firma – szuka analityków biznesowo-systemowych. Wynika to ze specyfiki naszej organizacji, jesteśmy twórcą i dostawcą usług IT, w związku z tym wiedza z zakresu wytwarzania oprogramowania jest dla nas bardzo ważna. Nie skreśla to natomiast szans na zatrudnienie osobom, które do tej pory pracowały jako analityk biznesowy. Często zdarzają się przypadki, że do naszego zespołu dołączają osoby, które nie miały nigdy do czynienia ze światem IT ale albo posiadają ogromną wiedzę dziedzinową albo określamy je jako osoby perspektywiczne. Ścieżka rozwoju takich osób zależy od tego co chcą dalej robić. Jeżeli chcą pozostać analitykami biznesowymi to zdecydowanie znajdą się projekty, w których będą mogły się dalej rozwijać i przynosić wartość. Jeżeli chcą nabyć wiedzę z zakresu analizy systemowej, to z pewnością znajdą tu odpowiednie osoby aby czerpać wiedzę i poznawać dobre praktyki.

2. Jak wygląda rekrutacja na stanowisko analityka biznesowo-systemowego? Składa się z etapów, czy jest to zwykła rozmowa?

Patryk Lewkiewicz: Proces rekrutacji zależy od wielu czynników. Wpływają na niego między innymi terminy, specyfika projektu, zakres obowiązków itp. Zazwyczaj rekrutacja jest jedno etapowa. Spotkanie składa się z kilku elementów: przedstawienie agendy spotkania, rozmowa na temat doświadczeń kandydata, omówienie projektu i organizacji, ewentualne pytania obu stron oraz warunki współpracy. Na spotkaniu są obecne 3 osoby: Specjalista HR, Kierownik Projektu oraz Analityk. Każda osoba ma zweryfikować konkretny zakres umiejętności. Sposobów weryfikacji jest kilka:

  • luźna rozmowa, podczas której kandydat przedstawia swoje dotychczasowe doświadczenia. Podczas takiej rozmowy można zweryfikować zarówno znajomość dobrych praktyk jak i znajomość technik i narzędzi.
  • Test weryfikacji kompetencji i umiejętności. Składa się zarówno z pytań zamkniętych jak i otwartych.
  • Scenka do odegrania, w trakcie której kandydat wciela się w rolę analityka a rekruterzy w rolę klientów. Scenkę odgrywa się w celu przeprowadzenia analizy określonego case study. Po przeprowadzeniu analizy rekruterzy wcielają się w developerów, dla których analityk ma przekazać zadania do realizacji.

Warto zaznaczyć, że czasem stosuje się kilka technik na jednym spotkaniu, natomiast zazwyczaj takie spotkanie nie trwa dłużej niż godzinę. Zazwyczaj informacja zwrotna o wynikach rekrutacji są przekazywane w ciągu kilku dni.

3. O czym powinien pamiętać kandydat przygotowując się do rozmowy rekrutacyjnej? Powinien przypomnieć sobie diagramy UML, a może przynieść swoje portfolio, rekomendacje?

Sławomir Kończyk: Najważniejsze, to przypomnieć sobie dotychczasowe doświadczenie w poprzednich projektach, tak aby opowiedzieć w jakiej roli się występowało, jaki był zakres obowiązków, specyfika pracy – konkretna metodyka/framework oraz jakie artefakty analityczne były tworzone. Warto także w ramach przygotowania do rozmowy wylistować sobie stosowane dobre praktyki czy techniki, na przykład w ramach pozyskiwania wymagań – brainstorming, wywiad czy też inne. Aby dobrze przygotować się do weryfikacji wiedzy teoretycznej z zakresu UML czy BPMN warto przypomnieć sobie notację, diagramy i chociaż podstawowe pojęcia z nimi związane.

4. Jakie szanse ma osoba bez doświadczenia? Czy warto złożyć CV czy taka osoba jest od razu odrzucana?

Patryk Lewkiewicz: Oczywiście, że warto! W ramach naszej polityki rozwoju staramy się stawiać na zróżnicowany poziom kompetencji w zespołach. Doskonale rozumiemy, że aby stać się ekspertem należy czerpać dobre praktyki od najlepszych, dlatego w większości naszych projektów znajdziemy zarówno starszego analityka jak i młodszego.
To, czy osoba bez doświadczenia zostanie zatrudniona zależy w dużym stopniu jak bardzo jest perspektywiczna i jak dużo może wnieść w przyszłości do organizacji. Osobiście przy podjęciu decyzji o zatrudnieniu zadaję sobie jedno pytanie: Czy chcę z taką osobą współpracować i przekazywać jej wiedzę?

5. W wielu ogłoszeniach pracodawcy zwracają uwagę na znajomość narzędzia: Enterprise Architect. W jakim stopniu taka znajomość jest wymagana? Jak taka znajomość jest weryfikowana?

Sławomir Kończyk: Od osoby rekrutowanej na stanowisko analityka pożądana jest znajomość narzędzia Enterprise Architect co najmniej w zakresie podstawowym czyli obsługi podstawowych funkcji. Weryfikację znajomości zastosowania narzędzia do diagramów UML czy BPMN przeprowadzamy wraz z weryfikacją wiedzy o danej notacji. Przeważnie odbywa się to w ramach prowadzonej rozmowy lub testu. Szczegółowa weryfikacja znajomości narzędzia przez kandydata następuje w okresie próbnym.

6. Każdy pracodawca chciałby spotkać kandydata, który jest mocny merytorycznie, ale również ma wysoko rozwinięte zdolności komunikacyjne. Chciałby, aby po kilku dniach szybko odnalazł się w nowej rzeczywistości projektowej. Jak to wygląda w Waszej firmie? Jak wyglądają pierwsze dni pracy takiej osoby, czy może liczyć na wsparcie i w jakim zakresie ona jest możliwa?

Sławomir Kończyk: Zarówno dla firmy i dla projektu istotne jest, aby nowa osoba szybko wdrożyła się w realizowane prace. Aby ułatwić i przyspieszyć ten proces każdej nowej osobie, oprócz zalecenia zapoznania się z materiałami opisującymi informacje organizacyjne, przydzielana jest osoba wprowadzająca do projektu i organizacji – mentor, który pomaga w „aklimatyzacji” i we wdrożeniu w codzienną pracę.

Osobom przyjętym na stanowisko młodszego analityka przydzielany jest także nauczyciel, który dba o rozwój kompetencji i umiejętności. Taka osoba delegowana jest także na szkolenia wewnętrzne organizowane przez grupy kompetencyjne, np. w zakresie SCRUMa czy analizy.

7. Firma Barclay w rozmowie na stanowisko analityka zadawała swego czasu pytania: “Ile osób podróżuje codziennie metrem?”. Jak zapatrujecie się na tego rodzaju pytania?

Sławomir Kończyk: Tego typu pytań raczej nie stosujemy. Mamy opracowany zbiór pytań, którymi przekrojowo staramy się zweryfikować wiedzę, kompetencje, doświadczenie i umiejętności rekrutowanej osoby.

8. Jak to jest ze “sztampowymi” pytaniami w stylu: “Dlaczego chce Pan/Pani u nas pracować?”, “Gdzie widzi się Pan/Pani za…..X lat”? Czy tego rodzaju pytań można spodziewać się na rozmowie? Jaką niosą wartość dla Was? Czego chcecie się dzięki nim dowiedzieć o kandydacie?

Sławomir Kończyk: Unikamy sztampowych pytań, bo tak naprawdę nic nie wnoszą. W Internecie jest mnóstwo odpowiedzi na tego rodzaju pytania, co powoduje, że na spotkaniu kandydat nie odpowiada szczerze. Naszą rekrutację opieramy na wywiadzie behawioralnym, który pokazuje zachowania kandydata w przeszłości. Zachowanie kandydata w przeszłości może sugerować to, w jaki sposób poradzi on sobie z podobną sytuacją w przyszłości. Ponadto, jest to proste narzędzie weryfikacji deklarowanych przez kandydata kwalifikacji i umiejętności. Zwracamy również uwagę na aspekt pracy zespołowej która jest dla nas istotna.

Na każdym spotkaniu staramy się, aby obecny był przedstawiciel kadr, kierownik projektu, do którego jest rekrutowana nowa osoba oraz starszy lub główny analityk. Każda z tych osób przeprowadza ocenę kandydata w innym zakresie. Powyższe podejście jest realizowane przez osoby z działu kadrowego.

9. Jak patrzycie na osoby, które zmieniają pracę średnio co 2 lata? Jak wygląda polityka utrzymania pracownika w firmie?

Sławomir Kończyk: Dzisiaj częsta zmiana pracy to zjawisko dość powszechne. Specjaliści stosunkowo chętnie zmieniają firmy i stanowiska, szukając lepszego projektu, pensji, czy możliwości rozwoju. Dopytujemy zawsze jakie były powody zmian, bo to nam pokazuje jakie oczekiwania ma kandydat. Jesteśmy nastawieni na rozmowę i współpracę z naszymi pracownikami. Dajemy możliwość rozwoju poprzez szkolenia, udział w konferencjach oraz pracę przy ciekawych projektach. Czasem zdarza się, że pracownik chce się przekwalifikować i dajemy mu taką możliwość. W naszej organizacji funkcjonują wspomniane już grupy kompetencyjne takie jak analiza, user experience, .NET, java, testowanie, architektura, metodyki zwinne, business intelligence oraz web & mobility. W ramach tych grup funkcjonują liderzy kompetencyjni, którzy odpowiedzialni są za organizacje szkoleń wewnętrznych, określanie ścieżek rozwoju oraz stanowią pierwszą linię wsparcia dla członków organizacji.

10. W jaki sposób sprawdzacie umiejętność myślenia? W jaki sposób rozpoznajecie, że taka osoba “pasuje” do Waszego teamu?

Patryk Lewkiewicz: Myślę, że zazwyczaj opieramy się na intuicji. Podczas luźnej rozmowy, o której wspominałem wcześniej, jesteśmy w stanie zweryfikować czy dana osoba odnajdzie się w realiach naszej organizacji. Bywają sytuacje, że kandydat w przeszłości realizował zadania w zupełnie inny sposób niż my, natomiast sam przyznaje, że z obecną wiedzą podszedłby do nich inaczej. Chęć uczenia się oraz wyciąganie wniosków z dotychczasowych projektów jest bliższa naszej ideologii.

11. Czy jest jakaś rozmowa rekrutacyjna, która utkwiła Wam w głowie?

Patryk Lewkiewicz: Nawet niejedna J zdarzały się rekrutacje, podczas których nie mogliśmy się przestać śmiać, niestety tajemnica przedsiębiorstwa zabrania nam mówić o szczegółach. Nie mniej jednak wydaje mi się, że te osoby wiedzą o kim mowa, więc jeżeli będą to czytać to serdecznie je pozdrawiam! 🙂

12. Gdybyście mieli powiedzieć jakich cech i umiejętności szukacie w kandydacie, który ma duże szanse na pracę. Chciałabym się dowiedzieć, które cechy i umiejętności są tzw. “Must have’, a które dana osoba może rozwijać w trakcie pracy.

Patryk Lewkiewicz:

Must have:

  • Zdolności analityczne, organizacyjne (planowanie), dokumentowania, umiejętności kreatywnego myślenia, podejmowania decyzji, negocjacji, spostrzegawczość.
  • Umiejętności komunikacyjne – analityk nie powinien mieć problemów podczas komunikacji zarówno z zespołem merytorycznym jak i wytwórczym.
  • Znajomość technik analitycznych – nie wymieniamy jakie konkretne techniki są kluczowe bo jest to kwestia indywidualna. Nie mniej jednak nie wyobrażam sobie analityka, który przykładowo pozyskiwałby wymagania bez podstawowej znajomości technik z zakresu inżynierii wymagań.

Should/Could:

  • Umiejętność moderacji spotkań (facylitacja), radzenie sobie w sytuacjach stresowych, uczenie się i przekazywanie wiedzy.
  • Znajomość metodyk zwinnych (głównie SCRUM) – w większości realizowanych projektów staramy się wytwarzać produkt za pomocą metodyk zwinnych. Wiedza w zakresie sposobu wytwarzania produktu w takich metodykach z perspektywy analityka jest kluczowa.
  • Znajomość notacji – analityk powinien z łatwością wykorzystywać takie notacje jak UML oraz BPMN, natomiast podstawową wiedzę w tym zakresie jest w stanie nabyć w dość krótkim czasie, więc jeżeli jest osobą która ma inne zalety, brak wiedzy w zakresie znajomości notacji jest do nadrobienia.
  • Znajomość narzędzi – Enterprise Architect, JIRA, TFS, Balsamiq Mockups, Axure RP, Pakiet MS i inne.

Doświadczenie w roli PO – przy realizacji projektów dla klienta zewnętrznego, często zdarza się, ze analityk pełni również funkcję Product Ownera. W tym celu umiejętności związane z tą rolą również są mile widziane.

13. Jak wygląda praca analityka?

Sławomir Kończyk:

  • zapoznawanie się z dokumentacją projektową w zakresie przedmiotu zamówienia (np. OPZ w przypadku przetargów publicznych) oraz innymi dokumentami precyzującymi potrzeby klienta, procesy biznesowe, wymagania i funkcjonalności (np. akty prawne, wewnętrzne regulaminy w organizacji klienta itp.)
  • koordynowanie spotkań i ustaleń analitycznych z klientem w celu:
    • precyzowania procesów biznesowych,
    • kroków procesów, które mają być wspierane przez systemem,
    • wymagań i funkcjonalności
    • lub ustalanie z klientem zmian w działających produkcyjnie systemach
  • sporządzanie notatek ze spotkań i ustaleń z klientem
  • wytwarzanie dokumentacji analitycznej w formacie ustalonym w umowie (opisy słownomuzyczne, diagramy procesów biznesowych, diagramy UML, repozytorium EA, projekty formatek ekranowych – wireframe-y lub mockup’y)
  • spotkania zespołu wytwórczego w ustalonej częstotliwości (np. SPM w scrumie):
    • planowanie i monitorowanie postępów prac,
    • przekazywanie wiedzy o bieżących i przyszłych pracach w projekcie od strony analizy/funkcjonalności np. w ramach przypisanego do osoby modułu systemu
  • spotkania zespołu analitycznego (planowanie prac analitycznych, dbanie o spójność i kompletność artefaktów analitycznych)
  • codzienne wsparcie deweloperów w implementowanych funkcjonalnościach
  • wsparcie:
    • zespołu testerów w planowaniu i weryfikacji wyników testów (scenariusze testowe, przypadki testowe, raporty z testów)
    • kierownika projektu w zakresie informacji nt. harmonogramu, zakresu, terminów
    •  pracowników serwisu w rozwiązywaniu zgłoszeń do systemu produkcyjnego w ramach umowy utrzymaniowej
  • uczestniczenie w pracach związanych z:
    • przygotowywaniem ofert
    •  rozwojem systemów wewnętrznych
    • wytwarzaniem produktów dla klientów zewnętrznych

 

Pentacomp Systemy Informatyczne S.A. działa na polskim rynku już od 1995 roku. W trakcie ponad 20 letniej działalności odnotowaliśmy wiele sukcesów na rynku wdrożeń dedykowanych systemów IT dla firm z sektora telekomunikacji, finansów, ubezpieczeń i przemysłu w kraju i za granicą, oraz dla sektora publicznego.

Specjalizacja Pentacompu obejmuje dedykowane rozwiązania IT, wspomagające strategiczne obszary działalności organizacji:
 Business Intelligence bazujące na hurtowniach danych
Zarządzanie bezpieczeństwem, w tym wsparcie służb mundurowych
Doradztwo w zakresie Architektury Korporacyjnej
Pełne wsparcie komunikacji między podmiotami gospodarczymi i administracją
Zarządzanie produktami w sektorze ubezpieczeniowym

Strona firmy: https://www.pentacomp.pl/

Powiadom mnie o zapisach

Dowiesz się, gdy tylko ruszą.

Szczegóły
Brak danych o cenie
Rozmowa rekrutacyjna oczami kandydata
Zapisy wkrótce

Rozmowa rekrutacyjna to spotkanie kandydata i firmy, która potencjalnie takiego kandydata chce zatrudnić. Dziś zobaczymy, jak wygląda taka rozmowa oczami kandydata. Czy zwracamy uwagę na te same aspekty?

Mikołaj Kukurba od lat związany z realizowaniem potrzeb klientów. Przygodę w świecie IT rozpoczynał od testowania aplikacji, a następnie został odpowiedzialny za zbieranie wymagań. Miłośnik aktywnego spędzania czasu i ciągłego samokształcenia. Poniższy wpis stanowi jego prywatną opinię.

Według danych z 2016 roku, przedstawionych przez Biuro Statystki Pracy (Bureau of Labor Statistics) przeciętny czas pracy u jednego pracodawcy wynosi 4,2 lata i zmniejszył się w przeciągu dwóch lat z 4,6 lat (źródło: https://www.thebalancecareers.com/how-often-do-people-change-jobs-2060467). Istnieje wiele powodów, z których pracownicy decydują się na zmianę pracy. Wśród nich można wymienić:

  • wyższą pensję,
  • zmianę miejsca zamieszkania,
  • poszukiwania lepszego balansu praca – życie prywatne,
  • rozwój osobisty,
  • redukcja etatów u obecnego pracodawcy.

W ostatnim wywiadzie na temat procesu rekrutacji analityka biznesowego został przedstawiony punkt widzenia firmy i jej podejścia do rekrutacji. Warto zapoznać się z tym tekstem (link: https://analizawymagan.pl/spiswywiadow/proces-rekrutacji-analityka-biznesowego-z-punktu-widzenia-firmy/) aby przygotować się do rozmowy na stanowisko analityka.

W niniejszym artykule chciałbym przedstawić proces rekrutacji na stanowisko analityka biznesowego z punktu widzenia kandydata.  Skupię się na podejściu firm do kandydata oraz sposobu, w jaki odbywa się weryfikacja jego umiejętności. Szczególnie ten ostatni punkt różni się w zależności od firm.

Na wstępie chciałbym zaznaczyć, że zgadzam się ze słowami Moniki Perendyk na temat rozróżnienia pojęć pomiędzy analityk biznesowy i inżynier wymagań. Mam wrażenie, że często te dwa pojęcia są używane zamiennie. Co więcej pod pojęciem: „analityk biznesowy” w rzeczywistości kryją się zadania jakie będziemy wykonywać jako analityk biznesowo- systemowy (inżynier wymagań).

Rozmowa rekrutacyjna u potencjalnego pracodawcy rozpoczyna się już w trakcie rozmowy telefonicznej, podczas której osoby z działu HR, przed zaproszeniem nas na spotkanie chcą poznać między innymi:

  • powody poszukiwania przez nas nowego miejsca pracy,
  • zweryfikować nasze CV o informacje związane z obecnymi obowiązkami, wielkością zespołu, z którym pracowaliśmy, czy dopytać o rolę jaką pełnimy w projekcie.

Często jest to szansa do  weryfikacji naszej znajomości języków obcych, jeżeli w ofercie zaznaczono taki wymóg .

Ciekawym doświadczeniem była dla mnie rozmowa telefoniczna z lektorem językowym, który w trakcie tej rozmowy miał ocenić mój faktyczny poziom znajomości języka.

Dla niektórych kandydatów rozmowa telefoniczna kończy etap rekrutacji dając wynik negatywny. Jeśli należymy do drugiej grupy, otrzymujemy zaproszenie do siedziby firmy, aby tam odbyć rozmowę „w cztery oczy” z przyszłym pracodawcą.

W niektórych przypadkach możemy zostać poproszeni o wykonanie zadanie (opis wymagań do przesłanego przez pracodawcę case study, bądź wykonanie modelu BPMN).

Spotkanie z przyszłym pracodawcą to wzajemne sprawdzenie oczekiwań: pracodawcy wobec nas, ale również nas wobec pracodawcy.

Przed rozmową polecam zapoznać się z listą pytań rekrutacyjnych dla analityka. Podczas rozmowy często pojawiają się pytania odnośnie naszej umiejętności radzenia sobie z błędami, porażkami. Pytania te dotyczą bardziej naszym umiejętności tzw. miękkich. Zdarza się, że firmy wykorzystują zewnętrzne narzędzia do weryfikacji naszych predyspozycji oraz do sprawdzenia naszej spostrzegawczości i logicznego myślenia.

Podczas rozmów spotkałem się z różnymi sposobami weryfikacji – rozpoczynając od sprawdzenia mojej wiedzy teoretycznej, kończąc na sprawdzeniu wiedzy praktycznej. Pytania, z jakimi się spotkałem najczęściej dotyczyły postępowania w pracy analityka, ale również poszczególnych etapów analizy w projekcie, np. analiza interesariuszy. Pytania związane były również z technikami, z których skorzystam w celu zminimalizowania ryzyka pominięcia ważnego interesariusza w projekcie.

W przypadku pytań związanych z pracą analityka biznesowego, dużej mierze pytania te pochodziły z BABOK.

Jeżeli chodzi o wiedzę praktyczną to pojawiają się pytania związane z wymienieniem cech dobrego wymagania. Konieczne jest np. wskazanie, który z diagramów UML będzie odpowiedni do najlepszego zobrazowania danego przypadku.

W trakcie rozmowy przyszły pracodawca chce sprawdzić z jaką grupą interesariuszy projektu rozmawiam, w celu zebrania wszystkich wymagań. Jak można zauważyć, przebieg rozmowy może przyjąć różne kierunki i w głównej mierze podyktowany jest warunkami jakie były umieszczone w ofercie pracy.

Najlepiej wspominam jedną z rekrutacji, w ramach której musiałem rozwiązać zadania typu: czytanie ze zrozumieniem, korekta przedstawionego wymagania na język zrozumiały dla biznesu, przygotowanie pytań na pierwsze spotkanie z klientem dla przedstawionego wstępnego zamówienia.

Rekrutacja jest ciekawym doświadczeniem i pozwala zweryfikować nasze umiejętności oraz poznać potrzeby rynku, ale również jest do moment weryfikacji naszej wiedzy. Dzięki uczestniczeniu w procesach rekrutacyjnych możemy odkryć  obszary, nad którymi jeszcze powinniśmy popracować.

Powiadom mnie o zapisach

Dowiesz się, gdy tylko ruszą.

Szczegóły
Brak danych o cenie
Rozmowa rekrutacyjna na stanowisko analityka- jak się przygotować?
Zapisy wkrótce

Rozmowa rekrutacyjna na stanowisko analityka biznesowego jest zwieńczeniem Twoich przygotowań do niej, których nie powinno się lekceważyć. Rozmowa rekrutacyjna powinna być traktowana jak swego rodzaju test twojej wiedzy, umiejętności, ale również zachowania się w stresującej sytuacji. Podczas rozmowy rekrutacyjnej nie chodzi o to, aby go zdać, lecz wypaść najlepiej spośród wszystkich kandydatów.

Przygotowanie do rozmowy rekrutacyjnej na stanowisko analityka biznesowego możemy sprowadzić to kilku prostych kroków. Ten artykuł otwiera cykl: “Pytania rekrutacyjne na stanowisko analityka”. W serii będą publikowane pytania na stanowisko analityka biznesowego, ale również systemowego (inżyniera wymagań) wraz z odpowiedziami. Pytania będą pogrupowane tematycznie. W międzyczasie będą publikowane artykuły tematyczne, które ułatwią Tobie pozyskanie wiedzy.

Krok 1 – Zbadaj firmę, do której rekrutujesz

Nawet, jeśli wysyłając CV tego nie zrobiłeś to przed spotkaniem z rekruterem musisz odrobić lekcję. Niektórzy rekruterzy mogą zakończyć rozmowę z Tobą już po pierwszym pytaniu związanym z firmą do której aplikujesz. Postaw się na miejscu rekrutera – dlaczego miałby chcieć z Tobą kontynuować rozmowę skoro nie wiesz nawet w jakiej branży będziesz pracował, nie wiesz czym zajmuje się dana firma?

Co powinieneś wiedzieć?

  1. Branża firmy– jest to istotne ponieważ część pytań w dalszej części rozmowy może być z nią związana. Rola analityka biznesowa może być typową pracą analityka, czyli przygotowywanie zestawień analizy rynku. Czasem rola analityka idzie w kierunku inżyniera wymagań, czyli będą wymagane od Ciebie umiejętności analityka biznesowo-systemowego.
  2. Produkty – pamiętaj, że nie zdajesz egzaminu ze 100% wiedzy o firmie, ale dobrze jest, jeśli znasz z 2-3 podstawowe produkty firmy.
  3. Klienci– mamy tutaj podobną sytuację, jak w przypadku produktów. Wymień 2-3 klientów. Jeśli nie ma informacji na stronie firmy pomiń tą odpowiedź.

Wszystkie powyższe informacje znajdziesz na stronie firmy I to właśnie strona powinna stanowić Twoje główne źródło wiedzy. Pomocny będzie również wujek Google 🙂
Zastanów się co Ty mógłbyś wnieść do tej firmy, ale również pomyśl nad tym czego chciałbyś się nauczyć pracując w niej przy projektach.

Na stronie opublikowałam wywiad z jedną z firm rekrutujących na stanowisko analityka. Dowiesz się z niego jak wygląda proces rekrutacji na stanowisko analityka.

Krok 2 – Sprawdź ponownie opis stanowiska, na które rekrutujesz

Być może wysyłałeś swoje CV pod wpływem impulsu, albo było to działanie bardziej przemyślane. Otrzymując zaproszenie na rozmowę ponownie przejrzyj opis stanowiska. Skup się na tych wymaganiach, które są wymienione w opisie. Pamiętaj, że podczas rozmowy nie opowiadasz historii swojego życia, lecz syntetyzujesz swoją wypowiedź, aby Twój słuchacz rozumiał co do niego mówisz 🙂 Na podstawie Twoich jasnych i przemyślanych odpowiedzi rekruter będzie wiedział czy firma szuka takiej osoby jak Ty, czy Twoje doświadczenie, chęć uczenia się jest wystarczająca.

Jeśli w opisie stanowiska wymienione są narzędzie oznacza to, że na 90% będziesz ich używał w swojej pracy. W zależności od tego jakiego kandydata poszukuje dana firma znajomość narzędzia może okazać się kluczowa. Większość firm, która szuka osoby z bardzo dobrą narzędzia oznacza ten fakt w opisie stanowiska. Jeśli otrzymałeś zaproszenie na rozmowę rekrutacyjną a w swoim CV zaznaczyłeś znajomość narzędzia na poziomie podstawowym oznacza to, że prawdopodobnie będziesz miał czas, aby się jeszcze podszkolić z niego.
Pamiętaj, że podczas rozmowy może być sprawdzany poziom Twojej wiedzy z danego narzędzia, więc warto napisać prawdę 🙂

Jakie narzędzia mogą pojawić się w ogłoszeniu?

  1. Enterprise Architect

Jest to narzędzie do modelowania za pomocą UML. Jeśli zostało ono wymienione prawdopodobnie Twoja praca będzie łączyła rolę analityka biznesowego i inżyniera wymagań, czyli będziesz analitykiem biznesowo-systemowym.

Kilka przydatnych linków ze Sparx Systems:

Zarządzanie wymaganiami w EA:
https://www.youtube.com/watch?v=CzYMhwd7v4c

Tworzenie przypadku użycia:
https://www.youtube.com/watch?v=MczA69WdDM4
https://www.youtube.com/watch?v=soID6Hg4uSw

Diagram klas:
https://www.youtube.com/watch?v=Iw3FjQ-qxt8

Diagram maszyny stanów:
https://www.youtube.com/watch?v=dhvbZABv-Es

Generowanie dokumentów z EA:
https://www.youtube.com/watch?v=q8RlpOE2AfU

2. Visual Paradigm

Narzędzie podobnie jak EA wspierające modelowanie UML, ale również modelowanie procesów biznesowych. W ogłoszeniach występuje w mniejszym stopniu, co wcale nie oznacza, że jest mniej znane. W moim odczuciu jest narzędziem dającym więcej możliwości niż EA w zakresie pracy typowego analityka biznesowego. Dlatego, jeśli w ogłoszeniu zostało wymienione, wiedz, że najprawdopodobniej faktycznie pracodawca szuka analityka biznesowego, który będzie wykonywał dla niego macierz RACI, schemat EPC, analiza SWOT, PEST, analiza konkurencji oraz wiele wiele innych.
Aby zapoznać się z narzędziem możesz skorzystać z wersji demo, bądź w wersji online free: https://online.visual-paradigm.com/

Na stronie producenta dostępne są tutoriale:
Video: https://www.visual-paradigm.com/features/demo/
Tutoriale: https://www.visual-paradigm.com/tutorials/

3. Bizagi Modeler
Jedno z najbardziej popularnych narzędzi do modelowania procesów biznesowych. Darmowe do użytku niekomercyjnego. Narzędzie w mojej ocenie nie wymagające dużego czasu na naukę
Link: https://www.bizagi.com/en/products/bpm-suite/modeler

Producent na swoim kanale również publikuje przydatne tutoriale:

Wprowadzenie do narzędzia: https://www.youtube.com/watch?v=GpXYgNVcdMU&list=PL-6mNeLaDVHC6Vw6UTQbfMieAJ_O6LAWs
Pierwsze tworzenie modelu procesu biznesowego: https://www.youtube.com/watch?v=GpXYgNVcdMU
Dokumentowanie procesu biznesowego: https://www.youtube.com/watch?v=RDxP1o_Slbs&index=3&list=PL-6mNeLaDVHCGh21C-4ExP3qmcQSHxd6g
Generowanie dokumentu: https://www.youtube.com/watch?v=vCS6eqEmnWM&list=PL-6mNeLaDVHCGh21C-4ExP3qmcQSHxd6g&index=7
Importowanie pliku z MS Visio: https://www.youtube.com/watch?v=65shF5qtRyw&list=PL-6mNeLaDVHCGh21C-4ExP3qmcQSHxd6g&index=11

Krok 3 – Przestudiuj najczęściej pojawiające się pytania związane z pracą analityka biznesowego i inżyniera wymagań (analityka biznesowo-systemowego).

W zależności od tego czy Firma poszukuje analityka biznesowego, czy osoby, która tak naprawdę będzie analitykiem biznesowo-systemowym pytania mogą być różne. Poniżej znajdziesz listę podstawowych pytań, z jakimi możesz się spotkać oraz odpowiedzi z moim komentarzami. Możesz wybrać grupę pytań, aby przenieść się do artykułu. Zachęcam do śledzenia wszystkich odpowiedzi. Lista pytań będzie aktualizowana.

Spis pytań:

## Podstawowa rola analityka- część 1 ##

#1 – Jaka jest różnica między analizą biznesową a analityką biznesową?
#2 – Co to jest analiza modelu biznesowego?
#3 – Dlaczego analityk biznesowy jest ważny w projekcie?
#4 – Wymień kluczowe według Ciebie umiejętności każdego analityka biznesowego
#5 – Jakie najczęstsze problemy może napotkać analityk w projekcie?

Powiadom mnie o zapisach

Dowiesz się, gdy tylko ruszą.

Szczegóły
Brak danych o cenie
Wymaganie biznesowe a reguła biznesowa
Zapisy wkrótce

Wymaganie biznesowe czy jeszcze reguła biznesowa? Czy podczas rozmowy z Klientem zastanawiałeś się jaka jest różnica? Czy kiedykolwiek miałeś sytuację, kiedy Klient był zdziwiony, że nie wszystkie wymagania zostały poprawnie zidentyfikowane, albo nie do końca chciał osiągnąć w systemie to co właśnie otrzymał? Jeśli byłeś świadkiem takie sytuacji prawdopodobnie zinterpretowano reguły biznesowe jako reguły systemowe. W artykule odpowiadam na najczęściej pojawiające się pytania: Czym jest reguła biznesowa? Jak rozpoznać czy to co mówi Klient jest regułą, czy jego wymaganiem wobec rozwiązania IT? Czy istnieje klasyfikacja reguł biznesowych? Kto odpowiada za definiowanie reguł biznesowych w projekcie? Jakie pytania zadać Klientowi, aby odkryć reguły biznesowe?

(więcej…)

Powiadom mnie o zapisach

Dowiesz się, gdy tylko ruszą.

Szczegóły
Brak danych o cenie
Konferencja dla analityków
Zapisy wkrótce

Jest taki jeden dzień w roku, kiedy w jednym miejscu spotykają się dwa światy: Biznesu i IT. Miejsce, gdzie podczas wspólnych rozmów próbują wzajemnie zrozumieć swoje potrzeby. Miejsce, gdzie podnoszą swoje umiejętności, aby kolejne projekty były sprawniejsze i sprawiały, że Klient chce korzystać z produktu, który otrzyma.

Co roku już od 2014 roku w Warszawie spotykają się analitycy, inżynierowie wymagań (analitycy biznesowo-systemowi), product ownerzy, managerowie, oraz wszyscy Ci, którzy chcą dostarczać produkty wysokiej jakości dla swoich Klientów. Podczas dwóch dni wymieniają się wiedzą, ale przede wszystkim podczas warsztatów odbywających się pierwszego dnia podnoszą swoje kompetencje.

Wydarzenie, o którym jest mowa- Konferencja Inżynierii Wymagań i Analizy Biznesowej, w skrócie: KIWAB to jedyne takie w Polsce wydarzenie i pierwsze, jakie powstało w Polsce i od lat gromadzi coraz większą liczbę uczestników. Konferencja dla analityków, ale nie tylko to wyjątkowe wydarzenie, ponieważ podczas konferencji występują uznani specjaliści z Polski, którzy dzielą się swoją wiedzą oraz odpowiadają na najtrudniejsze pytania od uczestników.

Analiza bez względu czy w stopce masz: analityk biznesowy, analityk systemowy, analityk biznesowo-systemowy, czy jeszcze inaczej, występuje wszędzie. Dlatego na naszej konferencji spotkasz się m.in z tematami:

  • tworzenia produktów
  • analiza w podejściu zwinnym
  • automatyzacja procesów biznesowych

Dla kogo jest to konferencja? Dla wszystkich tych, którzy są zaangażowani w tworzenia produktów, które kochają klienci. Umiejętność słuchania potrzeb Klientów oraz precyzyjnego opisania ich wymagań wobec systemu jest kluczem do sukcesu każdego projektu.

W tym roku spotykamy się podczas 5 edycji Konferencji już 10-11 czerwca 2019 w Warszawie, w Hotelu Lord ****, Al. Krakowska 218.

Forma konferencji

Konferencja to 2 dni intensywnej wymiany wiedzy i doświadczeń.

1 DZIEŃ – Warsztaty 

Pierwszego dnia jako uczestnik masz do wyboru 2 z 8 warsztatów, które udostępniamy.

Tematy warsztatów:

  1. “Pisanie wymagań w Agile” – Aleksandra Mozalewska
  2. “Myślenie produktowe z wykorzystaniem Innovation Games” – Maciej Sowiński
  3. “Współpraca analityka i Product Ownera, czyli analiza w zwinnym projekcie” – Sławomir Kończyk i Patryk Lewkiewicz
  4.  “Jak uniknąć problemów w SCRUM” – Ł. Nowacki
  5. “Jak zacząć wyznaczać OKR w praktyce”- ekipa z Neoteric
  6. “Event Storming dla biznesu” – Michał Bartyzel
  7. “How might we…? Design thinking- wprowadzenie do myślenia projektowego”– Karolina Krawczyk
  8. “Poznaj i zabierz robota do domu” – Piotr Ślęzak, Łukasz Burczak, Tomasz Górecki
Uwaga! Liczba miejsc na poszczególne warsztaty jest ograniczona do 35 miejsc.

Skorzystaj z podstawowego rozkładu:

Albo dowolnie miksuj warsztaty:

Tyle ile jest możliwości tyle znajdziesz biletów na stronie rejestracji: www.5kiwab.evenea.pl

2 DZIEŃ – Prelekcje

Nie musisz wcześniej deklarować, w której prelekcji weźmiesz udział. Możesz dowolnie przemieszczać się miedzy dwoma slotami w zależności od swoich potrzeb.

Pełna agenda znajduje się na stronie wydarzenia: https://kiwab.pl/agenda/

Strona konferencji: www.kiwab.pl

 

Powiadom mnie o zapisach

Dowiesz się, gdy tylko ruszą.

Szczegóły
Brak danych o cenie
Adaptowanie produktu w czasach kryzysu, czyli czym jest PIVOT
Zapisy wkrótce

Analityk biznesowy nie był bardziej potrzebny w firmie niż właśnie teraz. W czasach, które postawiły duże wyzwania przed firmami. Wiele firm szuka “patentu” na przetrwanie na rynku, wykorzystanie szansy na szybką i efektywną przebudowę swojego biznesu i zaadaptowanie produktu w czasach kryzysu.

Za analizę biznesową w firmie odpowiedzialny jest analityk biznesowy, którego zadaniem jest przejrzenie modeli biznesowych i zastosowaniem zmiany zwanej PIVOT.

W artykule dowiesz się nie tylko czym jest PIVOT, ale przede wszystkim kiedy jest czas na zrobienie PIVOT-a i jakie są jego rodzaje.

Czym jest PIVOT?

Każda firma posiada swój model biznesowy, który musiał powstać, aby odpowiedzieć na kilka podstawowych pytań takich jak (przykładowe pytania):

1) Do jakiej grupy odbiorców kierujemy swoje produkty?

2) Jakie problemy chcemy rozwiązać?

3) Jakie rozwiązania dla danej grupy odbiorców będą najatrakcyjniejsze?

4) Jakimi kanałami chcemy dotrzeć do konkretnej grupy odbiorców?

5) W jaki sposób zarobimy?

6) Jakie koszty musimy uwzględnić?

7) Jakie kluczowe zasoby powinniśmy uwzględnić w naszym produkcie?

8) Czy uwzględniamy kluczowych partnerów w naszym rozwiązaniu? Jeśli tak, to jakie rodzaj partnerstwa chcemy z nimi budować? Kto ma być kluczowym partnerem? Czy z partnerem wiążą się dodatkowe zasoby, koszty, kluczowe działania?

9) Jakie wartości dostarcza nasz produkt grupie odbiorców? Za co klient jest w stanie nam zapłacić? Co ma dla niego kluczowe znaczenie?

10) Jakie działania musimy podejmować, aby dostarczyć wartość grupie odbiorców?

11) Jakich działań wymagają nasze kanały dotarcia do grupy odbiorców?

Powyższe te pytania stanowią element większej całości określanej jako BMC (Business Model Canvas) składającej się z 9 elementów.

PIVOT-em określamy zmianę w 1 z elementów wynikającą z wcześniejszej analizy postawionej hipotezy: “Uważam, że [wynik biznesowy] zostanie osiągnięty, jeśli [grupa odbiorców] osiągnie [korzyść] dzięki [funkcji]”. Wynikiem biznesowym w tym przypadku będą zmiany zachowań grupy odbiorców, dzięki rozwiązaniu prawdziwego problemu Twojej grupy odbiorców. Taka hipoteza może doprowadzić do zmiany w kanałach dotarcia, modelu zarabiania, czy wygenerowaniu nowej wartości dla grupy odbiorców, czy zmianie sposobu dostarczania produktu do grupy odbiorców. Wszystkie te elementy będą wpływać na zmianę zachowania Twojej grupy odbiorców.

Jeśli tylko wprowadzasz zmianę ceny, czy wielkość produktów (downsizing) przy zachowaniu dotychczasowej ceny nie generujesz wartości dla grupy odbiorców. Jeśli chcesz całkowicie zmienić rodzaj dostarczanego produktu, bo poszerzasz swoją działalność nie możemy mówić o PIVOT.

Kiedy jest czas na zrobienie PIVOT?

Wydawało Ci się, że Twój model biznesowy jest dobrze przemyślany jednak nie widać tego w bilansie finansowym? Odbiorcy nie podzielają tych samych wartości, jakie zakładałeś dla swojego produktu, bądź usługi?  A może rynek, bądź sytuacja wymaga zweryfikowania, czy tą samą wartość dla grupy odbiorców jesteś w stanie dostarczać tym samym kanałem komunikacji? Klient nie chce płacić za konkretną dodatkową usługę, która miała być dla Twojej firmy przepustką do zostania kluczowym graczem na rynku? A może Twój biznes nie jest skalowalny i potrzebujesz przemyśleć zmianę podejścia do sprzedaży?

Powyższe pytania są przykładem sytuacji, kiedy powinieneś zastanowić się na użyciem PIVOT-a.

Mamy rok 2020, marzec, który przyniósł wielu firmom “wirusa w koronie”. Część firm musiała szybko dostosować się do sytuacji, której nie byliśmy w stanie przewidzieć (ich modele biznesowe na pewno). Przykładem takich firm, są chociażby firmy szkoleniowe dostarczające szkolenia stacjonarne. PIVOT polega na tym, aby zastanowić się, czy tą samą wartość, jakim jest wiedza jesteśmy w stanie dostarczyć innym kanałem, czyli na przykład za pomocą internet. Dla wielu firm jest to szansa, aby podczas trwania epidemii poszerzyć swoją ofertę. Co z firmami szkoleniowymi, które tylko bazują na szkoleniach on-line? Na pewno muszą również zweryfikować swój model biznesowy ze względu na pojawienie się nowych graczy na rynku usług szkoleniowych on-line. Trudno bowiem się łudzić, iż po zakończeniu trwającej epidemii Ci gracze, którym szkolenia on-line udały się wycofają je ze swojej oferty.

Czy zatem firmy, które dotychczas oferowały szkolenia on-line powinny wejść na rynek szkoleń stacjonarnych? Taki PIVOT byłby całkowicie pomyłką. Gdzie zatem kryje się PIVOT dla takich firm? W pierwszej kolejności w potrzebach grupy odbiorców (Customer Need Pivot).

PIVOT robią wszyscy, którzy chcą być konkurencyjni i innowacyjni na rynku.

Rodzaje PIVOT-ów:

 1) Business Architecture Pivot – firmy zazwyczaj przyjmują jedną z dwóch strategii:

  1. a) złożony model systemowy – wysoka marża, niskie obroty. Ta strategia kierowana jest zazwyczaj dla produktów sprzedawanych na rynku B2B
  2. b) model działania w oparciu o wolumen – niska marża, wysokie obroty. Przyjęto, że ta strategia jest lepsza dla produktów, usług kierowanych na rynek konsumencki.

PIVOT polega na zmianie dotychczasowego modelu na inny, np. z rynku masowego przechodzimy na rynek konsumencki i odwrotnie.

2) Channel Pivot – firmy dostarczają swoje usługi, bądź produkty różnymi kanałami sprzedaży. Wiele firm zamiast tworzyć kosztowne własne kanały dystrybucji, korzystają z pośredników i ich kanałów dotarcia do docelowego klienta. PIVOT najczęściej pojawia się dość naturalnie w przypadku, gdy firmy umacniają swoją markę na rynku i mogą pozwolić sobie na utworzenie swojego kanału sprzedaży- tak jak np. zrobiło to Apple. Z drugiej strony przykładem PIVOT są produkty spożywcze dużych graczy na rynku dostarczane pod postacią “marek własnych” wielkopowierzchniowych sklepów. Innym przykładem jest to co dzieje się w branży prasy drukowanej (czasopisma, gazety), które zostały niejako zmuszone do “przeniesienia” się przynajmniej częściowo do sieci.

3) Customer Need Pivot – wydawało Ci się, że poprawnie zdiagnozowałeś problem Twojego klienta, jednak po wprowadzeniu produktu na rynek okazuje się, że problem Twojego klienta jest zupełnie inny? A może za wąsko podszedłeś do analizy problemu, bagatelizując problemy pokrewne. Czasem jest tak, że to właśnie korzystanie z Twojego produktu powoduje pojawienie się nowej potrzeby u Twojego Klienta, na którą szybko trzeba zareagować.

4) Customer Segment Pivot – mówiąc krótko: masz odpowiedni produkt, ale kierujesz go do niewłaściwej grupy odbiorców.

5) Engine of Growth Pivot – firma zmienia strategię rozwoju w celu znalezienia szybszej i bardziej rentownej ścieżki wzrostu. Czasem może oznaczać zmianę sposobu realizacji kreowanej wartości.

6) Platform Pivot- to odejście od aplikacji na rzecz platformy lub odejście od platformy na rzecz pojedynczej aplikacji.

7) Technology Pivot – pojawia się możliwość opracowania takiego samego rozwiązania, ale za pomocą innej technologii. Taki ruch odbierany jest przez grupę odbiorców najczęściej jako przejaw innowacji.

8) Value Capture Pivot –oznacza zmianę sposobu zarabiania na rozwiązaniu. Możemy tutaj wyróżnić jednorazową płatność, abonament, sprzedaż ratalna, płatność za użytkowanie, czy nawet płatność za uzyskany rezultat.

9) Zoom-in Pivot –skupiasz się tylko na jednym aspekcie Twojego produktu, tworząc tym samym nowy produkt. Najlepszym przykładem takiego PIVOT-u jest Benefit System, który początkowo oferował benefity pozapłacowe dla pracowników. Ze wszystkich oferowanych benefitów pracodawcy najbardziej cenili siłownię, stąd firma przestawiła się na operatora, który oferuje tylko kartę na siłownię.

10) Zoom-out Pivot – czyli rozszerzanie swojego produktu o nowe aspekty tak długo, póki nie będzie stanowił wartości dla grupy odbiorców. To dokładanie nowych funkcjonalności, czy rozszerzenie oferty w oparciu o sposób pracy grupy odbiorców z Twoim produktem.

 

 
Powiadom mnie o zapisach

Dowiesz się, gdy tylko ruszą.

Szczegóły
Brak danych o cenie
Techniki identyfikacji wymagań, które sprawdzą się w Agile i nie tylko…
Zapisy wkrótce

Podstawowa przyczyna problemów w komunikacji między Klientem a Dostawcą wynika z rozbieżności między tym, co klient mówi, a tym czego rzeczywiście potrzebuje.

W przypadków rozwiązań technologicznych Klient sugeruje się najczęściej rozwiązaniami, które obejrzał w internecie, bądź próbuje przepisać dotychczasową funkcjonalność istniejącego systemu wraz z jej błędami i regułami.

Dlatego umiejętne korzystanie z technik w procesie identyfikacji wymagań pozwoli na uniknięcie niedopowiedzeń czy domysłów, które najczęściej pojawiają się na ostatnim etapie projektu IT- testów przez Klienta.

Podczas testów Klientowi wydawało się, że coś zostanie zaimplementowane, Dostawca jest nie tyle zdziwiony, co poddenerwowany tym, że w trakcie rozmów dane wymaganie nie zostało przez Klienta wypowiedziane.

Czy podczas etapu identyfikacji wymagań muszę korzystać ze wszystkich dostępnych technik? Odpowiedziałabym jak typowy handlowiec – “to zależy”. Zależy od Klienta, specyfiki projektu, ale również od poziomu naszej wiedzy dziedzinowej. Istnieją jednak “żelazne zasady”, a raczej techniki, których użycie podczas spotkania z biznesem minimalizuje ryzyko pominięcia ważnych dla niego kwestii.

W artykule przedstawiam wybrane techniki, które sprawdzą się w środowisku zwinnym, ale wynikają z tradycyjnego podejścia do tworzenia oprogramowania.

1. Co rozumiemy poprzez etap pozyskiwania i identyfikacji wymagań w projekcie?

Pozyskiwanie wymagań – proces identyfikowania wymagań pochodzących z różnych źródeł za pośrednictwem rozmów, warsztatów, grup fokusowych, obserwacji, analiz dokumentów oraz innych mechanizmów.

Celem identyfikacji wymagań jest:

  1. Identyfikacja wszystkich pożądanych funkcji, charakterystyk, ograniczeń oraz oczekiwań
  2. Zorientowanie wymagań względem wizji projektu
  3. Uszczegółowienie wymagań wysokopoziomowych i jasne opisanie funkcji oraz usług
  4. Wyłączenie funkcji i cech, których klient nie potrzebuje

Na początkowym etapie prac nad projektem analityk biznesowy czy inżynier wymagań (analityk biznesowo-systemowy) powinien zaplanować, jakie będzie jego podejście do pozyskiwania wymagań. Dzięki planowaniu unikniemy sytuacji, w których uczestnicy procesu będą odrywani od swoich zajęć w celu wykonania innych czynności.
Plan pozyskiwania wymagań obejmuje techniki, które będziesz stosować oraz wskazania, kiedy w i jakim celu chcesz z nich skorzystać.

Zagadnienia, o których musisz pamiętać:

1. Strategia pozyskiwania i planowane techniki

a) Zdecyduj z jakich technik będziesz korzystać w odniesieniu do każdej grupy interesariuszy
b) Łącz ze sobą techniki pozyskiwania

2. Harmonogram i oszacowanie zasobów

a) Zidentyfikuj osoby po stronie klienta i dostawcy, które będą brały udział w poszczególnych aktywnościach- sprawdź ich dostępność
b) Oszacuj czas jaki będziesz potrzebować na przygotowanie się do pozyskiwania wymagań oraz analizy materiałów

3. Spodziewane efekty

Podziel pozyskiwanie wymagań względem grup interesariuszy i rodzaje dokumentów, jakie mają być wytworzone w ramach współpracy.

4.Ryzyko związane z pozyskiwaniem

a) Zidentyfikuj czynniki uniemożliwiające pozyskiwanie wymagań zgodnie z planem

b) Znajdź rozwiązanie i zaplanuj aktywności minimalizujące ryzyko

5.Klasyfikowanie informacji pozyskanych od użytkownika

a) Nie oczekuj, że użytkownicy przedstawią zwięzłą, kompletną i dobrze zorganizowaną listę swoich potrzeb
b) Analityk musi klasyfikować otrzymane informacje wg. kategorii, dzięki czemu będzie mógł je rozwijać
c) Podczas identyfikacji wymagań może natrafić na zagadnienia, które wymagają dodatkowych wyjaśnień
d) Podczas przeglądania tak zaklasyfikowane wymagania biznesowe klienta pozwolą Ci na sprawdzenie czy są kompletne, czy są kwestie otwarte, czy są wymagania ze sobą sprzeczne

2. Kryteria, którymi należy się kierować przy wybieraniu technik zbierania wymagań

Prezentowane techniki uwzględniają następujące kryteria:

Kryterium 1 – Technika pozwala na zrozumienie podstawowych funkcji, jakie ma posiadać produkt. Jest to wartość bazowa,na której możemy budować kolejne funkcjonalności zaoszczędzając w przyszłości czas na dyskusję o podstawowych potrzebach Klienta.
Kryterium 2 – Zainwestowana praca jest proporcjonalna do uzyskanej dzięki niej wartości biznesowej
Kryterium 3 – Użyta technika pozwala zespołowi wytwarzającemu oprogramowanie skupić się na potrzebach biznesowych i wynikających z nich wymaganiach funkcjonalnych

3. Przegląd technik identyfikacji wymagań podczas spotkań z Klientem

Poniżej zostały zaprezentowane techniki wraz z bezwzględną kolejnością ich stosowania:

Krok 1: Przepływ procesu biznesowego

Analityk biznesowy, ale również inżynier wymagań (analityk biznesowo-systemowy) podczas zbierania wymagań musi upewnić się, aby każdy proces biznesowy dostarczał wartość biznesową. Proces też musi posiadać interesariusza (aktora) wykonującego określone zadanie, dane wejściowe oraz wyjściowe.

Podczas zbierania wymagań nie chodzi o to, tym bardziej w podejściu zwinnym, aby rysować proces biznesowy za pomocą języka BPMN (aczkolwiek nikomu tego nie zabronię).

Warto skupić się w pierwszej kolejności na kilku elementach:

  1. <Aktorzy> uczestniczący w procesie biznesowym,
  2. <Krok procesu>, jaki wykonywany jest przez <aktora>
  3. <Narzędzia>, które używane są w ramach danego kroku
  4. Jakie <dane wejściowe> potrzebuje <aktor>, aby wykonać <zadanie> w danym <kroku procesu>?
  5. Kto <aktor> przygotowuje te <dane>?
  6. Jakie <dane wyjściowe> są wytwarzane przez <aktora> w danym <kroku procesu>?
  7. Czy <narzędzie>, z którego korzysta w danym <kroku procesu> generuje <dokumenty>? Jeśli tak, to jakie? Jak są przechowywane? Kto <aktor> ma do nich dostęp? Kto <aktor> nie powinien mieć do nich dostępu? W przypadku danych warto sprawdzić je pod kątem RODO.
  8. Co musi się stać, aby <aktor> nie mógł rozpocząć wykonywanie swojego <kroku procesu>?
  9. Czy są wyjątki od standardowego postępowania w danym <kroku procesu>? (Przypis: takie pytanie jest dość ogólne. Najczęściej Klient odpowie: “Nie ma wyjątków”. Warto zatem powyższe pytanie przekształcić w pytania pomocnicze, np. Jak wygląda <krok procesowy> jeśli nie masz kompletnych <danych wejściowych>? Jak wygląda <krok procesowy>, jeśli <narzędzie> nie wygenerowało dokumentu? itp.

W pierwszym kroku rozmawiamy z Klientem, który opowiada o procesie biznesowym, jaki obecnie funkcjonuje (AS-IS). Najczęściej jest to proces niewydajny, który należy zoptymalizować. Czasem wydajność procesu biznesowego jest zadowalająca, lecz potrzeba pojawienia się rozwiązania informatycznego wynika z rozwoju organizacji Klienta.

Zanim dojdziesz do optymalizacji, w której bierze udział Twój produkt, który zaprojektujesz, musisz zrobić jeszcze jeden krok- porozmawiać z Klientem o procesie docelowym (TO BE). Pamiętaj! To nie jest proces docelowy. Jest to jedynie “przymiarka” do docelowego procesu biznesowego widziany oczami Klienta. Bardzo często jest jeszcze mniej wydajny niż ten pierwotny (AS-IS), bo przesiąknięty przyzwyczajeniami Klienta. Jednak nie pomijaj tego kroku, bo dzięki niemu dowiesz się do jakiego rozwiązania dąży Klient. A przyzwyczajenia Klienta mogą okazać się ważnym elementem docelowego systemu, bądź “ukrytym” wymaganiem.

Z drugiej strony jako analitycy (analityk biznesowy i inżynier wymagań) mamy tendencję do “przegrzewania” funkcjonalności, czyli dostarczanie funkcjonalności, których klient nie potrzebuje, ale wydały nam się “fajne”. Etap rozmowy z Klientem o docelowym rozwiązaniu pozwala nam “tylko” oprogramować niektóre funkcje bez ich zbędnego rozdmuchiwania 🙂 Oczywiście nie popadajmy w drugą skrajność, czyli zamiast analizy spisujemy to co powiedział Klient i implementujemy 1:1. Dlatego tak ważne jest, aby skupić się  również na regułach biznesowych.

Na czym zatem polega cała optymalizacja procesu biznesowego. Tutaj kryje się cała filozofia rodem z filozofii Agile 🙂 Optymalizacja procesu biznesowego to w skrócie jak najszybsze dostarczenie wartości końcowej (usługi, bądź produktu procesu biznesowego) przy użyciu minimum kroków. Jeśli w procesie biznesowym udział bierze system, jego zadaniem jest przejęcie niektórych <kroków procesu>, które do tej pory wykonywał <aktor>, jeśli są one powtarzalne.

Krok 2: Diagram kontekstowy i mapa ekosystemu

Rozmowę z Klientem bezwzględnie rozpoczynamy od ustalenia przepływu procesu biznesowego. Bowiem w nim znajdują się <narzędzia>, którymi mogą być systemy, jakie powinniśmy wziąć pod uwagę przy projektowaniu naszego rozwiązania.

Diagram kontekstowy oraz mapa ekosystemu pozwala na określenie prawdziwego zakresu projektu. Wszystko przedstawione jest w formie graficznej.

Mapa ekosystemu pokazuje wszystkie systemy mające związek z Twoim projektowanym rozwiązaniem. Mapa ekosystemu pokazuje dodatkowo “otoczenie systemowe”, czyli również te systemy, które nie muszą być bezpośrednio związane z Twoim systemem lecz mogą na niego pośredni wpływ. Twój system również może mieć wpływ na poprawne działanie ww. systemów poprzez konieczność generowania danych niezbędnych do podstawowych funkcjonalności tych systemów.

Diagram kontekstowy pokazuje jak nowe rozwiązanie systemowe “wpasowuje się” w środowisko. Definiuje on granice oraz interfejsy pomiędzy nowym systemem a już istniejącymi systemami, aktorami, ale również używanymi danymi.

Najczęściej podczas pracy w projekcie IT napotykamy sytuację, kiedy potrzebny jest np. raport w systemie zewnętrznym niepowiązanym bezpośrednio z naszym systemem.

Dlatego ważne, jest aby mapa ekosystemu i diagram kontekstowy były częścią analizy, jaką wykonujesz w projekcie. To zewnętrzny niepowiązany system jest źródłem nowych wymagań, o których nie pamięta najczęściej Klient. Wróć! Pamięta, ale dopiero w fazie testów 🙂

Krok 3: Reguły biznesowe

O powiązaniu między wymaganiem biznesowym a regułą biznesową pisałam tutaj: https://analizawymagan.pl/wymaganie-biznesowe-a-regula-biznesowa/

Krok 4: Diagram przepływu danych

Mając wykonane następujące kroki: przepływ procesu biznesowego -> mapa ekosystemu -> diagram kontekstowy —>reguły biznesowe czas na diagram przepływu danych, w którym przyjmuje się podejście do analizy systemów polegające na dekompozycji funkcjonalnej.

Dzięki takiemu podejściu jesteśmy w stanie zidentyfikować brakujące <dane> w <kroku procesu biznesowego>.

Diagram przepływu danych dodatkowo pokazuje kontekst wymagań funkcjonalnych związany ze sposobem, w jaki użytkownik wykonuje określone zadania w <kroku procesu>.

Sprawdź wspólnie z Klientem, czy na diagramie przepływu danych znajdują się wszystkie dane wejściowe i wyjściowe, które są mu znane. Zweryfikujcie czy procesy przetwarzające dane zostały poprawnie opisane oraz czy nie narysowano niepotrzebnych przepływów. Podczas weryfikacji może się zdarzyć, że uda Wam się zidentyfikować nowych <aktorów>, procesy biznesowe czy nawet połączenia z systemami.

4. Dodatek: Dokumentowanie podczas spotkań z biznesem

Technika ta jest jedynie wsparciem i pokazaniem, w jak prosty, szybki i efektywny sposób można wspólnie z Klientem zamodelować reguły biznesowe opierając się na rzeczywistym modelu, słowniku pojęć oraz listą reguł.

Dla przykładu zamodelujmy reguły biznesowe w procesie zamawiania przez Klienta auta w leasingu

W bardzo dużym uproszczeniu proces biznesowy wygląda następująco:

Po rozmowie Handlowca z Klientem na podstawie warunków finansowych,modelu pojazdu, Handlowiec przygotowuje ofertę z kalkulacją. Klient akceptuje ofertę, która staje się wnioskiem. Handlowiec po uzupełnieniu dodatkowych informacji, np. zgody na sprawdzenie w BIK i KRD wysyła wniosek do analizy ryzyka przez Analityka Ryzyka. Po analizie wydawana jest decyzja o finansowaniu.

Wystarczy tylko narysować powiązania między pojęciami, aktorami jakie wynikają z opisu i masz punkt wyjścia do zadawania pytań.

Powiadom mnie o zapisach

Dowiesz się, gdy tylko ruszą.

Szczegóły

Potrzebujesz wsparcia w wyborze?

Porozmawiajmy. Doradzę Ci opcję, która najlepej wesprze Cię na obecnym etapie rozwoju zawodowego.

Porozmawiajmy
PRACOWNIKU

Chcesz, aby pracodawca sfinansował Ci szkolenie?

Pomogę Ci przekonać go do tej decyzji.

Daj mi znać
PRACODAWCO

Chcesz zorganizować szkolenie dla pracowników?

Przygotuję szkolenie wewnętrzne ze specjalnym programem.

Porozmawiajmy