Wdrażanie FRIS® w zespole IT to praca u podstaw, której początkowy etap – poznanie modelu – jest bardzo zbliżone do produkcyjnego uruchomienia produktu IT. Żeby to mogło się udać, należy we właściwy sposób przygotować się i przekazać uczestnikom procesu właściwe rozumienie narzędzia.

W poprzednim artykule zainicjowałem temat wykorzystania narzędzia diagnostycznego FRIS® w sektorze IT. Zilustrowałem, jak efektywnie możemy pracować, stosując metafory i tworząc silne analogie, na przykład porównując człowieka do oprogramowania, a FRIS® do frameworka. Taka perspektywa sprawia, że 'oprogramowanie’ – czyli człowiek – staje się bardziej efektywne, zadowolone i spełnione, szczególnie w kontekście wykonywanych obowiązków na swoim stanowisku.

Temat wdrażania FRIS® w zespole IT ciągle trwa, ponieważ zamierzam w dalszych częściach tego cyklu zagłębiać się jeszcze bardziej w świecie technologicznym. Poszukamy większej liczby połączeń między FRIS® a specyfiką działania firm IT, ponownie korzystając z pryzmatu metafory. Takie połączenie jest niezwykle skuteczne w celu przedstawienia modelu FRIS® z perspektywy elementów charakterystycznych dla sektora IT. Dzięki temu, osoby z tej branży będą mogły lepiej zrozumieć nasz model.

Chciałbym ponownie skupić się na narzędziu diagnostycznym, jakim jest FRIS®. W poprzednim artykule zaznaczyłem, że nie będę szczegółowo opisywał samego modelu i badania psychometrycznego. Dzisiaj jednak, nieco zmienię ten schemat – zrobię mały krok wstecz, by przedstawić Wam model FRIS®. Pokażę go specjalnie z perspektywy świata IT i firm technologicznych, korzystając z naszej sprawdzonej metafory.

Metafora w branży IT

Gdy mówimy o FRIS®, mamy na myśli przede wszystkim cztery perspektywy poznawcze. Te odpowiedzą na pytanie, jakiego rodzaju informacje traktujemy jako najważniejsze, zwłaszcza w sytuacjach nowych dla nas. Te perspektywy to Fakty, Relacje, Idee i Struktury.

Jeżeli jesteś już zapoznany z tym narzędziem, z pewnością masz głębokie zrozumienie tych perspektyw. Dla tych natomiast, którzy rozważają zanurzenie się w świat FRIS® i doświadczenie tego procesu, za chwilę przedstawię krótkie wprowadzenie. Zrobię to jednak stricte z perspektywy firm technologicznych.

FAKTY jak bramki logiczne

Zacznę od perspektywy Faktów. Pierwszą metaforę, którą Wam przytoczę właśnie w tym miejscu usłyszałem od twórczyni samego badania Ani Samborskiej-Owczarek, która na jednym z webinarów dedykowanych trenerkom i trenerom FRIS® użyła właśnie owej metafory, porównując perspektywę Faktów do układów cyfrowych.

Układy cyfrowe reprezentowane są przez tzw. bramki logiczne, które mają kluczowe znaczenie dla funkcjonowania naszych komputerów. Z technicznego punktu widzenia, bramka logiczna albo dopuszcza, albo blokuje przepływ prądu do procesora naszego komputera. Dzięki tym bramkom, komputery mogą działać, wykorzystując tzw. system binarny, czyli 0-1.

Kiedy myślimy o perspektywie Faktów z punktu widzenia bramek logicznych, stwierdzamy, że żadne z nich nie będzie działać, jeżeli nie będzie to logiczne.

Jeżeli współpracujemy z kimś, kto charakteryzuje się silną, aktywną, dominującą perspektywą Faktów, ta osoba zwykle podchodzi do nas z stwierdzeniem, że pewne zadanie jest bez sensu. Jeżeli postaramy się zadać pytanie „A czym dla Ciebie jest sens?”, odpowiedzią będzie zazwyczaj, że coś jest nielogiczne.

Bramka logiczna / układ cyfrowy działają w ten sam sposób. Jeżeli nasze postępowanie z tym elementem będzie nielogiczne, bramka po prostu nie zadziała.

