To jest 255. odcinek podcastu Porozmawiajmy o IT, w którym z moim gościem rozmawiam o customer centricity, czyli skupieniu się na potrzebach klienta.

Wszystko co potrzebujesz, notatka, linki, transkrypcja czekają na Ciebie na porozmawiajmyoit.pl/255.

Myślisz o zmianie pracy lub przebranżowieniu się do IT? zajrzyj na SolidJobs, gdzie znajdziesz przejrzyste oferty z informacją co do zarobków, technologii i projektów.

Nazywam się Krzysztof Kempiński, prowadzę ten podcast oraz jestem autorem książki Marka osobista w branży IT. Mam misję polegającą na poszerzaniu horyzontów ludzi z branży IT. Tak się składa, że możesz bardzo mi pomóc w jej realizacji poprzez wystawienie oceny w aplikacji, w której tego słuchasz lub podzielenie się odcinkiem w social mediach. A teraz zapraszam Cię już do odcinka.

Odpalamy!

 

Cześć, mój dzisiejszy gość to engineering manager z 16-letnim doświadczeniem w IT. Przez lata zdobywał doświadczenie jako frontend developer, UX designer oraz team leader, co dało mu unikalne spojrzenie na tworzenie produktów zorientowanych na użytkownika. Obecnie kieruje zespołami developerskimi w Leica Geosystems, rozwijając zaawansowaną usługę chmurową do monitorowania produktywności i jakości prac ciężkich maszyn budowlanych. Specjalizuje się w budowaniu kultury, procesów i narzędzi wspierających podejście customer centricity, prywatnie entuzjasta motorsportu, simracer i pasjonat psychologii sportu oraz rozwoju osobistego. Moim i Waszym gościem jest Adam Kochanowski.

Cześć, Adam, bardzo miło mi gościć Cię w podcaście.

 

Cześć, Krzysztof, również bardzo mi miło, że mogę dzisiaj gościć u Ciebie.

 

Rozwijając produkty cyfrowe, tworząc je, tworząc software, bardzo często skupiamy się na tych rozwiązaniach technologicznych, na architekturze, na infrastrukturze, na tych wszystkich detalach implementacyjnych i niestety umyka nam często to, że na koniec dnia tworzymy te rozwiązania dla użytkownika końcowego czy też dla naszego klienta. 

I właśnie o tym, jak nie stracić z oczu tego najważniejszego powodu, czy też odbiorcy rozwiązań cyfrowych, które na co dzień w IT tworzymy, będę rozmawiał z Adamem. 

Zanim jednak do tego przejdziemy, to chciałbym Cię, Adam, standardowo, jak to u mnie, zapytać, czy słuchasz podcastów. Jeśli tak, to może jakieś ciekawe audycje będziesz w stanie zarekomendować. 

 

Jasne, byłem przygotowany na to pytanie, słucham Cię od dość dawna i szczerze mówiąc, muszę powiedzieć, że jeśli chodzi o tematy branżowe, IT i tym podobne, to prawdę mówiąc, słucham tylko Twojego podcastu. 

 

Dziękuję bardzo. 

 

Natomiast głównie w wolnych chwilach koncentruję się raczej na tematach sportowych, na motorsportowych, więc jeśli ktoś jest tym zainteresowany, to na pewno mogę polecić tutaj kilka audycji. Więc numerem jeden będzie na pewno Speed Secrets Rossa Bentleya. Numerem dwa dla mnie to jest coś bardziej z dziedziny coachingu, motywacji, to jest Enzo Mucci, program się nazywa Race Driver Coach Show. I ostatnio też dość dużo czasu jakby spędzam na zgłębianiu tajników psychologii sportu, tak szeroko pojętej. I tutaj słucham Andrzeja Staszczuka. 

A tak poza tym to raczej nie słucham czegoś, znaczy nie słucham podcastów w sposób jakby taki regularny, natomiast jest kilka osób ze środowiska, których czasem szukam ich wystąpień u różnych osób, bo bardziej mnie interesuje, co ta osoba ma do powiedzenia na dany temat, więc to tak taka hybryda. 

 

Pewnie, ma to sens. Dzięki za rekomendacje, na pewno kilku z nich tutaj jeszcze nie było, więc to jest też fajne źródło dla tych osób, które poszukują tego typu nowych audycji, o których jeszcze nie słyszeli. 

Dobrze, Adam, na początku przedstawiając Ciebie, wspomniałem o customer centricity i chciałbym Cię teraz zapytać, czym właśnie jest ten parasol różnych podejść, technik, filozofii i metodologii, bo to jest, myślę, coś takiego, co definiuje nam podejście nakierowane na użytkownika końcowego. Więc czym to właściwie jest? 

 

