Współpraca analityka: 6 zachowań, które utrudniają pracę

Najgorszy analityk w zespole? Łatwo rzucić taką etykietę po nieudanym projekcie. Znacznie trudniej powiedzieć, co konkretnie poszło źle i czego potrzebujemy przy następnym zadaniu. A właśnie od tego zależy, czy rozmowa cokolwiek poprawi. Samo nazwanie kogoś trudnym we współpracy zostawia sporo miejsca na domysły i niewiele miejsca na działanie.

Ja wolę przyjrzeć się zachowaniu. Czy ktoś obiecał wynik bez sprawdzenia swoich możliwości? Czy zmienił definicję bez uzgodnienia? Czy zostawił rozwiązanie, którego nikt inny nie potrafi uruchomić? Takie pytania pozwalają ocenić konkretną pracę. Nie wymagają zgadywania osobowości, intencji ani tego, jak człowiek zachowuje się poza biurem.

Poniżej omawiam sześć problemów, które możesz zauważyć również u siebie. Przykłady rozmów i zadań są fikcyjne, przygotowane do ćwiczenia współpracy. Nie są historiami kandydatów z moich rekrutacji. Przyjmijmy, że nasz zespół przygotowuje cykliczny raport aktywnych klientów. Technicznie brzmi prosto. Wystarczy jednak kilka przemilczanych ustaleń, żeby każdy zaczął liczyć coś innego.

1. Deklarujesz kompetencje bez określenia granic

Wszechstronny analityk może być bardzo przydatny. Problem widzę wtedy, gdy zdanie „znam SQL, Pythona i Power BI” zastępuje rozmowę o rodzaju doświadczenia. Ktoś mógł samodzielnie utrzymywać raport albo tylko odtworzyć ćwiczenie z kursu. Oba doświadczenia coś znaczą, ale nie dają tej samej podstawy do powierzenia mu odpowiedzialności za cykliczne rozwiązanie.

W naszym przykładzie deklarujesz, że przygotujesz cały proces. Dopiero przed terminem wychodzi, że nigdy nie konfigurowałeś odświeżania w środowisku zespołu. Sam brak doświadczenia jest do omówienia. Kosztowna staje się informacja przekazana za późno: nikt nie zaplanował konsultacji, a odbiorca czeka na automatyczny raport. Zespół musi teraz rozwiązać jednocześnie problem techniczny i problem terminu.

Ja opisałbym kompetencje na poziomie zadania: „Potrafię przygotować i sprawdzić zapytanie. Publikację raportu robiłem z pomocą, a konfigurację odświeżania potrzebuję przejść z osobą znającą nasze środowisko”. To pozwala podzielić pracę i zaplanować sprawdzenie. Nie wymaga publicznego katalogu wszystkich słabości. Wystarczy uczciwa informacja o granicy istotnej dla tego konkretnego zobowiązania.

Przy ocenie drugiej osoby proszę o przykład wyboru i jego uzasadnienie. Co zrobiła samodzielnie, co sprawdził ktoś inny, gdzie potrzebowała pomocy? Nie zamieniam płynnej opowieści w dowód kompetencji. W tekście o sprawdzaniu umiejętności analityka rozwijam podejście oparte na zadaniu. Tutaj najważniejsze jest to, żeby obietnica miała zakres, który obie strony rozumieją podobnie.

2. Mieszasz negocjowanie warunków z ignorowaniem ustaleń

Pytanie o wynagrodzenie, pracę zdalną albo godziny dostępności jest normalnym elementem rozmowy o współpracy. Nie wyciągam z niego wniosku o czyimś charakterze. Możesz potrzebować określonych warunków i możesz zrezygnować z oferty, która ich nie spełnia. Firma również powinna jasno powiedzieć, jaki zakres i jakie warunki rzeczywiście oferuje, zanim obie strony zainwestują czas.

Problem, który chcę tu nazwać, dotyczy przyjmowania zobowiązania, a potem jednostronnego zmieniania jego zasad. Uzgodniłeś termin przeglądu raportu, ale nie przychodzisz i nikogo nie informujesz. Potwierdziłeś przekazanie instrukcji, lecz uznajesz później, że dokumentowanie jest poniżej Twoich kompetencji. To konkretne zachowania do wyjaśnienia. Preferencja pracy z domu nie mówi o nich nic.

Dobra reakcja zaczyna się od sprawdzenia, czy ustalenie było jasne i wykonalne. Może termin kolidował z innym zadaniem, a dwie osoby równolegle ustawiały priorytety. Może instrukcja miała powstać po przeglądzie, ale ktoś zrozumiał odwrotnie. Zanim nazwę brak odpowiedzialności, odtwarzam uzgodnienie. Jeśli zabrakło komunikatu, mówię właśnie o brakującym komunikacie i jego skutku dla pracy.