Po drugie, bramka logiczna jest odporna na szum. Lubi robić jedną rzecz na raz, a właściwie bramka logiczna robi tylko jedną rzecz na raz. Osoba z silnymi Faktami, z dominującą perspektywą Faktów, unika wielozadaniowości. Czuje potrzebę zakończenia jednego zadania, zanim zacznie kolejne. To jest charakterystyczne dla osób, u których ta perspektywa dominuje – dla „Zawodników”, jak nazywamy osoby, u których perspektywa Faktów jest dominująca we FRIS®.

Trzecia charakterystyka bramek logicznych i perspektywy Faktów to fakt, że na wejściu i wyjściu musi być 0 lub 1. Przenosząc to na język narzędzia diagnostycznego, osoba z silnymi Faktami, kiedy mówi tak, ma na myśli tak, a kiedy mówi nie, ma na myśli nie. Nie ma tutaj miejsca na dwuznaczności. Kiedy Zawodnik pyta nas „Czy podoba Ci się to rozwiązanie?” a my odpowiadamy „Nie wiem”, możemy wprowadzić tę osobę w konsternację. Może ona pomyśleć, że odpowiadamy na inne pytanie niż ona zadała.

Odpowiedź na pytanie Zawodnika powinna być jasna – tak albo nie. W ten sam sposób działają bramki logiczne.

Zaraz zaprezentuję Wam trzy kolejne perspektywy, zatem chcę podkreślić również jedną ważną kwestię. Stosując te metafory, np. odnoszące się do bramek logicznych czy innych elementów ze świata IT, możemy w efektywniejszy sposób dotrzeć do osób z sektora technologicznego, szczególnie tych, którzy zajmują się programowaniem.

Istnieje jednak pewne „ale” lub gwiazdka, która mówi, że jeżeli chcemy używać tego typu narzędzi we współpracy z osobami z sektora technologicznego, musimy dobrze zrozumieć, co te elementy znaczą.

W tym świecie ważne jest poczucie, że po drugiej stronie, po stronie osoby, która pracowała nad wykorzystaniem tych metafor, jest ktoś kompetentny. Jeżeli nie zrozumiemy dobrze, czym są bramki logiczne, czy kolejne elementy, które zaraz przedstawimy, może okazać się, że sami sobie strzelimy w stopę. Jeżeli podążamy ścieżką metafor, szczególnie tych technicznych, dobrze jest wiedzieć, o czym mówimy – przynajmniej na podstawowym, definicyjnym poziomie.

RELACJE jak API

Perspektywa Relacji jest dedykowana osobom nazywanym Partnerami. Można ją porównać do API, interfejsu oprogramowania aplikacji, który jest metodą komunikacji pomiędzy elementami oprogramowania. Przykładowo, w sklepie internetowym API działa jak łącznik pomiędzy sklepem a bramką płatności, umożliwiając realizację transakcji. Tym samym API, podobnie jak perspektywa Relacji, pomaga dwóm różnym systemom nawiązać komunikację.

Partnerzy dominujący w perspektywie relacji to osoby, które mają zdolność do łączenia ludzi. Są oni spoiwem, klejem zespołu, które umożliwia skuteczną, komfortową współpracę, nawiązanie relacji, a nawet rozmowy pomiędzy osobami z różnymi punktami widzenia, czy to w zakresie FRIS®, ról, czy światopoglądu.

Co więcej, API i osoby z aktywną perspektywą relacji mają podobne cechy. API preferuje bieżącą komunikację z każdym systemem, podobnie jak osoby z aktywną perspektywą relacji, które łatwo wchodzą w interakcje z innymi i wysyłają interpersonalne sygnały. Są one zaangażowane, a ich emocje są widoczne dla innych.

Podobnie jak w przypadku API, jeżeli jestem zadowolony i mam aktywną perspektywę relacji, zobaczycie i odczujecie to, ponieważ nie mam potrzeby ukrywać mojego stanu emocjonalnego. Wręcz przeciwnie, chętnie podzielę się nim z wami.

Komunikacja w API, podobnie jak wśród partnerów, musi być na bieżąco. Jeżeli jest jakiś temat do omówienia, powinniśmy go przegadać, pokazując nasz stan emocjonalny, ponieważ nie ma nic złego w dzieleniu się emocjami i byciu z nimi blisko. To jest właśnie świat perspektywy Relacji.

Kolejna wspólna cecha API i perspektywy Relacji to to, że oba są spoiwem łączącym systemy, w tym przypadku ludzi. Sklep internetowy i bramka płatności mogą być napisane w różnych technologiach, ale dzięki API mogą współpracować i osiągać wspólne cele.