Bardzo fajnie w zasadzie już mi trochę pomogłeś odpowiedzieć na to pytanie, bo dokładnie to jest taki parasol; po prostu według definicji jest to holistyczne podejście do zarządzania, budowania kultury organizacyjnej, procesów i jakby całego cyklu rozwoju i wdrażania oprogramowania czy po prostu czegoś innego. Ale generalnie ma ona na celu integrację wszystkich działów uczestniczących w tym cyklu życia, to jest właśnie IT, to jest marketing, to jest sprzedaż, business development itd., tak żeby te działy mogły współpracować razem, podejmowały decyzje, które są zorientowane wokół wspierania potrzeb i budowania relacji z użytkownikiem czy klientem. 

Bardzo fajnie w zasadzie już mi trochę pomogłeś odpowiedzieć na to pytanie, bo dokładnie to jest taki parasol; po prostu według definicji jest to holistyczne podejście do zarządzania, budowania kultury organizacyjnej, procesów i jakby całego cyklu rozwoju i wdrażania oprogramowania czy po prostu czegoś innego. Ale generalnie ma ona na celu integrację wszystkich działów uczestniczących w tym cyklu życia, to jest właśnie IT, to jest marketing, to jest sprzedaż, business development itd., tak żeby te działy mogły współpracować razem, podejmowały decyzje, które są zorientowane wokół wspierania potrzeb i budowania relacji z użytkownikiem czy klientem. 

 

Okej, czyli mamy połączenie, można powiedzieć, różnych sił, różnych działów po to, żeby na koniec dnia tę satysfakcję klienta, użytkownika, jakkolwiek by to nie zdefiniować, po prostu podnieść. 

Pojawia się pytanie, dlaczego w ogóle tego typu nowe podejście, swego rodzaju może nawet buzzword powstał, prawda? Bo to nie jest, jak gdyby, tak jak tutaj wspomniałeś na początku, coś zupełnie nowego. To nie jest nowa metodologia, nowy sposób podejścia do wytwarzania, oprogramowania, jego dostarczania itd. Raczej zebranie tych wszystkich elementów, które gdzieś tam już po części funkcjonują, które gdzieś się sprawdzają, i takie złączenie ich po to, żeby właśnie 1 plus 1 dało nam 3 na koniec dnia. Więc chciałbym Cię zapytać, po co tego typu podejście powstało i komu ma służyć? 

 

Dlatego dla mnie ta definicja pierwsza, ona jest taka trochę jakby, właśnie tak to nazywałeś, parasolem, ona jest trochę rozmyta, ale wydaje mi się, że trochę też celowo, ponieważ dla mnie przede wszystkim, gdyby ktoś zapytał o to, w jaki sposób wprowadzić taki, brzydko powiem, proces do organizacji, to ja bym powiedział, że raczej się go nie da wprowadzić, bo to nie jest jakby framework, który jest spisany, tym bardziej, że no trudno jest zintegrować nam działy, które pracują w zupełnie innej jakby dynamice.

Natomiast dla mnie tym takim klejem łączącym to wszystko, który umożliwia płynną współpracę tych działów jest mindset tak naprawdę. To jest dociekliwość. To jest np. sytuacja, w której nie zakładamy, że wiemy wszystko z góry, tylko stawiamy sobie bardzo dużo pytań. I pytań w kontekście: okej, ale jak to wpłynie na naszych użytkowników lub na nasze cele biznesowe itd., itd. Więc to jest dla mnie taki mindset ciągłego kwestionowania wszystkiego albo raczej zadawania właściwych pytań, czy wszystko to, co robimy, czy decyzje, które podejmujemy, są tak naprawdę zgodne z potrzebami naszych użytkowników czy klientów. 

Dużym też aspektem dla mnie jest też to, że jeśli mówimy o zadawaniu pytań, to też jako inżynierowie mamy pewną tendencję do stawiania od razu rozwiązań do tych pytań. I to często też jest dość zgubna droga, dlatego dla mnie bardzo ważne jest to, żeby te odpowiedzi na te pytania były poparte danymi. 

I tutaj wchodzi nam też cały dział tego tak zwanego decision driven. Czyli po prostu, żebyśmy mieli też dane na temat naszych użytkowników, ilościowe, jakościowe, żebyśmy mieli zestawione kanały komunikacji, tak żebyśmy mogli idealnie, bardzo szybko po prostu znaleźć potwierdzenie tych danych, tudzież zwalidować nasze hipotezy. 

 

Jasne. Pytanie powstaje takie, czy to podejście, które pewnie za chwilę będziemy sobie rozbierać na większe szczegóły, ma sens tylko w przypadku firm produktowych, które przez dłuższy czas dopieszczają jakiś produkt, rozwijają go, dają kolejne feature’y, sprawdzają, jak to się przyjmuje na rynku i tutaj w takich interakcjach do tego podchodzą, czy też może inny rodzaj zespołów, firm, który działa w nieco inny sposób też wyniesie jakąś wartość właśnie zastosowania tego zbioru różnych taktyk i podejść? 

 

