Bezpośredni kontakt z klientem uczy zdrowej pokory, bo każdy człowiek przywiązuje się do tego, co robi. – Może okazać się, że taki użytkownik po prostu to rozwiązanie zjedzie z góry na dół, bo ma rację, bo ma zły dzień, bo się spieszy, bo woli inny kolor. I w tym przejawia się zdrowe podejście, żeby za bardzo nie przywiązywać się emocjonalnie do tego typu rzeczy i potrafić wejść w buty użytkownika, zmienić perspektywę – mówi Piotr Guziorski, Product manager w Bosch Polska. 

Rozmawialiśmy z Piotrem o umiejętnościach miękkich programistów oraz o komunikacji, która przydaje się także w życiu, nie tylko zawodowym.

Co cię zaskoczyło, kiedy pierwszy raz kontaktowałeś się z klientem?

Może zabrzmi to troszkę jak taka sztampa i klisza, ale uciekanie od hierarchii. Zmiana w rozmowie zleceniodawcy i zleceniobiorcy na komunikację partnerską, czyli równorzędną, konstruktywną. Na większości szkoleń komunikacyjnych mówi się, że redukowanie poziomu dyskusji wpływa pozytywnie i na nią samą, i na przekaz. Jeśli jest możliwość i nie ma kulturowych sprzeczności, to przejście na „ty” bardzo dużo ułatwia w takiej komunikacji. Automatycznie wymusza się komunikację na tym samym poziomie partnerskim, mimo że czasem robi się to kurtuazyjnie, bo są różnice wieku, wiedzy itd.

A w praktyce jak takie przechodzenie wygląda? Raczej nie ma z tym problemu czy zdarza się, że klienci nie chcą przechodzić na „ty”, nie chcą takiego uproszczenia?

Są takie sytuacje. Wiadomo, że jak się organizuje spotkania jednoosobowe z klientem i widać, że jest starszy, że raczej woli być nazywany per „pan”, to trzeba sobie z tym poradzić. Z reguły staram się jednak robić po prostu bardzo mieszane grupy wiekowo, etnicznie itd. Wtedy grupa, brzydko mówiąc, wymusza to przejście na “ty” i buduje partnerstwo. Chodzi też o to, kto pierwszy ośmieli się wyjść z tych ograniczeń. Ustalamy na początku reguły i pada propozycja czy możemy przejść na „ty”. Jeszcze nie zdarzyło się, żeby ktoś powiedział, że nie. Mimo że wiedzieliśmy, że mamy przed sobą w sali potencjalnie takich kandydatów.

Z zewnątrz wydaje się, że im większy klient, tym powinno być bardziej formalnie.

Jest oczywiście taka ogólno przyjęta zasada niezależna od firmy, że jak następuje pierwszy kontakt i nie jest osobisty, to stosuje się formę oficjalną. Jeśli się tylko zdarza spotkanie twarzą w twarz, to z reguły staram się te bariery jak najszybciej kruszyć. Im dłużej te bariery trwają, tym ciężej jest z komunikacją.

Do takich spotkań trzeba się jakoś przygotowywać? Miałeś historie związane z jakimiś kulturowymi obostrzeniami?

Istnieją typowe zachowania związane z konkretnym kontekstem. Mamy instrukcje, jak postępować w niektórych grupach etnicznych, co jest bardzo zabawne w odniesieniu do stereotypów na temat swojej nacji. Bardzo dużo można się nauczyć.

Najczęściej jest to kontakt z klientami z Niemiec, bądź z krajów niemieckojęzycznych. Z racji tego, że przez 6 lat mieszkałem w Niemczech, to może część z tych rzeczy stała się dla mnie naturalna. Ale faktycznie, koledzy z Niemiec, zwłaszcza ci starsi, szczególnie inżynierowie i konstruktorzy, lubią być tytułowani per „pan”, ale we współpracy na dłuższą metę, nie mają problemu z przejściem na „ty”. Zwłaszcza jeśli podejdzie się do nich profesjonalnie i szczerze.

Warto także przygotować się, zwłaszcza jeśli chodzi o konkretnie nację niemiecką, żeby przychodzić z konkretami. Niemcy są bardzo odporni, brzydko mówiąc, na „marketing bullshit”. Od razu wykrywają, że ktoś tutaj kręci, sprzedaje nie wiadomo co, a nie mówi konkretów.