Dwie osoby mogą pochodzić z dwóch różnych światów, ale często Partnerzy sprawiają, że te osoby tworzą zespół. Dla osób z perspektywą Relacji, poczucie zespołowości i wspólnoty jest niezwykle istotne.

IDEE jak mikroserwisy

Trzecia perspektywa, perspektywa idei, dedykowana Wizjonerom, jest porównywalna do czegoś takiego jak mikroserwisy, czyli pewnego sposobu projektowania architektury oprogramowania.

Mikroserwisy działają niezależnie, są odrębnymi programami, które tworzą jedną, spójną aplikację. Przenosząc to na płaszczyznę Wizjonera, otacza on się wielością różnych konceptów, pomysłów, podejść, które dla kogoś z zewnątrz mogą wydawać się niepowiązane. Wizjoner, podobnie jak mikroserwisy, świetnie odnajduje się w tej złożonej układance, w nieoczywistych połączeniach pomiędzy wieloma, na pierwszy rzut oka, niepowiązanymi elementami.

Mikroserwisy, chociaż funkcjonują niezależnie, tworzą jedną całość. Awaria jednego z nich nie wpływa na funkcjonowanie całego oprogramowania. Analogicznie, jeżeli jeden pomysł Wizjonera przestaje działać, bo na przykład nie wpisuje się w rzeczywistość, nie pada na podatny grunt, nie ma problemu. Wizjoner może dalej funkcjonować, ponieważ taka sytuacja stwarza możliwość zredefiniowania rzeczywistości i wymyślenia czegoś nowego.

To prowadzi nas do najważniejszej cechy mikroserwisów, którą warto zapamiętać. Z czasem mikroserwisów jest coraz więcej. Tak samo jest z Wizjonerami, którymi otacza się coraz więcej „mikroserwisów”, czyli pomysłów i możliwości, które generują z łatwością.

Przechodząc na płaszczyznę mikroserwisów, na pewnym etapie ich rozwoju, rozbudowa nie przebiega tak szybko. Kiedy jednak już zdecydujemy się na architekturę mikroserwisów, zaczynamy od jednego lub dwóch programów, które działają niezależnie, tworząc jedną aplikację. Po jakimś czasie okazuje się, że tych mikroserwisów mamy już kilkanaście.

To jest właśnie świat perspektywy idei.

STUKTURY jak niskopoziomowe języki programowania

Zamknijmy tę strukturę metafor perspektywą Struktur, dedykowaną osobom, które określamy mianem Badaczy.

Struktury można porównać do niskopoziomowych języków programowania. Jeżeli nie jesteście obecnie związani ze światem technologii, ze światem pisania i tworzenia oprogramowania, mogliście pomyśleć, że to jest jakaś ujma. Cóż, to nie jest.

Kiedyś organizowaliśmy w firmie otwarte spotkanie – meetup – dedykowany społeczności technologicznej, na którym obecni byli również ludzie spoza tej bańki technologicznej. Gdy tematem jednego z wystąpień był język wysokopoziomowy, nie było problemu. Ale kiedy zapowiedziano prelegenta, który miał omówić niskopoziomowy język programowania, poszedł z widowni komentarz: „Uuu, ale mu pocisnął!”, bo ludzie spoza tego świata pomyśleli, że to jest coś pejoratywnego. Nic bardziej mylnego! 😀

Niskopoziomowe języki programowania służą do tworzenia narzędzi, które umożliwiają innym programistom programowanie. Analogicznie jest z perspektywą Struktur: osoby z aktywnymi Strukturami, z dominującą tą perspektywą, lubią mieć dużo danych. Często mają takie podejście, że im więcej dostaną danych, tym lepiej – dzięki temu podejmują lepsze decyzje.

Niskopoziomowe języki wymagają precyzji i zwracania uwagi na szczegóły. Osoby, które mają w sobie dominującą perspektywę Struktur, paradoksalnie – albo może nie paradoksalnie – lubią dokładność, gdzie jest wiele danych do przemyślenia, gdzie mogą się zanurzyć i skupić na analizie tych danych, zwracając uwagę na szczegóły, na braki, na to, co nie działa, jakie elementy naszej rzeczywistości czy systemu wymagają optymalizacji.

To jest charakterystyczne dla Struktur. No i ostatnia rzecz. Kolejnym wymogiem jest cierpliwość i zastosowanie wielu celnych metod pisania kodu. Podobnie jest w Strukturach.