Ja miałem przyjemność bycia po dwóch stronach, czyli miałem przyjemność pracować jako konsultant na projektach dla klientów, a aktualnie pracuję w firmie produktowej i jakby działam w ramach jednego produktu, jednej usługi. Więc powiem tak, odnosząc się do definicji, że jest to integracja wielu działów, na pewno łatwiej by było to podejście jakby osiągnąć i ustabilizować w sytuacji, w której mamy wpływ, mamy kontakt ze stakeholderami z innych działów organizacji i po prostu mamy wpływ właśnie na marketing, na sprzedaż, na biznes itd. 

Natomiast jeśli wrócimy sobie do samej definicji tego, że to jest organizacja wszystkich procesów, a to jest przede wszystkim mindset, to ja się trochę podroczę z tą definicją, natomiast załóżmy, że gdyby naszym produktem np. jako software house czy body leasing po prostu byłaby jakość dostarczana w naszych ludziach, których po prostu udostępniamy jako specjalistów, to też możemy trochę na to popatrzeć od strony tego, czego nasi ludzie potrzebują i ich potrzeb, żeby na koniec dnia ten klient końcowy po prostu osiągnął swój sukces, więc też jest to rozwój, jest to zapewnianie warunków pracy. 

Może to jest naciągana trochę definicja, natomiast wydaje mi się, że jeśli zaaplikujemy ten mindset ciągłego rozwoju, ciągłego dowiadywania się i tej takiej ciekawości, to wydaje mi się, że tutaj spektrum jest dość szerokie, ale na pewno łatwiej będzie to zastosować w przypadku firm produktowych. 

 

Rozumiem. Tutaj na początku wspomniałeś, że customer centricity to nie jest jakaś metodologia, to nie jest sztywny framework. W związku z tym, czy są jakieś niezbędne składniki, czy jest jakieś takie minimum, o którym mógłbyś powiedzieć, gdzie możemy mówić o tym podejściu, versus kiedy już, powiedzmy, czegoś zabraknie i to nie jest już customer centricity w takim definicyjnym podejściu, jak przedstawiłeś? 

 

Wydaje mi się, że tutaj wyszczególniłem sobie kilka takich składników w momencie, kiedy eksperymentalnie zacząłem wdrażać tego typu rozwiązania w moich zespołach. Więc na pierwszym miejscu dla mnie to jest właśnie kultura organizacyjna i mindset. Ja może rozwinę zaraz te punkty. 

Drugi, wydaje mi się, kluczowy bardzo to jest strategia na produkt. To nam też trochę zapewnia pewien constraint do myślenia na temat tego, co robimy, czego nie robimy. Łatwiej się pewne decyzje w ten sposób podejmuje. Kluczowa na pewno jest dobra definicja ról w zespołach. 

I oczywiście skillset. Wiadomo, że to wszystko musi być też wsparte konkretnymi procesami. Tutaj właśnie już też możemy mówić o procesach już takich popularnych, agile’owych. czy technikami już takimi bardziej też inżynieryjnymi typu continuous delivery i tym podobnymi. 

I też odnosząc się do tej definicji, że są to pytania czy decyzje oparte o dane, to musimy mieć po prostu zwyczajnie źródło tych danych i narzędzia analityczne ułatwiające nam po prostu szybkie znalezienie odpowiedzi. 

I wydaje mi się, że takie dwa ostatnie kluczowe to są dobrze zdefiniowane i zestawione kanały komunikacyjne ze światem zewnętrznym, czyli właśnie z użytkownikami tudzież innymi personami, które występują w całym cyklu. Tutaj nawiążę już trochę do change managementu, ale wiadomo, że jeśli mówimy o zmianie kultury i mówimy o integracji różnych działów, to musimy mieć dobry buy in i porządne wsparcie stakeholderów i decydentów w samej organizacji, bo w takim małym bąbelku gdzieś od strony, powiedzmy, zespołu developerskiego można pewne, że tak powiem, ciśnienie przyłożyć, żebyśmy bardziej się orientowali, natomiast jest zawsze ten sufit, od którego się odbijemy, więc tak, na pewno zaangażowani stakeholderzy. 

 

Podkreślasz tutaj znaczenie różnych ról, czy różnych osób, które są potrzebne, aby w ogóle mówić o tego typu podejściu. Oczywiście osoby zajmujące się technologią, oczywiście osoby zajmujące się produktem, pewnie też danymi i analityką co nieco, żeby mieć ten wkład, ale na koniec dnia nic pewnie się nie może wydarzyć bez finalnego przyklepania decydentów. 