Zdjęcie pochodzi z HackYeah z 2018 roku.

Co to w praktyce oznacza?

Zależy, z kim rozmawiasz. Jeżeli rozmawiasz z kimś decyzyjnym, na poziomie managera, to zawsze przychodzi się albo z decyzją, albo z informacją i wychodzi się z zadaniem. Dobrze przygotować kilka wariantów takich zadań i uformować prośbę o decyzję w korzystny dla nas sposób. Natomiast jeśli rozmawiasz z partnerami technicznymi, konsultantami, to jest to troszeczkę paradoks. Z jednej strony w ich pragmatyzm trafia namacalny argument, ale uwodzi też całościowe opakowanie i utylitaryzm. Polecam taki schemat: zagrywka marketingowa i twardy dowód na to, że tak jest. 

Wspomniałeś, że mieszkałeś w Niemczech. Czy mógłbyś więcej na ten temat powiedzieć?

Mniej więcej po półtora roku pracy w Warszawie zaczynałem tam karierę w centrali. Miałem okazję faktycznie przejść od stanowiska konsultanckiego, do takiego na pierwszej linii wsparcia, czyli bezpośrednio z użytkownikiem, nawet nie z klientem. Później zająłem się dewelopowaniem zmian w istniejących produktach pod wymagania użytkownika, prowadzeniem małych projektów, by w końcu pracować jako konsultant systemowy, czyli ktoś działający już bardziej na poziomie architektury. 

Po powrocie do Warszawy to były już stanowiska project managera i senior developera. Więc miałem okazję z centrali przejść przez cykl wsparcia produktu od pierwszej linii po development i architekturę produktu.

Kiedy doszło do pierwszego kontaktu z klientem, nie jako towarzysz spotkania, ale jako prowadzący spotkanie?

To był pierwszy rok mojego pobytu w Niemczech. Wyglądało to z reguły tak, że przychodził ticket od użytkownika. Osoba, która te zgłoszenia przyjmowała, jeżeli klasyfikowała je jako temat, który trzeba zaprogramować, przychodziła do mnie. I bardzo często było tak, że jak ustalaliśmy pewne szczegóły, to razem z kolegą z help desku wydzwanialiśmy do tego klienta i z nim dyskutowaliśmy.

W kontekście takiego podejścia: „kiedy w ogóle powinno się w swoją karierę wplatać elementy kontaktu z użytkownikiem?” moim zdaniem – im szybciej, tym lepiej. Wiem, że to może być trudne dla programistów, bo jesteśmy raczej introwertykami i taka otwartość nie zawsze leży w naszej naturze.

W Boschu w jakiś konkretny sposób wdraża się pracownika, żeby wchodził w taki etap kontaktu z klientami? 

Na rynku pracy, kiedy opisuje się stanowiska przy poszukiwaniu juniorów, to wychodzi na to, że jedyną formą komunikacji programisty ze światem jest rozumienie dokumentacji technicznej. Można go zamknąć w szafie, zalać formaliną i obrzucić go dokumentami. Natomiast wiem, że programista jako taki musi się też troszeczkę otworzyć. 

Jak można go spokojniej wdrożyć?

Jeżeli prowadzący projekt ma spotkanie z użytkownikiem, nie mam na myśli sponsora czy managament, tylko zwykłego użytkownika, to najlepiej developera na to spotkanie zaprosić w charakterze obserwatora. Dzięki temu zobaczy, jakie są prawdziwe problemy i oczekiwania użytkownika. Nawet nie musi „słownego inputu” w to spotkanie wnosić, ale może zobaczyć, jak faktycznie jest odbierane to, co robi, jak to jest używane w rzeczywistości, poza sterylnymi warunkami piwnicy developerów :). Zwłaszcza jeśli mówimy o takich procesach czy rozwiązaniach typu User Experience i narzędziach, to bardzo często stosuje się też testowanie z użytkownikiem, gdzie developer zapisuje akcje użytkownika i pomaga w syntezie rezultatów. 

Programiści są chętni sami z siebie, czy trzeba ich przekonywać do udziału w spotkaniach?

