Rozwój w zespole: pokaż swoją pracę i pomóż innym

Chcesz być osobą, której zespół powierza ważne zadania. Uczysz się, poprawiasz raporty, pomagasz kolegom. A potem przychodzi rozmowa o rozwoju i nagle trudno powiedzieć, co właściwie zmieniło się dzięki Twojej pracy. Zostaje lista narzędzi i wspomnienie kilku bardzo długich tygodni. Trochę słaby materiał na rozmowę o następnej roli.

Ja zaczynam od prostszego pytania: po czym ktoś pozna, że może na mnie polegać? Potrzebuję umieć wybrać problem, dowieźć uzgodniony fragment i pokazać, jak korzystać z wyniku. Do tego dochodzi pomoc innym, ale taka, która mieści się obok moich zobowiązań. Kalendarz niestety nie rozszerza się od dobrych intencji.

Poniżej przeprowadzę Cię przez fikcyjne zadanie w zespole analitycznym. Sytuacje, wypowiedzi i liczby są przykładami edukacyjnymi, a nie opisem konkretnego klienta czy moich wyników zawodowych. Możesz wykorzystać ten sposób myślenia również w projekcie do portfolio. Ważne, żeby uczciwie nazwać warunki ćwiczenia.

Wybierz problem, przy którym możesz wziąć odpowiedzialność

W naszym przykładzie zespół co tydzień przygotowuje zestawienie zgłoszeń klientów. Dane pochodzą z dwóch eksportów, definicja zamkniętego zgłoszenia bywa różnie rozumiana, a końcowy plik poprawia kilka osób. Kierowniczka chce sprawniej planować pracę na kolejny tydzień. Ty chcesz rozwinąć warsztat i dostać bardziej samodzielne zadanie. Te potrzeby da się połączyć.

Zanim poproszę o cały projekt, ustalam, co dokładnie przeszkadza odbiorcy. Czy raport przychodzi za późno? Czy liczby się nie zgadzają? Czy nikt nie wie, skąd wziął się wynik? Każda odpowiedź prowadzi do innej pracy. Automatyzowanie eksportu nie rozwiąże sporu o to, co właściwie liczymy. Efektowny dashboard potrafi bardzo sprawnie wyświetlać nierozstrzygnięte ustalenia.

Wybrałbym mały zakres: przygotowanie powtarzalnego zestawienia zamkniętych zgłoszeń z opisem definicji i kontrolą kompletności. Potrzebuję odbiorcy, dostępu do właściwych danych, osoby do konsultacji oraz terminu pierwszego przeglądu. Pytam też, z którego dotychczasowego zadania rezygnujemy albo co przesuwamy. Dodatkowa odpowiedzialność musi zmieścić się w realnym tygodniu pracy.

Duży projekt może być dobrą okazją, lecz sama jego nazwa niewiele mówi o rozwoju. Jeżeli przez miesiąc tylko przeklejasz wartości do prezentacji, prestiż inicjatywy nie uczy Cię samodzielnego podejmowania decyzji. Wolę fragment, w którym potrafię wskazać własny wybór, uzasadnić go i przyjąć feedback. O różnych kierunkach takiej odpowiedzialności piszę też w mapie kariery analityka.

Uzgodnij, co oznacza gotowe i kto podejmuje decyzje

Przed rozpoczęciem zapisuję krótki opis rezultatu. W tym przykładzie plik ma obejmować zakończony tydzień, mieć ustaloną definicję zamknięcia i pozwalać odtworzyć wynik. Osobno pokazujemy zgłoszenia bez potrzebnej daty. Odbiorczyni ma sprawdzić, czy układ pomaga planować pracę. Osoba znająca system źródłowy potwierdza znaczenie statusów. Ja odpowiadam za przygotowanie i kontrolę zestawienia.

Nie potrzebuję od razu rozbudowanej macierzy odpowiedzialności. Potrzebuję wiedzieć, kto rozstrzyga wątpliwość. Gdy dwa działy inaczej definiują zamknięcie, nie mogę po cichu wybrać wygodniejszej wersji i uznać sprawy za załatwioną. Przedstawiam różnicę na przykładach, opisuję jej wpływ i proszę właściwą osobę o decyzję. Uzgodnienie trafia do wspólnej notatki.

Podobny punkt wyjścia ma ćwiczenie Roles and Responsibilities w Atlassian Team Playbook: zestawienie oczekiwań wobec ról i wyjaśnienie luk w odpowiedzialności. Traktuję je jako pomoc do rozmowy, nie obowiązkowy firmowy rytuał. W małym zadaniu wystarczą nazwane obowiązki i miejsce na nierozstrzygnięte kwestie.