W związku z tym pojawia się pytanie, jakie są takie kluczowe, niezbędne role w firmie, aby tego typu strategię, tego typu podejście wdrożyć i jakie znaczenie, jaką rolę tutaj odgrywają te osoby, które z tym twardym IT na co dzień mają do czynienia? 

 

Ja Ci może powiem, jak ja zacząłem, bo ja zacząłem to podejście wdrażać w takim małym, eksperymentalnym zespole, w takiej grupie roboczej i żeby w ogóle wystartować, wiedziałem, że na pewno potrzebuję, bo jak mówimy o buy in tym z góry, to też musimy mieć ten buy in jakby oddolny też. Dla mnie kluczowe było, żeby w całym tym procesie uczestniczyli tech leadzi zespołów, jako po prostu ambasadorzy zmian, czy też ewentualnie architekci, w zależności jak to jest setupowane w organizacji. Na pewno UX designer, czy UI designer, osoba, która będzie też strzegła w pewnym sensie tego całego procesu. 

Uwzględniłbym też osobę, która miała bardzo dużo jakby chęć uczenia się analizy danych, po prostu pracą z danymi, analityką produktową, bo musimy gdzieś te dane jakby zbierać i później je umieć czytać. Devopsi na pewno, ponieważ żebyśmy mogli też zapewnić te techniki, o których mówiłem, czyli właśnie zestawienie w taki sposób całego cyklu, żeby to wszystko lądowało bardzo szybko na produkcji, żebyśmy mogli po prostu skrócić feedback lub iterować na naszych pomysłach jak najszybciej. Czyli całe podejście MVP się kłania, które po prostu musi być wsparte przez infrastrukturę. 

 

Jasne. Te osoby, które mają na co dzień do czynienia z technologiami, czy według Ciebie one mają jakąś szczególną rolę tutaj w tym podejściu? czy też po prostu są kolejną rolą, która wchodzi w skład i dokłada się do sukcesu na koniec dnia? Próbuję nawiązać do tego, że słuchacze tego odcinka, często będący osobami właśnie zajmującymi się technologią, być może będą chciały zrewidować, zastanowić się, jak właśnie sprzedać wyżej, można powiedzieć, tego typu pomysł. W związku z tym, żeby to zrobić, to chyba muszą trochę uwierzyć same w to, że to im również w jakiś sposób przynosi określone korzyści, zyski, coś ułatwia? 

 

Odpowiedź może być trochę złożona. Wydaje mi się, że takim głównym benefitem, który możemy uzyskać jako osoby po prostu, jako inżynierowie, to większe zaangażowanie, większa motywacja. Na przykład ja tak miałem i dlatego też, szczerze mówiąc, całe życie spędziłem na frontendzie, bo miałem możliwość szybkiego feedbacku odnośnie do tego, co zrobiłem, bo to było widoczne, więc ten feedback był bardzo szybki z natury. Więc myślę, że to. 

Jeden z takich przykładów, który mogę się posłużyć, jest to, że w momencie, kiedy ja robiłem pierwsze MVP z moim zespołem, jako pilot totalny, to mieliśmy zapiętą analitykę, to było to w postaci Hotjara, i po prostu zobaczyliśmy, jak ludzie używają tego. Jakby ilościowo, bo była po prostu zapięta analityka ilościowa, natomiast mogliśmy też podejrzeć nagrania. 

To jest dość ciekawe doświadczenie, bo ono może budzić trochę frustracji, ale też trochę dumy. Więc jeśli zrobimy coś, co faktycznie później widzimy, że ludzie z tego korzystają i jak zrobimy to w efektywny sposób, to dla mnie osobiście chyba nie ma lepszej gratyfikacji jako osoba tworząca cokolwiek, że po prostu zmieniamy czyjeś życia, ułatwiamy, dostarczamy wartość i ludzie lubią po prostu, czy chcą tego używać. 

Wydaje mi się, że takim głównym benefitem, który możemy uzyskać jako osoby po prostu, jako inżynierowie, to większe zaangażowanie, większa motywacja. Na przykład ja tak miałem i dlatego też szczerze mówiąc, całe życie spędziłem na frontendzie, bo miałem możliwość szybkiego feedbacku odnośnie do tego, co zrobiłem, bo to było widoczne, więc ten feedback był bardzo szybki z natury. 

 

Tak. Ja myślę, że to jest punkt warty podkreślenia, bo większa satysfakcja z pracy może się wydawać czymś trudno mierzalnym albo jakimś takim hasłem, które gdzieś możemy przeczytać w ofercie o pracę, ale przypomniało mi się, jak Ty to mówiłeś, że wypalenie zawodowe, które gdzieś tam coraz bardziej do IT również wchodzi, to zgodnie z definicją jednym z komponentów wypalenia zawodowego albo właściwie przyczyn jest to, że nie widzimy sensu naszej pracy. 

