AI w zespole: dlaczego patrzę na zadania zamiast nazw stanowisk

Spodziewałem się, że w rozmowach o AI będę bronił sensu pracy programistów i analityków. Tymczasem w rozmowach z firmami zaskoczyło mnie coś innego: przekonanie, że osoby techniczne pozostają potrzebne, a trudniej uzasadnić część ról skupionych na koordynacji. Szczególnie gdy codzienność sprowadza się do przekazywania zadań między ludźmi.

To moja obserwacja i mocna opinia, bez reprezentatywnego badania rynku. Nie wyprowadzam z niej listy zawodów skazanych na zniknięcie. Chcę przyjrzeć się temu, skąd bierze się wartość pracy i dlaczego techniczne podstawy uważam za ważne również wtedy, gdy AI wykonuje coraz więcej czynności.

Od rozmowy z czatem do odpowiedzialności za proces

Dopóki korzystanie z AI polega na zadaniu pytania i przekopiowaniu odpowiedzi do maila, łatwo widzieć w nim narzędzie dostępne dla każdego na podobnych zasadach. Różnice zaczynają mnie interesować przy bardziej złożonej pracy: kilku zadaniach, zależnych wynikach, dostępie do źródeł i konieczności sprawdzenia rezultatu.

Samo rozpisanie projektu na polecenia jest dopiero początkiem. Chcę wiedzieć, które zadanie może ruszyć wcześniej, jakie materiały musi dostać, co będzie potrzebne później i kto rozstrzygnie sprzeczność. Im więcej takiej pracy deleguję, tym bardziej potrzebuję rozumieć cały proces. Inaczej mam dużo aktywności i niewielką kontrolę nad tym, co powstaje.

Dlatego interesuje mnie techniczny zmysł: umiejętność rozłożenia problemu, rozpoznania zależności i zauważenia, że wynik przestał mieć sens. Nie utożsamiam jej z prestiżem stanowiska. Osoba na początku kariery może już ćwiczyć takie myślenie, a doświadczony specjalista może nadal mieć obszary, w których potrzebuje pomocy.

W moim sposobie oceny projektu pytanie brzmi więc: czy potrafię opisać drogę od źródła do rezultatu? Jeśli nie, to szybkie generowanie kolejnych elementów nie rozwiązuje głównej trudności. Najpierw potrzebuję wyjaśnienia brakującego fragmentu. Dopiero potem umiem rozsądnie ustalić, co mogę oddać narzędziu.

Analityk pracuje także przed powstaniem wykresu

Kiedy mówię o pracy analityka, mam przed oczami więcej niż samo szukanie wniosków. W mojej zawodowej perspektywie dużo miejsca zajmują raporty, przepływy danych i przygotowanie warunków, w których raport da się regularnie otrzymywać. To mniej widowiskowe niż prezentacja gotowego dashboardu, ale bardzo konkretne.

Weźmy wymyślony raport sprzedaży. Zanim ktoś zacznie interpretować wykres, muszę wiedzieć, z jakiego źródła przychodzą zamówienia, co oznacza status transakcji i jak traktuję korekty. Chcę też ustalić, czy dane są już kompletne. Ładna wizualizacja przygotowana przed rozstrzygnięciem tych pytań niewiele mi daje.

Właśnie dlatego doceniam rozumienie baz, raportowania i przepływów między systemami. AI może uczestniczyć w pracy, ale ja potrzebuję punktu odniesienia do oceny propozycji. Gdy otrzymam rozwiązanie, chcę umieć powiedzieć, gdzie sprawdzę zgodność z zadaniem i co zrobię, gdy źródła sobie przeczą.

Nazwy ról bywają przy tym mylące. Porządkuję je szerzej w tekście o analityku danych, analityku biznesowym i BI developerze. Tutaj oceniam przede wszystkim rzeczywistą pracę. Nie zakładam, że każda osoba z tym samym tytułem robi to samo i ma identyczny zakres odpowiedzialności.

Przesunięcie zadania i rozstrzygnięcie problemu mają inną wartość

Mam problem z sytuacją, w której poważnie brzmiący opis zarządzania przykrywa zwykłe przekazywanie wiadomości. Ktoś przenosi kartę, przypisuje wykonawcę i pyta o termin, ale nie usuwa przeszkody ani nie pomaga ustalić celu. W takim układzie pytam, co konkretnie wnosi dodatkowy etap.

