Czy przeczytana książka mi pomoże?

Problem: W morzu sprzecznych rad

Konrad chce nauczyć się programować. Po wpisaniu frazy „how to start learning programming” w wyszukiwarkę zobaczył setki artykułów, kursów, filmów i materiałów pomocniczych.

Większość z tych źródeł wiedzy jest poprawna - jeśli Konrad wykorzysta te źródła to prędzej lub później nauczy się programować. Jednocześnie – większość z tych poprawnych źródeł wiedzy jest sprzeczna z innymi źródłami.

Te inne źródła też są poprawne. Ale źródeł jest za dużo i każde mówi coś innego.

Konrad nie ma zielonego pojęcia jak zacząć się uczyć programować - z czego korzystać.

Może macie podobnie? 

Załóżmy, że przeczytaliście książkę lub artykuł i chcielibyście wykorzystać nowo nabytą wiedzę. Jak to zrobić, jeśli bardzo często informacje z książki brzmią bardzo dobrze, ale nie wiadomo jak to wykorzystać w praktyce?

Czy po przeczytaniu książki / artykułu jesteście w czymś lepsi czy jedynie macie wrażenie, że jesteście w czymś lepsi? Przeczytaliście książkę, chcecie użyć znajdujących się tam technik - i co dalej? Jak to zrobić, jak zacząć?

Bardzo długo miałem dokładnie ten problem. W końcu udało mi się opracować technikę która u mnie działa, łącząc “Jobs To Be Done” (na poziomie analizy) i “STAR” (na poziomie wdrożenia). I o tym właśnie ten artykuł:

• Jak szybko i łatwo sprawdzić, czy warto czytać tę książkę dalej, czy poszukać czegoś innego? (przykład: gdy szukałem dobrej książki o negocjowaniu. Miałem kilka - której użyć?)
• Miernik badający stopień dopasowania pomiędzy danym źródłem wiedzy a moim problemem (przykład: które artykuły dają rady odnośnie negocjacji, które mogę wykorzystać na co dzień - czyli które są “lepsze” z mojego punktu widzenia)
• Jak rozwiązać problem wyboru źródeł danych i przetwarzania ogólnej teorii na praktyczne działania.

Gdzie jesteśmy w pętli OODA?

Pamiętacie może jak mówiliśmy o pętli OODA w podcaście ?

Z perspektywy pętli OODA ten artykuł jest w “Orient” - które źródła wiedzy wybrać do podejmowania decyzji (i w jaki sposób je wykorzystać po wybraniu).

To jak, zaczynamy?

Nie rozumiem, co Cię boli - Jobs to be Done

Mamy cztery przykładowe osoby: Adam, Basia, Cyprian i Daria. Wszyscy poza Darią kupili bilet na Wielką Konferencję Javascriptową. Gdy jednak pojawiło się zagrożenie epidemiczne, Konferencja została zmuszona do przejścia w formę zdalną. Ceny biletów spadły o 25%.

W wyniku tego Basia się wypisała z Konferencji. Co ciekawe, Daria – która nigdy nie jeździła po konferencjach - kupiła bilet na Konferencję w formie zdalnej. Adam i Cyprian się nie wypisali.

Dlaczego?

Adam chciał nauczyć się nowych rzeczy i poznać nowinki ze swojej branży. Przejście Konferencji w tryb zdalny nic a nic mu w tym nie przeszkadzało. 

Jeśli zrezygnuje z Konferencji, Adam pozna nowinki dzięki: kursom w internecie, warsztatom, hackatonom, artykułom.

Basia chciała zmienić pracę i zobaczyć jakie są propozycje różnych firm, poznać ludzi z branży. Przejście konferencji w tryb zdalny sprawiło, że Konferencja nie ma dla niej żadnej wartości. 

Basia zamiast pojechania na Konferencję rozwiąże swój problem przez: chodzenie na rekrutacje do firm, szukanie informacji o firmach w internecie.

Cyprian chciał się dobrze bawić i spędzić luźno czas z osobami myślącymi podobnie do niego. Przejście Konferencji w tryb zdalny mu przeszkadza, ale i tak nie ma żadnych innych imprez. 

Jeśli zrezygnuje z Konferencji, Cyprian zaspokoi potrzeby rozrywki i kontaktu przez: oglądanie filmów w internecie, imprezy z przyjaciółmi.