Są takie etapy w karierze młodego programisty, że te pierwsze dwa lata z reguły są mocno nastawione na twardą wiedzę techniczną, na szkolenia stricte techniczne. Wówczas cały swój wolny czas wolą poświęcić na kodowanie, niż na przesiadywanie na spotkaniach. Lubię wtedy mówić: „Słuchajcie, możecie sobie zaplanować swój rok na szkolenia na zasadzie 3:1. Zróbcie sobie 3 twarde szkolenia techniczne i jedno miękkie, na początku z komunikacji. Z biegiem lat i kariery zwiększajcie ten stosunek”.

Nie oszukujmy się, programiści nie lubią przesiadywać na tego typu spotkaniach. Zawsze mówię im, że nie muszą przychodzić na całą godzinę, ale tylko zobaczyć, jak ich praca jest odbierana. I jeśli faktycznie idziemy rozmawiać z użytkownikiem czy z klientem na temat konkretnego rozwiązania, które ten programista robił, to ich to bardziej zachęca. 

Czego uczy ich ta wiedza, jak użytkownicy odbierają efekt pracy danego programisty?

Uczy zdrowej pokory, bo każdy człowiek przywiązuje się do tego, co robi. Może okazać się, że taki użytkownik po prostu to rozwiązanie zjedzie z góry na dół, bo ma rację, bo ma zły dzień, bo się spieszy, bo woli inny kolor. I w tym przejawia się zdrowe podejście, żeby za bardzo nie przywiązywać się emocjonalnie do tego typu rzeczy i potrafić wejść w buty użytkownika, zmienić perspektywę. Im więcej się takich rzeczy zbierze, tym łatwiejsza jest po prostu nasza praca, bo wiemy, że coś, co robimy teraz, może mieć sens. Ale nie musi. 

Twoim zdaniem przejście z programisty seniora na product ownera, team leadera, konsultanta i różnych innych stanowisk, powinno być dosyć naturalnym przejściem?

Znów zależy to od osobistych preferencji. Nie każdy czuje się dobrze w takiej roli, ale nawet jeśli się jest ekspertem, takim stereotypowym “mrukiem” w sweterku, to trzeba pójść do ludzi, zrobić jakiś workshop czy napisać coś w domu. To już wymaga minimum umiejętności komunikowania się z drugą osobą.

Jak nie zgadzać się z klientem w sposób, powiedzmy, kulturalny?

Ważne jest doświadczenie, które zależy od tego, jak szybko w naszej karierze zaczniemy się kontaktować i przysłuchiwać rozmowom z użytkownikiem. Problemem jest na pewno to, że często programistów od młodych lat kształci się pod kątem znajdowania rozwiązań do prezentowanych problemów. W kontakcie z klientem lepiej wrócić do problemów, skupić się na przeszkodzie i na celach, które użytkownik czy też klient chce osiągnąć, niż na potencjalnym rozwiązaniu. To działa w dwie strony. Bardzo często jest tak, że to klient do nas przychodzi już z gotowym rozwiązaniem i my jesteśmy już tak zorientowani na to rozwiązanie, że nawet nie podejmujemy tematu: “A dlaczego chcesz to zrobić? Jakie są twoje ukryte cele?”. Przechodzimy prosto do rozwiązań i nagle gdzieś na produkcji okazuje się, że to działało tylko dla tego jednego użytkownika, a dla pozostałej setki nie.

Druga sprawa, to umiejętne zadawanie otwartych pytań, bez przeforsowywania swoich pomysłów. To związane troszeczkę z tym, o czym już mówiłem, że jak za bardzo się przywiązujemy do swoich pomysłów i potencjalnych rozwiązań, to mamy tendencję do nakłaniania do nich innych ludzi. Jeśli klient czuje się nakłaniany i nie widzi bezpośrednich benefitów, to oczywiście się na to nie zgodzi.

Co jeszcze mogę doradzić, to definiowanie rozwiązań od ogółu do szczegółu. Czyli definiujemy jakieś kroki, już nawet w postaci prostego MVP (Minimum Viable Product), iteracji, następnych kryteriów akceptacji oraz potencjalnej wartości dla użytkownika. 

Powiedzmy, że udało się już spotkać pierwszy raz z klientem. Czy proponujesz wtedy, że spotkacie się w tym samym gronie za dwa tygodnie, czy przenosisz komunikację na e-mail? A może jakoś to łączysz?