Jednocześnie łatwo przesadzić w drugą stronę. Uzgodnienie sprzecznych oczekiwań, nazwanie celu albo podjęcie decyzji o rezygnacji z części zakresu może wymagać realnej pracy. Chcę ją widzieć, zamiast z góry odmawiać jej sensu. Moja krytyka dotyczy pustego pośrednictwa, bez względu na stanowisko osoby, która je wykonuje.

Dobrym ograniczeniem mojej oceny jest Scrum Guide z 2020 roku. Product Owner odpowiada tam za maksymalizację wartości produktu, a Scrum Master za ustanowienie Scruma i skuteczność zespołu. Sprowadzenie tych odpowiedzialności do przesuwania kart byłoby uproszczeniem. Ocena konkretnej praktyki i definicja roli wymagają rozdzielenia.

W przykładowym projekcie zapytałbym managera: którą decyzję pomogłeś podjąć, jaki konflikt rozwiązałeś i czego zespół dzięki temu nie musiał robić? Analitykowi zadałbym podobne pytanie o raport. Sam fakt, że każdy był zajęty, jest dla mnie za słabą odpowiedzią.

Wyobraźmy sobie, że odbiorca chce raport na piątek, ale nie ustalono znaczenia sprzedaży. Samo przekazanie terminu do wykonawcy pozostawia problem bez rozwiązania. Osoba koordynująca może natomiast doprowadzić do rozmowy z właściwym odbiorcą, zapisać przyjętą definicję i ustalić zakres pierwszej wersji. Taki wkład umiem nazwać i ocenić. Nie wymaga on udawania, że manager musi samodzielnie zbudować cały raport.

AI może pomóc uporządkować zadania, ale plan trzeba odebrać

W materiale mocno stawiam tezę, że AI dobrze radzi sobie z porządkowaniem zadań. Praktycznie traktowałbym tę możliwość jako coś do sprawdzenia na ograniczonym przypadku. Dałbym opis projektu, znane zależności i poprosił o propozycję kolejności. Potem sprawdziłbym, skąd wzięła się każda istotna zależność.

Dla wymyślonego raportu można zaproponować: najpierw definicje, potem dostępne źródła, przygotowanie danych, kontrola i prezentacja. Taki szkic pomaga rozpocząć rozmowę. Nie rozstrzyga jednak, czy firma ma już gotowe definicje, czy źródła są dostępne i kto może zaakceptować zmianę. To muszę ustalić w konkretnym otoczeniu.

Nie zakładam, że przekonujący plan jest poprawny. NIST w profilu ryzyk generatywnej AI z 2024 roku opisuje ryzyko pewnie przedstawianych fałszywych treści, w tym błędnej argumentacji. Dlatego płynne uzasadnienie kolejności zadań nie zastępuje sprawdzenia, czy zależności rzeczywiście istnieją.

Mogę więc wykorzystać propozycję do rozmowy z zespołem. Chcę wiedzieć, co przyjmujemy, co poprawiamy i kto odpowiada za decyzję. Jeśli nikt nie potrafi tego nazwać, problem pozostaje nawet wtedy, gdy plan powstał bardzo szybko. Narzędzie nie załatwia za mnie ustaleń między ludźmi.

Brak mikrozarządzania nie oznacza braku potrzebnej koordynacji

Znam ze swojego doświadczenia sytuacje, w których zespół techniczny pracował sprawniej podczas nieobecności osoby zarządzającej. Odczytuję to jako sygnał do przyjrzenia się mikrozarządzaniu: dodatkowym uzgodnieniom, przerywaniu pracy i komplikowaniu prostych decyzji. Nie traktuję tego jako eksperymentu dowodzącego, że każdy zespół powinien pozbyć się managera.

W takiej sytuacji zadałbym dwa zestawy pytań. Co przestało nam przeszkadzać? Jakie potrzebne zadania koordynacyjne nadal ktoś wykonywał, nawet bez formalnego tytułu? Być może zniknęła zbędna kontrola, a może część pracy po prostu stała się niewidoczna. Bez sprawdzenia obu rzeczy łatwo wyciągnąć wygodny wniosek.