Darii w ogóle nie interesuje Konferencja. Ma zamiar skorzystać z Konferencji by przetestować stos technologiczny pozwalający na pracę zdalną, by potem jako konsultantka doradzać w tym obszarze różnym firmom. 

Gdyby Daria nie skorzystała z Konferencji, musiałaby pozyskać wiedzę w inny sposób: przeprowadzenie własnych badań i własnoręczne testowanie wszystkiego.

Popatrzcie - mówimy o tej samej Konferencji, ale dla każdego z czterech bohaterów ma ona zupełnie inne znaczenie. Twórcy Konferencji musieliby zrobić zupełnie inne rzeczy by cała czwórka była zadowolona. Przechlapane.

To powyżej jest przykładem techniki „Jobs to be done”, którą znam dzięki książkom Claytona Christensena. Ta technika mówi, że „produkt” oznacza dla każdego coś zupełnie innego i ludzie kupują produkt w zależności od kontekstu w którym go użyją:

• Ten sam produkt może dla różnych ludzi mieć zupełnie inne znaczenie.
• Ten sam produkt może konkurować z zupełnie innymi produktami, bo konteksty użycia są bardzo różne

Innymi słowy, nowo wydana gra komputerowa „Doom Eternal” konkuruje nie tylko z innymi grami komputerowymi, ale też z Netflixem – bo obie mogą być “zrekrutowane” przez tą samą grupę odbiorców w tym samym celu (linkuję artykuł pokazujący zjawisko).

Produkt jest czymś innym w zależności od celu i kontekstu

Koncepcja „Jobs to be Done” (dalej: JTBD) jest kluczowa do zrozumienia, dlaczego różne źródła wiedzy (książki, filmy, artykuły) mogą być jednocześnie poprawne (rozwiązywać problem czytelnika)  jak i sprzeczne ze sobą (rozwiązywać różne problemy lub ten sam problem w różnych kontekstach).

Dla ilustracji, weźmy przykładowego Erwina. Erwin jest niezbyt doświadczonym managerem zespołu który musi dać swojemu podwładnemu feedback (informację zwrotną). Ów podwładny potrzebuje feedbacku mającego skierować daną osobę na właściwe tory - po prostu ten podwładny robi coś źle.

Erwin czuje się niepewnie z dawaniem feedbacku, więc poprosił swoją doświadczoną koleżankę, Felicję, o dobry artykuł w dziedzinie feedbacku.

Felicja akurat niedawno przeczytała świetny artykuł o feedbacku  - był to jednak artykuł na temat dawania feedbacku mającego zachęcić kogoś do dalszego działania. Coś zupełnie innego, niż Erwin potrzebuje i oczekuje.

Za to dla Felicji, która aktualnie stara się zachęcić niedoświadczoną osobę do dalszego działania ten artykuł jest rewelacyjny.

Tak więc Felicja poleciła Erwinowi ów artykuł w dobrej wierze. Erwin - oczekujący czegoś zupełnie innego - będzie lekko zagubiony. Felicja nie rozwiązała jego problemu - ona jeszcze bardziej wzmocniła zamęt i chaos w głowie Erwina.

Stąd właśnie bierze się chaos i szum informacyjny.

Tak więc JTBD pokazuje nam pierwszą zasadę: „źródło wiedzy jest wartościowe lub nie jedynie w kontekście jego użycia”. Coś świetnego w jednym kontekście może być bezwartościowe w innym kontekście.

Znacie to zresztą dobrze z dowolnych kursów. Coś dobrego dla doświadczonego programisty jest niemożliwe do wykorzystania dla początkującego a coś dobrego dla początkującego jest dla doświadczonej osoby nudne i bezużyteczne.

Jak wykorzystać JTBD w praktyce?

Pierwsza część problemu “czy moje źródło komuś pomoże” polega na tym, że nie rozumiemy, co drugą osobę boli. Widzimy pewne objawy - ale nie znamy kontekstu, nie rozumiemy dokładnego problemu i mamy kłopoty z dopasowaniem rozwiązania do okoliczności drugiej osoby.

Trochę jak lekarz. Słyszy “boli mnie ucho”, ale nie wie, czy to zapalenie (na które pomoże lek) czy np. delikwent wsadził tam ciało obce (na co pomoże wyjęcie przedmiotu). Podobne objawy - inne rozwiązania.

