Spotkałam się ostatnio ze stwierdzeniem, że analityk źle wpływa na komunikację w projekcie tworząc efekt tzw. głuchego telefonu. Niepotrzebnie staje między biznesem a developerami. A popularne w analitycznej branży stwierdzenie „łączymy biznes i IT” zaczęło być odbierane negatywnie. Czy tak właśnie jest i niepotrzebnie robimy głuchy telefon? Zanim wydamy werdykt – najpierw analiza ?
Głuchy telefon
Pewnie każdy bawił się w głuchy telefon za dzieciaka ? Osoby siadają w kole lub w rzędzie. Jedna osoba wymyśla hasło i wyszeptuje je na ucho kolejnemu uczestnikowi. Ten przekazuje następnemu i tak dalej, aż dojdzie do ostatniej osoby. Ostatni mówi na głos co zrozumiał. Zazwyczaj to inne słowo, niż wymyślone hasło.
Głuchy telefon działa też w wersji rysowanej. Pierwsza osoba np. rysuje plecak, a ostatnia jakimś cudem kończy z odkurzaczem czy rakietą kosmiczną.
Trochę z teorii komunikacji
Na czym polega komunikacja? Jeden z twórców teorii informacji – zasłużony dla IT matematyk Claude Shannon oraz cybernetyk Warren Weaver stworzyli model transmisji sygnałów w układach telekomunikacyjnych wyróżniając elementy takie jak:
- źródło informacji,
- nadajnik,
- sygnał wysłany,
- źródło szumu,
- sygnał otrzymany,
- odbiornik,
- adresat informacji.
Wtrącając – głównym czynnikiem dającym efekty w zabawie w głuchy telefon daje szum powodowany szeptaniem do ucha. Czy zabawa miałaby sens, gdyby każdy uczestnik mówił głośno i wyraźnie? Jakie ma to podobieństwa do pracy analityka?
Główna różnica między światem komputerów a światem ludzi polega na tym, że ten pierwszy jest jednoznaczny, bardzo precyzyjny. Coś jest lub tego nie ma. W świecie ludzi to samo zdanie może być zupełnie inaczej odebrane przez różne osoby czy w różnych kontekstach. Zdanie „Fajna bluzka” jedna osoba odbierze jako komplement, a druga jako nabijanie się. Zależy to też od intonacji, tego jak ta bluzka wygląda, w jakim miejscu padają te słowa, od kogo do kogo, od historii relacji tych osób. Pewnie też wyzwania z komunikacją znają panowie z akcji typu „domyśl się”.
- Kochanie, czy mogę iść z kolegami na piwo?
- Rób co chcesz.
A potem foch, kiedy on zrobił, to co chciał ?
Albo:
“Aha, jest jej zimno.” W domyśle była to prośba o zamknięcie okna.
W komunikacji między ludźmi nie ma łatwo.
Inny uniwersalny model komunikacji opracował Roman Jakobson zwracają uwagę na takie elementy jak:
- nadawca,
- odbiorca,
- kontekst,
- kod,
- kontakt,
- komunikat.
Nadawca formułuje komunikat w określonym kontekście kodując go w znanym sobie kodzie. Posiada przy tym określoną intencję. Odrębną rzeczą jest interpretacja komunikatu przez odbiorcę. Ten zdekoduje wiadomość znanym sobie sposobem i zinterpretuje ją w znanym sobie kontekście.
A teraz o analizie
Komunikacja w biznesie ma inne wymagania niż komunikacja w świecie IT. Komunikat wystarczający do właściwej reakcji odbiorcy biznesowego może być niezrozumiały czy za mało precyzyjny dla odbiorcy IT. Nadawca komunikuje się w kontekście postrzeganym przez siebie wraz z wynikającymi z nimi założeniami, rzeczami zbyt oczywistymi, żeby przyszło do głowy o nich mówić i z brakiem świadomości, że niektóre rzeczy istnieją i są dla IT kluczowe. Kody stosowane przez biznes (np. żargonowe pojęcia) czy przez IT (kod, pseudokod, wymagania, user stories, UML) mogą być interpretowane odmiennie. Każda ze stron także inaczej może postrzegać kontekst, który wpływa na interpretację.
Jak wygląda to w najprostszym modelu projektowym z udziałem analityka?
Jest to widok przekazywania jednej informacji od jednego nadawcy do jednego odbiorcy. W projekcie wygląda to jednak bardziej skomplikowanie.
Załóżmy teraz, że klient/użytkownik nie jest 1, ale jest ich 5. Dajmy na to, że, developerów także jest 5.
Jak zinterpretujemy taką sytuację? Można powiedzieć, że analityk stał się główną osobą do kontaktu (SPOC – Single Point of Contact). Można też powiedzieć, że stworzył wąskie gardło komunikacji.
Co dostaniemy po usunięciu analityka?
Wygląda na to, że pozbyliśmy się wąskiego gardła komunikacji. Mamy jednak mnóstwo różnych strumieni. Co, jeśli równocześnie zajdą zdarzenia:
- Klient/Użytkownik 1 powie Developerowi 1, że chce A
- Klient/Użytkownik 2 powie Developerowi 2, że chce A i B
- Klient/Użytkownik 3 powie developerowi 3, że nie chce A
- Klient/Użytkownik 4 powie developerowi 4, że chce C, z czego wynika, że nie można zrobić B
- Klient/Użytkownik 5 powie developerowi 5, że chce A lub B
Potrzeba będzie bardziej intensywnej komunikacji między Developerami, żeby wychwytywać takie sytuacje. Po wychwyceniu jej, trzeba ją też rozwiązać, sprowadzając do wspólnego uzgodnionego stwierdzenia.
Dla usprawnienia komunikacji zespołu ze światem zewnętrznym tworzy się w Scrumie rolę Product Ownera.
PO robi też analizę.
Z założenia analityk powinien być specjalistą od komunikacji. Jego pracą jest odkrywanie i ujawnianie kontekstu, poznawanie kodów, nawiązywanie kontaktów. Będąc świadomym tych rzeczy, powinien tworzyć komunikaty, które spełniają swoje zadanie – zostają zinterpretowane zgodnie z intencją. W obie strony Biznes -> IT, IT -> Biznes. I powinien umieć weryfikować, że właśnie taka poprawna interpretacja miała miejsce. Analitycy są też szkoleni do tego, żeby ogarniać wielowątkowość komunikacji.
Przygotowanie bazy do komunikacji to: analiza interesariuszy.
Tworzenie kontekstu komunikacji to: określanie potrzeb, celów przedsięwzięcia, analiza organizacji, analiza kierunków rozwoju, analiza procesów biznesowych, analiza kontekstu zagadnienia, analiza reguł biznesowych, identyfikacja nastawienia, wpływu, zaangażowania interesariuszy.
Praca nad kodem komunikacji to: precyzowanie pojęć dziedziny, tłumaczenie znaczenia makiet, diagramów, wymagań.
Tworzenie kontaktu to nawiązywanie i utrzymywanie relacji.
Analiza komunikatu to rozbijanie go na czynniki pierwsze, zrozumienie intencji i sprawdzanie co to oznacza dla modeli działania systemów IT i w drugą stronę – dla biznesu.
Czy robisz te rzeczy w sposób sformalizowany czy nie, to sprawa drugorzędna. Byle skutecznie dla efektu komunikacji. Analityk powinien rozkminiać z kim rozmawiać w jaki sposób, kto jakie formy komunikacji lubi, kto jakie kody rozumie. Analityk powinien uwzględniać i łączyć różne potrzeby organizacji, wielu różnych klientów, użytkowników w jedno najbardziej wartościowe rozwiązanie.
Mamy różnych developerów. Jeden chce dostać konkret – co on ma zaprogramować, a na spotkaniach z biznesem usypia, bo nie pada „nic istotnego”. Inny chce dostać zadania, ale też rozumieć kontekst. Inny chce poznać problem i sam zaproponować rozwiązania (robiąc w sumie analizę). Komunikacja z zespołem to też dostosowanie się do jego potrzeb, umiejętności i chęci, mając z tyłu głowy oczekiwany efekt dla biznesu i motywacji zespołu.
Cała zabawa tkwi w tym, żeby przełożyć intencje biznesu na wpierające je system informatyczny. Czy developer sam tego nie jest w stanie zrobić? Przeważnie jest. Wyjątkiem są osoby bardzo biznesowe i bardzo techniczne, które nie mogą znaleźć wspólnego języka. Wtedy z ratunkiem mogą przyjść eksperymenty, demonstracje i dopasowanie do informacji zwrotnej. Pytanie tylko ile zajmie osiągnięcie zadowalającego efektu.
Czy analitycy nie robią błędów? Jasne, że robią. Czasem się mylą, czasem brakuje im kwalifikacji, predyspozycji czy właściwego nastawienia. Różnie bywa. Jednak z założenia, my się właśnie w tym specjalizujemy, żeby trafiać w sedno biznesu i w sedno IT.
Jeśli nie potrafisz tych rzeczy, Twój zespół developerów potrafi to zrobić lepiej niż Ty lub tak samo dobrze, to ja się pytam, co robiłeś przez ostatnich X lat? ? Trochę to zaczepny żart, a trochę nie. Bo faktycznie, bywa, że Ty jesteś młody, nowy, uczysz się, a Twój zespół siedzi w projekcie od zarania dziejów – mają prawo dużo wiedzieć, mieć dobre relacje i przetarte ścieżki komunikacyjne. Ale może być też tak, że chodzisz na spotkania, robisz za gumowe ucho, dyktafon i stenotypistkę i faktycznie nie wkładasz nic od siebie do komunikacji, przerzucając widłami z prawej na lewą, przeklejając z jednego miejsca w drugiej. Wtedy pamiętaj, że rozwój kompetencji to Twoje priorytetowe zadanie. Bo nie tak ma wyglądać praca analityka.
Co robi analityk w głuchym telefonie? Nie powtarza słowa z lewa na prawo, ale przykładowo:
- sprawdza kto mówi – czy ta osoba jest właściwą osobą do tego komunikatu, jakie ten komunikat powinien mieć znaczenie i jak powiązać go z komunikatami innych osób,
- upewnia się w jakim języku zostanie ono przekazane,
- jeśli danej rzeczy nie da się wyrazić efektywnie danym językiem, to definiuje właściwy język,
- sprawdza czy słowo występuje ono w dialekcie biznesu i developerów i czy oznacza to samo,
- jeśli nie oznacza tego samego w równie precyzyjny sposób – tworzy mapowanie języka biznesowego na IT,
- sprawdza sensowność komunikatu w kontekście biznesu, branży, firmy,
- sprawdza spójność z innymi komunikatami i obecnym działaniem biznesu i systemu IT,
- sprawdza jakie są intencje biznesu, jakie są jego prawdziwe potrzeby (strategia, cele, intencje),
- sprawdza zrozumienie IT (czy jest wystarczająco precyzyjny),
- sprawdza czy zrozumiany komunikat po wykonaniu polecenia rzeczywiście pomoże biznesowi – czy da mu wartościowy wynik zbliżający do wyznaczonego celu za warte tego pieniądze,
- …
I co? Robisz głuchy telefon? Jeśli tak, to koniecznie to zmień, bo ewidentnie jest coś nie halo.
Sławek Ryszkowski
Również obserwuję “trend” postawiony w tytule. Wydaje mi się, że w ostatnim czasie, także z uwagi na tempo rozwoju produktów, świat analizy przeniósł swój środek ciężkości na stronę biznesową, właśnie dzięki popularyzacji roli analityka biznesowego. Dodając tego szybkość zmiany strategii czy taktyki biznesowej przedsiębiorstw oraz liczbę utrzymywanych systemów i aplikacji, analityk często nie schodzi na poziom komunikacji oczekiwany przez dewelopera. Często jest to poziom czarnoskrzynkowych wymagań na system. Przemyślany słownik pojęć nie nie jest wcale tak powszechnie stosowany, nie wspominając już o jego formie w postaci diagramy klas. Pozostaje jeszcze jeszcze pytanie gdzie jest Projektant? I tu właściwie tkwi moim zdaniem sedno problemu. Projektowanie oprogramowania dzieli się na dwa obszary. Pierwszy techniczny/inżynierki, odpowiada za niego architekt – dotyka obszaru architektury systemu, komunikacji między jego warstwami a także z interfejsami zewnętrznymi, czyli wszystko to co jest niezbędne, aby logika biznesowa działała sprawnie i bezpiecznie. Drugi biznesowy, odpowiada za niego analityk – opisuje działanie systemy w ujęciu logiki biznesowej (w tym miejscu język analityka i architekta musi być uspójniony). Niestety analitycy rzadko schodzą na ten poziom, gdyż wymaga on dobrego warsztatu obiektowego, który dość prostą techniką “User Stories” lub wymaganiami tylu black-box.
Graand
Spoko artykuł, zabrakło mi jednak conajmniej jednego i w sumie najwazniejszego elementu/ diagramu – najlepszego rozwiazania ze wszystkich (moim zdaniem). Chodzi mi o polaczenie sytuacji SPOC i kolejnego diagramu. Czyli analityk jest na pozycji SPOC i robi wszystko co w jego mocy aby wymagania byly jak najbardziej SMART, ale w momencie watpliwosci lub potrzeby dodatkowych informacji jest w stanie precyzyjnie wskazac najbardziej odpowiednie zrodło informacji z ktorym developer/ zespoł moze sie samodzielnie skontaktowac w celach weryfikacyjnych lub uszczegolowiajacych. Takimi osobami kontaktu moga byc klient/uzytkownik, PO (jesli analityk nie pelni takiej roli), UXa, desinger’ow czy poprostu SME. Tak otware sytuacje sa bardzo zadki, lecz z doswiadczenia moge powiedziec ze sa najlepszym rozwiazaniem.
Hania Tomaszewska
Celem było bardziej pobudzenie do myślenia czy analityk robi “głuchy telefon”, co to znaczy i czy to źle. Nie było celem proponowanie najlepszego rozwiązania. Zresztą ciężko to stwierdzić niezależnie od projektu. 4 osobowy projekt będzie inny niż 300-osobowy. Skoncentrowana wiedza i decyzyjność osób też wymaga innych rozwiązań niż rozproszona. Ale tak – często pewnie dobrym wyjściem będzie zajmowanie się przez analityka tym, czym trzeba samemu a zostawienie bezpośredniego dogadania się tam, gdzie nie ma sensu wchodzić miedzy wódkę a zakąskę ?
Iza B
Dzień dobry,
łatwo wpaść w pułapke “głuchego telefonu”. Jedna z umiejętnosci BA to wystrzeganie się podobnych sytuacji. Bez zrozumienia potrzeb biznesowych nie bedzie mógł przekazać developerom zakresu zmian wynikających z wymagań. Ani ocenić, czy dostarczone rozwiązania odpowiadają potrzebom biznesowym. Rozumienie to klucz. I telefon już nie jest taki głuchy 🙂
Może zaciekawi Cię także:
Nie ogarniasz? Nie jesteś sam
Nie ogarniasz? Mam dla Ciebie kilka myśli… alternatywnych. Problemy, porażki, kryzysy. Spójrzmy na nie inaczej. Wspólnie. Tu nie musisz być
Czemu szef Cię nie słucha? Sprzedaj pomysł w firmie.
Masz pomysł, ale szef Cię nie słucha? Dzielę się wnioskami z analizy setek sugestii pracowników – dlaczego niektóre nie mają
Moja droga analityka biznesowego
Ostatnio napisał do mnie Marcin: “Czy mogłabyś podzielić większa ilością informacji na temat Twojej historii? Jakie działania podejmowałaś? Jaką wiedzę
Książki, które polecam z 2020 roku
Polecam 7 spośród książek, po które sięgnęłam w 2020 roku. Może posłużą i Tobie. Książki uczą, poszerzają horyzonty i wywracają
Podsumowanie roku 2020
Co działo się w 2021? Sporo. Spełniłam swoje marzenie wystąpienia na największej konferencji dla analityków biznesowych na świecie. IIBA Building
Zaskoczenie
Nagle słyszysz jak zespół poprawnie formułuje cel pokazujący korzyści dla firmy a nie na zasadzie „dostarczyć narzędzie”. Pracowałeś na to
Bezpańskie wymagania
Pamiętam pierwszą zaskakującą lekcję o wymaganiach. Wyciągnęłam pieczołowicie przygotowaną moją pierwszą specyfikację wymagań. Zebraliśmy wymagania przez wywiad z klientem –
Jakimi wartościami powinien kierować się analityk?
Droga Kobietko! 🙂 ❤🌹
W IT jest nas ok. 30% [2]. Za to prawie połowa w analizie (44%) [1].I to super, bo 72% kobiet
Nie, nie wiesz, czego chce klient – pułapki myślenia i egocentryzm
Czwartek. Przysłuchuję się Alicji i Piotrowi. Przygotowali w firmie prezentację o błędach poznawczych. Daniel Kahneman – autor książki „Pułapki myślenia”
Kochani :)
Z okazji Walentynek życzę Wam dużo miłości! Ukułam sobie takie zrozumienie, że miłość to pomaganie komuś być tym, kim on
Lean Coffee Analityków i Analiza Przyczyn Źródłowych
#4 spotkanie Lean Coffee Analityków w Trójmieście. Wybieramy tematy. Najwięcej głosów dostaje temat na czasie, czyli – dlaczego ludzie się
Podsumowanie roku 2019 (nie z bloga)
To był najgorszy rok w moim życiu. Usiany najtrudniejszymi prywatnymi problemami. Zbierając swoje poczucie wartości z podłogi zapisywałam codziennie przynajmniej
Podsumowanie roku 2019
Starym zwyczajem, zapraszam na podsumowanie roku. Co się wydarzyło, co było fajne, zaskakujące, trudne, nieudane? Jakie wnioski na kolejny rok?
Wpływ, proaktywność i odpowiedzialność
Zanim siądziemy do podsumowywania roku i planowania kolejnego (zawodowego czy prywatnego), czas właściwie rozłożyć akcenty. Co było naszą winą czy
Jak pracować z przeszkodami?
Co łączy Scrum Mastera, lidera i strategicznego analityka biznesowego? Każdy z nich próbuje usuwać przeszkody stojące na drodze grupy osób,
Dlaczego nie dają nam się samoorganizować?
Taka myśl z dziś. Chcemy samoorganizacji, wpływu na firmę, decydowania o swoim zespole. Agile, turkusy, managementy 3.0, itp. Wiele firm
aw3m #017 Kiedy inny zespół ma Twoją zmianę głęboko w backlogu
Co zrobić, kiedy Twoje zadanie zależy od części, jaką dostarcza inny zespół, ale on ma swoją część głęboko w backlogu?
wszędzie analiza #001 ten dzień
Zobaczymy czy tylko mi wszystko się kojarzy z analizą 😛 Zapraszam do nowej serii – wszędzie analiza. W pierwszym odcinku pozdrawiam z
Komunikacja – co może pójść nie tak?
„Zaczynam myśleć, że to największy problem ludzkości” – powiedział znajomy. Mnie również każdego dnia przytłacza nieskuteczna komunikacja – u siebie,
aw3m #016 Optymalizacje lokalne
Masz pomysł na uprawnienia w pracy? Czy jesteś pewien, że to będzie dobre? A może jedynie przesuniesz problem w inne
analiza w 3 minuty #005 Jak współpracować ze specjalistami UX
Jak współpracować ze specjalistami UX? Trudno o tym w 3 minuty :P, ale cóż – próbuję 🙂 A w tym
Nie wychodzi Ci? Mi też nie
„Scrum Masterowi wyjdzie dopiero w 3-cim zespole.” – usłyszałam w podcaście „Porządny Agile”. Uderzyło mnie, że 2 pierwsze zespoły nie
Czy analitycy wyginą?
Czy analitycy wyginą? Bo przecież agile i w ogóle. To pytanie zadał Radek. I teraz pewnie żałuje, bo jak przystało
Jak zweryfikować wiedzę analityka? Certyfikat ECBA IIBA wg Mikołaja
Funkcja analityka biznesowego w firmach oraz projektach IT w Polsce pojawiła się dość niedawno. Zakres obowiązków na tym stanowisku oraz
Czy da się przekwalifikować na analityka spoza IT – historia Natalii
Masz za sobą parę lat przepracowanych w różnych firmach i na różnych stanowiskach. Dziś postanawiasz, że pójdziesz do świata IT,
Agile Analityk w Scrumie
Wielu analityków zastanawia się jak pogodzić swoją pracę z podejściem agilowym, a zwłaszcza popularnym Scrumem, który nie ma roli analityka.
Czy analityk robi głuchy telefon?
Spotkałam się ostatnio ze stwierdzeniem, że analityk źle wpływa na komunikację w projekcie tworząc efekt tzw. głuchego telefonu. Niepotrzebnie staje
Pozytywnie do problemu
Istnieje w językoznawstwie takie pojęcie jak semantyka i ona stanie się dziś tematem wpisu. Nie ta językoznawcza jednak, która zajmuje
Książka "Inżynieria wymagań. Studium Przypadków"
Naczytałeś się już o wymaganiach i analizie, ale nadal brakuje Ci konkretów? Chciałbyś podejrzeć przez ramię jak faktycznie pracują inni
To szybko czy pewnie?
Dostajemy czasem od szefów istne mission impossible. Nie, żeby brakowało nam chęci czy kompetencji. Po prostu świat, w którym żyjemy,
Analityk płakał # 14 Bardziej agile i bardziej fixed-price
Czego można się nauczyć pracując nad utrzymaniem aplikacji
– Może po prostu na początku mówmy im szczerze jak to wygląda, żeby nie mieli złudzeń i się nie rozczarowywali.
Analityk płakał # 13 odpowiedzialnego brak
Problemy analityków – Praca magisterska Wojtka
Zapraszam Was do wzięcia udziału w badaniu problemów analityków, które przeprowadza Wojtek Ślesiński w ramach swojej pracy magisterskiej. Wygląda na
Zanim znajomy zrobi Ci stronę WWW lub system IT
Kilkudziesięcioosobowa organizacja z dużą rotacją. Stawiają nową stronę. Znajomy znający się na IT spada z nieba i oferuje pomoc. Tworzy
Czego Analityk może nauczyć się od Product Managera i vice versa?
Rzadko spotykamy się w jednym projekcie. Chociaż nasza praca ma w dużej mierze zbliżony charakter, PM-owie zabierają się za swoje
Utrzymanie aplikacji, maintenance, indycenty, defekty, CRy
Słowo wyjaśnienia pojęć dla zielonych i nowych w branży. Kiedy ludzie wpadają na genialny pomysł wykonania nowej aplikacji, zazwyczaj mają
Pomysły na prezent dla analityka
Klawiatura z 1 przyciskiem Forward W końcu wiadomo, że jedyne, co robimy, to przekazujemy dalej maile. Zaletą klawiatury z dużym
Jak to jest między biznesem a IT
Mówimy, że analityk stoi między biznesem a IT. Często przychodzi nam wtedy do głowy obraz ludzi rozmawiających innymi językami, a
13 powodów, żeby nie marnować życia w analizie biznesowej
Do tego wpisu zainspirował mnie jeden z ostatnich artykułów Harvard Business Review. Mówił o tym, że żyjesz mrzonkami, bo nie
Jak pracować z Trudną Osobą?
Masz wrażenie, że wsadziłby Ci nóż w plecy. Normalnie odciąłbyś się od takiej osoby. Teraz jednak nie możesz. Pracujecie nad
Drogi do analizy – zbiór sylwetek analityków
Drogi Analityku! Oto przekazuję Ci ideę podzielenia się czymś cennym, co posiadasz – doświadczeniem z Twojej zawodowej drogi. Jest to
Podstawowe kompetencje analityka
Zastanawiasz się jakie kompetencje zdobyć lub rozwijać, aby być lepszym analitykiem? IIBA na podstawie wieloletniej wymiany doświadczeń analityków z całego
Fuckup Nights – o moich analitycznych fuckupach
W ramach Fuckup Nights Trójmiasto opowiadałam o swoich analitycznych fuckupach. Zapraszam do uczenia się na błędach – najlepszych, bo cudzych
Jak wykorzystać analizę biznesową do zapewnienia jakości projektów IT [cz. 2]: Analiza w firmach
artykuł jest kontynuacją – część pierwsza: https://analizait.pl/2014/jak-wykorzystac-analize-biznesowa-do-zapewnienia-jakosci-projektow-it-cz-2-analiza-w-firmach/ Zmieniające się znaczenie rozwiązań IT w przedsiębiorstwach Ostatnie kilkadziesiąt lat pokazuje, że rola
Jak wykorzystać analizę biznesową do zapewnienia jakości projektów IT [cz. 1]: Wprowadzenie
W przedsięwzięciach informatycznych przywiązuje się różną wagę do pracy analitycznej. Wiele czynników i przyjętych kryteriów ma na to wpływ. W
REQB. Requirements Engineering Qualifications Board – w trzech aktach
Uwaga! Ten certyfikat nie jest już dostarczany jako REQB. Zobacz IREB: https://www.ireb.org/ Prolog W pewnym momencie kariery zawodowej – czy to
Wiedza, doświadczenie, osobowość – co ma znaczenie i co warto rozwijać? – wywiad z jednymi z najlepszych analityków w Polsce
Wiedza, doświadczenie, osobowość – co determinuje sukces analityka? Zadaliśmy pytania trzem znakomitym ekspertom, postaciom, które wniosły wielki wkład w rozwój
Początkujący czy ekspert analizy – na jakim jesteś poziomie? – wywiad z jednymi z najlepszych analityków w Polsce
Jak ocenić na jakim poziomie zaawansowania wykonujesz swoją pracę? Zadaliśmy pytania trzem znakomitym ekspertom, postaciom, które wniosły wielki wkład w