Samodzielność zespołu wymaga też jasności celu. Chcę wiedzieć, co mogę zdecydować sam, z kim uzgodnić zmianę i kiedy eskalować problem. Jeżeli te granice są czytelne, mogę mniej czasu spędzać na czekaniu. Jeśli ich nie ma, samo usunięcie spotkania nie odpowie na pytanie o odpowiedzialność.

Za sensowny następny krok uznałbym zatem przegląd jednego rodzaju uzgodnień. Sprawdziłbym, do jakiej decyzji prowadzą i kto korzysta z ich wyniku. Dopiero na tej podstawie proponowałbym zmianę. Reorganizacja całego zespołu po jednym udanym tygodniu urlopu szefa byłaby dla mnie zbyt dalekim skokiem.

Junior potrzebuje podstaw i możliwości sprawdzenia wyniku

W materiale porównuję technicznego juniora z osobą, która nie rozumie podstaw analizy. Dostrzegam przewagę pierwszej osoby: ma większą szansę rozpoznać problem i zapytać o właściwy fragment. Chodzi o wiedzę potrzebną przy zadaniu. Sam tytuł zawodowy tej przewagi nie tworzy.

Nie chcę też robić z AI magicznego wyrównywacza doświadczenia. Junior może nie znać wyjątków, o których bardziej doświadczona osoba pomyśli od razu. Dlatego przy ważnym zadaniu zapewniłbym możliwość konsultacji i odbioru pracy. Dostęp do modelu nie jest dla mnie powodem, żeby zostawić początkującą osobę bez wsparcia.

Gdybym dziś układał naukę, łączyłbym podstawy techniczne z objaśnianiem własnych decyzji. Dlaczego wybrałem źródło? Co oznacza wynik? Czego jeszcze nie sprawdziłem? Chcę umieć odpowiedzieć samodzielnie. O organizacji takiej pracy piszę w artykule o kontekście i kompetencjach w pracy z AI.

Do ćwiczenia wybrałbym mały raport na wymyślonych danych, z opisanym źródłem i odbiorcą. Poprosiłbym początkującą osobę, żeby najpierw wyjaśniła zadanie, potem wskazała pytania do modelu, a na końcu opowiedziała, co przyjęła z odpowiedzi. W miejscu, w którym traci możliwość wyjaśnienia wyniku, zatrzymałbym zadanie i wrócił do podstaw. To pozwala mi wskazać konkretny temat do nauki zamiast ogólnie radzić, żeby lepiej poznać AI.

Sprawdź wartość swojej pracy na jednym zadaniu

Wybierz ostatnio ukończone zadanie. Zapisz problem odbiorcy, potrzebne informacje i decyzje, które podjąłeś. Oddziel czynności powtarzalne od miejsc, w których musiałeś coś rozstrzygnąć. Dopisz, jak sprawdziłeś wynik oraz co odbiorca mógł dzięki niemu zrobić. To ćwiczenie można wykonać bez udostępniania komukolwiek firmowych danych.

Potem wskaż jeden fragment, przy którym mógłbyś sprawdzić pomoc AI. Ustal wcześniej warunek odbioru. Może chodzić o uporządkowanie własnych notatek albo wychwycenie niejasności w wymyślonym opisie projektu. Po próbie oceń całą pracę, łącznie z wyjaśnianiem i poprawkami. Sama szybkość otrzymania odpowiedzi niewiele rozstrzyga.

Jeżeli pracujesz głównie koordynacyjnie, zapytaj też osobę wykonującą zadanie, czego brakowało jej w przekazanym opisie. Jeżeli jesteś po stronie technicznej, sprawdź z odbiorcą, czy dostarczony wynik odpowiedział na jego pytanie. W obu przypadkach szukałbym jednej konkretnej poprawki na następny raz. Takie ćwiczenie mówi mi więcej niż porównywanie stanowisk wyłącznie po nazwach.

Tak wracam do początkowej obserwacji. Bardziej niż nazwa stanowiska interesuje mnie to, czy rozumiem proces i pomagam doprowadzić go do użytecznego wyniku. W tym widzę kierunek własnego rozwoju. Do przewidywania, kto dokładnie straci pracę, nadal brakuje mi podstaw.