Dopisuję również, czego pierwsza wersja nie obejmuje. Tutaj będzie to prognozowanie liczby zgłoszeń i ocena pracy pojedynczych osób. Bez tej granicy odbiorca może oczekiwać odpowiedzi, których dane nie pozwalają udzielić. Zapis zakresu chroni też zespół przed sytuacją, w której każda kolejna uwaga staje się automatycznie warunkiem ukończenia pierwotnego zadania. Nową potrzebę można omówić osobno i świadomie ustawić jej priorytet.

Pokazuj postęp wtedy, gdy ktoś może z niego skorzystać

Widoczność pracy zaczynam od uzgodnienia sposobu komunikacji. Przy krótkim zadaniu może wystarczyć aktualizacja po pierwszym sprawdzeniu danych i przed przekazaniem wyniku. Przy dłuższym przyda się stały rytm. Nie zakładam, że kierowniczka codziennie czyta historię zmian pliku. Z drugiej strony pięć wiadomości o kosmetyce wykresu raczej nie pomoże jej podjąć decyzji.

Przykładowa aktualizacja mogłaby brzmieć tak: „Mam zestawienie za zakończony tydzień i sprawdzone identyfikatory zgłoszeń. Część rekordów ma status zamknięty bez daty zamknięcia, więc pokazuję je osobno. Potrzebuję potwierdzenia reguły dla tych przypadków do środy. Po tej decyzji przygotuję wersję do przeglądu”. Obok dodaję link do podglądu i kilka przykładowych rekordów w dozwolonym środowisku.

W takiej wiadomości widać stan, ograniczenie, potrzebę i kolejny krok. Odbiorca może pomóc, zanim opóźnienie stanie się faktem. Samo „pracuję nad raportem” nie daje tej możliwości. Podobnie procent ukończenia niewiele znaczy, jeśli ostatnia niewiadoma może zmienić całą definicję wyniku. Wolę powiedzieć, co już sprawdziłem i jaka decyzja pozostaje otwarta.

Jeżeli wynik jest niepewny, oznaczam go przy samych liczbach. Zastrzeżenie schowane w osobnej wiadomości łatwo zgubić, gdy ktoś przekopiuje tabelę. W podglądzie wpisuję na przykład „wersja robocza, otwarta definicja zamknięcia”. Po rozstrzygnięciu aktualizuję notatkę oraz wynik. W ten sposób pokazuję pracę na tyle wcześnie, żeby skorygować kierunek, a jednocześnie nie udaję gotowości materiału.

Dokumentuj własny wkład i oddzielaj go od wyniku zespołu

Po zakończeniu zadania zapisałbym krótką notatkę: problem, mój zakres, współpraca, rezultat, dowód i ograniczenie. W naszym przykładzie moim wkładem może być przygotowanie transformacji, kontroli identyfikatorów i instrukcji odświeżania. Koleżanka potwierdziła znaczenie statusów, a kierowniczka określiła zastosowanie raportu. Zespół wspólnie dostarczył zestawienie. Każde z tych zdań opisuje inny poziom odpowiedzialności.

W notatce nie wystarczy „usprawniłem raportowanie”. Dodaję link do pliku lub zadania, opis zmiany oraz informację, kto sprawdził rezultat. Jeżeli dopiero powstał prototyp, nazywam go prototypem. Jeżeli ktoś raz otworzył dashboard, nie twierdzę jeszcze, że zespół regularnie go wykorzystuje. Rozróżnienie wykonania, użycia i skutku biznesowego pozwala uniknąć bardzo kreatywnej autobiografii.

Załóżmy teraz dane syntetyczne: ręczne przygotowanie porównywalnego raportu zajmowało 45 minut, a po zmianie zajmuje 20 minut. Przy czterech takich raportach tygodniowo różnica to 100 minut. Jeżeli obsługa rozwiązania wymaga dodatkowych 30 minut tygodniowo, szacowany bilans wynosi 70 minut. To kalkulacja warunkowa dla przyjętego obciążenia, bez dowodu na trwałą oszczędność w każdej sytuacji.

W prawdziwej notatce podałbym sposób pomiaru, liczbę obserwacji i czynności objęte pomiarem. Sprawdziłbym również jakość wyniku oraz pracę przeniesioną na inne osoby. Krótsze przygotowanie pliku może niczego nie poprawić, jeśli odbiorca później dłużej szuka błędów. Bez pomiaru napisałbym uczciwie: „usunąłem ręczne łączenie eksportów; wpływ na łączny czas wymaga obserwacji”. To nadal konkretna zmiana, którą można ocenić.

Pomagaj tak, żeby druga osoba mogła ruszyć dalej

Kolega pyta, dlaczego jego zestawienie pokazuje więcej zgłoszeń. Pierwszy odruch: zabrać plik, poprawić wszystko i odesłać. Szybko, sprawnie, bo przecież umiesz. Tyle że następnym razem prawdopodobnie wróci podobne pytanie, a Ty będziesz już nieformalnym właścicielem kolejnego raportu. Ja wolę zacząć od wspólnego sprawdzenia jednego przypadku.