Tak samo JTBD pokazuje nam, że dla każdej osoby ten sam produkt może oznaczać coś zupełnie innego w zależności od kontekstu użycia. Coś przydatnego dla mnie może być bezużytecznego dla Was.

Jak możecie wykorzystać to w praktyce?

To samo działanie może być dobre lub złe w zależności od tego, co chcemy osiągnąć.

Określcie faktyczny cel przez zdefiniowanie “lepiej” i znalezienie alternatywnych rozwiązań.

Erwin, który chciał dać feedback korygujący miał zupełnie inny cel niż Felicja, która skupiała się na feedbacku zachęcającym. Basia, która chciała poznać różne firmy czegoś innego oczekiwała od konferencji niż Adam, który chciał poznać nowinki z branży.

Gdy próbujecie komuś pomóc, określcie czemu potrzebuje Waszej pomocy. Nie wystarczy usłyszeć “poleć mi świetną konferencję”, musicie wiedzieć czego Wasz rozmówca oczekuje od tej świetnej konferencji. 

Dobrymi pytaniami pomocniczymi są też: “co po tej konferencji będziesz robić lepiej” lub “jeśli nie konferencją, to czym rozwiążesz ten problem” - to pomoże Wam doprecyzować faktyczny, niejawny cel znajdujący się za jawnym problemem.

Jeśli nie próbujecie nikomu pomóc a chcecie znaleźć lepsze rozwiązanie pod swoim kątem, przeanalizujcie problem sami w ten sam sposób.

To samo działanie może być dobre lub złe w zależności od kontekstu - określcie, czy macie podobne zasoby i ograniczenia do tych rekomendowanych w technice. 

Gdy Konferencja przeszła w formę zdalną, dla Basi był to duży problem. Jej zależało przede wszystkim na prywatnym kontakcie z ludźmi i możliwością rozmowy o różnych firmach. Basia świetnie nawiązywała znajomości, ale nie zdalnie - tego nie lubiła i nie umiała. W kontekście Basi ta konferencja przestała być przydatna.

Jeżeli ktoś martwi się tym, że przyjdzie inflacja, typową radą jest dywersyfikacja - niech zainwestuje część pieniędzy w obligacje i część w waluty obce. Jednak ta rada nie pomoże komuś, kto nie ma dużej ilości gotówki, ma kredyt o wysokich ratach i po prostu nie ma możliwości zainwestowania pieniędzy. Ta rada jest dla takiej osoby bezwartościowa.

Gdy ktoś udziela Wam rady, załóżcie, że ta rada jest poprawna w kontekście osoby dającej radę. Ale nie oznacza to, że jest poprawna w Waszym kontekście. Tylko Wy wiecie jakie macie możliwości, ograniczenia i zasoby.

Podczas wykorzystywania nowych technik i narzędzi najpierw warto się zapoznać z tym kiedy te techniki i narzędzia były użyte w świecie rzeczywistym i jakie korzyści przyniosły - technika negocjacyjna która ma dowody sukcesu tylko w wielkich korporacjach niekoniecznie Wam pomoże gdy próbujecie wynegocjować podwyżkę w małej firmie.

Innymi słowy - poszukajcie dowodów, że ta technika działa i sprawdźcie czy te dowody są w kontekście zbliżonym do Waszego.

“Rekrutujemy” produkt pomagający nam w podobnych czynnościach

Dobrze - przeszliśmy przez pierwszy klocek, czyli JTBD. Ale sam kontekst i cel to nie wszystko, trzeba jeszcze zbudować dowód, że technika jest przydatna. Jak to zrobić?

W samym opisie JTBD pojawia się twierdzenie o “zatrudnianiu” produktów pod kątem celów (“People hire services and products to get specific jobs done in their lives.”).

A co, gdybyśmy potraktowali to dosłownie?

Co, jeśli wykorzystamy techniki rekrutacyjne stosowane wobec ludzi do sprawdzenia czy nasze źródła wiedzy działają?

To był drugi klocek układanki - znalezienie sprawnej techniki rekrutacyjnej opartej na faktach i wykorzystanie jej do sprawdzenia, czy produkt robi to, czego od niego oczekuję w moim kontekście jego użycia.

Techniką, która dobrze zadziałała okazała się technika STAR.

Wdrożenie techniką STAR – od sytuacji po wynik

Technika STAR (Situation – Task – Action – Result) jest techniką rekrutacji ludzi, behawioralną, opartą na następujących założeniach:

• Rekrutujemy na konkretne stanowiska na których ludzie będą robili konkretne rzeczy. Wiemy, czego oczekujemy od ludzi w pracy – wiemy, co będą w pracy robić.
• Rekrutujemy ludzi z uwagi na ich silne strony, ewentualne słabości skompensujemy odpowiednim zespołem.
• Jeśli ktoś robił coś w przeszłości, jest duża szansa, że będzie umiał to powtórzyć. Tak więc powinniśmy sprawdzić czy robili to, czego będziemy od nich oczekiwać.
• Skupiamy się na faktach, na rzeczach które faktycznie się wydarzyły.
• Praca jest silnie osadzona w kontekście, więc nie da się ocenić działania drugiej osoby nie znając sytuacji w której ta osoba się znajdowała.

W tej technice pytamy o następujące rzeczy (w odniesieniu do sytuacji podobnej do tego co osoba pytana robiłaby w pracy):

• Situation: opiszcie kontekst sytuacji w której się znajdowaliście
• Task: oraz co mieliście osiągnąć
• Action: jakie faktyczne czynności wykonaliście by wykonać zadanie w danym kontekście
• Result: czego oczekiwaliście i jaki dało to wynik

Pokażę technikę STAR na przykładzie.

Grzegorz próbuje sprzedać zdalne szkolenie firmie ChickenSoft. Hanna, decydentka z ChickenSoft zadaje Grzegorzowi pytanie: „Opowiedz mi o poprzednim razie jak przeprowadziłeś zdalne szkolenie”. Odpowiedź zgodnie ze STAR wyglądałaby mniej więcej w taki sposób:

• Sytuacja: Z uwagi na stan epidemiczny nie było możliwości przeprowadzić szkolenia na które byliśmy umówieni i które było sprzedane. Nikt nie był szczęśliwy z tego powodu, ale przeprowadzałem je zdalnie dla 12 osób. Inaczej się nie dało.
• Zadanie: Problem był trudny, bo uczestnicy szkolenia mieli uczestniczyć w warsztatach – to nie była tylko prezentacja. Wymagało to pracy w sekcjach i budowania rzeczy niezależnie. Lokalnie - żaden problem. Zdalnie - trudniej, bo nie ma “wspólnego stolika”.
• Akcja: W związku z tym używając Google Suite złożyłem 5 spotkań – „główne” i „4 pomocnicze”. Wszystkie spotkania były ustawione na 10 godzin. Wpierw działaliśmy razem, 30 min przedstawienia i wyjaśnienia. Potem kursanci pracowali w trzyosobowych grupach na innych spotkaniach (…)
• Wynik: Szkolenie zdalne zakończyło się powodzeniem – wykonywane przez nich ćwiczenia budowane na poprzednich udowodniły, że przyswoili wiedzę. Byli zadowoleni i poprosili o ciąg dalszy, nawet, jeśli też ma być zdalnie.

Zauważcie, że na podstawie takiej odpowiedzi Hanna może łatwo ocenić, czy umiejętności Grzegorza są wystarczające w kontekście firmy Chickensoft. Co więcej, Hanna może zadać kilka dodatkowych pytań by sprawdzić dopasowanie Grzegorza do swojego problemu.

Dla osób zainteresowanych innymi przykładami użycia techniki STAR polecam zalinkowany dokument.

Dobrze - jak teraz możemy przełożyć STAR na rekrutowanie źródeł wiedzy zgodnie z JTBD?

Jak wykorzystać STAR w praktyce?

Druga część problemu “czy moje źródło komuś pomoże” polega na tym, że nie wiemy jak wykorzystać istniejące źródło wiedzy w praktyce. Czy dana książka się przydała? Co wziąć z artykułu i jak przekształcić to na praktyczne działanie?

Tu wchodzi STAR - technika opartą na konkretyzacji. Weźmy coś ogólnego, np. “jestem świetnym programistą” i zbudujmy na to przykłady i dowody, np. “od poziomu wymagań biznesowych napisałem program, który przyniósł firmie 300 tysięcy złotych rocznie”.

Czyli STAR sprawia, że wszyscy obecni widzą co ja - osoba rekrutowana - uważam za “świetny programista”.

Jeżeli nie wiecie w jaki sposób przekształcić coś abstrakcyjnego w konkretny przykład, to technika STAR jest świetnym przykładem jak to zrobić:

• wyjdźmy od sytuacji - w jakiej to się przyda / zostało zrobione
• co muszę chcieć osiągnąć by to się przydało, w jakim kontekście i zadaniu mam to uzyskać
• jaką serią kroków mogę to osiągnąć; co kryje się pod abstrakcyjnym problemem
• jakiego wyniku oczekuję

To sprawia, że STAR można użyć m.in. w:

• analizie biznesowej (“w jakiej sytuacji to będzie użyte - co będzie chciał zrobić użytkownik - jakie kroki wykona - jaki ma być efekt” - widzicie podobieństwa do User Story?)
• programowaniu (“w jakim otoczeniu będzie ten kod działał - co ma być zrobione - jakie kroki mają być wykonane - jaki ma być efekt” - widzicie podobieństwa do budowania testów z okolicznościami wykonania i Given-When-Then?)

Bardzo ważne - STAR zakłada konkretny przykład. Nie “użyłem języka programowania” a “użyłem Pythona 3”. Wchodzimy w szczegóły, podajemy konkrety.

Czemu to jest ważne opisałem w artykule o usuwaniu Klątwy Wiedzy

Połączmy JTBD i STAR - zrekrutujmy źródło wiedzy pod kątem celu

Znacie już JTBD i STAR. Czas je połączyć.

Tak więc, z naszego punktu widzenia w technice STAR istotne są następujące rzeczy:

• Szukamy konkretnej serii czynności w konkretnym kontekście. Konkretyzujemy abstrakcje tworząc przykłady
• Idziemy cyklem: Sytuacja – Zadanie – Akcje – Oczekiwany Wynik
• Jako, że wszystko, co ważne jest obserwowalne przez osobę trzecią, potrafimy zobaczyć różnicę pomiędzy wykorzystaniem techniki a nie wykorzystaniem techniki

A wracając jeszcze do JTBD:

• Kluczem jest kontekst. Ten sam produkt przez różne osoby może być zatrudniany do różnych „prac” i ten sam produkt dla dwóch różnych osób może znaczyć odmienne rzeczy.
• Źródło wiedzy które rekrutujemy konkuruje z różnymi metodami i źródłami wiedzy, w zależności od kontekstu – z innymi.

Połączenie tych konceptów nam pierwszą prostą heurystykę badającą, czy źródło wiedzy jest poprawne / wystarczająco dobre:

1. Wiem jaki mam problem i jaką pracę chcę mieć rozwiązaną (Kontekst + JTBD). Wiem jakie mam możliwości rozwiązania tego problemu – one są moim punktem odniesienia.
2. Określam, co dla mnie oznacza „sukces” i jak będzie wyglądać sytuacja jeśli niczego nie zrobię (Result, zgodnie ze STAR).
3. Szukam w źródle wiedzy informacji na tematy powiązane z moim problemem.
4. Przekładam technikę pozyskaną ze źródła wiedzy na STAR: 
   1. W jakiej Sytuacji mogę użyć tej techniki ze źródła wiedzy? Czy jest choć jedna taka Sytuacja?
   2. Co chcę Osiągnąć by ta technika zadziałała – co dzięki niej zrobię lepiej?
   3. Jaką serię kroków muszę wykonać, by osiągnąć ten sukces? Jakie mam wymagania?
   4. Jak wygląda sukces? Jak się różni od mojego dotychczasowego podejścia? Czy sukces będzie znacząco lepszy niż stan aktualny?
   5. Czy mam jakiekolwiek dowody że to może zadziałać? Czy komuś się udało? Jak wiarygodne to źródło?
5. Jeśli nie umiem znaleźć ani jednej Sytuacji, w której technika pochodząca ze źródła wiedzy by mi pomogła, to analizowane źródło wiedzy nie przystaje do moich potrzeb. Nie znaczy to, że jest błędne – ale oznacza to, że kontekst stworzenia tego źródła jest inny niż mój kontekst.

Co najlepsze, powyższa seria kroków jest bardzo prosta do przetestowania – albo osiągam sukces tą techniką, albo nie.

Nie jest to proste, więc pokażę przykład, jak tego użyć. W tym przykładzie nie mam sprecyzowanego celu - więc pokażę dodatkowy krok: czy istnieje sytuacja, w której dana technika może mi się przydać.

Przykład - artykuł o znajdowaniu product-market fit