To zależy od kalendarza konkretnych klientów. Wiadomo, są ludzie mniej lub bardziej zajęci. Jeżeli dostępność jest okej, to raczej wolałbym organizować częstsze a krótsze spotkania. Np. od pół godziny do godziny tygodniowo. Żeby za każdym razem być aktualizowanym na bieżąco. Jeżeli jest problem z dostępnością, no to faktycznie organizujemy dłuższe cykle. Jednak wydłużanie wtedy czasu pojedynczego spotkania też wiele rezultatów nie przynosi. 

Email staje się raczej narzędziem komunikowania raportów ze spotkań, niż głównym źródłem komunikacji. Bardzo łatwo jest stracić kontrolę nad tym, co ląduje na naszych skrzynkach w natłoku codziennych zadań.

Co jeśli klient wybiera rzadkie, ale długie spotkania?

Z reguły są to spotkania z komitetem sterującym, raz na kwartał. Trwają pół dnia, czasami nawet cały dzień. Jeśli się da, to organizujemy je na miejscu, twarzą w twarz. To naprawdę jest świetne rozwiązanie, bo nie potrafię wyobrazić sobie siedzenia na telefonie przez cały dzień. To jest droga przez mękę. No i wtedy mamy też okazję bardziej aktywizować uczestników. Co jakiś czas organizujemy gry, które mają pobudzić do komunikacji, kąciki dyskusyjne, korzystamy z pełnego wachlarza narzędzi do prowadzenia różnego rodzaju warsztatów. 

Zaciekawiły mnie gry podczas spotkań. Jak przebiegają?

To jest część mojej profesjonalnej drogi, gdy zacząłem się interesować tematami UX i doszedłem do etapu, w którym byłem szkolony na trenera takich spotkań. Są różne klasy krótkich gier, które mają oddziaływać na konkretne aspekty. Jeśli chcesz pobudzić do kreatywnego myślenia, to możesz uczestnikom pokazać np. taką prostą grę – wymyślasz nazwy bezsensownych produktów (np. nożyczki bezprzewodowe, szampan z celownikiem), dzielisz ludzi na małe podgrupki, dajesz im te nazwy i mają pięć minut na wymyślenie kampanii marketingowej dla takiego produktu. Później muszą ten pomysł zaprezentować i “sprzedać” pozostałym uczestnikom. Powstał nawet online generator do takich nazw produktów.

Jeśli chcemy pobudzić aspekty komunikacyjne i kooperacyjne, to kiedyś wymyśliłem taką zabawę – mamy puzzle 3D, jest w nich jeden metalowy element – puzzel – który się składa z kilku części. Zadanie polega na tym, aby go tak kreatywnie obrócić i rozmontować, żeby dało się go rozłożyć na części pierwsze i złożyć z powrotem. Jeśli to się robi samemu, to nie ma mowy o komunikacji. Jak już ktoś widział jak to zrobić, to poradził sobie w miarę szybko, ale wprowadziłem taką modyfikację: 

Dzielimy się na trzy grupy. Jedna osoba, która ten puzzel rozwiązuje i trzyma go fizycznie w ręku, nie może mówić, a dwie pozostałe osoby mają jej dyktować, co ma robić. I pracujecie nad rozwiązaniem tego problemu. Wtedy okazuje się, jak bardzo komunikacja jest utrudniona przez to, że osoba, która wydaje polecenia, nie jest w stanie dotknąć, zważyć w ręku tego puzzla. Obrócić go i zobaczyć, jak wygląda ten klocek w środku. A ta osoba, która wykonuje polecenia, musi jeszcze zrozumieć, co partner miał na myśli i być może widzi, że to jest bezsensowne, ale nie może nic powiedzieć. Daje nam to świetny pogląd na to z jak wielu kanałów przekazu podświadomie korzystamy rozwiązując problemy.

Wróćmy do tematu umiejętności. W jakim obszarze współpraca z klientem rozwija programistę?

Rozwija głównie umiejętności miękkie, z reguły są to zdolności komunikacyjne. Dzięki takim spotkaniom programista zaczyna rozumieć, że nie może zejść na pewien poziom detali z klientem, bo traci jego uwagę. Jak już rozmawiam ze swoimi developerami, nawet na inne tematy, to staram się im wręcz mówić: „Słuchaj, gdybyś chciał to sprzedać klientowi, nie możesz wejść na ten poziom detali, bo on cię nie będzie słuchał”. 