Często nie widzimy tego sensu, ponieważ zwyczajnie nie ma tej pętli zwrotnej, nie widzimy po prostu efektów. W związku z tym nie wiemy, co robić dalej, nie mamy takiej informacji zwrotnej, czy nasza praca w jakiś sposób się przyczynia do czegoś. 

To, o czym tutaj mówimy, czyli skupienie się właśnie na tym użytkowniku i takie też szybsze iterowanie, może być swego rodzaju panaceum na tego typu problemy, bo nie dosyć, że w miarę szybko jesteśmy w stanie te nasze pomysły, idee sprawdzać, to jeszcze prawie że namacalnie widzimy, jak faktycznie użytkownicy z tego korzystają, więc to jest pewnie nie do przecenienia. 

 

Dokładnie. I wydaje mi się, że tak jak też wspomniałeś na początku, to nie jest tak, że to jest nowy koncept, prawda? Bo agile o tym mówi od wielu, wielu lat. Natomiast z moich obserwacji niestety ten agile często jest nadużywany i tak bardzo często sprowadza się po prostu do pewnych ceremonii lub gdzieś spotykania się po prostu rano. 

Natomiast wydaje mi się, że to podejście, ono może nie wymyśla tego wszystkiego od nowa, ale jakby przypomina po prostu, po co tu wszyscy jesteśmy, bo wydaje mi się, że niestety ten agile może nie jest używany zgodnie z oryginalną intencją bardzo często.

 

Idea się troszkę rozmyła. Faktycznie. Okej, to skoro jesteśmy przy tym punkcie, to jakie według Ciebie są największe problemy, bariery, rzeczy, które występują gdzieś po drodze, a może nawet i wcześniej, które gdzieś nas blokują we wdrażaniu customer centricity? 

 

To też powiem z mojego doświadczenia. Chyba największym wyzwaniem to jest sprzedawanie tego konceptu, tak naprawdę. Tutaj bym położył najwięcej uwagi. Bo jeśli dobrze, powiedzmy, tego nie udokumentujemy, tudzież nie pokażemy czegoś, nie zrobimy może jakiegoś pilota, bo zazwyczaj to już najczęściej to trzeba zrobić troszkę bez pytania, a potem ewentualnie przepraszać lub nie, po prostu zrobić pilota, który pokazuje wartość takich rozwiązań, bo inaczej zazwyczaj to się po prostu odbija o to, że nie ma czasu, są inne priorytety, trzeba robić funkcjonalności. 

I teraz to jest troszkę śmieszne, bo później prawdopodobnie nie wiemy, czy w ogóle ktokolwiek będzie ich używał, czy one faktycznie niosą jakąś wartość itd. Więc jakby to bym powiedział, że po prostu sprzedaż i komunikacja. Komunikacja, komunikacja, komunikacja, więc tutaj też z mojego doświadczenia polecam zrobić bardzo dokładną stakeholder mapę i dopasować treści, które komunikujemy w ramach tego typu przedsięwzięć, do grupy odbiorców. 

Wiadomo, że zarząd będzie zupełnie innymi informacjami zainteresowany, a zespoły deweloperskie prawdopodobnie będą zainteresowane, co się zmienia w technologii, czy mamy zaimplementować coś po swojej stronie, czy coś trzeba zoptymalizować, czy gdzieś coś zautomatyzować, więc to jest jakby takie świadome zarządzanie tą komunikacją. 

I jeśli chodzi dalej o wyzwania, to znowu wracam do początku. Ten mindset. Zmiana mindsetu może być wyzwaniem, właśnie dlatego, że jeśli mówimy tutaj o ciekawości i takiej dociekliwości, i ciągłym kwestionowaniu, i zadawaniu pytań, i drążeniu, czy na pewno, to szczególnie w działach inżynieryjnych wydaje mi się, może to być wyzwaniem, bo tak jak już mówiłem, wydaje mi się, że większość jednak osób jest przyzwyczajona do podawania rozwiązań, nie daj Boże kodowania ich od razu, co wcale też nie jest takie rzadkie, więc po prostu pilnowanie tego mindsetu i tłumaczenie, dlaczego, i pokazywanie zalet tego podejścia. 

Zmiana mindsetu może być wyzwaniem, właśnie dlatego, że jeśli mówimy tutaj o ciekawości i takiej dociekliwości, i ciągłym kwestionowaniu, i zadawaniu pytań, i drążeniu, czy na pewno, to szczególnie w działach inżynieryjnych wydaje mi się, może to być wyzwaniem, bo tak jak już mówiłem, wydaje mi się, że większość jednak osób jest przyzwyczajona do podawania rozwiązań, nie daj Boże kodowania ich od razu, co wcale też nie jest takie rzadkie, więc po prostu pilnowanie tego mindsetu i tłumaczenie, dlaczego, i pokazywanie zalet tego podejścia. 

 