Na przyszłość zapisuję właściciela zadania, moment przekazania i sposób zmiany planu. Przy kolizji terminów proszę o decyzję, zamiast obiecywać obu odbiorcom to samo okno w kalendarzu. Dotrzymywanie ustaleń obejmuje również wczesne powiedzenie, że nie da się ich spełnić. Udawanie dostępności do ostatniej chwili jest mało pomocne, nawet gdy wynika z bardzo dobrych chęci.

3. Zostawiasz innych bez informacji potrzebnej do działania

Ktoś może mówić mało na spotkaniach i zostawiać doskonałe notatki. Ktoś inny mówi dużo, a po rozmowie nadal nie wiadomo, co ustalono. Dlatego nie używam introwersji ani nieśmiałości jako skrótu oceny współpracy. Sprawdzam, czy informacja dociera do właściwej osoby we właściwym momencie i czy można z niej skorzystać bez odgadywania brakującego kontekstu.

Przy raporcie aktywnych klientów potrzebna jest odpowiedź na prostą rzecz: co oznacza aktywność? Jeżeli masz otwartą wątpliwość i zatrzymujesz ją w głowie, inni mogą równolegle budować wykresy na innym założeniu. Problemem jest brak widocznego ustalenia. Rozwiązaniem może być krótka notatka z dwoma wariantami, przykładami klientów i pytaniem do osoby odpowiedzialnej za definicję.

W praktyce proponuję uzgodnić kanał aktualizacji, oczekiwany czas reakcji i sposób zgłaszania pilnej blokady. Pomocnym odniesieniem jest Working Agreements z Atlassian Team Playbook, czyli wspólne ustalanie zasad współpracy. Zamiast zakładać, że każdy czyta czat cały dzień, umawiamy się, gdzie trafiają decyzje i kiedy potrzebna jest rozmowa na żywo.

Jeśli wypowiedź na spotkaniu się plącze, można poprosić o zapisanie wyniku i pytania po chwili namysłu. Nie wyciągam z jednego stresującego momentu wniosku o całym warsztacie. Jednocześnie pisemny kanał również wymaga konkretu: „potrzebuję potwierdzenia definicji do środy, bo bez niej nie zakończę porównania”. Format ma wspierać przekazanie informacji, a nie stać się dodatkowym testem towarzyskiej sprawności.

4. Zamykasz zadanie bez sprawdzenia zastosowania wyniku

Raport może spełniać opis techniczny i nadal prowadzić odbiorcę do błędnej decyzji. Wyobraź sobie, że liczysz aktywnych klientów według logowania w aplikacji. Odbiorca traktuje wynik jako liczbę płacących klientów, bo nie widzi definicji. Zapytanie działa, zadanie ma status ukończone, a dwie osoby używają tej samej liczby w zupełnie innym znaczeniu. Taki rozdźwięk warto wykryć przed publikacją.

Nie oczekuję, że analityk sam podejmie wszystkie decyzje biznesowe. Oczekuję jednak pytania, co mierzymy i do czego będzie użyty wynik. Jeśli zakres ogranicza się do technicznego eksportu, także można to zapisać. Wtedy odbiorca wie, czego eksport jeszcze nie rozstrzyga. Problem zaczyna się, kiedy ograniczenie znika, a techniczna poprawność dostaje w prezentacji szersze znaczenie niż rzeczywiście ma.

Ja przy odbiorze pokazuję jedno zdanie z wnioskiem i proszę drugą osobę o opisanie następnego kroku. Jeśli jej interpretacja wykracza poza dane, doprecyzowujemy opis. W przykładzie może wystarczyć zmiana tytułu wykresu i dopisanie definicji. Czasem trzeba wrócić do zapytania, bo do zamierzonej decyzji potrzebne są płatności, a nie logowania. Lepiej odkryć to na przeglądzie małej próbki.

Zainteresowanie kontekstem nie oznacza zgody na każdy kolejny pomysł. Nowy podział albo inna definicja mogą zmienić zakres i termin. Potrzebna jest jawna decyzja, co robimy teraz. O rozbieżnych definicjach i odpowiedzialności szerzej piszę w artykule o problemach z danymi w firmach. To dobre uzupełnienie rozmowy, gdy konflikt powtarza się między działami.

5. Utrzymujesz całą wiedzę we własnej głowie