Proszę o oczekiwany wynik, rzeczywisty wynik i najmniejszy fragment danych, na którym widać różnicę. W przykładzie może się okazać, że połączenie zgłoszeń z historią statusów tworzy kilka wierszy dla jednego identyfikatora. Pokazuję, jak to sprawdzić, a następnie proszę kolegę, żeby sam zastosował kontrolę do reszty danych. Uczymy się rozpoznawać przyczynę, zamiast zapamiętywać pojedynczą poprawkę.

Ustalam też granicę: „Mam teraz dwadzieścia minut na diagnozę. Jeżeli okaże się, że trzeba przebudować model, wpiszmy to do kolejki i ustalmy właściciela”. To przykładowa wypowiedź, którą możesz dopasować do relacji. Pilna awaria może wymagać innej reakcji, zgodnej z zasadami zespołu. Zwykła prośba o pomoc nie powinna jednak bez uzgodnienia przesuwać Twoich pozostałych terminów.

Po wspólnym sprawdzeniu zostaje krótka instrukcja albo przykład. Jeżeli ten sam problem wraca u kilku osób, proponuję omówienie go w zespole. W Working Agreements Atlassian znajdziesz podejście do wspólnego ustalania zasad pracy. Ja wykorzystałbym taką rozmowę do uzgodnienia kanału pytań, oczekiwanego czasu reakcji i sposobu zgłaszania pilnych przypadków. Dzięki temu pomaganie ma czytelne warunki, a dostępność jednej osoby nie zastępuje organizacji pracy.

Zostaw rozwiązanie, które da się przejąć

Przekazanie raportu kończę próbą odtworzenia. Druga osoba dostaje instrukcję, dostęp do dozwolonego źródła i przykład oczekiwanego wyniku. Sprawdza, czy potrafi odświeżyć zestawienie oraz rozpoznać błąd. Ja obserwuję, w którym miejscu musi zapytać o coś, co wcześniej wydawało mi się oczywiste. Tam zwykle jest luka w opisie albo w samym rozwiązaniu.

Instrukcja powinna wyjaśniać, skąd pochodzą dane, jaki okres obejmują i co oznacza pojedynczy rekord. Dodaję kolejność działań, kontrolę liczby zgłoszeń, znane ograniczenia oraz osobę odpowiedzialną za utrzymanie. Nie dokumentuję każdego kliknięcia, jeśli odbiorca zna narzędzie. Opisuję natomiast decyzje, których nie da się wywnioskować z samej tabeli, na przykład przyjętą regułę zamknięcia.

Jeżeli utrzymanie ma zostać przy mnie, potwierdzam ten zakres. Jeżeli przejmuje je inna osoba, ustalamy moment przekazania i sposób zgłaszania usterek. Samo wrzucenie pliku na wspólny dysk nie tworzy właściciela. Przy zmianie źródła danych instrukcja też będzie potrzebować aktualizacji. Warto z góry wiedzieć, kto zauważy, że przestała pasować do rzeczywistości.

Taka praca bywa mniej widowiskowa od prezentacji nowego dashboardu, ale daje konkretny dowód do rozmowy o rozwoju: ktoś potrafi korzystać z rezultatu bez Twojej stałej obecności. Jeżeli planujesz specjalizację techniczną, to również cenna umiejętność. Możliwe kierunki opisuję szerzej w tekście o ścieżkach rozwoju analityka.

Rozwiązuj problemy zespołu i nazywaj ryzyka

W pierwotnym sposobie myślenia o karierze łatwo sprowadzić wszystko do zadowolenia szefa. Ja dopytałbym, jaki problem stoi za jego prośbą. Kierowniczka chce więcej wykresów, bo na spotkaniach wracają pytania o obciążenie. Być może wystarczy doprecyzować jedną miarę i dodać informację o brakujących danych. Zanim dołożę kolejną zakładkę, pokazuję tę możliwość.

Jeżeli widzę ryzyko, zgłaszam je wraz z uzasadnieniem. „W tym zestawieniu zgłoszenie może wystąpić kilka razy, więc porównanie osób będzie mylące. Mogę przygotować podsumowanie zespołu po usunięciu tego problemu”. To przykład sprzeciwu dotyczącego jakości analizy. Nie potrzebuję przy tym oceniać czyjejś inteligencji ani intencji. Rozmowa ma doprowadzić do decyzji o pracy.