Aby różni interesariusze, zwłaszcza ci biznesowi, myślę, zostali kupieni, tak jak to się ładnie mówi, pewnie muszą zobaczyć liczby, pewnie muszą zobaczyć jakieś realne dane, które pokażą, że mamy tutaj szansę coś ugrać, że mamy szansę zdobyć jakąś przewagę konkurencyjną itd. W związku z tym, co pewnie potwierdzisz, kluczowe jest nie tylko zdefiniowanie, ale faktyczne mierzenie tego, na czym nam faktycznie zależy w danym procesie czy też w danym po to, żeby wiedzieć, czy zmierzamy w tą dobrą stronę, ale też, żeby mieć właśnie te twarde dane na potrzeby różnych osób, różnych ról w firmie. 

Pojawia się w związku z tym pytanie, jakie metryki, jakie wskaźniki, jakie dane warto zbierać i śledzić, aby właśnie ten proces, tę strategię z sukcesem mierzyć i podglądać?

 

Jasne, to ja bym to podzielił na dwie grupy, czyli metryki, wskaźniki takie bardziej biznesowe, marketingowe i może takie czysto analityczne. Biznesowe: na pewno rzeczy, do których możemy się odnieść, to są podstawy, czyli to jest charn rate, to jest retencja, to jest customer satisfaction, to jest NPS. Bo na dobrą sprawę, jeśli mówimy tutaj o dobrych doświadczeniach użytkowników lub satysfakcji rozwiązywaniu potrzeb, to CSAT czy NPS, a wynikowo tak naprawdę retencja i charn są taką ostateczną metryką naszych działań, więc możemy po prostu tutaj złapać ten baseline i w ramach po prostu eksperymentów, jakichś programów pilotażowych możemy sprawdzić, co się zmieniło. 

To jest trochę długa pętla zwrotna, bo jednak sprawdzenie tych danych troszkę trwa, natomiast ja do tego podszedłem też z innej strony. Czyli w momencie wdrażania narzędzi analitycznych zmapowałem po prostu sobie najczęściej używane funkcjonalności i pewne założenia. I tutaj z zakresu tych metryk już takich bardziej, że tak powiem, produktowych, możemy zmierzyć np. adopcję nowych funkcjonalności albo wcześniej jeszcze discoverability. 

Tutaj muszę przyznać, że dla mnie to było dość otwierające oczy doświadczenie, gdzie po zapięciu analityki i release’ie okazało się, że funkcjonalności są nawet i niezłe, tylko nikt nie potrafi ich znaleźć. Czyli jakby można to zrobić od strony negatywnej, można przedstawić, że np. adopcja jest niska, czy discoverability jest niskie, albo właśnie samo już później, czy to z obserwacji, czy z przeglądania nagrań, możemy pokazać, że hej, robimy rzeczy, robimy je może bardzo dobrze, może egzekucja jest super, ale niestety nie osiągamy tego outcome’u, który chcemy. 

Ja myślę, że to jest taka baza, którą powinniśmy monitorować, natomiast w długim terminie tu zdecydowanie się opieram na NPS-ie i CISAC-ie, co wydaje mi się, że się też bezpośrednio będzie przekładać na churn i na retencję. 

 

To są te twarde dane, to są te twarde metryki i wskaźniki, ale tutaj wiele razy przewijało się z Twoich ust, że swego rodzaju mindset, swego rodzaju podejście w firmie jest kluczowe do sukcesu wdrożenia czy zaadaptowania tej strategii customer centricity. Czy zauważyłeś albo czy z Twojej obserwacji wynika, że organizacja ze swoją jakby nie było kulturą w jakiś sposób może pozytywnie albo negatywnie wpłynąć właśnie na sukces podejścia czy też zastosowania tego podejścia?

 

O zdecydowanie, bo wydaje mi się, że na dobrą sprawę tworzenie i pielęgnowanie kultury to jest chyba taki główny komponent tego, żeby pewien mindset w ogóle mógł wykiełkować. I tak jak ja do tego podchodziłem, to my np. zrobiliśmy to w taki sposób, że zmieniliśmy kompletnie język, w jakim się porozumiewamy. Czyli wyrzuciliśmy ze słownika naszego słowo wymaganie. Zastąpiliśmy słowo wymaganie słowem hipoteza. 

To jest trik językowy, ale on robi dużo. Bo wymaganie ze swojej natury jest zdefiniowane, ono jest stałe, ono ma w sobie bardzo dużo pewności. 

 