Ekspert, który dobrze rozumie skomplikowany proces, jest dla zespołu cenny. Uzależnienie każdej drobnej poprawki od jego obecności staje się jednak problemem organizacyjnym. Jeśli tylko jedna osoba zna kolejność uruchomienia raportu, jej urlop zmienia się w wydarzenie infrastrukturalne. Tego nie rozwiąże kolejne zdanie „w razie czego napisz do mnie”. Potrzebne jest przekazanie wiedzy w formie możliwej do użycia.

Przy naszym raporcie zostawiłbym definicję aktywnego klienta, źródła, okres, sposób odświeżenia i podstawowe kontrole. Opisałbym też, dlaczego wykluczamy określoną grupę oraz co zrobić, gdy kontrola nie przejdzie. Kod może pokazać, jak działa filtr. Powodu biznesowego często nie da się z niego uczciwie odtworzyć. Właśnie te decyzje najłatwiej zgubić podczas przekazania pracy.

Sprawdzeniem dokumentacji jest próba użycia przez drugą osobę. Daję jej instrukcję oraz dostęp do uzgodnionego środowiska i obserwuję, gdzie musi dopytać. Nie podpowiadam od razu każdego kroku, bo wtedy sprawdzamy moją dostępność zamiast instrukcji. Po próbie uzupełniamy konkretne luki. To może być krótki opis w zadaniu, bez budowania encyklopedii wszystkich kliknięć w narzędziu.

Zespół musi też zaplanować czas na przekazanie. Jeśli nagradza wyłącznie tempo nowych funkcji, a dokumentację zawsze odkłada, samotny ekspert bywa skutkiem takiego systemu. W rozmowie sprawdzam więc zarówno zachowanie osoby, jak i warunki pracy. Uzgadniamy mały fragment do przekazania, odbiorcę i termin próby. Odpowiedzialność za rozwiązanie nie powinna opierać się na niekończących się prywatnych wiadomościach.

6. Wybierasz narzędzie przed rozpoznaniem ograniczeń

Lubię mieć narzędzia, w których pracuję sprawnie. Głęboka specjalizacja pozwala rozwiązywać problemy, które dla innych są trudne. Kłopot pojawia się, gdy każda potrzeba automatycznie staje się argumentem za moim ulubionym rozwiązaniem. Wtedy łatwo pominąć dostępność licencji, kompetencje odbiorcy, sposób utrzymania albo fakt, że wynik ma być użyty tylko raz.

Wyobraź sobie, że raport aktywnych klientów jest potrzebny co tydzień i ma go odświeżać zespół znający obecny zestaw narzędzi. Nowa technologia może coś poprawić, ale wymaga osoby do utrzymania. Zanim ją zaproponuję, sprawdzam konkretną trudność: czy problemem jest czas przetwarzania, ręczne kopiowanie, błędy definicji czy brak dostępu do wyniku? Każdy powód może prowadzić do innego rozwiązania.

Porównałbym dwie małe próby na tych samych danych i tych samych warunkach odbioru. Sprawdzamy poprawność, odtworzenie, obsługę błędu i możliwość przejęcia pracy. Jeśli nie mierzyłem czasu, nie dopisuję procentowej przewagi. Jeśli prototyp działa tylko na moim komputerze, zapisuję ten warunek. Narzędzie wygrywa wtedy, gdy ma uzasadnienie w zadaniu, a nie dlatego, że lepiej wygląda w moim portfolio.

Bywa też odwrotnie: obecny zestaw naprawdę nie spełnia potrzeb i warto zaproponować zmianę. Dobrze opisany problem, dowód z próby oraz koszt przejścia pomagają o niej rozmawiać. Nie trzeba tłumić technicznej ciekawości. Trzeba oddzielić eksperyment edukacyjny od zobowiązania, które później będzie utrzymywał cały zespół. Ten drugi przypadek wymaga wspólnego uzgodnienia odpowiedzialności i granic.

Powiedz, co się wydarzyło i jakiej zmiany potrzebujesz

W feedbacku przydaje mi się podejście Situation-Behavior-Impact opisane przez Center for Creative Leadership: wskazanie sytuacji, zachowania i skutku, a następnie pytanie o intencję. To pomoc w uporządkowaniu rozmowy. Nie traktuję tego jako gwarancji rozwiązania konfliktu ani dowodu, że już rozumiem motywację drugiej osoby.

Przykładowy komunikat: „Przy środowym przekazaniu raportu nie było definicji aktywnego klienta. Dwie osoby odczytały wynik inaczej i musieliśmy wrócić do obliczeń. Jak rozumiałeś zakres opisu przy oddaniu?”. Dopiero po odpowiedzi ustalamy zmianę: przy następnej wersji definicja będzie przy wykresie, a odbiorca potwierdzi ją przed publikacją. Mamy konkretny element do sprawdzenia przy kolejnym zadaniu.