Jeżeli jest do podjęcia jakaś decyzja, może ona być wielokryterialna, ale nie zawsze jest jedna prosta droga decyzyjna, bo jest tyle czynników do uwzględnienia, tyle danych do przeanalizowania, że potrzeba na to czasu, cierpliwości i spojrzenia na to z perspektywy wielu kryteriów.

Margaret Hamilton i niskopoziomowe języki programowania

Chciałbym zakończyć pewną puentą te cztery metafory, które opisują cztery perspektywy poznawcze. Chciałbym Was zabrać do roku 1969 i może trochę odczarować obraz branży IT, pozostając nadal w kontekście niskopoziomowych języków programowania. Branża ta jest mocno zdominowana przez mężczyzn.

A co by było, gdybym Wam powiedział, że kiedyś programowanie było postrzegane jako… bardzo męskie zajęcie? W latach 50-tych i 60-tych programowanie, jako praca biurowa, nie było kojarzone jako zawód, którym powinni się zajmować mężczyźni. Dlatego robiły to kobiety i to z dużymi sukcesami. Nie wiem, czy kojarzycie taką osobę jak Margaret Hamilton. To właśnie dzięki niskopoziomowym językom programowania, w 1969 roku pomogła wynieść Neila Armstronga w kosmos.

Jeżeli oglądacie to na YouTube albo słuchacie na Spotify, gdzie macie też wideo, zobaczycie zdjęcie pani Hamilton stojącej przy stosie kilkunastu ksiąg.

Można by pomyśleć, że to są książki telefoniczne. Nic bardziej mylnego. Są to swego rodzaju zapiski – zapiski, które są po prostu niskopoziomowym oprogramowaniem, napisanym w tej technologii i wydrukowanym w postaci książek, które sięgają od góry do dołu i niemalże ją przewyższają.

Myślę, że ona mogła mieć tutaj około metr siedemdziesiąt sześćdziesiąt. Wyobraźcie sobie, że od góry do dołu jest tyle kodu. Tyle było potrzebne, żeby wynieść człowieka w kosmos. Ale zadziałało, i dziś możemy myśleć o rozwiązaniu problemów, które mamy na Ziemi, próbując zdobyć kosmos. Koniec dygresji, ale mam nadzieję, że ta ciekawostka dotycząca świata technologicznego może być dla Was przynajmniej interesująca, albo nawet w jakiś sposób użyteczna.

Które firmy to technologiczne?

Przejdźmy zatem dalej. Kiedy myślimy o firmach technologicznych, zadajemy sobie pytanie: które firmy to te technologiczne? A właściwie, które nie są? Jeżeli się nad tym zastanowić, to dzisiaj każda firma, która w jakiś sposób funkcjonuje w Internecie, jest firmą technologiczną.

Możemy tutaj mówić zarówno o różnego rodzaju korporacjach, firmach logistycznych, produkcyjnych, software house’ach, firmach produkujących gry komputerowe. Przecież to też jest bardzo duży rynek. Mamy też firmy dostarczające różnego rodzaju produkty cyfrowe. Ja przygotowałem tę prezentację z mniejszymi lub większymi sukcesami na MIRO. To właśnie firma, która produkuje tę aplikację, również jest firmą technologiczną.

Świat ten jest dość złożony, bardzo kolorowy, bogaty, a przede wszystkim pełen różnego rodzaju ról i stanowisk, które mogą wprowadzić w konsternację kogoś spoza świata IT. Przykładowo, programistów często nazywamy deweloperami, co może prowadzić do nieporozumień.

Mamy tutaj różnego rodzaju inżynierów, analityków, osoby zajmujące się przetwarzaniem ogromnych ilości danych – mówimy o data analitykach, data scientistach, data deweloperach, czyli programistach. Mamy też ludzi zajmujących się technologią blockchain i wiele innych, czasem nietypowych ról, które mogą wprowadzić Was w zakłopotanie.

Możemy również spotkać osoby na stanowisku administratora systemów. Co to tak naprawdę oznacza? Mam swój „papier lakmusowy”, który pozwala mi łatwo sprawdzić, czy osoba po drugiej stronie dobrze rozumie świat IT, czy jedynie coś o nim wie.

Może ta osoba ma swoją stronę internetową, ale być może nigdy nie zainwestowała swojego czasu i energii w zrozumienie tego świata. „Papier lakmusowy” polega na tym, że kogoś spoza świata IT często można rozpoznać po tym, że nazywa programistę „informatykiem”. To świadome uproszczenie z mojej strony.