Tak, nienaruszalne. 

 

Jest nienaruszalne, jest święte i jest statyczne. Natomiast hipoteza z natury wymaga, z definicji też wymaga antytezy i syntezy. Więc przez to, że porozumiewamy się takimi słowami, ja bardzo często zacząłem też widzieć, że w momencie, kiedy zmieniliśmy język, ludzie zaczęli faktycznie się, jak to powiedzieć, triggerować na zasadzie, że w momencie, kiedy o czymś rozmawiamy i bardzo dużo jest komentarzy, a czy na pewno? A wziąłeś pod uwagę to, a co jeśli? I właśnie następuje ten proces antytezy. 

I to generalnie sama ta dyskusja, no to jest z teorii tego podejścia, jakby naprowadzi do lepszych syntez po prostu. Natomiast kluczem tego wszystkiego jest walidacja, czyli eksperyment. Tak na dobrą sprawę też możemy sobie hipotetyzować w nieskończoność, ale to będziemy zakrywać trochę bardziej o filozofię. Dopóki nie sprawdzimy, nie zwalidujemy pewnych założeń, to dalej nic nie wiemy. 

Więc dla mnie taką pierwszą składową tej kultury to jest właśnie zmiana języka. To jest, to bym powiedział, że to jest taki quick win, jeśli o to chodzi. I to podejście też automatycznie przerodziło się w powstawaniu nowych odpowiedzi, nowych pytań, czyli np. ja obserwuję bardzo często u siebie zachowania, że jeśli jesteśmy postawieni przed jakąś decyzją i zastanawiamy się, co zrobić, co będzie lepiej, zacząłem coraz częściej słyszeć: hej, sprawdźmy to. 

I to jest dla mnie znak, że faktycznie całe to podejście jakby wsiąka w tą kulturę, bo to zmienia kompletnie zachowania, to też nam otwiera drogę do właśnie albo zbudowania, albo do kupienia pewnych może narzędzi, i otwiera się cały wachlarz po prostu możliwości, które do tej pory jakby no może nie było dostępne, ale też to jest trochę tak, jak nie wiemy, że tego potrzebujemy, dopóki tego potrzebujemy. 

 

Tak samo myślę sobie, takie przyzwolenie na popełnianie błędów to też jest pewnie dosyć istotna rzecz, bo jeśli gdzieś jesteśmy karani albo są wyciągane jakieś konsekwencje takie negatywne, to pewnie siłą rzeczy tę pomysłowość, tę kreatywność prędzej czy później jako organizacja zabijemy wewnątrz. Tak samo właśnie jak język, o którym wspomniałeś, bardzo ważny. Myślimy językiem, można powiedzieć, więc jeśli go zmieniamy, to też nasz sposób podejścia i myślenia się zmienia, więc ta kultura organizacyjna gdzieś z tylnego siedzenia, ale mimo wszystko ma olbrzymi wpływ na to podejście. 

Myślę sobie, że też postawienie użytkownika końcowego wręcz w naszej misji, wartościach czy też wizji pozwala po prostu się na nim skupić. 

 

Tak, ale fajnie, że poruszyłeś ten temat właśnie tych, że tak powiem, kar, bo kolejną rzeczą, którą też starałem się zdefiniować, i to też jest dla mnie w zasadzie część procesów czy tej kultury, to jest reewaluacja naszego Definition of Done. 

Czyli standardowy taki, że tak powiem, cykl życia wymagań jest w sumie taki, że coś musi być zaprojektowane, udokumentowane, potem wydevelopowane, przetestowane, zdeployowane i wdrożone. Deployed and released. Natomiast ja do tego dorzuciłem jeszcze kilka etapów. Czyli cykl życia, tak naprawdę wymagania, nie kończy się w momencie, kiedy funkcjonalność została wdrożona. Ona się kończy w momencie, kiedy ona została odkryta przez użytkowników, kiedy ona została zaadoptowana przez użytkowników, kiedy ona jest łatwa w użyciu i ludzie są z niej zadowoleni, i wtedy dla mnie możemy powoli kończyć tę pętlę. 

Bo na każdym z tych etapów, na dobrą sprawę, mamy bardzo dużo iteracji i odnoszenia się do pierwszych cykli. Natomiast dla mnie przedefiniowanie Definition of Done niejako tworzy właśnie tę kulturę eksperymentacji, bo to nam zdejmuje całkowicie jakąkolwiek kwestię kary czy rozliczenia, ale też wymusza na nas wzięcie bardzo dużej odpowiedzialności za to, co robimy. 

Czyli to już nie jest task, który po prostu został przesunięty do done i koniec, jadę z następnymi. No nie, tam dobrze jeszcze właśnie popatrzeć, czy to zostało odkryte, zaadoptowane itd. 

 

