Opublikowano

Trendy analizy biznesowej 2016

Trendy analizy biznesowej w 2016 roku to głównie weryfikacja tego, co zostało zainicjowane w roku 2015.

Niepoprawnie zdefiniowany  cel biznesowy jest nadal aktualny, ponieważ trudno zweryfikować czy został zrealizowany. Podobna sytuacja jest w przypadku przewidywań trendów.

Zanim napiszę o trendach, jakie przewiduję na 2016 rok zweryfikujmy, na ile udało się przewidzieć to, co będzie działo się w 2015 roku (http://analizawymagan.pl/trendy-analizy-biznesowej-w-2015/).

Oto 8 trendów w analizie biznesowej z 2015 roku oraz ich weryfikacja w roku 2016:

TREND 1: Coraz częściej będziemy świadkami łączenia się podejścia zwinnego ze standardowym podejściem i tworzeniem hybryd: łączenia agile z waterfall – pod nazwą:Water-scrum-fall. Dla wielu organizacji będzie to łagodne wejście w zwinne metodyki przy zachowaniu dotychczasowych przyzwyczajeń.

Weryfikacja w 2016: Cały rok 2015 to triumf podejścia zwinnego w projektach – takiego purytańskiego, ale również pojawienia się hybryd różnego rodzaju. Organizacje nieprzygotowane do pracy w podejściu zwinnym wytworzyły własne frameworki, które stanowią zbiór różnych praktyk i podejść w wytwarzaniu oprogramowania, które pasują i sprawdzają się w ich organizacji. Nie jest to złe podejście – wręcz przeciwnie. Świadome tworzenie hybrydy może przynieść korzyść, jeśli wiemy czemu ma służyć – ma usprawniać pracę zespołom deweloperskim oraz umożliwiać szybki przepływ informacji od biznesu do IT i odwrotnie.

 

PRZEWIDYWANIA NA 2016: UMACNIANIE SIĘ TRENDU W 2016

 

TREND 2: Co to oznacza dla analityka? Po pierwsze będziemy coraz częściej pracować w środowiskach mieszanych, dla których będziemy wsparciem w zakresie nie tylko analizy jako reprezentacji wymagań Klienta, ale przede wszystkim będziemy zarządzać wymaganiami na całym procesie wytwórczym.

Weryfikacja w 2016: Zarządzanie wymaganiami to jedno z podstawowych zadań każdego inżyniera wymagań. Zgadza się. Jednak jak praktyka pokazywała w podejściu tradycyjnym zarządzanie wymaganiami kończyło się najczęściej na etapie zaakceptowania dokumentu SRS (System Requirements Specification). Z uwagi na pojawianie się metod iteracyjnych wytwarzania oprogramowania, zarządzanie wymaganiami obejmuje cały proces wytwarzania oprogramowania. Dzięki czemu analityk uczestniczy w projekcie również na etapie testów akceptacyjnych z Klientem.

 

PRZEWIDYWANIA NA 2016: UMACNIANIE SIĘ TRENDU W 2016

TREND 3: Mimo rosnącego wpływu rozwiązań będących w chmurze, analityk będzie coraz więcej miał do czynienia z integracjami między systemami. Liczba nowych rozwiązań oferowanych Klientom z roku na rok rośnie w lawinowym tempie. Klient zamiast jednego spójnego rozwiązania, dla każdego obszaru swojego biznesu otrzymuje osobny program, aplikację, dedykowane rozwiązanie. Problem z ich obsługą pojawia się na etapie spójności danych pomiędzy systemami. Klienci coraz częściej zwracają uwagę na transparentność rozwiązań, które umożliwią płynne przekazywanie danych pomiędzy wszystkimi rozwiązaniami, jakie posiada w Firmie. Wymusza to konieczność połączenia systemów między sobą w celu wymiany informacji.

Weryfikacja w 2016: Jak zaobserwowano rok 2015 to kontynuacja integracji systemów IT w sektorze energetycznym. Koncerny energetyczne zainwestowały nie tylko w samą integrację swoich systemów, ale przede wszystkim na rozwój m.in systemów billingowych.  Coraz więcej pojawiło się projektów związanych z  integracją z systemami CRM oraz wdrożeniem rozwiązań dla tzw. „smart meteringu”, czyli  inteligentnych systemów pomiarowych w energetyce.

 

PRZEWIDYWANIA NA 2016: Umacnianie się trendu w 2016roku, choć w energetyce nie przewiduje się szybkiego wzrostu wdrożeń rozwiązań wykorzystujących chmurę.

 

TREND 4: Z jednej strony Analitycy będą musieli identyfikować potrzeby Klienta, ale coraz częściej będą musieli zwracać uwagę na aspekty bezpieczeństwa danych. Jest to nowy obszar szczególnie w analizie biznesowej, która po raz pierwszy wkracza w obszar analizy systemowej, tym samym wymuszając na analitykach rozbudowanie swoich kompetencji.

Weryfikacja w 2016: Analiza biznesowa okazała się niewystarczająca. Skupienie się tylko na tym aspekcie znacznie wydłuża proces wytwórczy z uwagi na konieczność wykonania analizy systemowej, czyli przeniesienia wymagań biznesowych w obszar projektowania rozwiązań systemowych. Taką tendencję zauważył już BABOK ver3, który powoli wchodzi w inżynierię wymagań. Coraz większa liczba analityków biznesowych dokształca się właśnie w tym kierunku.

 

PRZEWIDYWANIA NA 2016: UMACNIANIE SIĘ TRENDU W 2016, oraz wzrost popytu na certyfikację w kierunku inżynierii wymagań.

 

PRZYPIS: Inżynieria wymagań jest dziedziną interdyscyplinarną, ponieważ łączy ze sobą wiele dziedzin, które mają kluczowe znaczenie dla powodzenia projektu IT. Do nich należą: analiza biznesowa, analiza systemowa, zarządzanie projektem, technologie programowania, sposoby testowania, regulacje prawne, oraz psychologia. Szczególnie ta ostatnia dziedzina od kilku lat nabiera dużego znaczenia w procesie zbierania wymagań, kiedy wielu analityków szuka technik rozmawiania z Klientami, czy radzenia z różnymi emocjami podczas spotkań biznesowych.Potrzeba szerzenia wiedzy i dobrych praktyk w zakresie inżynierii wymagań była jednym z powodów powstania Stowarzyszenia Inżynierii Wymagań (http://www.siw.org.pl)

TREND 5: Tak jak w poprzednich latach nadal będzie utrzymywała się tendencja pomniejszania roli analityka w projektach.

Weryfikacja w 2016: Pierwszy przewidywany trend, który się nie sprawdził w 100%.  Klienci dostrzegli, że udział analityka w projektach IT to dobrze zainwestowane pieniądze, a przede wszystkim gwarancja zrozumienia ich języka. Coraz chętniej korzystają z warsztatów analitycznych oraz innych form współpracy z analitykiem na etapie identyfikacji i zbierania wymagań, ale przede wszystkim podczas ich opracowywania.

 

PRZEWIDYWANIA NA 2016: Umocnienie trendu coraz większej współpracy między Klientem a Analitykiem w całym procesie wytwarzania oprogramowania. Przewidywany jest również wzrost zapotrzebowania na analityka z wiedzą dziedzinową w projektach IT, na co wskazują ostatnie badania . Wg. Forbes (http://kariera.forbes.pl/2016-rok-najlepsze-zawody-nadchodzacego-roku,artykuly,201511,1,1,3.html) drugim najbardziej pożądanym zawodem będzie Product Manager w sektorze bankowym.

TREND 6: Wprowadzenie zwinnego podejścia, bądź podejścia waterscrumfall, będzie sprawiał wrażenie rozmycia kompetencji analityka na cały zespół.

Weryfikacja w 2016: Zwinne podejście niejako wymusza tworzenie interdyscyplinarnych zespołów, czyli również takich, którzy posiadają umiejętności analityczne. Fakt braku roli analityka jako takiej w podejściu zwinnym faktycznie może sprawiać wrażenie rozmycia kompetencji.

 

PRZEWIDYWANIA NA 2016: Jak pokazuje praktyka, wiele organizacji, w których udało się wdrożyć podejście zwinne/hybrydę metod trudno jest zbudować zespół interdyscyplinarny, który będzie skupiał umiejętności testera, analityka, programisty. Dlatego też coraz częściej można zaobserwować wytworzenie mniejszych specjalistycznych grup osób z określoną specjalizacją, np. analityczną, którzy dostarczają produkty zespołowi deweloperskiemu. Dodatkowo zauważalny jest trend edukowania grup: tester, programista, analityk pod kątem umiejętności analitycznych. Stąd na rynku coraz częściej pojawiają się nowe stanowiska takie jak np. analityk- tester.

 

Opublikowano

Główne trendy analizy biznesowej na 2017 rok

Jakie są trendy analizy biznesowej na 2017 rok? Rola analityka nadal będzie taka ważna jak w roku ubiegłym? Co ze zwinnością analityka?

Przewidywania głównych trendów analizy biznesowej na dany rok nigdy nie należy do najprostszych. Wymaga obserwacji tego co dzieje się na świecie, ale również w Polsce w tym zawodzie. W zeszłym roku pojawił się opis weryfikacji trendów z 2015 roku (http://analizawymagan.pl/trendy-w-analizie-biznesowej/). Jak będzie w tym roku dowiemy się dopiero na początku roku 2018, kiedy przewidywania zostaną poddane weryfikacji.

Oto 3 kluczowe trendy analizy biznesowej na rok 2017.

1. Analityk wkracza do zwinnego świata, czyli analityk w agile

W świecie Agile nie ma specjalnie dedykowanej roli analityka. Nic nie wskazuje również na to, aby w przyszłości miałaby się pojawić, choć jak to mówią niektórzy „nigdy nie mów nigdy”. Mimo to w przedsiębiorstwach od co najmniej 3 lat można zaobserwować chęć utworzenia nowej roli w scrum, jakim jest analityk. Jest to naturalna kolej rzeczy szczególnie w tych przedsiębiorstwach, których wdrożenie zwinnego podejścia skończyło się na wypowiedzeniu słów: „od dziś będziemy tworzyć produkty zwinnie”.  Dlaczego jest to naturalna kolej rzeczy? Ponieważ nikt nie wie co zrobić z testerem, kierownikiem projektu i analitykiem w nowej rzeczywistości. Z braku pomysłu analityk najczęściej ubierany jest w buty „Product Ownera” – przecież analityk i Product Owner kontaktują się z programistami i klientem. Prawda, lecz kompetencji Product Ownera jest dużo więcej. Najważniejszą z nich jest jednak możliwość samodzielnego podejmowania decyzji i wyznaczania kierunku rozwoju aplikacji. Czy jest to złe? Nie, jeśli analityk będzie miał możliwość podejmowania takich decyzji.

Zapowiada się, że rok 2017 będzie nadal „próbowaniem” metodyk zwinnych w projektach do tej pory wytwarzanych metodą tradycyjną. Będzie to rok  naznaczony poszukiwaniem modeli umożliwiających połączenie metodyk zwinnnych i tradycyjnych –Water-scrum-fall (o trendzie pisałam w roku 2015 – http://analizawymagan.pl/trendy-analizy-biznesowej-w-2015/. Zatem należy spodziewać się, że w obecnym roku coraz częściej pojawią się pytania: „Co z tym analitykiem w agile”.

Rok 2017 to również metody zwinne w zamówieniach publicznych zgodnie z opinią prawną (https://cppc.gov.pl/opinia-prawna-sprawie-mozliwosci-sposobu-wykorzystania-metodyki-agile-projektach-informatycznych-realizowanych-zastosowaniem-ustawy-prawo-zamowien-publicznych/). W tym obszarze wydaje się, że będzie najwięcej „kombinowania”, gdzie tego analityka „upchać”. Jestem przekonana, że zaobserwujemy powstawanie frameworków, które będą złożeniem podejścia zwinnego i tradycyjnego w obszarze zamówień publicznych. Dlatego analitycy mogą spodziewać się, że w ofertach pracy na 2017 rok coraz częściej na liście wymaganych umiejętności będzie się pojawiać znajomość metodyk zwinnych.

2.Tytuł stanowiska zobowiązuje

Wg raportu Pracuj.pl: „W III kwartale pracodawcy znacząco zwiększyli zapotrzebowanie na specjalistów IT – wzrost ofert skierowanych do nich w stosunku do analogicznego kwartału 2015 r. wyniósł 13,9%. Wzrosło także zapotrzebowanie na inżynierów – o 10,7% w ujęciu rok do roku. Wciąż także obserwuje się rosnące zapotrzebowania na pracowników produkcji, w III kwartale 2016 r. wzrost zapotrzebowania na tych specjalistów wyniósł 17,1% w porównaniu z analogicznym okresem roku poprzedniego.” (http://www.pracuj-dla-mediow.pl/pr/332045/pracuj-pl-raport-rynek-pracy-specjalistow-w-iii-kw-2016-roku).

Pracodawcy nadal poszukują specjalistów na stanowisko: „Analityk”, które na przestrzeni lat stało się pojęciem dość pojemnym. Niektórzy na stanowisku: „analityk” zajmują się tylko i wyłącznie tworzeniem dokumentu wizji projektu, który zawiera specyfikację pożądanych funkcji rozwiązania oraz analizę przedsiębiorstwa. Inni robią wszystko, począwszy od analizy przedsiębiorstwa, aż po przygotowanie dokumentu SRS (Specification Requirements Software) zawierający szczegółowy opis rozwiązania.

Rynek zauważył, że potrzeba tak naprawdę obu kompetencji: analityka biznesowego i analityka systemowego, czyli inżyniera wymagań.

 

Mimo takiej wiedzy pracodawców, nadal wielu decyduje się na nazwy stanowisk takich jak : analityk biznesowy, analityk biznesowo-systemowy, analityk systemowy, architekt biznesu, technical writer. Perełkami wśród ogłoszeń są stanowiska: „Inżynier wymagań”.

Obserwując taki podział kompetencji w zawodzie: „Analityk” możemy spodziewać się w 2017 roku usystematyzowania nazewnictwa w taki sposób, aby pracodawca i pracownik wiedział, jakie są oczekiwane umiejętności związane są z konkretnym stanowiskiem. Jest to oczywiście proces, który nie zakończy się w obecnym roku. Dążymy do sytuacji, kiedy chcąc zatrudnić: „analityka biznesowego” pracodawca będzie miał na myśli osobę, która wykona analizę przedsiębiorstwa, przygotuje ten dokument wizji, lecz nie będzie oczekiwał znajomości relacyjnej bazy danych, aby opisać jak ma być dokładnie zrealizowane dane rozwiązanie – od tego jest inżynier wymagań.

Zwiększone zainteresowanie szkoleniami z zakresu inżynierii wymagań tylko potwierdza ten trend. Niestety nadal nam daleko do standardów światowych, gdzie funkcjonowanie dwóch ról: inżyniera wymagań i analityka biznesowego jest normą.

Czy wiesz, że w Polsce od 2014 roku działa pierwsze stowarzyszenie dla analityków biznesowych i inżynierów wymagań- Stowarzyszenie Inżynierii Wymagań (www.siw.org.pl) ?

3.Analityk ma się dobrze

Trend pomniejszania roli analityka w projektach przewidywany w roku 2015 na podstawie obserwacji z lat ubiegłych po raz pierwszy nie sprawdził się. Rola analityka w projektach w 2016 roku znacznie wzrosła w porównaniu do lat ubiegłych. Trend obserwowany od kilku lat to specjalizacja analityków w określonych dziedzinach. Przez wiele lat uważano, że skoro jesteś analitykiem to odnajdziesz się w każdej dziedzinie. Jest to prawda, lecz

„Jesteś tak dobrym analitykiem jak dobrze znasz dziedzinę, w której pracujesz” (M.Perendyk).

Tworzenie specjalizacji to trend, który również w tym roku będzie się utrzymywał, a nawet będzie miał silniejsze znaczenie niż w latach ubiegłych ze względu na coraz większy wpływ nowych technologii oraz pojawianie się rozwiązań dedykowanych na telefony komórkowe.

Z  badań „U.S. Bureau of Labor Statistics, Employment Projections Program” wynika, że amerykańscy przedsiębiorcy do roku 2020 będą potrzebować 876 tys. analityków biznesowych. To nie jest trend jedynie światowy, lecz również obserwowany w Polsce co widać po liczbie ofert pracy na to stanowisko.

A jakie trendy Ty typujesz na ten rok?

 

Opublikowano

IREB ® i REQB ® łączą siły- co to zmienia w certyfikacji?

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)

Opublikowano

Czy Twój cel biznesowy jest S.M.A.R.T?

Minął 2016 rok, a Ty właśnie zdałeś sobie sprawę, że nie udało Ci się zrealizować wszystkich planów, jakie założyłeś na jego początku? Dziś Twoja lista ponownie się zapełnia celami na 2017 rok. Ten rok będzie przecież lepszy, cele bardziej realne. Z pewnością Ci się uda…..jeśli tylko podejdziesz do nich jak do celów biznesowych w projekcie IT. Spójrz na swoje cele jak na cele biznesowe w projekcie IT.

W pierwszej kolejności musimy odpowiedzieć na pytanie czym jest cel biznesowy w projekcie IT?

Cel biznesowy – finansowa albo niefinansowa korzyść biznesowa, jaką spodziewa się odnieść organizacja w wyniku zrealizowania projektu lub innej inicjatywy (K.Wiegers, J.Betty)

Na etapie zbierania wymagań interesariusz nie będzie mówił o swoich celach biznesowych, lecz o funkcjonalnościach jakie są jego zdaniem niezbędne. Zadaniem każdego analityka, inżyniera wymagań jest poszukiwanie celu, jaki kryje się pod opisem danej funkcji, czy funkcjonalności. W jaki sposób to zrobić? Sprawdzając czy cel biznesowy jest: S.M.A.R.T.

1. S – (ang.Simple) – PROSTY

Cel musi być sformułowany w sposób jednoznaczny, prosty oraz zrozumiały. Dobrze sformułowany cel nie pozostawia miejsca na interpretację, domyślanie się. Proste sformułowanie celu pozwala dostawcy opracować różne rozwiązania, dzięki którym cel może być on osiągnięty. Pamiętaj, że cel nie musi być wyrażony w jednym zdaniu.

2. M – (ang.Measurable) – MIERZALNY

Definiując cel biznesowy nie możemy pomijać elementu, jakim jest jego mierzenie. To miara odpowiada nam na pytania: „ Co to oznacza, że funkcja została dobrze wykonana?” „Kiedy wiemy, że funkcjonalność jest gotowa do oddania Klientowi?” Aby zdefiniować miarę założonego celu biznesowego wystarczy poprosić klienta o opowiedzenie, w jaki sposób będzie testował daną funkcję, czy funkcjonalność. Pamiętaj, że tester sprawdza jedynie, czy produkt jest zgodny z opisem przygotowanym przez analityka biznesowego, inżyniera wymagań. Klient natomiast wykonuje testy sprawdzając poprawność funkcji wykorzystując je w normalnej pracy operacyjnej. Stąd wynikają duże nieporozumienia przy odbiorze funkcjonalności przez Klienta. Jeśli przy definiowaniu funkcjonalności nie wiemy, jaki jest jej cel powstania, i dodatkowo nie dopytamy o sposób testowania funkcjonalności przez Klienta możemy mieć duże problemy przy odbiorze produktu przez Klienta. Zawsze znajdzie się argument przemawiający za tym, że wg. Klienta funkcjonalność nie jest gotowa, bo nieuwzględniona została jeszcze jedna opcja.

Jeśli cel biznesowy projektu zakłada poprawienie wydajności, bądź generowania (czegoś) nie zapominaj o mierze jakim jest czas, ilość.

Nie pisz: „Umożliwienie generowania faktur po dokonaniu zakupu’, wiem, że to ładnie brzmi i nie trzeba zbytnio się pochylać nad tym do czego będzie wykorzystywany system – przecież jest wpisane w umowie.

Zastanów się w jaki sposób będzie sprawdzał to tester i Klient? Czy wygenerowanie 1 faktury jest wystarczającym potwierdzeniem poprawności działania? Czy generowanie 1000 faktur w ciągu 10 minut jest wystarczające dla Klienta, aby móc powiedzieć, że funkcjonalność działa zgodnie z oczekiwaniami?

3. A – (ang. Achievable) – OSIĄGALNY

Realizm – to słowo, które powinno nam towarzyszyć przy definiowaniu celu biznesowego. Nie możemy zakładać celu biznesowego, który nie jest możliwy do osiągnięcia w założonym czasie i środkach, wiedzy oraz umiejętnościach. Co to oznacza w praktyce? Wspólnie z klientem należy się zastanowić czy przy użyciu wszystkich możliwości jesteśmy w stanie dostarczyć funkcjonalność realizującą dany cel.

Spójrzmy na przykład:

System umożliwiał generowanie 100 faktur w ciągu 5 minut. Celem projektu jest zwiększenie wydajności systemu, który generowałby 100 faktur, ale w ciągu 3,5 minuty.

W pierwszej kolejności sprawdzamy ograniczenia, czyli sprawdzamy, przy jakich warunkach system jest w stanie osiągnąć taki czas generowania faktur. To co z punktu widzenia klienta jest organiczeniem, dla dostawcy jest doprecyzowaniem warunków, przy których zapewnia on poprawność działania funkcjonalności.

4.  R – (ang.Relevant) – ISTOTNY

Cel biznesowy musi być „krokiem naprzód” dla organizacji, musi nieść korzyść biznesową. W jaki sposób to sprawdzić? Zapytaj klienta:

„ W jaki sposób obecnie radzi sobie z problemem?”

„Ile zaoszczędzi czasu/pieniędzy, jeśli funkcjonalność nie zostanie wdrożona?”

Jeśli klient nadal twierdzi, że cel jest polepszeniem jego pracy, po wycenie realizacji funkcjonalności, która ma pozwolić mu osiągnąć ten cel ponownie zapytaj: „Ile zaoszczędzi czasu/pieniędzy, jeśli funkcjonalność nie zostanie wdrożona?”.

Zestawienie kosztów z korzyścią, jaką niesie dana funkcjonalność jest ostatecznym sprawdzianem istotności danego celu. Jeśli koszty wdrożenia są większe niż korzyść, jaką można dzięki niemu odnieść, zazwyczaj cel nie był istotny.

5. T – (ang. Timely defined) – OKREŚLONY W CZASIE

Definiując cel biznesowy musimy zdefiniować jego horyzont czasowy, w jakim zamierza się go osiągnąć. Może to być konkretna data, bądź czas, np. 2 miesiące. W przypadku tego drugiego konieczne jest podanie od kiedy rozpoczynamy mierzenie czasu.

Przykłady poprawnie zdefiniowanych celów biznesowych:

„Klient osiągnie 75% udziału w rynku IT w ciągu 6 miesięcy od 1 stycznia 2017 roku”

„ Zostanie zwiększona wydajność obsługi transakcji o 15% w porównaniu ze stanem obecnym, tj. 100 transakcji na minutę”.

Spójrz teraz na listę swoich celów na 2017 i sprawdź czy są S.M.A.R.T
Opublikowano

Zarządzanie interesariuszami w projekcie – #1: Psychologia tłumu

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?

Opublikowano

Studia podyplomowe dla analityka

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ć. 

 

Opublikowano

Identyfikacja interesariuszy

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ąć?

Czytaj dalej Identyfikacja interesariuszy

Opublikowano

Zarządzanie interesariuszami w projekcie -#2 Trudny interesariusz

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.

Opublikowano

Jak zostać analitykiem biznesowym?

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.

Opublikowano

Kompetencje analityka wg. modelu T

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.

Opublikowano

Tworzenie produktów bez udziału interesariuszy- historia WoobyKids

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.

Opublikowano

Najczęstsze problemy analityka- jak ich uniknąć

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
Opublikowano

Proces rekrutacji analityka biznesowego z punktu widzenia firmy

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/

Opublikowano

Pytania rekrutacyjne na stanowisko analityka- część 1- podstawowa wiedza

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ąć.

Opublikowano

Rozmowa rekrutacyjna na stanowisko analityka- jak się przygotować?

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?

Opublikowano

Rozmowa rekrutacyjna oczami kandydata

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ć.

Opublikowano

Konferencja dla analityków

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