Jeżeli macie w swoim otoczeniu kogoś, kto pracuje w firmie technologicznej i zajmuje się tworzeniem oprogramowania, zapytajcie tę osobę, jak się czuje, gdy ktoś nazywa ją „informatykiem”. Przeprowadzałem takie testy i większość osób nie reagowała pozytywnie na takie określenie. „Nie jestem informatykiem, jestem programistą, tworzę oprogramowanie, piszę różnego rodzaju funkcje. Nie zainstaluję Ci Windowsa…” – to jest to, co warto wiedzieć o tej branży.

Aby skutecznie wdrażać narzędzia IT w firmach technologicznych, warto zrozumieć specyfikę ich działania, język, którym się posługują. To skraca drogę, zmniejsza dystans, sprawia, że mury między nami, szczególnie jeśli jesteśmy osobami wprowadzającymi różne rozwiązania, stają się mniejsze.

Jeżeli wejdziecie na salę albo na spotkanie i użyjecie do osób zebranych określenia „cześć informatycy”, możecie sobie zbudować niezły mur. Oczywiście, upraszczam, ale zdarzało mi się słyszeć podobne stwierdzenia.

Za każdym razem, kiedy mówicie do programisty, że jest informatykiem, to jest ten sam scenariusz, kiedy ktoś do coacha mówi, że jest mówcą motywacyjnym. Wszyscy coachowie czytający ten tekst właśnie zrozumieliście o co mi chodzi.

Wdrażanie FRIS® w firmie IT

Jeśli wkraczacie w świat firm technologicznych, wiedzcie, do kogo się zwracacie. Jeżeli na sali są programiści, developerzy, zastanówcie się lub zapytajcie ich, jak wolą, aby się do nich zwracano. Czy określenie „informatyk” jest dla nich akceptowalne, czy nie? Są to bardzo prozaiczne rzeczy – takie drobne kamyki, które świadomie lub nieświadomie możemy wrzucić do buta. Podczas maratonu, jakim jest wdrażanie i późniejsze utrzymanie narzędzia psychometrycznego, te małe kamyki mogą nam przeszkadzać. Nie ma więc sensu utrudniać sobie zadania.

Czego unikać podczas wdrażania FRIS® w zespole programistycznym

Pierwsza rzecz to nadużywanie psychologicznego, branżowego żargonu. Nikt nie lubi czuć się niekompetentny. Jeżeli trener czy osoba wdrażająca wchodzi z jakimś narzędziem i zaczyna używać słów, które są niezrozumiałe dla odbiorców, bo założył, że to są bardzo ważne i poważne rzeczy, które należy opisywać w skomplikowany sposób, to komunikacja stanie się trudniejsza.

W świecie IT wiele osób uważa, że jeśli nie potrafisz opisać czegoś skomplikowanego w prosty sposób, to znaczy, że tego nie rozumiesz. Im prostszym językiem będziemy się posługiwać wobec osób, które mają skorzystać z narzędzia albo już go używają, tym lepiej. Zaleca się używanie bardziej neutralnego, bezpośredniego języka, dopasowanego do grupy odbiorczej.

Widziałem kilka ofert dotyczących wdrażania różnych narzędzi w firmach technologicznych, które zostały napisane przez osoby, które zajmują się czymś innym niż IT, głównie psychologią. W tych ofertach pojawiało się wiele niepotrzebnych słów, a pomijano najważniejszy aspekt: rozwiązywanie problemów biznesowych, które często mają te zespoły. Takie problemy mogą dotyczyć np. trudności w komunikacji.

Jeżeli chcecie dotrzeć do ludzi za pomocą FRIS® (np. waszym zadaniem jest wprowadzić to narzędzie w organizacji, niekoniecznie je sprzedawać), warto mówić w kategoriach typu „istnieje szansa, że zaczniemy się lepiej rozumieć i może nawet polubimy się po tym procesie”. Podkreślam „istnieje szansa”, bo dużo zależy od ludzi, którzy wejdą w ten proces. Nie nadużywajcie psychologicznego żargonu. Używajcie możliwie prostego, praktycznego, zrozumiałego języka.