W opisie Project Aristotle w Google re:Work wśród czynników związanych ze skutecznością zespołów pojawiają się bezpieczeństwo zadawania pytań, niezawodność oraz jasność oczekiwań. To ustalenia z badania zespołów Google, z ograniczeniami przenoszenia ich na inne organizacje. Nie wynika z nich gwarancja indywidualnego awansu. Dla mnie stanowią użyteczny punkt odniesienia przy rozmowie o codziennej współpracy.

Jeśli każde pytanie kończy się karą albo ośmieszeniem, pojedyncza lepsza notatka może nie wystarczyć. Zapisuję konkretne sytuacje i korzystam z dostępnego, bezpiecznego sposobu zgłoszenia problemu. Nie przypisuję pracownikowi pełnej odpowiedzialności za kulturę całej organizacji. Rozwijanie komunikacji ma sens, lecz otoczenie również musi pozwalać na uczciwe przedstawienie błędu i ograniczeń danych.

Ucz się na zadaniu i zaplanuj małą próbę

Rozwój techniczny wiążę z problemem, który właśnie próbuję rozwiązać. Jeśli ręczne łączenie eksportów powoduje błędy, mogę poćwiczyć odpowiednią transformację i sprawdzić ją na kopii danych przeznaczonej do takiej pracy. Nie przebudowuję produkcyjnego raportowania tylko dlatego, że skończyłem ciekawy kurs. Najpierw porównuję wyniki i proszę o przegląd.

Dobrze postawiony cel nauki mógłby brzmieć: „Chcę samodzielnie wyjaśnić, skąd po połączeniu tabel biorą się dodatkowe wiersze, i przygotować kontrolę”. Wiem wtedy, co ćwiczyć oraz jak sprawdzić postęp. „Muszę ogarnąć cały SQL” jest znacznie mniej użyteczne przy planowaniu najbliższego tygodnia. Szerszy warsztat buduje się z takich konkretnych umiejętności.

Własne pomysły też zaczynam od ograniczonej próby. Proponuję jeden raport, uzgodniony czas pracy i warunek kontynuacji: zgodne wyniki, prostsza obsługa, akceptacja odbiorcy. Jeśli próba nie spełni warunku, zostawiam notatkę z wnioskami i kończę ją bez dorabiania historii sukcesu. Eksperyment może ujawnić, że koszt utrzymania rozwiązania przewyższa korzyść. To przydatna informacja przed większym zobowiązaniem.

Prośba o feedback powinna wskazywać przedmiot oceny. Zamiast „jak mi idzie?” pytam, czy druga osoba potrafi odtworzyć raport i czy moje wyjaśnienie ograniczeń jest zrozumiałe. Odpowiedź przekładam na następną poprawkę. Nie potrzebuję co tydzień nowej technologii, żeby zobaczyć rozwój. Czasami największy postęp polega na tym, że umiem zakończyć pracę, którą wcześniej tylko zaczynałem.

Porozmawiaj o następnym zakresie odpowiedzialności

Na rozmowę o rozwoju zabieram dwa lub trzy konkretne przykłady. Jeden pokazuje samodzielne dowiezienie uzgodnionego zadania, drugi współpracę albo przekazanie wiedzy, trzeci może dotyczyć rozpoznanego ryzyka. Nie muszą być spektakularne. Ważne, żeby dało się sprawdzić mój wkład, rezultat i granice tego rezultatu. Długa lista drobnych aktywności nie zastąpi tej czytelności.

Mówię też, czego chcę spróbować dalej. W naszym przykładzie: „Chciałbym poprowadzić podobne zadanie od zebrania wymagań do przekazania rozwiązania. Jakie umiejętności powinienem jeszcze pokazać i na jakim zadaniu mogę to zrobić?”. To otwiera rozmowę o realnym zakresie. Następnie ustalamy wsparcie, kryteria oraz termin powrotu do tematu. Po spotkaniu zapisuję uzgodnienia.

Większa odpowiedzialność nie musi od razu oznaczać awansu. Warto wyjaśnić, czy jest to czasowa próba, rozwój w obecnej roli, czy przygotowanie do konkretnej zmiany stanowiska. Jeżeli organizacja nie oferuje następnego kroku, potrzebujesz tej informacji do własnej decyzji. Dobre wyniki i pomoc innym dają materiał do rozmowy, ale nie tworzą automatycznie wolnej roli ani obietnicy zmiany warunków.

Na początek proponuję ćwiczenie na dwa tygodnie. Wybierz jedno małe zadanie i uzgodnij jego rezultat. Wyślij jedną użyteczną aktualizację, poproś o konkretny przegląd i doprowadź pracę do przekazania. Na końcu zapisz własny wkład oraz jedną rzecz, którą poprawisz następnym razem. Będziesz mieć coś znacznie bardziej użytecznego niż ogólne przekonanie, że bardzo się starasz: przykład pracy, o którym potrafisz spokojnie i precyzyjnie opowiedzieć.