AI skraca czas pisania kodu, ale nie zwalnia zespołu z ustalenia, co ma powstać i po co. Im szybciej idzie samo wykonanie zadania, tym większą część pracy zajmuje jego przygotowanie: doprecyzowanie problemu, oczekiwanego działania produktu i decyzji, które już zapadły. Dla HR to sygnał, żeby przejrzeć oczekiwania wobec pracowników technicznych. Obok wiedzy technicznej coraz więcej znaczy umiejętność zadawania pytań, wyjaśniania decyzji i dzielenia się wiedzą. Te kompetencje warto uwzględnić w rekrutacji, planach rozwoju i ocenie pracy.

Szybsze pisanie kodu to tylko część pracy

Narzędzia AI potrafią w kilka minut wygenerować kod, nad którym programista pracowałby wcześniej znacznie dłużej. Na pierwszy rzut oka może się wydawać, że zespół po prostu zrobi więcej w tym samym czasie. W praktyce wygląda to trochę inaczej.

Zanim ktokolwiek napisze kod – samodzielnie czy z pomocą AI – zespół musi odpowiedzieć na kilka podstawowych pytań:

• jaki problem rozwiązuje zadanie,
• jak produkt ma działać po zmianie,
• które decyzje już zapadły, a które są jeszcze otwarte.

Jeśli te odpowiedzi nie są jasne, AI nie zatrzyma się i nie dopyta. Uzupełni brakujące informacje własnymi założeniami. Kod może wtedy wyglądać poprawnie, a mimo to rozwiązywać inny problem niż ten, o który chodziło. Jakość wyniku zależy więc między innymi od tego, czy zespół wcześniej jasno określił, czego oczekuje.

Warto tu zwrócić uwagę na jedną rzecz. Wkład w przygotowanie zadania – dobre pytanie, wychwycona sprzeczność, porządnie opisana decyzja – rzadko jest widoczny w statystykach. Nie zamyka się jak zadanie w systemie i nie przekłada się wprost na liczbę dostarczonych funkcji. Jeśli kryteria rekrutacji, ścieżki rozwoju i ocena pracy patrzą głównie na tempo wykonania, ta część pracy może umykać. Dlatego warto sprawdzić, czy procesy HR w Twojej organizacji ją uwzględniają.

Czym jest refinement i dlaczego zyskuje na znaczeniu?

Refinement to rozmowa, podczas której zespół doprecyzowuje zadanie i sprawdza, czy wszyscy rozumieją je tak samo. Odbywa się przed rozpoczęciem realizacji. Uczestniczą w niej zwykle programiści i osoba odpowiedzialna za produkt.

Zespoły pracujące zwinnie planują pracę w sprintach. Sprint to krótki cykl pracy, który trwa zwykle od jednego do kilku tygodni. Na konkretnym przykładzie dobrze widać, jak zmienia się proporcja między przygotowaniem a wykonaniem zadań.

W jednym z zespołów Pragmatic Coders doprecyzowanie zadań zajęło około 30% czasu sprintu. Programiści sami zaczęli prosić o więcej takich rozmów, choć kilka miesięcy wcześniej uważali, że jest ich za dużo. Ważnym elementemrefinementu z AI w tym zespole było wyjaśnienie przez programistę własnymi słowami, co zamierza zbudować, jaki problem rozwiązuje i gdzie widzi ryzyko. Dzięki temu osoba odpowiedzialna za produkt mogła sprawdzić, czy obie strony tak samo rozumieją oczekiwany efekt.

Te 30% to obserwacja z jednego zespołu, a nie norma dla branży. Zespół przewidywał też, że udział przygotowania w sprincie może dalej rosnąć. To jednak prognoza, a nie zmierzony wynik.

Tu łatwo o błędne wnioski. Rosnący udział przygotowania nie oznacza, że rozmowy o zadaniach muszą trwać więcej godzin. Część tej zmiany wynika z tego, że samo pisanie kodu trwa krócej. Jeśli wykonanie się skraca, a przygotowanie zajmuje podobnie dużo czasu, to jego udział w całym cyklu i tak rośnie.

Dla HR ważniejsza od samej liczby jest zmiana nastawienia. Programiści, którzy wcześniej uważali rozmowy o zadaniach za stratę czasu, zaczęli o nie prosić. To pokazuje, że przygotowanie zadania przestaje być dodatkiem do „właściwej” pracy. Staje się jej istotną częścią.