Tutaj myślę, że bardzo dobrze ujawnia się i pokazuje to, o czym mówiłeś, że cała organizacja musi dzielić ten mindset, bo tego typu podejście, kiedy właśnie zakończenie zadania to nie jest przesunięcie do tej ostatniej kolumny, że poszło na produkcję i teraz już żyje sobie gdzieś tam w tym świecie, ale jest jeszcze kilka tych kroków. 

Wszystko to wymaga zrozumienia, zaakceptowania i też takiego, powiedziałbym, stwierdzenia, że tak robimy ze strony różnych osób decyzyjnych, różnych osób, które na ten produkt mają wpływ, więc teraz już myślę bardziej, rozumiem to, o czym mówiłeś na początku, że ten mindset musi być wspólny, żebyśmy o sukcesie tego podejścia mogli mówić. 

I to sprowadza mnie tutaj do ostatniego pytania, mianowicie jakie błędy są popełniane przez firmy, organizacje, zespoły, które właśnie mają gdzieś tutaj na swoim talerzu takie zadanie jak zastosowanie tego typu podejścia, z czym muszą się mierzyć i jakbyś też może tutaj tych problemów unikał, co byś doradził? 

 

Jeśli chodzi o wdrażanie, to mogę powiedzieć z mojego doświadczenia, ale gdybym miał się dzielić, gdybym miał pomóc komuś, kto chciałby spróbować się z tym zmierzyć, to prawdę powiedziawszy zacząłbym tutaj od takiego podstawowego change managementu. 

Czyli po prostu o zdefiniowaniu stakeholderów i od rozpoczęcia po prostu jakiegoś programu pilotażowego, bo na pewno, Krzysztof, Ty też widziałeś wiele razy, jak zmiany w organizacji potrafią zachodzić, czyli to jest dopiero definicja Big Bank Release, gdzie po prostu przez pierwsze kilka miesięcy nikt nie wie, co się dzieje, pojawiają się zwolnienia itd., więc tego bym na pewno unikał, więc musimy zbudować oddolnie to zaangażowanie ludzi. 

Na pewno tutaj jest potrzebny czas na jakieś szkolenia czy na jakiś coaching, tak żeby po prostu zespoły mogły popracować z tym, pouczyć się na tych błędach. Bo to też działa w dwie strony, całe to podejście, tak? Czyli musimy iterować też na poziomie meta, nie tylko na produktach. 

I chyba najważniejsze, jeśli nie mamy tego buy inu od decydentów i organizatorów, i reprezentantów pozostałych działów, bo wspomnieliśmy sobie tutaj o rozszerzonym Definition of Done. Ja już słyszę, że pewnie niektórym project managerom już tutaj lampki palą, bo co to znaczy, że coś nie jest skończone, dopóki nie jest skończone, jak ja mam to zaprogramować, znaczy jak ja mam to zabudżetować i jak mam to później rozliczyć, tak? No nie wiem jak, zakładam, że jest to część tych wyzwań. Natomiast każda z tych grup, z tych stakeholderów, jeśli zostanie podważony status quo, to każdy niestety ma swoje interesy, swoje pytania, swoje wyzwania, które po prostu trzeba jakoś wspólnie rozwiązać. 

 

Tak, to jest na pewno wymagające też takich umiejętności dyplomatycznych, umiejętności budowania relacji, które pewnie są niezbędne, żeby tego typu zmianę przeprowadzić. Na pewno duży temat. Dlatego niemniej bardzo się cieszę, że mieliśmy okazję dzisiaj właśnie o tym porozmawiać. I właśnie do takiego kompleksowego, holistycznego podejścia skierowanego na użytkownika końcowego, na tego naszego klienta zgodnie z customer centricity namawiał Adam Kochanowski. Adam, bardzo Ci dziękuję za poświęcony czas i za tą rozmowę.

 

Dziękuję bardzo.

 

Powiedz jeszcze, proszę, na koniec, gdzie Cię możemy znaleźć w internecie, gdzie możemy słuchać, czy odesłać? 

 

Najlepszym miejscem jest LinkedIn. 

 

Świetnie. Oczywiście link będzie w notatce do odcinka. Jeszcze raz Ci bardzo dziękuję. Udanego dnia i cześć. 

 

Dziękuję również. Pozdrawiam.

 

I to na tyle z tego, co przygotowałem do Ciebie na dzisiaj. Więcej wartościowych treści znajdziesz we wcześniejszych odcinkach. Masz pytania? Napisz do mnie na krzysztof@porozmawiajmyoit.pl lub przez social media. Ja się nazywam Krzysztof Kempiński, a to był odcinek podcastu Porozmawiajmy o IT o customer centricity.

Do usłyszenia w następnym odcinku.

Cześć!