Drugi aspekt to budowanie asertywności. Jeśli chodzi o najmłodsze pokolenie, oni nie mają problemów z asertywnością, wręcz trzeba ją troszeczkę zmniejszać, ale moje pokolenie – zawsze było wycofane i tej asertywności trzeba było się uczyć. Przynajmniej, ja musiałem. Poza tym cierpliwość i opanowanie.

Co ciebie popchnęło do tego, żeby kontaktować się z klientem i jakie miałeś oczekiwania, jak zostałeś zaproszony na pierwsze warsztaty w tym temacie?

W pewnym momencie uświadomiłem sobie, że na swoim poziomie mógłbym próbować nadążyć za nowinkami technicznymi, ale nigdy nie będę w stanie tego fizycznie zrobić, więc być może lepiej wyjść troszeczkę szerzej. Tak się złożyło, że dostałem projekt, który wymaga komunikacji na wielu poziomach. Byłem wtłoczony w tę rolę, co koniec końców okazało się strzałem w dziesiątkę. Zobaczyłem, jak dobrze to potrafi działać. Że umiem takie spotkanie zorganizować i wypełnić treścią, że potrafię wyjść ze swojej naturalnej roli introwertyka i prowadzić szkolenia, aktywnie angażować ludzi. 

Moje pierwsze spotkania z klientem niekoniecznie wychodziły najlepiej. Taki zabawny przykład – jeszcze na pierwszej linii wsparcia tworzyłem rozwiązanie, które miało pokazywać postęp procesu biznesowego. Wcześniej nie było w ogóle takiej informacji, kiedy proces się zakończy i na czym “wisi”. Nic innego się nie zmieniło, tylko graficzna reprezentacja procesów, na jakim etapie jest użytkownik. Co ciekawe, dostałem feedback, że proces działa szybciej, mimo że tak naprawdę działał kilka milisekund wolniej. I to było moje odkrycie, że jeśli zwaliduję swoje rozwiązania z autentycznym użytkownikiem, może mieć on zupełnie inny obraz, inną percepcję tego rozwiązania. 

Jak młodzi programiści mogą budować swoje kompetencje komunikacyjne?

Polecam wziąć udział w dużym hackatonie. To świetna możliwość i dla juniorów, i dla regularów, bo tam naturalnie – zwłaszcza projekty sponsorowane – mają swoich przedstawicieli od klientów i można bezpośrednio wyczuć, w bardzo skróconej formie, jak ta komunikacja z klientem działa i jak można jej pomóc w rozwoju. 

Polecam także eventy np. na temat komunikacji. Niezbędny okazuje się także koncept pair programmingu, zalecam regular-senior programming. Polega to na tym, że senior jest właśnie taką osobą, która patrzy na rozwiązanie przez pryzmat doświadczenia z użytkownikiem i mówi: „Słuchaj, to nie zadziała z użytkownikiem, ale to już tak”. Ważne jest też angażowanie developera w takie warsztaty. Jeśli mamy budżet, żeby wziąć jeszcze jedną osobę na wizytę u klienta, to dlaczego by nie wziąć developera? Dlaczego Project Manager będzie dawał lepszy feedback klientowi niż developer?

Czyli jest to kwestia skierowana do właścicieli firm, Product Ownerów i Product Managerów. Żeby nie tylko przeznaczać budżet na warsztaty techniczne, lecz także na spotkania z klientami i warto głównie do nich skierować taki komunikat?

Zgadza się. Większość dużych firm IT w tej chwili oferuje nie tylko szkolenia techniczne, lecz także miękkie. Warto umówić się z przełożonym, że jeśli planuje na cały rok szkolenia, że chociaż jedno miękkie z komunikacji by się przydało. Z drugiej strony, dla takiego programisty, który szkolenia realizuje, warto przemyśleć, czy będzie to dla niego przydatne. Bo można pójść na szkolenie i zaraz zapomnieć, ale warto również wykorzystywać te rzeczy, bo dzięki temu się utrwalają.

Piotr Guziorski. Product Manager w Bosch Polska. Ukończył Politechnikę Śląską na kierunku Automatyka i Robotyka, Przetwarzanie informacji w procesach biotechnologicznych oraz Inżynierię oprogramowania na Politechnice Warszawskiej. Na co dzień zaangażowany w duży produkt integrujący dane z rozproszonych systemów. Specjalista od usług sieciowych i technologii danych, orędownik User Experience. Jest bywalcem hackathonów, konferencji oraz meetupów (jako uczestnik i prelegent).

Źródło