Jak zmienia się praca programisty, osoby odpowiedzialnej za produkt i lidera?

Zmiana nie dotyczy jednej roli. Każda osoba w zespole ma w niej swoje zadanie, a oczekiwania wobec nich warto opisać wprost.

Programista

Programista nie czeka już tylko na gotowy opis zadania. Uczestniczy w doprecyzowaniu rozwiązania. Przed rozpoczęciem pracy potrafi wyjaśnić, co zamierza zrobić i dlaczego wybrał właśnie ten sposób realizacji. Mówi też otwarcie, gdzie widzi ryzyko.

Przed rozpoczęciem realizacji osoba odpowiedzialna za zadanie omawia kilka rzeczy:

• jaki problem rozwiązuje,
• jak ma działać rozwiązanie,
• jak zamierza je wykonać,
• gdzie widzi ryzyko,
• które decyzje już zapadły.

Dla wielu programistów to nowa część obowiązków. Ktoś, kto świetnie pisze kod, nie musi od razu dobrze sobie radzić z opowiedzeniem planu osobie spoza zespołu technicznego.

Osoba odpowiedzialna za produkt

Osoba odpowiedzialna za produkt przekłada potrzebę biznesową na konkretne wymagania dotyczące działania produktu. Nie wystarczy już ogólny opis w rodzaju „użytkownik ma móc łatwiej zapisać zamówienie”. Potrzebne jest określenie, co dokładnie ma się wydarzyć i w jakich sytuacjach.

Druga część tej roli to weryfikacja. Kiedy programista opowiada, co zamierza zbudować, osoba odpowiedzialna za produkt sprawdza, czy proponowane rozwiązanie rzeczywiście odpowiada potrzebie biznesowej.

Lider zespołu

Lider zapewnia czas na pytania i wyjaśnienie wątpliwości przed rozpoczęciem realizacji zadania. Jeśli zespół jest rozliczany tylko z tempa dostarczania, rozmowy o zadaniach będą skracane jako pierwsze.

Lider jasno komunikuje też oczekiwania dotyczące współpracy i odpowiedzialności. Każdy w zespole powinien wiedzieć, kto podejmuje które decyzje i jaki ma udział w przygotowaniu zadania.

Wiedza o produkcie musi być wspólna

Jest jeszcze jedna rzecz, która dotyczy wszystkich ról. Wiedza o produkcie nie może pozostawać wyłącznie w głowie jednej osoby. Powinna być dostępna dla całego zespołu, z jasnym wskazaniem, które informacje są aktualne.

Gdy oczekiwany efekt zna przede wszystkim jedna osoba, pozostali – i narzędzia AI, z których korzystają – działają na domysłach. To ryzyko także z perspektywy HR. Odejście albo urlop tej jednej osoby może zatrzymać pracę zespołu.

Jakie kompetencje zyskują na znaczeniu?

Hasło „komunikatywność” pojawia się w niemal każdym ogłoszeniu o pracę. Niewiele jednak mówi o tym, czego naprawdę oczekujesz. Lepiej opisać konkretne zachowania, które da się zaobserwować w codziennej pracy.

Zwróć uwagę, że żadna z tych umiejętności nie zastępuje wiedzy technicznej. Programista, który dobrze zadaje pytania, ale słabo zna technologię, nie oceni ryzyka rozwiązania. Chodzi o to, żeby obie grupy umiejętności były widoczne w procesach HR, a nie tylko jedna.

Jak HR może wspierać zmianę sposobu pracy z AI?

HR nie odpowiada za wymagania produktu ani za organizację codziennej pracy zespołu. To zadanie osoby odpowiedzialnej za produkt i lidera. Może jednak pomóc określić, czego organizacja oczekuje od pracowników, i stworzyć warunki do rozwoju potrzebnych kompetencji. Poniższe wskazówki wynikają z opisanych zmian w sposobie pracy.

Zaktualizuj kryteria rekrutacji

Wspólnie z liderami technicznymi sprawdźcie, czy obecny proces rekrutacji pozwala ocenić, czy kandydat:

• zadaje pytania, zanim zaproponuje rozwiązanie,
• dostrzega niejasności w opisie zadania,
• potrafi wyjaśnić swoje decyzje.