Druga rzecz to uwzględnienie specyfiki IT i świadomość tego, czy przychodzicie na spotkanie czy warsztat do start-upu, czy do korporacji. Kiedyś miałem przyjemność uczestniczyć w szkoleniu w jednym z software house’ów, gdzie trenerka mówiła do nas jak do pracowników korporacji, co wielu osobom się nie podobało. Nie oceniam tutaj ani firm o zacięciu start-upowym, ani korporacji – po prostu trzeba wiedzieć, do kogo się zwracać i dopasować swój język. Znowu, kluczowa jest tutaj komunikacja.

Ostatnia rzecz: jeżeli osoba wdrażająca narzędzie albo zapowiadająca jego wdrożenie wejdzie ze zbyt dużym entuzjazmem i powie, że „FRIS® odmieni wasze życie!”, może to być strzał w kolano. Jak już wielokrotnie podkreślałem, w tej branży spotkacie wiele osób sceptycznych, dążących do obiektywizmu, zdystansowanych. Świat firm technologicznych przyciąga takie osoby w znacznej mierze. To potem pokażę na danych.

Warto uwzględnić to w swojej komunikacji, zwłaszcza że FRIS® dotyczy komunikacji, współpracy, a przede wszystkim – komunikacji. Osoba, która przychodzi do organizacji i ma wdrożyć to rozwiązanie w zespole, powinna mieć opanowane podstawy komunikacyjne zawarte w narzędziu.

Jak mówić o FRIS® w zespole technologicznym

Rekomenduję Wam używać prostego języka. Mówcie o FRIS® praktycznie i konkretnie. Podawajcie przykłady i wskazówki dotyczące wykorzystania narzędzia na realnych case’ach. Jak można korzystać z tego narzędzia, aby było ono użyteczne? Mówcie zatem prosto, praktycznie i użytecznie. I ostatnia rzecz – wdrażajcie FRIS® w firmach technologicznych w poprawny sposób. Jeżeli mamy Zawodników, to używajmy słowa „Zawodnicy”, a nie „zieloni”, bo ten kolor jest akurat przypisany do tej perspektywy. Jeżeli mamy Partnerów, to mówmy „Partnerzy”, jeżeli mamy Wizjonerów, to „Wizjonerzy”, jeżeli mamy Badaczy, to „Badaczy”. Te nazwy są po to, abyśmy lepiej korzystali z narzędzia, zgodnie z tym, do czego zostało ono przypisane.

Jest to istotne, ponieważ FRIS® jako proste, praktyczne i użyteczne narzędzie łatwo adoptuje się do naszej rzeczywistości. Jednakże istnieje duże zagrożenie, że ludzie będą nadużywać tego narzędzia lub wykorzystywać je przeciwko sobie.

W niedalekiej przyszłości na pewno nagram odcinek na temat zagrożeń, które mogą wyniknąć, jeśli będziemy niewłaściwie używać narzędzi psychometrycznych, takich jak FRIS®. Im prostsze narzędzie, tym większe jest pole do popisu dla osób, które mogą chcieć je nadużywać. Łatwo jest wpadać w pułapkę etykietowania lub posługiwania się stereotypami. Dlatego – prosto, tak; praktycznie, tak; użytecznie, tak; poprawnie – sto razy tak. Rolą osoby, która wdraża to narzędzie, jest zadbać o jego poprawne używanie.

Nie bez przyczyny FRIS® powołał do życia Radę Etyki oraz Kodeks Trenerów FRIS®. Etyczne podejście do osoby badanej, trenera i organizacji jest kluczowe podczas wdrażania tego narzędzia. Jeżeli chcecie dowiedzieć się więcej na ten temat, polecam wpisać w wyszukiwarkę. Dodam też do materiałów odcinek z Małgorzatą Podolecką, gdzie rozmawiamy o etycznym wykorzystaniu narzędzi psychometrycznych w biznesie.

W następnym odcinku opowiem Wam o świecie firm, które nie mają jeszcze FRIS® i pokażę, jak się zmienia rzeczywistość, gdy wdroży się FRIS®. Chociaż mówię oczywiście o firmach technologicznych, jestem przekonany, że jeżeli jesteście z innej branży lub sektora, znajdziecie wiele powiązań z waszą rzeczywistością w treściach, które prezentuję. Czemu by nie? Tymczasem dziękuję za dzisiejsze spotkanie. Jak zawsze, kolejny odcinek jest już dostępny do przeczytania lub odsłuchania.

Poprzedni odcinek: Człowiek jak oprogramowanie. FRIS® jest jak framework

Transkrypcję przygotowałem za pomocą algorytmów AI (chat GPT4).