Znalazłem swego czasu w internecie doskonały artykuł o wykorzystywaniu danych zebranych od użytkowników do budowania i kalibracji produktu.

Jedna kluczowa idea wzięta z artykułu na potrzeby przykładu:

• Żeby zmierzyć Product-Market Fit, dobrym miernikiem jest trend odpowiedzi na pytanie „jak byście się czuli gdybyście nie mogli już używać tego produktu” i liczenie osób odpowiadających „bardzo rozczarowany”.
• Odpowiedzi na pytanie „co jest największą korzyścią jaką uzyskujesz używając tego produktu” tych ludzi (i tylko tych ludzi), którzy odpowiedzieli „bardzo rozczarowany” pozwalają na określenie co jest powodem czemu aktualni użytkownicy kupują ten produkt
• Odpowiedzi na pytanie o korzyści tych ludzi, którzy odpowiedzieli „wcale nie byłbym rozczarowany” nie są na tym etapie wartościowe – ci ludzie nie są głównymi użytkownikami produktu. To tylko rozmyje sygnał.
• Te wszystkie segmentowane odpowiedzi potem były rzucone w forme chmury słów, dzięki czemu dało się zobaczyć które koncepty pojawiały się najczęściej – i które pojawiają się w których segmentach, dzięki czemu dało się określić jak rozwijać produkt.

Uważam, że sam zalinkowany artykuł ma dużo wartościowych pomysłów, jednak na potrzeby przykładu skupię się tylko na tym podejściu do segmentacji które skróciłem powyżej.

Czyli – wygląda na to, że artykuł ma wartościowy pomysł. Jak mogę sprawdzić, czy ta wiedza jest dla mnie w jakikolwiek sposób przydatna? W końcu nie jestem CEO firmy posiadającej produkt.

Zauważcie – z uwagi na to, że nie mam żadnego Problemu muszę zrobić dodatkowy krok – muszę znaleźć jakąkolwiek sytuację, w której ta technika mi się może przydać. Ale nie szukam hipotetycznej sytuacji, a czy faktycznie robiłem coś w przeszłości gdzie to mogłoby mi się przydać.

Przykład - czy taki artykuł może mi się przydać? STAR pod kątem JTBD

Pytanie (S w STAR): Czy istnieje jakakolwiek Sytuacja, w której taka forma segmentacji by mi się przydała? Czy robiłem coś w przeszłości, gdzie to by mi pomogło?

Odpowiedź: Gdy prowadzę szkolenia lub warsztaty to mam dwa typy feedbacku. Pierwszym jest odpowiedź systemu (czyli obserwuję ludzi i patrzę gdzie spędzają najwięcej czasu i się gubią), drugą jest feedback na poziomie reakcji (czyli pytam co im się podobało i co należy poprawić).

Jednak to nie jest tak, że na szkolenie przychodzą perfekcyjnie dopasowane osoby. Na szkoleniu pojawia się zawsze jakaś grupa osób i w zależności od grupy szkolenie musi być troszkę zmienione. 

Pytanie (T w STAR): Przy jakim Zadaniu taka forma segmentacji może się przydać?

Odpowiedź: Przy kalibracji szkolenia – budowaniu nowej edycji. Chcę zawsze usunąć te ćwiczenia, które przynoszą najmniejsze korzyści i zajmują najwięcej czasu i dodać nowe, które będą pełnić tą samą rolę, tylko lepiej. Ale jak analizowany artykuł pokazuje, trzeba odkryć jaką mam populację i jakie mam podgrupy – od tego zależy co to znaczy „lepiej”.

Pytanie (A w STAR): Jakie kroki mogę przeprowadzić by to osiągnąć? Co muszę robić inaczej niż do tej pory? Jakie mam wymagania by to osiągnąć?

Odpowiedź: Do tej pory obserwowałem i notowałem gdzie ludzie się gubią i co zajmuje najwięcej czasu lub nie przynosi efektów. Ten artykuł pokazuje, że muszę to poszerzyć – do jakiego segmentu należą osoby które się gubią, czy nie jest tak, że różne segmenty przechodzą przez różne ćwiczenia inaczej. Przez to, że będę notował reakcję uczestników na ćwiczenia uwzględniając segmenty powinienem uzyskać to co proponują w artykule.

Pytanie (R w STAR): Co dzięki temu chcę osiągnąć? Jakie korzyści da mi zastosowanie tej techniki?