Dobrym narzędziem jest zadanie z celowo niepełnym opisem. Zamiast oceniać tylko gotowe rozwiązanie, obserwujecie, o co kandydat dopytuje przed jego zaproponowaniem. Ktoś, kto od razu zaczyna pisać kod, i ktoś, kto najpierw pyta o brakujące informacje, pokażą dwa różne sposoby pracy. Warto, żeby kryteria oceny takiego zadania przygotował lider techniczny – on najlepiej wie, które pytania są w danym zespole naprawdę istotne.

Dopasuj działania rozwojowe

Ustal z liderami, jakich umiejętności brakuje ich zespołom. Odpowiedź może być różna w zależności od zespołu. Jednym brakuje osób, które precyzyjnie opisują oczekiwania, innym – nawyku zapisywania ustaleń.

Na tej podstawie możesz wspierać naukę:

• precyzyjnego opisywania oczekiwań,
• uzgadniania rozwiązań z osobami spoza zespołu technicznego,
• przekazywania wiedzy w formie, z której inni mogą korzystać.

Uwzględnij współpracę i dzielenie się wiedzą w ocenie pracy

To miejsce, w którym najłatwiej przeoczyć wkład pracownika. Jeśli ocena pracy opiera się głównie na liczbie wykonanych zadań, pracownik, który poświęcił czas na wyjaśnienie wątpliwości całego zespołu, może wypaść gorzej od kolegi, który w tym czasie zamknął kilka zadań.

Uzgodnij z liderami, jak rozpoznawać i doceniać:

• wkład pracownika w przygotowanie zadań,
• wspieranie innych członków zespołu,
• pracę, której efektem są lepsze ustalenia lub wyjaśnione wątpliwości.

Taka praca nie zawsze ma wymierny wynik. Lider często wie jednak, kto w zespole regularnie wychwytuje problemy, zanim staną się kosztowne. Warto dać mu narzędzie, żeby mógł to wpisać do oceny.

Rozpoznawaj trudności związane ze zmianą roli

Nie każdy pracownik od razu odnajdzie się w nowych oczekiwaniach. Programista zatrudniony kilka lat temu przede wszystkim do pisania kodu może nie wiedzieć, że od teraz oczekuje się od niego także czegoś innego.

W rozmowach z pracownikami pytaj, czy rozumieją nowe oczekiwania i wiedzą, jak je spełnić. Jeśli odpowiedź brzmi „nie do końca”, zaplanuj wsparcie razem z ich przełożonymi. Dzięki temu zmiana sposobu pracy nie zostanie odebrana jako dodatkowy obowiązek, o którym nikt wcześniej nie powiedział.

Najczęstsze pytania

Czy AI zmniejsza zapotrzebowanie na programistów? AI skraca czas pisania kodu, ale nie zwalnia zespołu z ustalenia, co i po co ma powstać. Zmienia się więc raczej to, na czym polega praca programisty, niż to, czy jest potrzebny. Rośnie znaczenie doprecyzowywania zadań i wyjaśniania decyzji.

Czym jest refinement w zespole programistycznym? To rozmowa, podczas której zespół doprecyzowuje zadanie przed rozpoczęciem pracy i sprawdza, czy wszyscy rozumieją je tak samo. Biorą w niej udział zwykle programiści i osoba odpowiedzialna za produkt.

Jakie kompetencje sprawdzać u programisty pracującego z AI? Oprócz wiedzy technicznej: precyzyjne określanie oczekiwanego efektu, zadawanie pytań uzupełniających brakujące informacje, dostrzeganie niejasności, wyjaśnianie decyzji i przekazywanie wiedzy innym.

Jak sprawdzić w rekrutacji, czy kandydat dobrze doprecyzowuje zadania? Daj mu zadanie z celowo niepełnym opisem i obserwuj, o co dopytuje, zanim zaproponuje rozwiązanie. Kryteria oceny warto ustalić z liderem technicznym.

Jak docenić w ocenie pracy wkład w przygotowanie zadań? Uzgodnij z liderami, jak rozpoznawać pracę, której efektem są lepsze ustalenia, wyjaśnione wątpliwości i wsparcie innych członków zespołu. Bez tego ocena opiera się głównie na tempie wykonania, a ta część pracy pozostaje niewidoczna.