Jeżeli sam dostajesz ogólny komentarz „słabo się komunikujesz”, poproś o sytuację i oczekiwany komunikat. Być może chodzi o spóźnione zgłoszenie blokady, a może o nieczytelny opis wyniku. Każdy przypadek wymaga innej praktyki. Nie musisz przyjmować wszystkich interpretacji bez dyskusji. Warto natomiast ustalić, jaki fakt obie strony widzą tak samo i co będzie oznaczać poprawę.

Unikam publicznego wyliczania czyichś porażek jako rozrywki dla zespołu. Rozmowa o konkretnym błędzie może być spokojna i stanowcza jednocześnie. Jeśli zachowanie powtarza się mimo uzgodnień, zapisuję fakty i zwracam się do osoby odpowiedzialnej za pracę zespołu. Sam artykuł ani gotowa formułka nie zastępują ustalonych zasad reagowania na poważne problemy we współpracy.

Sprawdź, czy oceniasz powtarzalny problem

Pojedynczy błąd dostarcza informacji o konkretnej sytuacji. Nie wystarcza mi do opisania kogoś jako osoby, która zawsze zawodzi. Przy powracającym problemie zbieram porównywalne przypadki: jakie było uzgodnienie, co się wydarzyło, kiedy druga strona dostała informację i jaki był skutek. Oddzielam to, co widziałem, od tego, co usłyszałem w korytarzowej opowieści. Ocena oparta na plotce nie stanie się rzetelniejsza po wpisaniu jej do formularza.

Sprawdzam też zmianę warunków. Jeśli wcześniej raport działał, a potem doszły nowe źródła bez czasu na przegląd, sam spadek jakości nie dowodzi utraty umiejętności. Potrzebujemy zobaczyć, co zmieniło obciążenie i czy zakres odpowiedzialności był nadal realny. To nie usuwa potrzeby poprawienia błędów. Pomaga jednak wybrać działanie, które dotknie ich przyczyny, zamiast tylko zwiększać presję na kolejną osobę.

Po uzgodnieniu poprawki daję jej szansę zadziałać w porównywalnym zadaniu. Zapisujemy oczekiwany rezultat i moment sprawdzenia. Jeżeli wcześniej brakowało definicji przy wykresie, oceniamy obecność i zrozumiałość definicji. Nie dokładamy po fakcie nowego kryterium, którego nikt nie znał. Takie podejście ułatwia również zauważenie postępu, a bez tego feedback szybko zamienia się w katalog dawnych potknięć.

Zrób przegląd własnych nawyków na prawdziwym zadaniu

Wybierz jedno niedawno zakończone zadanie. Otwórz jego opis, rezultat i historię uzgodnień. Sprawdź, czy odbiorca mógł zrozumieć zakres Twojej samodzielności, termin i ograniczenia. Poszukaj miejsca, w którym inna osoba musiała zgadywać. Zamiast przyznawać sobie ocenę za bycie dobrym członkiem zespołu, zapisz brakującą informację albo decyzję. To materiał, z którym da się pracować.

Następnie wybierz jedną zmianę na najbliższe zadanie. Może to być krótka instrukcja odświeżania, wcześniejsza próbka wyniku albo jawne zgłoszenie braku doświadczenia z danym elementem. Uzgodnij z drugą osobą, po czym pozna poprawę. Na przykład: będzie w stanie odtworzyć raport bez prywatnej wiadomości. Nie potrzebujesz obietnicy przemiany całej osobowości w ciągu tygodnia.

Po zakończeniu próby sprawdź również koszt. Czy nowa notatka pomogła, czy tylko powieliła dane w trzech miejscach? Czy spotkanie wyjaśniło definicję, czy można było załatwić to jednym komentarzem? Dobra współpraca powinna ułatwiać wykonanie pracy. Jeśli nowy rytuał nie pomaga, zmień jego formę. Sam fakt, że coś nazwaliśmy procesem, nie czyni tego automatycznie użytecznym.

Przy rozmowie rekrutacyjnej możesz zastosować podobną zasadę: opisać konkretny fragment projektu, granice własnej odpowiedzialności i sposób sprawdzenia wyniku. Osoba rekrutująca może poprosić o wyjaśnienie decyzji oraz krótki handover na syntetycznym przykładzie. To daje więcej materiału niż ocena, kto brzmiał najpewniej. Ja chciałbym wiedzieć przede wszystkim, czy po wspólnej pracy zostanie wynik, który potrafimy zrozumieć i dalej rozwijać.