Odpowiedź: Dwie zupełnie różne korzyści. Po pierwsze, w zależności od tego jakiego typu ludzie przyjdą na szkolenie będę w stanie dać im inne ćwiczenia – lepiej dopasowane do nich pod kątem celów jakie chcą osiągnąć. Druga korzyść – może się okazać, że większość ludzi którzy przychodzą na szkolenie to zupełnie inni ludzie niż ci dla których to szkolenie było planowane. Jeśli tak jest, muszę zmienić materiały i grupę docelową.

Jak faktycznie wykorzystałem wiedzę z przykładowego artykułu?

Po przeczytaniu tego artykułu zacząłem stosować te rzeczy dokładnie tak jak napisałem powyżej. I faktycznie, okazało się, że jest to warte robienia. 

Sama segmentacja feedbacku pod kątem różnych populacji była wartościowa. Poszerzyłem ilość ćwiczeń i zacząłem znajdować wzory.

Czyli: zamiast posiadać „lepsze i gorsze” ćwiczenia mam teraz ćwiczenia „lepsze i gorsze w zależności od tego w jakim segmencie są uczestnicy”. I to faktycznie działa.

Warto zaznaczyć - koszt monitorowania ćwiczeń pod kątem różnych segmentów populacji jest zauważalny. Ja to akceptuję jako koszt, ale niekoniecznie każdy uzna to za warte robienia. Zależy od kontekstu.

W ogóle, w tym artykule pominąłem problem kosztów czy inwestycji czasowej potrzebnych by ta technika działała. Jak widać, są one zauważalne. Sami oceńcie, czy jest to dla Was warte. Dla mnie tak.

Podsumowanie

Coś przydatnego dla mnie niekoniecznie jest przydatne dla Was. Te same spodnie mogą mieć różne znaczenie dla dwóch różnych osób – w zależności od tego do jakich prac te osoby rekrutują owe spodnie. Artykuł, który dla mnie jest świetny może być kiepski dla Was.

Szczęśliwie, technika STAR umożliwia nam sprawdzenie czy to, co przeczytaliście się Wam do czegoś może przydać. Jeśli umiecie odpowiedzieć na następujące pytania:

• W jakiej sytuacji z przeszłości mi by się to mogło przydać?
• Jaką „pracę do wykonania” miałem, którą bym usprawnił dzięki technice z tego artykułu? 
• Jaką serię kroków muszę wykonać by osiągnąć sukces? Co artykuł mi proponuje?
• Co to znaczy „lepsze” – jak to namacalnie wygląda? Po czym poznam sukces?

Jeśli jesteście w stanie stworzyć choć jedną taką sytuację z krokami i wynikiem to jesteście w stanie zdobyć tzw. „actionable insight” – hipotezę posiadającą zarówno konkretny zbiór kroków jak i oczekiwany wynik. 

A to oznacza, że jesteście w stanie przetestować taką hipotezę. Macie coś, co się Wam może przydać.

Jeśli ta seria kroków da Wam oczekiwaną korzyść… wygraliście. Macie nową technikę i macie dowód, że źródło wiedzy było z Waszego punktu widzenia wartościowe. Wiecie w jakim kontekście jest użyteczna i komu je polecić.

Jeśli ta seria kroków nie da Wam oczekiwanej korzyści lub nie macie możliwości wykonania takiej serii kroków, trudno. Oznacza to, że to źródło wiedzy – może i poprawne – nie jest dopasowane do Waszego kontekstu. Nie ma co poświęcać więcej czasu na analizę tej konkretnej techniki.

Ja stosuję to, co tu napisałem. Dość sporo czytam i większość interesujących artykułów i technik próbuję przekładać na STAR (wdrożenie) pod kątem JTBD (analizy) – czy faktycznie dzięki temu artykułowi czy książce mogę zrobić lepiej coś co przedtem robiłem inaczej? 

Potem zapisuję takie rzeczy i gdy pojawiają się okazje o niskich konsekwencjach porażki to testuję na nich nowe techniki.

Zwykle okazuje się, że w moim kontekście te źródła wiedzy nie działają. Ale czasami okazuje się, że to działa – i w ten sposób dostaję nowe narzędzie do swojego arsenału rozwiązań.

Tym artykułem chciałem Wam dać coś, dzięki czemu będziecie w stanie konstruować własny narzędziownik na bazie artykułów, faktów i Waszego kontekstu. 

Powodzenia!